diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index fc427dcd76f4d8834db29749213e54c6626d43e7..5572134fbb9a2d7f4bcb661752ab029dca3bdb53 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -33,102 +33,3 @@ build_kaniko_command:
# * Kaniko depends on the Docker image repositories supporting schema2 (https://docs.docker.com/registry/spec/manifest-v2-2/), both for pulling and pushing, so it will not work otherwise. As of July 2019, this is the case with quay.io. Ref https://github.com/moby/buildkit/issues/409
-# Using Kaniko to make multi-stage builds
-# --------------------------------------
-
-# This is useful when in the process of creating an image, part of the files created are not needed in the final image.
-# For example, a go file with several module dependencies that will be later compiled into a single binary. With this method only
-# the compiled binary is copied to the image that is pushed to the registry. If done without multi staged builds, to obtain the same result, several GitLab stages would have been necessary, and the binary must have been passed using artifacts. This is a much simpler solution.
-build_kaniko_command multistage build:
- stage: build
- variables:
- # To push to a specific docker tag other than latest(the default), amend the --destination parameter, e.g. --destination $CI_REGISTRY_IMAGE:$CI_BUILD_REF_NAME
- # See https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#variables-reference for available variables
- IMAGE_DESTINATION: ${CI_REGISTRY_IMAGE}:latest
- image:
- # We recommend using the CERN version of the Kaniko image: gitlab-registry.cern.ch/ci-tools/docker-image-builder
- name: gitlab-registry.cern.ch/ci-tools/docker-image-builder
- entrypoint: [""]
- script:
- # Prepare Kaniko configuration file
- - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- # Build and push the image from the Dockerfile at the root of the project.
- - /kaniko/executor --context $CI_PROJECT_DIR/multistage_builds --dockerfile $CI_PROJECT_DIR/multistage_builds/Dockerfile --destination $IMAGE_DESTINATION
- # Print the full registry path of the pushed image
- - echo "Image pushed successfully to ${IMAGE_DESTINATION}"
-
-# Using privileged runners
-# ------------------------
-
-# If you want to use DinD for your Docker-build jobs, you can use our privileged shared
-# GitLab-runners. This allows to directly build the image yourself as per https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-workflow-with-docker-executor
-build docker image with dind:
- stage: build
- tags:
- - docker-privileged
- # Use specific version of the official docker client image (as well as the docker-in-docker image) as recommended by
- # https://about.gitlab.com/2019/07/31/docker-in-docker-with-docker-19-dot-03/
- image: docker:19.03.1
- services:
- # To obtain a Docker daemon, request a Docker-in-Docker service
- - docker:19.03.1-dind
- # Note about internal IPs Clash
- # If the internal private network assigned to the dind service clashes with any service/host used on the job,
- # you can specify a different IP subnet to avoid the clash. Useful command to inspect the assigned IP range
- # is `docker network inspect bridge`.
- # To effectively assign a different IP subnet, replace the previous service definition with the following:
- # services:
- # # To obtain a Docker daemon, request a Docker-in-Docker service
- # - name: docker:19.03.1-dind
- # # Add to the dockerd command a specific bridge Ip, in this case the range 10.200.0.1/24 (to be adapted)
- # command: ["--bip=10.200.0.1/24"]
- variables:
- # As of GitLab 12.5, privileged runners at CERN mount a /certs/client docker volume that enables use of TLS to
- # communicate with the docker daemon. This avoids a warning about the docker service possibly not starting
- # successfully.
- # See https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
- DOCKER_TLS_CERTDIR: "/certs"
- # Note that we do not need to set DOCKER_HOST when using the official docker client image: it automatically
- # defaults to tcp://docker:2376 upon seeing the TLS certificate directory.
- #DOCKER_HOST: tcp://docker:2376/
- script:
- - docker info
- - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
- - docker build --pull -t "$CI_REGISTRY_IMAGE" .
- - docker push "$CI_REGISTRY_IMAGE"
-
-# Features
-# * Allows your job to have access to the host, as it runs in privileged mode
-# * Allows to use docker-build directly
-
-# Limitations
-# * Privileged runners take around 1-2 minutes to spawn a VM for your job and do not cache Docker-images
-# * These runners will not be available during Openstack Nova API downtime
-
-
-# DEPRECATED Docker-build
-# ------------------------
-
-# For backwards compatibility, we still support the following Docker-build jobs, but this is now decrepated
-# Please use the previous CI job type of jobs instead
-deprecated_build:
- stage: build
- tags:
- - docker-image-build
- script: "echo" # unused but this line is required by GitLab CI
- # Uncomment this section and add the variables you need if you want to
- # push your image to a different Docker registry than gitlab-registry.cern.ch
- # or you want to customize the build process of your image
- #variables:
- #TO: your.registry.example.com/your_image # where to push resulting image. Default, the GitLab registry
- # DOCKER_LOGIN_SERVER: your.registry.example.com # If different that gitlab-registry.cern.ch,
- # we need to authenticate against your docker registry to push this image
- # DOCKER_LOGIN_USERNAME and DOCKER_LOGIN_PASSWORD to be provided as Secure Variables
-
-# Features
-# * Simplicity
-# * No provisioning time
-
-# Limitations
-# * Builder image only allows certain level of configuration
-# * Cannot use latest Doccker-build features such as multistage building