Should I struggle for minimalistic context in GitLab CI jobs?

Question

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.

Answer 1

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