<p>To paraphrase:</p>
<blockquote>
<p>Is there a way to have <em>(a job)</em> pass regardless of whether the <em>(something has changed)</em>, and to have <em>(another job)</em> run conditionally if <em>(something was actually changed)</em>?</p>
</blockquote>
<p>The first part (run a job whether something changes or not) can be done by either changing the script so that it returns a zero exit code (success), even if something hasn't changed (which can be interpreted as &quot;fail&quot;), or you can continue the pipeline regardless of whether that job has failed or not. This is typically done with the <code>allow_failure</code> keyword on <a href="https://docs.gitlab.com/ee/ci/jobs/job_control.html#rules-examples" rel="nofollow noreferrer">gitlab jobs</a>.</p>
<p>If you're using <code>semantic-release</code>, the decision to cut a new release is done by default with the <a href="https://github.com/semantic-release/commit-analyzer/" rel="nofollow noreferrer"><code>commit-analyzer</code> plugin</a>,  which analyses every commit in the change to determine, according to your release policy, whether a new version is required.</p>
<p>In your particular case you're dealing with version numbers. So the version changes, publish. Else, do not publish. So a common trick is to compare the <code>nextVersion</code> (the version you have computed in this pipeline) with the existing tags on the repo or published versions of the artifact to determine whether <code>nextVersion</code> &gt; <code>latestVersion</code>.</p>
<p>If <code>nextVersion</code> &gt; <code>latestVersion</code> -&gt; publish</p>
<p>else exit 0</p>

CC BY-SA 4.0
2022-03-30T07:28:00.037Z
2022-03-30T07:28:00.037Z
Bruce Becker
<p>This is a follow up to <a href="https://devops.stackexchange.com/q/15709/18965">Should a pipeline fail if early termination is desired?</a>. In that question, I'm asking about best practices and whether this request is sound. In this, I just need to know how best to get it done.</p>
<hr />
<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. Is there a way to have the <code>Version Bump</code> pass <em>regardless</em> of whether the number was bumped, and to have Publish run conditionally if the version was bumped?</p>

<gitlab>
Can I create a pipeline stage which unconditionally passes but one in which a subsequent stage conditionally runs?
Evan Carroll
# Can I create a pipeline stage which unconditionally passes but one in which a subsequent stage conditionally runs?

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

This is a follow up to Should a pipeline fail if early termination is desired?. In that question, I'm asking about best practices and whether this request is sound. In this, I just need to know how best to get it done.

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. Is there a way to have the Version Bump pass regardless of whether the number was bumped, and to have Publish run conditionally if the version was bumped?

**Tags:** gitlab


---

## 1 answers

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

To paraphrase:

> Is there a way to have *(a job)* pass regardless of whether the *(something has changed)*, and to have *(another job)* run conditionally if *(something was actually changed)*?

The first part (run a job whether something changes or not) can be done by either changing the script so that it returns a zero exit code (success), even if something hasn't changed (which can be interpreted as "fail"), or you can continue the pipeline regardless of whether that job has failed or not. This is typically done with the `allow_failure` keyword on [gitlab jobs](https://docs.gitlab.com/ee/ci/jobs/job_control.html#rules-examples).

If you're using `semantic-release`, the decision to cut a new release is done by default with the [`commit-analyzer` plugin](https://github.com/semantic-release/commit-analyzer/), which analyses every commit in the change to determine, according to your release policy, whether a new version is required.

In your particular case you're dealing with version numbers. So the version changes, publish. Else, do not publish. So a common trick is to compare the `nextVersion` (the version you have computed in this pipeline) with the existing tags on the repo or published versions of the artifact to determine whether `nextVersion` > `latestVersion`.

If `nextVersion` > `latestVersion` -> publish

else exit 0


---

