Docker-in-Docker via dind has historically been widely used in CI environments. It means the "inner" containers have a layer of isolation from the host. A single CI runner container supports every pipeline container without polluting the host's Docker daemon.

This is probably confusing because the "host" in --network=host does not mean host as in the underlying runner host / 'baremetal' system. To understand what is happening here, we must first understand how the docker:dind service works. When you use the service docker:dind to power docker commands from your build job, you are running containers 'on' the docker:dind service; it is the docker daemon. When you provide the --host option to docker run it refers to the host network of the daemon I.E. the docker:dind container, not the underlying system host.

When you specify FF_NETWORK_PER_BUILD that was specifying the docker network for the build job and its service containers that encapsulates all of your job's containers.

return &container.HostConfig{ DNS: e.Config.Docker.DNS, DNSSearch: e.Config.Docker.DNSSearch, RestartPolicy: neverRestartPolicy, ExtraHosts: e.Config.Docker.ExtraHosts, Privileged: e.Config.Docker.Privileged, NetworkMode: e.networkMode, Binds: e.volumesManager.Binds(), ShmSize: e.Config.Docker.ShmSize, Tmpfs: e.Config.Docker.ServicesTmpfs, LogConfig: container.LogConfig{ Type: "json-file", },

I'm closing this issue as extra_hosts config is now passed to build containers and services.

When a job uses needs, it no longer downloads all artifacts from previous stages by default, because jobs with needs can start before earlier stages complete. With needs you can only download artifacts from the jobs listed in the needs configuration.

my/path/.my-custom-file.yml@mygroup/another-project:refname

export CI_SERVER_NAME="GitLab" export CI_SERVER_REVISION="70606bf" export CI_SERVER_VERSION="8.9.0"

How to set it up

The needs: keyword enables executing jobs out-of-order, allowing you to implement a directed acyclic graph in your .gitlab-ci.yml. This lets you run some jobs without waiting for other ones, disregarding stage ordering so you can have multiple stages running concurrently.

uses a pre-clone step to seed the project with a recent archive of the repository. This is done for several reasons: It speeds up builds because a 800 MB download only takes seconds, as opposed to a full Git clone.

GIT_DEPTH: '1' helps a little bit but we could speed up our pipelines massively for jobs that only rely on an image that is the sole dependency to run the job.

In a basic configuration, GitLab runs a pipeline each time changes are pushed to a branch. If you want the pipeline to run jobs only when merge requests are created or updated, you can use pipelines for merge requests.

Using the special CI_REGISTRY_USER variable: The user specified by this variable is created for you in order to push to the Registry connected to your project. Its password is automatically set with the CI_REGISTRY_PASSWORD variable. This allows you to automate building and deploying your Docker images and has read/write access to the Registry. This is ephemeral, so it's only valid for one job.

Implementando CI com GitLab