We just (re)discovered that our gitlab rules don't work nicely with pipelines running from stable staging branches. Every pipeline gets published with the 'latest' tag, whether its the main staging branch or one of the stable staging branches. If pipelines for multiple staging branches run concurrently they'll get very confused and end up using the wrong container content. eg a 8.0 stable job will get run with a container from the development branch, or vica-verca.
With this series we dynamically change the tag so that the 'staging' branch still uses 'latest', but the stable 'staging-X.Y' branaches use a 'staging-X-Y' container tag. We also let the container tag be set explicitly via the new variable QEMU_CI_CONTAINER_TAG to facilitate CI testing, the new variable QEMU_CI_UPSTREAM can be set to the fork namespace, to allow contributors to run a pipeline as if their fork were upstream. Finally 'QEMU_CI=1' is also made to work in upstream, so that it is possible to re-run selective jobs on staging branches. Changed in v3: - Really make QEMU_CI=1 work correctly on stable staging Changed in v2: - Allow QEMU_CI=1 to work on all staging branches, not just stable - Rebased Daniel P. Berrangé (5): gitlab: centralize the container tag name gitlab: allow overriding name of the upstream repository gitlab: stable staging branches publish containers in a separate tag gitlab: avoid extra pipelines for tags and stable branches gitlab: support disabling job auto-run in upstream .gitlab-ci.d/base.yml | 63 ++++++++++++++++++++++++---- .gitlab-ci.d/buildtest-template.yml | 4 +- .gitlab-ci.d/buildtest.yml | 4 +- .gitlab-ci.d/container-template.yml | 3 +- .gitlab-ci.d/crossbuild-template.yml | 6 +-- .gitlab-ci.d/static_checks.yml | 4 +- docs/devel/ci-jobs.rst.inc | 11 +++++ 7 files changed, 78 insertions(+), 17 deletions(-) -- 2.40.1
