e8ad51ae41
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
17 lines
446 B
YAML
17 lines
446 B
YAML
- hosts: all
|
|
roles:
|
|
- build-docker-image
|
|
|
|
# If buildset_registry is defined, that means a parent job is running it;
|
|
# only if it is not defined does it mean that we are running it. If we
|
|
# are running it, pause the job so that child jobs will automatically
|
|
# use it.
|
|
- hosts: localhost
|
|
tasks:
|
|
- name: Pause the job
|
|
when: buildset_registry is not defined
|
|
zuul_return:
|
|
data:
|
|
zuul:
|
|
pause: true
|