Previously valid 2.0 config now breaking without any related changes reported in the changelog

Here is my .circleci/config.yml file:

As you can see it has version: 2 right at the top and if you look at the history you can see that it has been on version 2 for months. However over the last couple days there have been two instances of its configurations no longer working. I suspect this is related to the 1.0->2.0 cutover that has been happening. I will acknowledge that looking at the docs now, it seems like we had a few configuration options which didn’t get transferred over from 1.0 to 2.0.

The first build that broke because of a CircleCI change without a change in our configuration was: It timed out after 10 minutes of no output, however we had no_output_timeout: 18000. The docs do specify that it should be a string like 10m or 1h, but giving it a number of seconds had been working for months prior to that build.

The second build that broke because of a CirlceCI change without a change in our configuration was: This build is complaining about an extraneous key in the machine part of our configuration: pre. I went back and checked the docs and sure enough, it was in the 1.0 docs (I had to use the wayback machine to figure that out) but not in the 2.0 docs. However that config has been on version 2 for months and has had those pre blocks without it breaking the config so my question is why are these things breaking now?

I migrated off of 1.0 months in advance of the cutover so I was pretty sure that I shouldn’t have seen any different behavior after it happened. I’ve tested my 2.0 config hundreds of times now, but never ever received any warning that it was invalid in any way. Additionally because the config validation script is broken as I reported months ago here: CircleCI Local CLI doesn’t validate config file’s workflows, I couldn’t even run a validation to turn up any errors like this.

How was I supposed to protect myself from this? Sure you can say that I should have read all the docs more carefully and realized that my config had accidentally brought some features over from 1.0 that it shouldn’t have, but I tested it before I merged it into my project. Generally I assume that if I test a config and it works that I have followed the documentation to a degree that I won’t get bitten by implementation changes like this.

In conclusion it’s hard to pinpoint at exactly what the bug happened here. However I would appreciate a way to validate that my config is following 2.0 specifications before any additional changes are released to CircleCI that causes it to suddenly start following the spec strictly in ways that my config doesn’t conform to.

Ok so it looks like didn’t actually fail. There was just a UI issue where it didn’t show the job starting so I assumed the message about the pre block had failed the job.

There’s reports of messages coming up with a 1.0 warning even for situations where this does not apply. I don’t think I have seen them myself, but see this:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.