Security repo's pipelines pushing resources can cause confusion
From: #28973 (comment 945794559)
- It indeed appears that the security pipeline
https://gitlab.com/gitlab-org/security/gitlab-runner/-/jobs/2236965949
for 14.9.1 was first to release the dep packages to packagecloud as opposed to the public pipeline https://gitlab.com/gitlab-org/gitlab-runner/-/jobs/2237103144. The security pipeline had a commitf188edd7
while the public pipelinebd40e3da
. - Once a version is published to packagecloud our pipeline doesn't override it, not sure if that's even possible
- At the same time the security pipeline couldn't push the images with the
f188edd7
commit due to permissions problems https://gitlab.com/gitlab-org/security/gitlab-runner/-/jobs/2452282858. - The public pipeline then released all the packages, binaries and images. So if you go and download v14.9.1 manually you'll find it working since the images for
bd40e3da
exist. - This has a few possible action items: 1. Why do we keep using the commit of the binary instead of the tag for officially released binaries? It's fine for non-official ones, but for official ones we should use the tag, especially since helper images with the release version are pushed to the registry. It would have only masked the current issue so I am not proposing it as a solution, rather as an improvement 2. We should stop pushing things from the security repo when it's not strictly a security release. How to do that is unclear to me at the moment 3. A workaround currently is to cancel security pipelines when creating tags in the public repo