Version 2.1 config & "Build processing" enabled, but everything runs as 2.0

Build Environment
1

circleci CLI version: 0.1.5245+5896baa

When I use the root-level key version: 2.1, circleci config validate fails locally as well as on circleci.com. When I change the version to 2, the config will validate (despite using the root-level executor tag that shouldn’t be valid in 2.0).

I believe my root problem is that I can’t get it to run the build on 2.1. Secondarily, I cannot validate the config locally against 2.1 despite having the very latest version of the CLI.

To confirm, I do have “Build Processing” enabled for the project. I have toggled it on and off, it’s almost like the value is being ignored entirely.

Thanks for any help you can provide.

2

Are you getting an error when you push the 2.1 config to CircleCI? I do not know offhand if the CLI supports 2.1 yet, but the UI should give you some feedback if there’s an error in the config.

If the build processor processes the config correctly then you should see the original config commented out at the bottom of the Configuration tab in a given job.

The major difference between 2.0 and 2.1 is in 2.1 the configuration is generated after processing your orbs and yaml anchors.

3

I played around with it quite a bit more and it would seem that the UI is just lying to me, until you mentioned:

in 2.1 the configuration is generated after processing your orbs and yaml anchors.

It is beginning to make sense – it generates a 2.0 configuration file and runs that one. So it’s not that the UI is totally lying to me, it did run a 2.0 configuration, it’s just that it processed a 2.1.

I had a ton of difficult-to-comprehend processing errors, so I started whittling it down until it worked. I knew it must have been working because top-level executor worked fine. I had a lot of issues using “shorthand” Strings over Mappings, so I converted them over and it worked.

Bad :-1:

            - restore_cache:
                - v1-repo-{{ .Environment.CIRCLE_SHA1 }}

Good :+1:

            - restore_cache:
                  name: Restoring repo cache # not required but I added for my own benefit
                  keys:
                      - v1-repo-{{ .Environment.CIRCLE_SHA1 }}

I had directly copied some of these broken things from documentation, so I was thrown off that they were issues.

It’s working as intended now. Now I just need to read up on how to use “workspaces” over “cache”.

1 Like
4

Thanks for the clear example, @erodewald. We’re definitely aware that the error messages can be tricky when there are bugs in the shape/syntax. The tricky thing is the set of potential errors is very large, and the YAML semantics of our config have lots of purposefully-free-form structures. Today we lean on errors coming out of the schema checking machinery, which can be unsatisfying for things like this. This is on our radar as part of the pain of configuring projects. Hopefully it’s evident that we have made some progress in this area (config processing exception errors), but we have more we want to get to. We’ve also talked about getting some kind of linter, which would help catch things like this upstream. I can say that in general it’s always good to use the CLI to validate config early, at least saving round-trips to find these kinds of errors.

2 Likes
5

The CLI validation has been a huge boon to me. It has made me confident that running another build on circleci would not be wasted time. :+1:

Thanks for elaborating on the schema errors. Great idea about the linter, too. I’ll admit that I did a quick search for an IntelliJ plugin for a circleci linter. :wink:

2 Likes
6

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