1

Normally a pipeline breaks down into stages such that each stage has one or more jobs. In order to stop the pipeline from running conditionally, you simply fail that stage of the pipeline.

For example let's assume I have a pipeline with four stages,

[Build] -> [Test] -> [Version Bump] -> [Publish]

Now, let's assume the Version Bump may or may not bump the version number which means the Publish stage may or may not run. In order to model this in GitLab we would normally fail the Version Bump stage at the point that we know the Publish should not run. But one of my co-workers does not like the term "fail" here.

Given the above circumstance, is it a normal flow to have a stage pass unconditionally, and to have a subsequent stage conditionally execute?

Or, is the pipeline failing just the way in which a pipeline should conditionally terminate?

Evan Carroll
  • 2,091
  • 3
  • 22
  • 65

1 Answers1

1

I'm going to take an opinionated approach based on the 12 factor app pattern

Typically, stages should execute a function, with predictable inputs and outputs.

If stage 3 executes the function "compute next version" and the output of that function is "The next version is the same as the previous version", then even if there is no version change, the stage has successfully executed it's function. Again, the inputs and outputs are predictable.

Similarly for the fourth stage (Publish). If you have built the software, but the version hasn't changed, you still have a new artifact. It has a different build, but the same version. This could happen if for example you change the environment or configuration it's deployed into. As the 12factor app puts it:

The twelve-factor app uses strict separation between the build, release, and run stages. https://12factor.net/build-release-run

So your publish function should deliver a new artifact, with the same version, but different build metadata (ie pipeline execution number, date, etc.)

In either case, no you do not need to fail the pipeline (nothing has broken, no changes are necessary) and yes you should execute the last stage, which should implement the actual deployment strategy you use.

Bruce Becker
  • 3,573
  • 4
  • 19
  • 40
  • Unfortunately, that won't work with npm unless we unpublish the last version. NPM itself doesn't support build metadata, and the automatic CICD tool (semantic-release) doesn't support it either. Moreover, even if they did support it semver is clear that build numbers can't determine version precedence. So it's hard to reconcile that theory with the ecosystem we're working with. But the answer is still useful because that text is probably what he read too and it's nice to have an idea of where he got this. Any other things come to mind to solve this? – Evan Carroll Mar 30 '22 at 05:37
  • Not only so I disagree, but so does the semver spec and semantic release. See https://semver.org/#spec-item-10 – Bruce Becker Mar 30 '22 at 05:40
  • I'm sorry, just so we're not talking past each other, what am I supposed to take away from that? It says Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. That means that if (1) semantic-release was patched to do this and (2) we did produce two versions 1.0.0+build1 and 1.0.0+build2 and (3) npm allowed us to publish both, then when the client requested version 1.0.0 there would be no mechanism for deciding which +build1 or +build2 to provide, they're both equal. – Evan Carroll Mar 30 '22 at 05:45
  • My apologies for the curt comment - was just in a rush. My point was not that a well-defined upgrade path is available, but that those two builds are distinct. Your deployment strategy should be the function that determines what to deploy, not the version comparison. A deploy should have a well-defined version ie, if the pipeline is +build2 then install +build2. – Bruce Becker Mar 30 '22 at 06:44