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):


    • The default behavior (requires no extra code and actions for this option to work).


    • 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:


    • The deploy job explicitly has no access to anything unnecessary.


    • 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.

New contributor
Himura is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your use case is very simple, so relying on artifacts is probably sufficient and as you said the default behavior.

That being said, you should probably be cautious using 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:

    key: "$CI_COMMIT_REF_SLUG"
      - deployment.spec.config

  stage: build
    - build something

  stage: deploy
    GIT_STRATEGY: none
    - 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.

Your Answer

Himura is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.