One of the nice aspects of the CircleCI UI is that each build and test command has a deliberate section. When inspecting a build, it’s easy to find a particular step’s output without searching through a huge log.
However this presents a dilemma for a project which aspires to have a one-command build:
CircleCI can be configured to use the one command. Unfortunately the nice UI is thus rendered moot.
Or, CircleCI can be configured to not use the one command, and instead run the underlying steps individually. The one command inevitably drifts from what CircleCI is doing. circle.yml gets updated to do a new thing without also updating the one command. Or some change is introduced which works for circle.yml but does not work for the one command, introducing a regression that is not tested by CI.
One specific example: I have some projects that are built as debian packages. The one command to build them is
debuild. This takes care of building the project, testing the build, and packaging it. Do I run just
debuild in CircleCI? Or do I run a multitude of steps to attempt to replicate what
A resolution would be to have some in-band signaling the build process can emit to communicate to CircleCI, “I am starting the next step.” Something like:
#!/bin/bash echo '*** CircleCI: building frontend' grunt echo '*** CircleCI: building backend' make
CircleCI then splits the output on lines matching
/^\*\*\* CircleCI: (.*)/ and then uses
$1 as the description for that step.