Security preparation pipeline - Check mirror status
🔭 Overview
We are automating the first steps of the security release as part of reducing release manager workload during security releases.
The goal is to remove those tasks entirely, allowing the release manager to start a pipeline and then move on to the early merge phase without having to manually send notifications and check pipeline statuses.
Each section of the security release tasks (each day's worth of tasks) will be it's own pipeline. That pipeline will be triggered by a parent pipeline that runs the entire security release. The benefit of using a downstream pipeline for each stage is that the stage can be re-run against new code changes without having to re-run the parent pipeline.
sequenceDiagram
Parent Pipeline (preparation stage)-->>+security-prepare pipeline: Triggers downstream pipeline
Note over Parent Pipeline (preparation stage): Not part of this issue
security-prepare pipeline-->>+security-prepare pipeline: Disable omnibus builds job
Note over security-prepare pipeline: This issue
security-prepare pipeline->>+security-prepare pipeline: Check mirror status
security-prepare pipeline-->>+security-prepare pipeline: Communicate security release
security-prepare pipeline-->>+security-prepare pipeline: Check component pipeline status
This issue covers the task to check the mirror status, ensuring the canonical, security, and dev repositories are synced.
We do not yet need to worry about the parent pipeline and are just working on one job in the security-prepare pipeline
in this issue.
🔬 Proposal
-
Add a job
check-mirror-status
to thesecurity-prepare
pipeline. The job should check the mirror status, the same functionality that happens with the/chatops run mirror status
command. It should output the results of the command into the job log.When the pipeline runs, it should output a success or failure message to
#f_upcoming_release
. If the job fails, the slack notification should link to the failed job, where the job includes information about the failure. If the job failed for a reason outside of the repositories not being synced, it should be clear that the error is not due to the sync, but something else went wrong. -
Place the related task in the security_patch template behind the
SECURITY_RELEASE_PIPELINE
feature flag added in #19300 (closed) so that this task is also captured in the new step to run the pipeline. The text for that task should be updated to something more generic likeRun a pipeline with $SECURITY_RELEASE_PIPELINE set to 'prepare'
since we now have multiple tasks being managed by that pipeline.
To do
-
Add configuration on release-tools to trigger a pipeline on ChatOps gitlab-org/release-tools!2422 (merged) -
Modify the mirror status
job on ChatOps to be triggered by a pipeline and to fail if the mirrors are broken gitlab-com/chatops!378 (merged) / gitlab-com/chatops!379 (merged) -
Remove add-check-mirror-status
protected branches from release-tools and remove the branch -
Remove allow-mirror-command-to-be-triggered-by-pipeline
as protected branch from ChatOps and remove the branch -
Remove image from container registry in ops -
Open a follow-up to decide if we need to check all the projects under security. -
Documentation for testing ChatOps gitlab-com/chatops!380 (merged) -
Perform tests -
Remove branch from GitLab and GitLab security -
Adjust the security release template gitlab-org/release-tools!2428 (merged)
Tests
-
✅ When/chatops run mirror status
is executed: The job is executed as usual -
✅ When repositories are in sync: The command is executed, the results are posted in a Slack channel and the job succeeds -
✅ When repositories are out of sync: The command is executed, results are posted in Slack and the job fails.
Executing ChatOps command | When repositories are in sync | When repositories are out of sync |
---|---|---|
Example | Example | Example |