Automate docker image verification for patch release pipeline
What does this MR do and why?
Describe in detail what your merge request does and why.
Content
Automate docker image verification for patch release pipeline
- Add rake tasks to notify and perform docker image verification for patch release pipeline
- Add CI jobs to notify and perform docker image verification for patch release pipeline
This is a follow up of !3216 (merged), to use the CheckDockerTags class for patch release pipeline.
Ref: gitlab-com/gl-infra/delivery#20237 (closed)
Testing
Pipeline creation
This was tested in this repo (gitlab-org/release-tools), just to see that the pipeline gets created as we expect it.
|
With |
With |
|---|---|
|
(The verify step happens after publishing and before finalizing) |
|
Configuration testing
This was to test the configuration of the pipeline (the job order).
| Step | Screenshot |
|---|---|
| Change notification channel for testing (Testing commit) | |
| Initialized as manual pipeline (Pipeline) |
|
After security_release:early_merge:start is manually triggered |
|
| Slack notification (Link) |  |
After security_release:early_merge:start is completed successfully, it starts security_release:early_merge stage |
 |
Execution testing
This was to actually test the execution of the job calling the bundle exec rake 'security:verify_images:verify' .
| Step | Screenshot/link |
|---|---|
| Check if the list of versions is get correctly |
[1] pry(main)> ReleaseTools::PatchRelease::Coordinator.new.versions => ["17.1.1", "17.0.3", "16.11.5"] |
| Pipeline manually started |
|
|
Slack notification (link) |
|
|
|
Job log: https://ops.gitlab.net/gitlab-org/release/tools/-/jobs/14423621 |
| If we test locally with existing versions, the Slack notification would look like this: |
|
