026e9fa6ef
This commit changes few things, implementing some of the GitLab CI known
best practices:
1. Explicitly pointing the `docker:git` image to a specific version.
Leaving the floating one we're risking that a buggy release of new
Docker image will be randomly introduced to our pipelines. It's also
best to make the Docker Client (used by the job from within the
`docker:git` image) to be at the same version as the Docker Engine
(running in the `docker:dind` service container).
2. Replacing `ci-job-token` with `CI_REGISTRY_USER` and `CI_JOB_TOKEN`
with `CI_REGISTRY_PASSWORD` makes the script more bulletproff. Yes,
at this moment these variables contain the same values. But they are
dedicated for such usage and if GitLab CI will ever decide to switch
how Registry access should be done, the dedicated variables will
folow the proper way.
|
||
|---|---|---|
| assets | ||
| patches/ruby | ||
| scripts | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| CONTRIBUTING.md | ||
| Dockerfile.alpine-helm | ||
| Dockerfile.build-git | ||
| Dockerfile.custom | ||
| Dockerfile.danger | ||
| Dockerfile.gitlab-charts-build-base | ||
| Dockerfile.gitlab-charts-build-base-helm-3 | ||
| Dockerfile.gitlab-helm3-kubectl1.14 | ||
| Dockerfile.gitlab-operator-build-base | ||
| Dockerfile.gitlab-puppeteer | ||
| Dockerfile.gitlab-qa-alpine-ruby-2.7 | ||
| Dockerfile.gitlab-qa-alpine-ruby-3.0 | ||
| Dockerfile.gitlab-qa-ruby-2.7 | ||
| Dockerfile.gitlab-qa-ruby-3.0 | ||
| Dockerfile.golangci-lint-alpine | ||
| Dockerfile.omnibus-gitlab-bionic | ||
| Dockerfile.omnibus-gitlab-buster | ||
| Dockerfile.omnibus-gitlab-centos7 | ||
| Dockerfile.omnibus-gitlab-centos8 | ||
| Dockerfile.omnibus-gitlab-cve-search | ||
| Dockerfile.omnibus-gitlab-depscan | ||
| Dockerfile.omnibus-gitlab-focal | ||
| Dockerfile.omnibus-gitlab-jessie | ||
| Dockerfile.omnibus-gitlab-opensuse15.1 | ||
| Dockerfile.omnibus-gitlab-opensuse15.2 | ||
| Dockerfile.omnibus-gitlab-stretch | ||
| Dockerfile.omnibus-gitlab-wheezy | ||
| Dockerfile.omnibus-gitlab-xenial | ||
| Dockerfile.release-tools | ||
| Dockerfile.sitespeed-gitlab | ||
| Dockerfile.terraform | ||
| Dockerfile.ubi-release | ||
| Dockerfile.www-gitlab-com-2.7 | ||
| Dockerfile.www-gitlab-com-3.0 | ||
| LICENSE | ||
| README.md | ||
GitLab Build Images
This repository is used to build docker images that are used to build and test various parts of GitLab:
- Build Omnibus packages
- Test GitLab-CE/EE project
- Build gitlab-org/www-gitlab-com project
Adding a new image
There are two methods to adding a new image:
- Use a Dockerfile.
- Use a custom image with versioned features.
Use a Dockerfile
A bespoke image is one that uses it's own Dockerfile. In the interests of avoiding repetition, it's better to use the custom docker build if possible.
Assuming the image you want to add is called new-image:
- Add a test task:
new-image test: *test_build. - Add a new build task:
new-image: *build_and_deploy. - Add a Dockerfile:
Dockerfile.new-image.
Use a custom image with versioned features
To add a new image to the build, edit .gitlab-ci.yml.
With custom images, the name of the image is used to define the contents (as opposed to use a bespoke Dockerfile build).
For this reason, the name needs to be correctly defined.
The name is defined as [feature]-[version] pairs, separated by -.
Here are some example build names:
ruby-2.7-golang-1.15-git-2.29ruby-3.0.0-git-2.29-lfs-2.9-node-14.15-yarn-1.22-graphicsmagick-1.3.34ruby-3.0.0.patched-golang-1.14-git-2.29-lfs-2.9-chrome-87-node-14.15-yarn-1.22-postgresql-12-graphicsmagick-1.3.34
The first pair represents the base image and version. So ruby-3.0-... will use the ruby:3.0 base image, while
golang-1.15 will use the golang:1.15 base image.
Each of the following parts represents another feature and version. Available options are:
chromedockergitgolanggraphicsmagicklfsnodepgbouncerpostgresqlrubyyarn
Adding a new build
As an example, if you want to add new image for Ruby 3.0 with git 2.29 and golang 1.15,
the name would be ruby-3.0-golang-1.15-git-2.29.
- Add a test task:
ruby-3.0-golang-1.15-git-2.29 test: *test_custom - Add a new build task:
ruby-3.0-golang-1.15-git-2.29 push: *build_and_deploy_custom
Pushing a rebuild image
To build (or rebuild) a given image and push it, you need to enable manual action for a given job after it is merged to master.
By default we don't do it to ensure that an upstream dependency doesn't end up breaking our images unexpectedly. For reference, this happened in the past: https://gitlab.com/gitlab-org/gitlab/issues/205192
Note regarding Google Chrome
Google has a policy of yanking older versions of Google Chrome from their PPA
whenever a new major version is released. To help maintain consistent build
images, there is a CI step that saves the latest Google Chrome .deb into an S3
bucket. The install for Chrome will attempt to retrieve from the bucket if it
cannot find the file in the apt repository. See scripts/cache-google-chrome
for more details.
Contributing
See Contributing