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?