2

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.

2

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.

2
  • 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"?
    – Himura
    Apr 12 at 10:38
  • 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!
    – zm31
    Apr 13 at 12:51

Your Answer

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.