Simplify auto deploy tagging
What does this MR do and why?
This MR moves auto-deploy tagging outside of the coordinator pipeline.
ReleaseTools::Tasks::AutoDeploy::Tag
has a very complex design. It detects whether it's running inside a coordinator pipeline and behaves differently.
- Outside the coordinator pipeline, it will check for something to tag, but it will tag release-tools instead (generating a coordinator pipeline)
- Inside the coordinator pipeline, it will tag the packagers, publish the release-metadata information, notify on slack, generate a sentry release, and generate an environment artifact with the current
DEPLOY_VERSION
.
This complex design could expose to the Time-of-check Time-of-use race condition, as well as having known bugs like gitlab-com/gl-infra/delivery#4053 (closed).
This merge request extracts some features from ReleaseTools::Tasks::AutoDeploy::Tag
, introducing the new ReleaseTools::Tasks::AutoDeploy::Start
that will only run inside the coordinator pipeline.
Each task has dedicated responsibilities and can run without changing behavior based on whether running in a coordinator pipeline.
ReleaseTools::Tasks::AutoDeploy::Tag
runs as part of the single auto-deploy timer and have the following responsibilities:
- it will verify if the condition to generate a new package are met (changes since the last package on GitLab rails, omnibus, or CNG)
- it will tag both packagers even if the changes are only in one of them (fixing gitlab-com/gl-infra/delivery#4053 (closed))
- it will produce the release-metadata of the package
- it will tag release-tools with the product version associated with the above metadata, triggering a coordinator pipeline
ReleaseTools::Tasks::AutoDeploy::Start
is the first job of the coordinator pipelne (replacing the tag job) and have the following responsibilities:
- generate
DEPLOY_VERSION
- generate the new sentry release
- notify the pipeline creation on slack
This MR fixes gitlab-com/gl-infra/delivery#17799 (closed) and gitlab-com/gl-infra/delivery#4053 (closed)