Is it normal that my 2.0 config files are much more verbose and less readable than 1.0?



I’ve been using CircleCI since the 1.0 beta version, and have convinced many people and organisations to use it over the years.

One good reason for that was speed, but by far the most important was the low barrier to entry: the config syntax was super readable and inferences made a fantastic job.

I’ve now migrated two important projects from 1.0 to 2.0, and am in the process of migrating a whole organisation. The builds are indeed even faster. It is impressive to get feedback under a minute after having pushed!
However, the syntax reads much more verbose than version 1.0. I had several coworkers wondering if it was normal that our config files sizes were multiplied by 2 to 5 after migration. See for example this PR.

I liked how 1.0 syntax had very few identifiers, and the few that had to be there were clearly named, making the config file read like literate programming. When I read a 2.0 config file, I feel that is needlessly repetitive and it forces me to scroll and to ignore many groups of lines of run: name: command when what I really want is just to list commands.

I have also been surprised by how less lax the parser is. For example, the cache does not work if I don’t explicitly define keys and paths. The “workflows” part forces me to list all task dependencies while I have already listed them in the order they’re supposed to run.

Unfortunately, the documentation is not complete enough to make sure that I am doing things correctly. It seems from the example apps that I am not mistaken in the amount of work it takes to get things to run properly. If that is indeed the case, I am quite disappointed in the developer experience of CircleCI 2.0.

Do you have any plans to evolve the syntax to support a less verbose version of the config file? Are there any strong limitations in the 1.0 syntax that would prevent supporting it, possibly with simply additional properties?



Hi @halfer. Thank you for your message.

As you have worked in a busy, commercial software environment, you know as well as me how the strongest drive to send a feedback report is often frustration. Yesterday, I have given in to that frustration and wrote what was indeed a poorly phrased message that came out as needlessly aggressive.

I have edited the whole message so that it focuses on actionable problems and reflects my experience better.

Thank you for holding me to better standards :slight_smile: :+1:


In case you’ve not seen it, there is an ideas page if you’d like to capture some of those actionable points.


I think YAML anchors help:


We do have work being done on this front actively. I’d welcome a chance to talk about our plans with you. Email me at nathan@ (our domain)