Pick into autodeploy does not work for CNG and Omnibus

Problem

Example walkthrough

An omnibus merge request used the Pick into auto-deploy label to get picked up by an existing auto-deploy branch. This means release-tools was tagged twice and two coordinated pipelines were generated.

The 1st pipeline https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/1885761 has the tag 16.0.202304241120. This pipeline did not contain the fix.

The 2nd pipeline https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/1885778 has the tag 16.0.202304241130. This pipeline does contain the fix.

The problem is, that when the CNG package was built for the 2nd pipeline in https://dev.gitlab.org/gitlab/charts/components/images/-/pipelines/281410, it was still referencing 16.0.202304241120 everywhere. So while it succeeded, if we look at a component, the wrong image is used. For example, in this job we see GitLab-Pages is listed with the older tag: gitlab-pages:16-0-202304241120-f37dd4f9d0a.

When the 16.0.202304241130 pipeline goes to deploy, it fails because it tries to pull gitlab-pages:16-0-202304241130-f37dd4f9d0a which does not exist.

Cause

ReleaseTools::Builder::CNGImage did not re-tag after the Pick was made. In this case there was no change to the commit but only the product version. So in the example above, CNG did not see any changes and skipped the tag (in this section of code: https://gitlab.com/gitlab-org/release-tools/-/blob/e543f4b9710568667f97688a653c11bfdd65105d/lib/release_tools/auto_deploy/builder/cng_image.rb#L39-44).

The same would happen in the opposite case, if a CNG change was Picked, Omnibus would experience a similar failure due to a similar sequence of code.

Solution

Make these sections of code idempotent.

Possible solutions

  1. Always tag regardless of changes.
  2. Update the logic to take other projects in account when tagging.