<h2><a href="https://gitlab.com/gitlab-org/gitlab/-/issues/324412" rel="nofollow noreferrer">Bug #324412</a></h2>
<p>With the bug, basically the rule of thumb is this,</p>
<blockquote>
<p>A job can rely on an artifact produced by a previous job only so long as no jobs previous to that one produced the same artifact.</p>
</blockquote>
<p>The bug report suggests using <a href="https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html" rel="nofollow noreferrer"><code>dependencies</code></a> to only download specific artifacts.</p>

CC BY-SA 4.0
2022-03-28T16:46:30.020Z
2022-03-28T16:53:18.343Z
2022-03-28T16:53:18.343Z
Evan Carroll
<p>In my GitLab CI log I pipeline with three stages</p>
<ol>
<li><code>build</code> creates a distribution</li>
<li><code>semantic-release</code> which bumps the version</li>
<li><code>publish</code></li>
</ol>
<p>The problem occurs in <code>publish</code>. Sometimes I see the version unbumped. You can see here that <code>semantic-release</code> has the higher number 148288 and it's running BEFORE <code>build</code> which overwriting the files. This means this job results in failure,</p>
<pre><code>Downloading artifacts for semantic-release (148288)...
Downloading artifacts from coordinator... ok        id=148288 responseStatus=200 OK token=xFzfAzW6
Downloading artifacts for build (148285)...
Downloading artifacts from coordinator... ok        id=148285 responseStatus=200 OK token=zxTTXZoA
</code></pre>
<p>But sometimes the same pipeline elsewhere is succeeding,</p>
<pre><code>Downloading artifacts for build (113579)...
Downloading artifacts from coordinator... ok        id=113579 responseStatus=200 OK token=Cfqjv8bG
Downloading artifacts for semantic-release (113665)...
Downloading artifacts from coordinator... ok        id=113665 responseStatus=200 OK token=GAyN8S9M
</code></pre>
<p>Notice on this one the <code>build</code> job comes before <code>semantic-release</code>. That means the older artifacts are replaced. What happens if the artifact in <code>semantic-release</code> and <code>build</code> conflict by path? Is this defined?</p>

<gitlab>
What happens when two jobs produce artifacts with conflicting locations?
Evan Carroll
# What happens when two jobs produce artifacts with conflicting locations?

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

In my GitLab CI log I pipeline with three stages

build creates a distribution
semantic-release which bumps the version
publish

The problem occurs in publish. Sometimes I see the version unbumped. You can see here that semantic-release has the higher number 148288 and it's running BEFORE build which overwriting the files. This means this job results in failure,
Downloading artifacts for semantic-release (148288)...
Downloading artifacts from coordinator... ok        id=148288 responseStatus=200 OK token=xFzfAzW6
Downloading artifacts for build (148285)...
Downloading artifacts from coordinator... ok        id=148285 responseStatus=200 OK token=zxTTXZoA

But sometimes the same pipeline elsewhere is succeeding,
Downloading artifacts for build (113579)...
Downloading artifacts from coordinator... ok        id=113579 responseStatus=200 OK token=Cfqjv8bG
Downloading artifacts for semantic-release (113665)...
Downloading artifacts from coordinator... ok        id=113665 responseStatus=200 OK token=GAyN8S9M

Notice on this one the build job comes before semantic-release. That means the older artifacts are replaced. What happens if the artifact in semantic-release and build conflict by path? Is this defined?

**Tags:** gitlab


---

## 1 answers

### Answer by username_0 on 2022-03-28. Score: 0 | Accepted answer

## [Bug #324412](https://gitlab.com/gitlab-org/gitlab/-/issues/324412)

With the bug, basically the rule of thumb is this,

> A job can rely on an artifact produced by a previous job only so long as no jobs previous to that one produced the same artifact.

The bug report suggests using [`dependencies`](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html) to only download specific artifacts.


---

