This role uses skopeo to perform image operations.
Also update the container roles docs to add missing documentation
for the already existing upload-container-image role. Clarify
some ambiguity about the registry and repository attributes of
the container images data structure.
Change-Id: Ib66c85daf0edacf0dd797ab34b0d629f99c7111b
Co-Authored-By: James E. Blair <jim@acmegating.com>
It seems like BuildKit is the next generation, but not likely to be
enabled by default soon (https://github.com/moby/moby/issues/40379).
Add a flag so people who want to use its features can easily opt-in.
Change-Id: I862819959c77a557199f64b4d42109bc7915959c
Docker has experimental support for building multi-arch
container images with a buildx command. Currently it only
supports pushing to a registry after running and the images
don't end up in the local docker images list. To work around
that, push to the buildset registry then pull back. This
is the inverse of the normal case where we build, then
retag, then push. The end result should be the same.
Change-Id: I6a4c4f9e262add909d2d5c2efa33ec69b9d9364a
We can attach some metadata to images we build indicating where
the image was built from. We can also allow users to add additional
labels, should they choose, although honestly for users doing it in
the Dockerfile makes more sense.
Change-Id: I01de15279a69026a09633eb488dac62910b324f5
When you build from a Dockerfile, it runs in a given "context"; that
is the directory the Dockerfile is in and the directories below it.
It can not access anything outside that context during the build.
When building a container for a project in the gate, you may wish to
install sibling projects that Zuul has checked-out into your container
(i.e. so that Depends-On works). As mentioned, because
/home/zuul/src/<project> is not in the context of the current project,
you will not be able to access this source code during the container
build.
So to help facilitate dependencies, add a siblings: tag which can copy
some or all of the required-projects already specified for the job
into a special sub-directory of the current source.
Because all the code is now in the same context, this will allow build
scripts to be written that look for directories in .zuul-siblings and
can install the source code from there. To further help the scripts,
the ZUUL_SIBLINGS arg is set for the docker build giving the copied
paths.
The test is updated with some paths to test the copy.
Change-Id: I079d823e7194e15b1b496aea0f53f70f6b563f02
In certain build projects, multiple Dockerfiles exist (for example,
one per distro) to simplify reading. However, this role is hardwired
to use dockerfiles only named "Dockerfile".
This is a problem, as you can't override the filename neither per
image, or globally.
This should fix the problem, allowing certain images to be build
by providing the dockerfile argument in docker_images, but also
have a globally overridable flag if you are using a different
convention (for example Dockerfile.distro_minordistroversion).
Change-Id: I075c365bc9f4f85f9ada832d22d1f1e213e68e21
These are generic docker image build and upload jobs which use
the recently added roles of the same names. With the new
pass-to-parent feature, child jobs can add their own credentials
to these jobs.
Change-Id: I669a9e6616a031837adab8c5c5806431fcca2150
This allows us to construct a job which allows users to pass in a
secret (via pass-to-parent) which includes not only the user/pass,
but also a restriction for what docker image repositories may be
accessed using that user/pass. This allows an operator to create
one credential, and then use that credential in multiple secrets
for multiple projects, each with a distinct restriction on where
images may be uploaded.
Change-Id: I7a3cf97a16d34c76df8601990954e1f2b0e498f5
These probably should have been prefixed to start with. The roles
are brand new, not publicised, and likely not widely used. I think
we can merge this without announcement or deprecation.
Change-Id: I7825ef6fee1325b6d4fcc179032652eb5530d016
okozachenko