Version
Affects operator-ci.yaml and agent-ci.yaml on main as of 921dc1a.
What happened?
Pushing a release-candidate tag republishes the :latest container tag, so :latest can point at a prerelease build.
The metadata step keys only on github.ref_type, with no check on the tag's shape:
case ${{ github.ref_type }} in
tag)
export VERSION=$(echo "${{ github.ref_name }}" | cut -f 2 -d /)
TAGS="${GIT_SHA} ${VERSION} latest"
;;agent-ci.yaml has the same logic. Any tag push takes that branch, and RC tags are a supported, used shape in this repo. docs/contributing/release-process.md documents <component>/v<MAJOR>.<MINOR>.<PATCH>-rc.<N> as a valid tag published as a GitHub pre-release, and these exist already:
operator/v0.17.0-rc.1
operator/v0.16.0-rc3
operator/v0.16.0-rc2
operator/v0.16.0-rc1
So the RC workflow described in the release process, "tag the RC, validate it, iterate with -rc.2 if needed", moves :latest to each RC in turn and leaves it there until the final tag is pushed. During an RC cycle, anyone pulling :latest gets a release candidate.
This is latent right now rather than active: the newest operator tag is the stable operator/v0.19.0, so :latest currently resolves to a stable release.
Expected behavior
:latest tracks the most recent stable release. An RC publishes its version tag and the SHA tag, and leaves :latest alone.
Worth deciding alongside the fix: :latest is also not guaranteed to be the highest version, because it is assigned by whichever tag was pushed most recently. A patch on an older release branch (operator/v0.16.2 cut after v0.19.0 shipped, which the documented patch workflow permits) would move :latest backwards. Gating on "is stable" fixes the RC case but not that one.
How to reproduce
Push any <component>/vX.Y.Z-rc.N tag and observe that the manifest step publishes latest alongside the version tag. No pull is required to see it; the tag list is computed in the compute-metadata job output.
Additional context
Found while implementing #627, which adds a weekly vulnerability scan of operator:latest and agent:latest. That scan deliberately targets :latest because it measures what users actually pull, so it inherits this behavior: during an RC cycle the scan would silently report on a prerelease rather than the shipped release. #627 is not blocked on this and does not work around it; the fix belongs here.
Version
Affects
operator-ci.yamlandagent-ci.yamlonmainas of 921dc1a.What happened?
Pushing a release-candidate tag republishes the
:latestcontainer tag, so:latestcan point at a prerelease build.The metadata step keys only on
github.ref_type, with no check on the tag's shape:agent-ci.yamlhas the same logic. Any tag push takes that branch, and RC tags are a supported, used shape in this repo.docs/contributing/release-process.mddocuments<component>/v<MAJOR>.<MINOR>.<PATCH>-rc.<N>as a valid tag published as a GitHub pre-release, and these exist already:So the RC workflow described in the release process, "tag the RC, validate it, iterate with -rc.2 if needed", moves
:latestto each RC in turn and leaves it there until the final tag is pushed. During an RC cycle, anyone pulling:latestgets a release candidate.This is latent right now rather than active: the newest operator tag is the stable
operator/v0.19.0, so:latestcurrently resolves to a stable release.Expected behavior
:latesttracks the most recent stable release. An RC publishes its version tag and the SHA tag, and leaves:latestalone.Worth deciding alongside the fix:
:latestis also not guaranteed to be the highest version, because it is assigned by whichever tag was pushed most recently. A patch on an older release branch (operator/v0.16.2cut afterv0.19.0shipped, which the documented patch workflow permits) would move:latestbackwards. Gating on "is stable" fixes the RC case but not that one.How to reproduce
Push any
<component>/vX.Y.Z-rc.Ntag and observe that the manifest step publisheslatestalongside the version tag. No pull is required to see it; the tag list is computed in thecompute-metadatajob output.Additional context
Found while implementing #627, which adds a weekly vulnerability scan of
operator:latestandagent:latest. That scan deliberately targets:latestbecause it measures what users actually pull, so it inherits this behavior: during an RC cycle the scan would silently report on a prerelease rather than the shipped release. #627 is not blocked on this and does not work around it; the fix belongs here.