Resolve the latest release image to a published version

[CharlieTLe]

What this fixes

getLatestReleaseImage() in integration/util.go derives the "latest release" image
straight from the VERSION file, and .github/workflows/test-build-deploy.yml mirrors it
as docker pull quay.io/cortexproject/cortex:v$(cat testdata/VERSION).

That holds on master, where VERSION is the last GA and its image exists. It does not
hold on a release branch: VERSION is bumped to the version being prepared (e.g.
1.22.0-rc.0) long before anything publishes that tag, and the deploy job that would
publish it has needs: [build, test, lint, integration]. So the integration_query_fuzz
leg would try to pull an image that does not exist yet, and release-1.22 would be red
from the moment VERSION gains its -rc.0 suffix.

The same applies on the GA tag push, where VERSION is 1.22.0 with no suffix: the
v1.22.0 image is only pushed by deploy, which again runs after integration.

This mechanism landed in #7737 (2026-07-30), after v1.21.1, so it has never been through
a release.

The fix

VERSION names the version being prepared, so it cannot answer "what is published".
The registry can, so ask it — thanks @SungJin1212 for the suggestion.

A new Resolve Latest Release Image step lists the GA tags (^v\d+\.\d+\.\d+$) published
to quay.io, takes the highest one that does not exceed VERSION, and exports it as
CORTEX_LATEST_RELEASE_IMAGE for the preload and test steps. It runs only on the
integration_query_fuzz matrix leg, which is the only caller of getLatestReleaseImage().

Against a registry whose newest GA is v1.21.1:

VERSION	resolves to
1.21.1	v1.21.1	master's steady state
1.22.0-rc.0	v1.21.1	release branch preparing a minor
1.22.0	v1.21.1	the GA tag build
1.21.2-rc.0	v1.21.1	release branch preparing a patch
2.0.0-rc.0	v1.21.1	a major pre-release
1.19.0	v1.19.0	an older branch — note it does not jump forward
1.19.5-rc.0	v1.19.1	the newest published patch, not a guessed 1.19.4

The <= bound (rather than simply "the newest published GA tag") only changes the result
when a newer release already exists on quay than the branch being tested, e.g. preparing
1.21.2 on release-1.21 after v1.22.0 has shipped.

Setting the CORTEX_LATEST_RELEASE_IMAGE repository variable bypasses the lookup
entirely.

The bash mirror of the Go derivation is gone. latestReleaseVersion() stays in
integration/util.go as the offline fallback for local runs, where nothing sets the env
var and a network call is unwelcome; CI always resolves against the registry.

Verification

• The workflow step was extracted from the YAML and run under bash -e (what Actions
  actually uses — no pipefail, no nounset) against the live registry, producing every
  row in the table above, plus errors for a VERSION below everything published and for a
  malformed VERSION. The repository-variable override was exercised too.
• shellcheck is clean on the step. actionlint reports the same 13 pre-existing SC2086
  findings as master and no new ones.
• latestReleaseVersion() keeps its table test; getLatestReleaseImage() is tested end to
  end against a scratch checkout and for the env override.
• go vet passes with every integration build tag set.

[SungJin1212]

Thanks for catching this.

I think the issue with this PR is:
When we push the v1.22.0 tag, VERSION is 1.22.0, and this resolves to quay.io/cortexproject/cortex:v1.22.0. That image is published by deploy, and deploy needs integration to pass.

Can we ask the registry what is actually published? The registry is the only source of truth for "published".

1. Pick the highest published GA tag (^v\d+\.\d+\.\d+$) that is <= the base of VERSION
   ㄴ The <= bound only changes the result when a newer release already exists on quay than the branch being tested (e.g. preparing 1.21.2 on release-1.21 after v1.22.0 shipped).
2. Export it as CORTEX_LATEST_RELEASE_IMAGE

[SungJin1212]

The discover-tags job excludes integration so util.test cannot be tested. We need to use something like an integration_query_fuzz.

done < <(grep -hE "^//go:build " integration/*.go \
         | sed -E 's|^//go:build ||' \
         | sort -u | grep -v '^integration$')

[CharlieTLe]

Good catch, and it was worse than dead weight — thank you.

You're right that nothing ran. The binary did compile them, since the compile step sets ALL_TAGS="slicelabels,integration,${tags_csv}", but Generate Run-Pattern Manifest iterates tags_csv alone, so no -test.run regex ever named them. I reproduced the pattern generation across all 12 matrix tags and every one selected zero of the three functions.

Moved to integration_query_fuzz in 58b5278, since that's the only leg calling getLatestReleaseImage().

Retagging then exposed a second bug that your comment saved me from shipping: that leg is exactly where the new resolve step exports CORTEX_LATEST_RELEASE_IMAGE, which short-circuits getLatestReleaseImage(). So the moment the test started running, it asserted against the override instead of the derivation it exists to cover:

--- FAIL: TestGetLatestReleaseImage
    expected: "quay.io/cortexproject/cortex:v1.21.0"
    actual  : "quay.io/cortexproject/cortex:v1.21.1"

Same commit clears the variable for that test. I verified by reverting the guard that the failure is real, then re-ran the way CI does — compiled with the full ALL_TAGS, regenerated the run-pattern (all three now selected), and ran the binary with CORTEX_LATEST_RELEASE_IMAGE and CORTEX_CHECKOUT_DIR set as the query_fuzz leg sets them. All three pass.

I should be straight about one thing: I'd said earlier this was verified, but that run used -tags integration — the one tag CI never sets. It proved nothing about CI, which is exactly the gap you found.

The registry lookup you suggested is in f4182fd; the PR description has the resolution table.