Search code examples
dockergitlabgitlab-cigitlab-ci-runner

Build and deploy on the same dockerized runner


I'd like to build and deploy a static website (Middleman) using a self-hosted GitLab instance and CI runners, all running on a local Docker engine. It works fine if I do both build and deploy in one job, however, I'm wondering if it's possible to split it in two jobs as the official examples suggest:

cache:
  paths:
    - _vendor

build:
  stage: build
  tags:
    - ruby-3.0
  only:
    - master
  script:
    - apk update
    - apk add build-base nodejs git
    - command -v bundler || { gem install bundler; }
    - bundle config set --local path '_vendor/'
    - bundle install
    - MM_ENV=production bundle exec middleman build

deploy:
  stage: deploy
  tags:
    - ruby-3.0
  only:
    - master
  variables:
    PROJECT_HANDLE: "$CI_PROJECT_NAMESPACE-$CI_PROJECT_NAME"
  script:
    - mkdir -p /deployment/$PROJECT_HANDLE
    - cd /deployment/$PROJECT_HANDLE
    - mkdir -p current
    - rm -rf next
    - mkdir next
    - cp -pr $CI_PROJECT_DIR/build/* next
    - rm -rf previous
    - mv current previous
    - mv next current

Problem with this, you'd have to pass the build result as artifacts to the deploy and each jobs spins up it's own Docker container.

Is there a way to have two stages use the same container, say, the first (build) stage selects the image by tag and spins up the container and passes it to the second (deploy) stage?

Thanks for your hints!


Solution

  • Currently, it's not possible to run two jobs in the same container. The gitlab-runner will spin up a new contianer for each job in a pipeline, and will destroy it after the job completes. You can run them on a single runner however, so a downloaded Docker image can be reused. There are some benefits to working this way however, including parallel jobs in a single stage each with their own workspace, and a clean starting point for each and every job (no artifacts left over that could cause unexpected side effects).

    Passing gitlab Artifacts between jobs and stages works quite well, even though it spins up a new container.