Add update path testing to patch release pipeline

What does this MR do and why?

Describe in detail what your merge request does and why.

Content

In order to replace the release instance, the QA scenario Test::Omnibus::UpdateFromPrevious is used. This change does it by:

• Add a new dynamic pipeline setting up the QA scenario based on the version upgrade.
• Add two new jobs to the tagging stage of the patch release pipeline, to generate the dynamic pipeline and run it.
  • security_release_tag:update_path:create_dynamic_pipeline - depends on the security_release_tag:check_omnibus_packages_tagging job, because the QA uses the Docker image built in the Omnibus pipeline.
  • security_release_tag:update_path - trigger the downstream pipeline. The downstream pipeline has only one stage with one job Based on the upcoming version, the test can be patch-to-patch, monthly-to-patch or patch-to-monthly.
  • To make sure it work without breaking the current workflow, the new jobs all have allow_failure: true
• How the new jobs are triggered:
  • When the stage runs stand-alone (i.e. SECURITY_RELEASE_PIPELINE=update_paths ): we manually trigger the start.
  • When the stage runs in a full pipeline (i.e. SECURITY_RELEASE_PIPELINE=true ): the stage runs automatically after security_release_tag:check_omnibus_packages job.
• The job security_release_tag:verify_release_deploy to check the release instance stays unchanged

Ref: gitlab-com/gl-infra/delivery#21074 (closed)

Job dependency

Full release pipeline SECURITY_RELEASE_PIPELINE=true

https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/4445681

As you can see in the following screenshot, the new jobs have their own stages, running after tagging

Looking at job dependencies, we see the stage starts after security_release_tag:check_omnibus_packages job, because the update paths QA needs the new Omnibus package.

Stand-alone stage SECURITY_RELEASE_PIPELINE=update_paths

https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/4445708

When running the stage stand-alone, the start job is a manual job

Functional Testing

To do the following test, I need to make some changes in the version choosing and pipeline logics, so I can run the new jobs only.

The QA job log is long, but we only need to check the line like this to know if we are testing the right versions.

[Apr 23 2025 19:17:54 UTC (Gitlab QA)] INFO  -- Performing gitlab update: gitlab/gitlab-ee:17.10.4-ee.0 => dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee:17.10.5-ee.0 (17.10.4)

Note: From feedback, the stage in the following example is changed to be security_release:verify_update_path, but otherwise the logic is the same.

patch-to-patch

Test when releasing 17.10.5

https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/4426448

bundle exec gitlab-qa Test::Omnibus::UpdateFromPrevious dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee:17.10.5-ee.0 17.10.4 patch -- --tag health_check

monthly-to-patch

Test when releasing 17.10.1

https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/4426296

bundle exec gitlab-qa Test::Omnibus::UpdateFromPrevious dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee:17.10.1-ee.0 17.10.0 patch -- --tag health_check

Notification Testing

Notification is triggered by security_release_update_paths:start