Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2022-03-28T16:46:30.020Z
Answers: 2022-03-28T16:53:18.343Z
Answers: 2022-03-28T16:53:18.343Z
Answers: Evan Carroll
Body: <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>
  
Tags: <gitlab>
Title: What happens when two jobs produce artifacts with conflicting locations?
UserDisplayName: Evan Carroll
ThreadText: # 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
  
  1. `build` creates a distribution
  2. `semantic-release` which bumps the version
  3. `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.
  
  
  ---
  
  