"Undefined: undefined" in "parsed and validated config"

https://config.travis-ci.com/explore fails with undefined: undefined error at this config.

version: ~> 1.0
//os: linux
dist: bionic

language: ruby
cache: bundler
rvm:
- 2.7

jobs:
  include:
    - stage: test
      name: "Tests"
      script:
        - cp config/database.example.yml config/database.yml
        - bundle exec rake db:setup RAILS_ENV=test
        - bundle exec rails spec
    - name: "Audit"
        - bundle exec bundle-audit check --update
        - bundle exec brakeman -z

    - stage: deploy
      script: skip
      deploy:
        - provider: script
          script: .cicd/travis_deploy.sh
          on:
            branch: master

Missing script: in Audit section

Is it still possible to show the exact error in this case?

This means the input is not valid YAML (and thus could not be parsed).

Some other online YAML parsers, e.g. YAML Parser Online, give a more specific message that shows where specifically the syntax error is.

Why it is not possible to show where the input became invalid YAML? Any guess is better than undefined: undefined.

This isn’t valid YAML.

I recommend trying: https://config.travis-ci.com/explore, or what @native-api suggested.

For one the first two lines would cause syntax issues:

version: ~> 1.0
//os: linux

@Montana thanks for reply, but you’re not being attentive to both mine and @native-api replies in this thread. :smiley:

In addition the first two lines do not cause the parser failure mentioned in the title.

It is possible. The code for the config explorer is at travis-yml/explore.html at f25fae51bc8aaab4d0792c6f14d5e26435f2a9ec · travis-ci/travis-yml · GitHub . You can submit a pull request that would replace that with an error message from parser.

1 Like

Missing script: in Audit section

The merit to the question seems to be confusing, if it’s bad .yaml it’s bad .yaml, here’s a version of your .travis.yml, that I rewrote in ~2 minutes, that gave me extremely verbose outputs, which I’ve gladly attached to my response, I’ve also attached screenshots, one is the Travis Build Explorer, and another gives Valid YAML, given of course there’s no actual .sh (bash scripts) to go with the .travis.yml currently given, it’s not going to build in a real env as far as syntax goes, the one I made seems good.

os: linux
dist: bionic
cache: bundler
jobs:
  include:
    - name: Tests
      script:
        - cp config/database.example.yml config/database.yml
        - bundle exec rake db:setup RAILS_ENV=test
        - bundle exec rails spec
      stage: test
    - name: Audit
    - bundle exec brakeman -z
    - bundle exec bundle-audit check --update
    - deploy: 
      script: skip
      stage: deploy
    - branch: master
      provider: script
      script: .cicd/travis_deploy.sh
      
language: ruby
rvm:
  - "2.7.0"

The lint command in the Travis CLI has gone through substantial changes recently, I recommend you also trying that for more verbose outputs. You can use -q to suppress any output, and -x to have it set the exit code to 1 if there are any warnings, for even more flexibility, example:

travis lint -qx || echo ".travis.yml does not validate"

Secondarily, you can always pipe the content into it:

echo "foo: bar" | travis lint
Warnings for STDIN:
[x] unexpected key foo, dropping
[x] missing key language, defaulting to ruby

I would take a look here for more information on travis-lint via the Travis CLI.

1 Like

You’ve missed the point of the initial post again. I’ve already fixed the config myself before writing the post, so I wonder if you use some kind of ML system that helps to write support answers?

While that doesn’t prevent the cause, I guess fixing config for users who can complain is cheaper than switching .yaml parser on experimental server. Anyway, I appreciate the screens and explanations.

Hey @abitrolly,

Having a parser with more verbose outputs (although that exists) is not a bad idea, as everything can always be improved - I’m not arguing that point.

I always understood the foundation of the post, but again I would encourage you try using lint as there was a lot of progress made with lint in late 2020, if you’re comfortable using the Travis CLI tool.

I’ll take compliment you think I’m a robot. I’ll be here if you run into any other issues with Travis to make sure every build turns out to your liking.

Thanks,
Montana Mendy
Travis CI Staff

Why would the CLI lint tool use different parser and linting logic than experimental linting service, that still calls some server side API?

When running travis lint, it works by talking to the API end point POST /lint with required payload. Most of the time you can record the payload and the actual return value from POST https://api.travis-ci.com/lint.

So you can just use curl with various arguments like -d, -X or -s, and get the return values that way. This is what I’ve always done, and it works really smoothly for me.

And which API end point will be triggered if I use https://config.travis-ci.com/explore ?

So which error have you got when giving the config from the initial post to travis lint?

travis list?

travis lint. Fixed.

From what I can tell, the requests come from the following (when using explore):

POST /v1/parse

When looking over the Travis network waterfall, this confirms that it’s not calling /lint but rather /parse:

PUT (you could also use in curl) as you know is an alternative endpoint to the POST with parameter, to make it work well with tools like curl ( curl -T .travis.yml api.travis-ci.com/lint ). The request body can contain the YAML file directly.

2 Likes

So which outputs have you got when giving the config from the initial post to both of these endpoints?

I saved config as Y, followed you advice.

And got nothing useful.

$ curl -T Y api.travis-ci.com/lint 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>openresty</center>
</body>
</html>
 22   733  100   168    0     0    504      0 --:--:-- --:--:-- --:--:--   504
$ curl -L -T Y api.travis-ci.com/lint
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   565    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   565    0     0  100   565      0    654 --:--:-- --:--:-- --:--:--   654Sorry, we experienced an error.

request_id:d5358861d84700f2416404e241556ca2
100   642  100    77  100   565     82    601 --:--:-- --:--:-- --:--:--  1026

Run something like:

curl -s -X POST  https://api.travis-ci.com/lint
{"lint":{"warnings":[]}}
curl -s -X POST -d "language: ruby" https://api.travis-ci.com/lint
{"lint":{"warnings":[]}}

You’ll see the outputs below of essentially a blank .travis.yml file I made and tested it on.

What it gives for the problematic config that is the topic of this thread? And how does it compare to another API?

Imprint