switch production promotion job to delayed
Today production promotion is a manual job.
We want to gradually change this to a quasi-automated job.
The idea is to move it from manual to delayed by 1hr.
We expect to be able to detect the automated delayed job from a release manager manual run thanks to GITLAB_USER_LOGIN
variable.
It should be the deployer
user in case of an automated run, and a release manager otherwise.
- When running in delayed mode, it will check the production status, and notify the release manager (in slack?) that a deployment could start now. But it will fail to prevent an automated deployment
- When the job is played manually from a release manager, it will behave as today, authorizing a deployment if production is healthy
Once #1092 (closed) will be ready, this same check will be extended to our monitoring system.
SSOT
So far ReleaseTools::Promotion:Manager
can only write the status on the monthly issue.
We should expand it to selectively send the status results to the issue or on slack.
With this in place, we could send the results on slack when the job runs in delayed mode, and write them on the issue only when a release manager promotes a build.
Bonus point, we could change /chatops auto_deploy blockes
to trigger release-tools production checks job. In this way we have a SSOT and we don't need to implement #1092 (closed) also in chatops
.