<p>I'm going to take an opinionated approach based on the <a href="https://12factor.net" rel="nofollow noreferrer">12 factor app pattern</a></p>
<p>Typically, stages should execute a function, with predictable inputs and outputs.</p>
<p>If stage 3 executes the function &quot;compute next version&quot; and the output of that function is &quot;The next version is the same as the previous version&quot;, then even if there is no version change, the stage has successfully executed it's function. Again, the inputs and outputs are predictable.</p>
<p>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 <strong>build</strong>, but the same <strong>version</strong>. This could happen if for example you change the environment or configuration it's deployed into. As the 12factor app puts it:</p>
<blockquote>
<p>The twelve-factor app uses strict separation between the build, release, and run stages.
<a href="https://12factor.net/build-release-run" rel="nofollow noreferrer">https://12factor.net/build-release-run</a></p>
</blockquote>
<p>So your publish function <em>should</em> deliver a new artifact, with the <strong>same</strong> version, but different build metadata (<em>ie</em> pipeline execution number, date, <em>etc</em>.)</p>
<p>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.</p>

CC BY-SA 4.0
2022-03-30T05:37:30.160Z
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
CC BY-SA 4.0
2022-03-30T05:40:23.307Z
Not only so I disagree, but so does the semver spec and semantic release. See https://semver.org/#spec-item-10
Bruce Becker
CC BY-SA 4.0
2022-03-30T05:45:11.183Z
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
CC BY-SA 4.0
2022-03-30T06:44:29.027Z
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
CC BY-SA 4.0
2022-03-30T05:22:58.920Z
2022-03-30T05:22:58.920Z
Bruce Becker
<p>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.</p>
<p>For example let's assume I have a pipeline with four stages,</p>
<pre><code>[Build] -&gt; [Test] -&gt; [Version Bump] -&gt; [Publish]
</code></pre>
<p>Now, let's assume the <code>Version Bump</code> may or may not bump the version number which means the <code>Publish</code> stage may or may not run. In order to model this in GitLab we would normally fail the <code>Version Bump</code> stage at the point that we know the <code>Publish</code> should not run. But one of my co-workers does not like the term &quot;fail&quot; here.</p>
<p>Given the above circumstance, is it a normal flow to have a stage pass unconditionally, and to have a subsequent stage conditionally execute?</p>
<p>Or, is the pipeline failing just the way in which a pipeline should conditionally terminate?</p>

<gitlab>
Should a pipeline fail if early termination is desired?
Evan Carroll
# Should a pipeline fail if early termination is desired?

(Asked by: username_0 on 2022-03-30)

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?

**Tags:** gitlab


---

## 1 answers

### Answer by username_1 on 2022-03-30. Score: 1

I'm going to take an opinionated approach based on the [12 factor app pattern](https://12factor.net)

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.

> **Comments:**
> **username_0**: 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?  
> **username_1**: Not only so I disagree, but so does the semver spec and semantic release. See https://semver.org/#spec-item-10  
> **username_0**: 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.  
> **username_1**: 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.  

---

