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.
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:
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.
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.
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.
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.
