Make sure we always log out of the docker registry, as not to allow
other playbooks to use the session.
Change-Id: I65fb71884b08802b5537ecef7304129cdeb952c3
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Use '{{ zuul.pipeline }}' tag prefix in *-docker-image instead of
'change_{{ zuul.change }}' one when zuul.change is not provided, that is
the case with periodic jobs. This allows to build, upload and promote images
using periodic jobs e.g:
- project:
periodic:
- project-buildset-registry
- project-build-image1:
dependencies:
- name: project-buildset-registry
- project-build-image2:
dependencies:
- name: project-buildset-registry
# pulls from buildset registry and tests both images
- project-test:
dependencies:
- name: project-build-image1
- name: project-build-image2
# pre-pulls images from buildset registry for fast build
- project-upload-image1:
dependencies:
- name: project-test
- project-upload-image2:
dependencies:
- name: project-test
- project-promote:
dependencies:
- name: project-upload-image1
- name: project-upload-image2
This fuctionality will allow to keep latest images up to date for the
case when image incorporates continuously updating code from multiple
repositories.
Using true ternary for tag evaluation because ternary filter requires
all passed to it variables be defined or defaulted [0].
[0] https://github.com/ansible/ansible/issues/51276
Change-Id: I8eb7d2baa24905e7aac51fce0b2f9b1f24f037f9
Signed-off-by: Andrii Ostapenko <andrii.ostapenko@att.com>
When using docker buildx to build a container image, use a temporary
registry to receive the built image instead of requiring a buildset
registry.
A multi-arch test is also added with a publication registry
using the same task list to reduce duplication.
Change-Id: Ib20d1c97f6cb63e0ff9d8888ea792d1941cd8690
Co-Authored-By: James E. Blair <jeblair@redhat.com>
The zuul.change variable isn't defined when run in a tag-based
release pipeline. Even though it's wrapped in a ternary operator,
it is still dereferenced even if it's not used. Make sure we
dereference it safely.
Change-Id: I215a003493603de99296035d77eee64cc66e83f1
This adds an option to the upload-docker-image role so that a job
can be written to run build-docker-image and upload-docker-image
in a release pipeline. This lets users build tagged docker images
from release tags rather than using the promote pipeline (which
may have built the image before a release git tag was applied).
Change-Id: Id28d0a85e02e56640911c44ddbfff7b38547b0b4
This is a copy/pasta error from pulling this logic over from build.
We need to upload to dockerhub but only to the change_ version
of the tag.
Change-Id: I19d1b326ad2c5b1cef846f47e667f3c3480582e7
Otherwise the context might be different and we might have to
rebuild, which would be silly. I mean, not like this isn't
silly already.
Change-Id: I3651390581ad1b4ae66ed336825f60284bd7c4ad
It's awesome, we used buildx to push to docker hub. What we forgot
to do is pass the arch argument.
Change-Id: I99025544f7a8aea651e9562041af859a38cddbfc
If we build multi-arch images with buildx we also need to push to
dockerhub using buildx, because otherwise we're just pushing
the single-arch image we fetched back from the buildset registry
for the local cache.
Change-Id: If8b95a708e4f0d24e959317b803f5c9379a8b62b
We have to be careful about avoiding outer loop loop_var conflicts in
ansible. Because the zuul-jobs roles are meant to be reconsumed
elsewhere we should not use 'item' loopvars and instead set them to
something a bit more unique.
We use a zj_ prefix to try and be unique to this repo and document this
convention.
Change-Id: I20b9327a914890e9eafcb2b36dc8c23fb472bc8f
So that users can specify two docker image builds for the same
repository, but with different tags, ensure that the temporary
change_ tag attached to the image also includes the final tag
name.
This allows this configuration to work:
docker_images:
- repository: foo/image
context: opensuse
tags:
- opensuse-latest
- repository: foo/image
context: ubuntu
tags:
- ubuntu-latest
Change-Id: I917dcf8a74fc864ea06dc70bdb3e212dc170eb48
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