base-jobs/playbooks/docker-image
James E. Blair e8ad51ae41 Always pause docker build jobs
The design idea for these jobs was that the buildset-registry job
would be used in systems where a dedicated registry job was desired
(e.g., because there are multiple image build jobs).  The image-build
job inherits from the buildset-registry job so that if a registry is
not already running, it runs one, but it overrides the playbook so
that it does not pause.  In other words, it was meant only to do what
is necessary to build its own image(s), not to serve them to other
jobs.

However, in the (arguably common) case that a repo has a single image
build job as well as jobs which could consume those images, it would
be efficient to have the image build job run the registry, build the
images, then pause for the registry to be used by the consuming jobs.

Rather than ask users to make a new playbook which restores the job
pause, let's have the image build job pause iff it is running a
buildset registry.  If there are no child jobs, Zuul will resume
the job immediately, so there won't be any change in behavior.  But
if there are child jobs, they will be able to use the registry
running on the image build job.

Change-Id: Iebd47305eeafbfaac0f699aae3e0a7d7a36f85ee
2019-04-02 15:12:34 -07:00
..
credentials.rst Add docker image jobs 2019-02-22 08:50:23 -08:00
README.rst Add docker image jobs 2019-02-22 08:50:23 -08:00
run.yaml Always pause docker build jobs 2019-04-02 15:12:34 -07:00
upload.yaml Add docker image jobs 2019-02-22 08:50:23 -08:00

This is one of a collection of jobs which are designed to work together to build, upload, and promote docker images in a gating context:

  • :zuulopendev-build-docker-image: Build the images.
  • :zuulopendev-upload-docker-image: Build and stage the images on dockerhub.
  • :zuulopendev-promote-docker-image: Promote previously uploaded images.

The :zuulopendev-build-docker-image job is designed to be used in a check pipeline and simply builds the images to verify that the build functions.

The :zuulopendev-upload-docker-image job builds and uploads the images to Docker Hub, but only with a single tag corresponding to the change ID. This job is designed in a gate pipeline so that the build produced by the gate is staged and can later be promoted to production if the change is successful.

The :zuulopendev-promote-docker-image job is designed to be used in a promote pipeline. It requires no nodes and runs very quickly on the Zuul executor. It simply re-tags a previously uploaded image for a change with whatever tags are supplied by :zuulopendev-build-docker-image.docker_images.tags. It also removes the change ID tag from the repository in Docker Hub, and removes any similar change ID tags more than 24 hours old. This keeps the repository tidy in the case that gated changes fail to merge after uploading their staged images.

They all accept the same input data, principally a list of dictionaries representing the images to build. YAML anchors can be used to supply the same data to all three jobs.

Job Variables