These are the analogs of the opendev-build-docker-image jobs,
using the newer container roles.
Change-Id: Ifec8fd7db3b238536b396a9012bdf93d0d19547e
Depends-On: https://review.opendev.org/c/zuul/zuul-jobs/+/878291
This adds a copy of the tox-docs related jobs but using nox instead.
Depends-On: https://review.opendev.org/868134
Change-Id: I445202f366c748191fe6a05e145c05cbad1bb8f5
It's mildly annoying that, in the wake of tagging a new release,
documentation lags behind because we only publish in the promote
pipeline from what was built by the last change to merge in the
gate. There is an existing job which can build and publish
documentation in the release pipeline, but does so into a
version-specific path leading to multiple versioned copies of the
documentation.
For fast-moving projects it's not much of a problem
since there will be a new change coming along soon to refresh the
default version of the documents and reflect the recent tag in page
footers and release notes. In simple projects with only a single
branch and infrequent changes, however, there can be long periods of
time where the published documentation makes no indication of the
existence of the latest release. Address this with a new job which
publishes to "latest" instead of the tag name.
Note that this requires a copy of the existing secret, in order to
update the "tag" variable attached to it. Also worth noting, this
job could be run in parallel with the existing
opendev-publish-tox-docs job in the release pipeline for the same
project in order to get the benefits of both.
Change-Id: Ibd4f31b9d06137f9cc52bc1a07e1c37766494e7b
This should be a production no-op; it splits the key and source setup
into a separate playbooks, but imports them both in pre.yaml in the
same order.
Currently this job sets up the executor so that it can log into bridge
to run the playbooks, then clones the system-config state into
/home/zuul/src/opendev.org/opendev/system-config on bridge.
This presents a problem for parallel operation; every production job
will overwrite each other's system-config checkout. This is
unnecessary since they are all working in the context of the same
buildset -- we only need to populate system-config on bridge once at
the start and all deployment jobs can share that checkout.
Thus we add two extra jobs to split up the operation of the existing
opendev-infra-prod-base job.
opendev-infra-prod-setup-src sets up the keys so the executor can log
into bridge and also replicates the state of system-config onto
bridge for this buildset. This is intended to run once per buildset.
opendev-infra-prod-setup-keys just sets up the keys so that the
executor can run production playbooks. It is intended that
opendev-infra-prod-setup-src will have already run to put the
correct changeset of system-config on bridge.o.o. This way,
production jobs can run in parallel all using the same copy of the
source without overwriting it.
These are used in https://review.opendev.org/c/opendev/system-config/+/807808
(This will eventually leave opendev-infra-prod-base unused, it can be
cleaned up in a follow-on)
Change-Id: I1bbf4f1402938216401dd924da62aa869a08875b
This reverts commit 80b93d1f04.
I have actually now realised that this duplicates the existing job
opendev-buildset-registry-consumer.
Change-Id: I6c32ee24ab7982c19c82ca79ad2e9d2911056606
To explain the problem first; I want the system-config-run-paste job
to be able to speculatively test containers from lodgeit project
changes. lodgeit is building containers, using
opendev-buildset-registry job and seems to be pushing the results of
changes into the Opendev intermediate registry just fine. However,
the system-config-run-paste job isn't picking up the container when
using Depends-On: <lodgeit-change>.
On the system-config side, there is nothing running
pull-from-intermediate-registry. So the build artifact container of
the dependent change is never put into the buildset registry and we
always end up pulling the latest upstream image. I think that in
system-config we are largely consuming containers that are co-built
along-side the testing jobs which is why we have never had this
problem.
Since pull-from-intermediate-registry runs in a trusted context on the
executor, we need it here. Add a new base job
"opendev-intermediate-registry-base" that jobs can use as a parent
that runs this role. This would be useful for any jobs that want to
consume containers from other projects via the Opendev intermediate
registry.
Change-Id: I2fa70ed034ca91904a2759811055e98b17e034cd
Git repo setup for infra prod playbook jobs needs to happen in a trusted
playbook. Create a base job to do that.
Change-Id: Ic0a1546141ccf3f030d3fbb073954792cea3cd55
The new javascript jobs need a new promote job for the tarballs,
but also need a new promote job for publishing the content
inside those tarballs.
Change-Id: I437795ae30384bb8d759e19907d5a91426ab3e46
Add documents to document roles and jobs and a job to test these.
These are not published yet since I don't know where to publish them
currently. Let's add them so that we can ensure that no breakage is
introduced.
Change-Id: I013ab998aba182a29ff4345c975b332406b1a197