Answers: <p>Your use case is very simple, so relying on <code>GIT_STRATEGY=fetch</code> is probably sufficient and as you said the default behavior.</p>
  <p>You should be cautious using <a href="https://docs.gitlab.com/ee/ci/yaml/README.html#artifacts" rel="nofollow noreferrer">artifacts</a> unnecessarily as they are uploaded to the gitlab server.</p>
  <p>The answer to your question generally depends on a few things, like the size of your repository, network connection, runner executor type, and so on. One option is to configure a cache (in this case at the pipeline level and for the deploy just set the <code>GIT_STRATEGY=none</code>:</p>
  <pre><code>default:
    cache:
      key: &quot;$CI_COMMIT_REF_SLUG&quot;
      paths:
        - deployment.spec.config
  
  build:
    stage: build
    script:
      - build something
  
  deploy:
    stage: deploy
    variables:
      GIT_STRATEGY: none
    script:
      - push-deployment ./deployment.spec.config
  </code></pre>
  <p>An added benefit here, depending on your build process, is the possibility of caching your dependencies when running multiple pipelines against the same branch. Note that you can only cache files relative to the project build directory.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-04-12T10:38:03.897Z
Answers: Thanks for your answer. The first sentence is not clear, did you mean "relying on **GIT_STRATEGY=fetch** is probably sufficient and as you said the default behavior"?
Answers: Himura
Answers: CC BY-SA 4.0
Answers: 2021-04-13T12:51:42.820Z
Answers: I swear it sounded correct in my head. I edited the answer. That is, in fact, what I meant. What I was getting at was to keep it simple. At the end of the day, I would choose what produces the fastest, reproducible, pipelines. If that means using artifacts because it's faster to ship 1 config file that way vs fetch the whole repo so be it. Another example being, if the gitlab server is hosted in cloud A connected to cloud B with a limited throughput vpn connecting them, a local cache may be a no brainer. Thanks!
Answers: zm31
Answers: CC BY-SA 4.0
Answers: 2021-04-10T23:07:35.483Z
Answers: 2021-04-13T12:52:25.003Z
Answers: 2021-04-13T12:52:25.003Z
Answers: zm31
Body: <p>I'm designing a build &amp; deploy pipeline for our project. We have two jobs:</p>
  <ul>
  <li><code>build</code> -- builds a docker image with our app and pushes it to a container registry.</li>
  <li><code>deploy</code> -- communicates with an orchestrator, which deploys the new version.</li>
  </ul>
  <p>There's one detail that I'm not sure about. Which choice is better:</p>
  <ol>
  <li>Get the full repository in the <code>deploy</code> job, while I need only one static config (deployment spec.).</li>
  <li>Use artifacts to pass the required config file from <code>build</code> job to <code>deploy</code> job, and set <code>GIT_STRATEGY</code> to <code>none</code>.</li>
  </ol>
  <p>These two options differ in the <code>deploy</code> job environment:</p>
  <ol>
  <li><p>The <code>deploy</code> has access to the same context as <code>build</code> (full repository):</p>
  <p><strong>Pros</strong>:</p>
  <ul>
  <li>The default behavior (requires no extra code and actions for this option to work).</li>
  </ul>
  <p><strong>Cons</strong>:</p>
  <ul>
  <li>The environment in <code>deploy</code> job is dirty.</li>
  <li>The true context of the <code>deploy</code> job is implicit.</li>
  <li>Someone could misuse it in the future.</li>
  </ul>
  </li>
  <li><p>The <code>build</code> job publishes an artifact with the required config for the <code>deploy</code> job:</p>
  <p><strong>Pros</strong>:</p>
  <ul>
  <li>The <code>deploy</code> job explicitly has no access to anything unnecessary.</li>
  </ul>
  <p><strong>Cons</strong>:</p>
  <ul>
  <li>Need to configure the <code>deploy</code> job not to fetch the repository.</li>
  <li>Need to configure the <code>build</code> job to publish the artifact.</li>
  <li>Need to configure the <code>deploy</code> job to consume the artifact.</li>
  <li>The artifact always contains an unchanged file from the repository (I'm afraid that I misuse artifacts in that case).</li>
  </ul>
  </li>
  </ol>
  <p>Please, help me choose.</p>
  
Tags: <continuous-integration><gitlab><deployment><continuous-deployment><build-pipeline>
Title: Should I struggle for minimalistic context in GitLab CI jobs?
UserDisplayName: Himura
ThreadText: # Should I struggle for minimalistic context in GitLab CI jobs?
  
  (Asked by: username_0 on 2021-04-07)
  
  I'm designing a build & deploy pipeline for our project. We have two jobs:
  
  * `build` -- builds a docker image with our app and pushes it to a container registry.
  * `deploy` -- communicates with an orchestrator, which deploys the new version.
  
  There's one detail that I'm not sure about. Which choice is better:
  
  1. Get the full repository in the `deploy` job, while I need only one static config (deployment spec.).
  2. Use artifacts to pass the required config file from `build` job to `deploy` job, and set `GIT_STRATEGY` to `none`.
  
  These two options differ in the `deploy` job environment:
  
  1. The `deploy` has access to the same context as `build` (full repository):
  
     **Pros**:
  
     * The default behavior (requires no extra code and actions for this option to work).
  
     **Cons**:
  
     * The environment in `deploy` job is dirty.
     * The true context of the `deploy` job is implicit.
     * Someone could misuse it in the future.
  2. The `build` job publishes an artifact with the required config for the `deploy` job:
  
     **Pros**:
  
     * The `deploy` job explicitly has no access to anything unnecessary.
  
     **Cons**:
  
     * Need to configure the `deploy` job not to fetch the repository.
     * Need to configure the `build` job to publish the artifact.
     * Need to configure the `deploy` job to consume the artifact.
     * The artifact always contains an unchanged file from the repository (I'm afraid that I misuse artifacts in that case).
  
  Please, help me choose.
  
  **Tags:** continuous-integration, gitlab, deployment, continuous-deployment, build-pipeline
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-04-10. Score: 2 | Accepted answer
  
  Your use case is very simple, so relying on `GIT_STRATEGY=fetch` is probably sufficient and as you said the default behavior.
  
  You should be cautious using [artifacts](https://docs.gitlab.com/ee/ci/yaml/README.html#artifacts) unnecessarily as they are uploaded to the gitlab server.
  
  The answer to your question generally depends on a few things, like the size of your repository, network connection, runner executor type, and so on. One option is to configure a cache (in this case at the pipeline level and for the deploy just set the `GIT_STRATEGY=none`:
  
  ```
  default:
    cache:
      key: "$CI_COMMIT_REF_SLUG"
      paths:
        - deployment.spec.config
  
  build:
    stage: build
    script:
      - build something
  
  deploy:
    stage: deploy
    variables:
      GIT_STRATEGY: none
    script:
      - push-deployment ./deployment.spec.config
  
  ```
  
  An added benefit here, depending on your build process, is the possibility of caching your dependencies when running multiple pipelines against the same branch. Note that you can only cache files relative to the project build directory.
  
  > **Comments:**
  > **username_0**: Thanks for your answer. The first sentence is not clear, did you mean "relying on **GIT_STRATEGY=fetch** is probably sufficient and as you said the default behavior"?  
  > **username_1**: I swear it sounded correct in my head. I edited the answer. That is, in fact, what I meant. What I was getting at was to keep it simple. At the end of the day, I would choose what produces the fastest, reproducible, pipelines. If that means using artifacts because it's faster to ship 1 config file that way vs fetch the whole repo so be it. Another example being, if the gitlab server is hosted in cloud A connected to cloud B with a limited throughput vpn connecting them, a local cache may be a no brainer. Thanks!  
  
  ---
  
  