Skip to content

Resolve the latest release image to a published version - #7786

Open
CharlieTLe wants to merge 1 commit into
cortexproject:masterfrom
CharlieTLe:release-1.22-pr-a-fix-latest-release-image
Open

Resolve the latest release image to a published version#7786
CharlieTLe wants to merge 1 commit into
cortexproject:masterfrom
CharlieTLe:release-1.22-pr-a-fix-latest-release-image

Conversation

@CharlieTLe

Copy link
Copy Markdown
Member

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.

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

The fix

Resolve a pre-release version to the release preceding it, which is always already
published by then:

VERSION resolves to
1.21.1 v1.21.1 (master's steady state — the last GA)
1.22.0-rc.0 v1.21.0 (the previous minor always shipped a .0)
1.22.2-rc.1 v1.22.1 (the preceding patch of the same minor)

Using the previous minor's .0 rather than its newest patch keeps this derivable from
VERSION alone, and the difference is immaterial for a backward-compatibility fuzz test.

A major pre-release (2.0.0-rc.0) is not derivable, so that case errors with a message
pointing at CORTEX_LATEST_RELEASE_IMAGE, a new env override that short-circuits the
resolution entirely.

The preload step in test-build-deploy.yml mirrors the same rule, including the override.

Known gap

This does not cover the GA tag build. On the v1.22.0 tag push, VERSION is 1.22.0
with no suffix, so it resolves to v1.22.0 — which deploy has not published yet at the
point integration runs. That is the same bug class and it will bite once, on the GA tag.
CORTEX_LATEST_RELEASE_IMAGE is the lever for that run. Raising it here rather than
silently widening the change.

Verification

  • latestReleaseVersion() has a table test covering all rows above plus the error cases;
    getLatestReleaseImage() is tested end to end against a scratch checkout whose
    VERSION contains 1.22.0-rc.0.
  • The bash mirror was run against the same inputs and produces byte-identical output.
  • go vet passes with every integration build tag set.

integration/util.go derived the "latest release" image straight from the VERSION
file. That holds on master, where VERSION is the last GA, but not on a release
branch: VERSION is bumped to the version being prepared (e.g. 1.22.0-rc.0) long
before the deploy job publishes that tag, and the integration job is a dependency
of deploy. So the query fuzz leg would pull an image that does not exist yet.

Resolve a pre-release version to the release preceding it instead, and add
CORTEX_LATEST_RELEASE_IMAGE as an escape hatch for the cases the version math
cannot cover (a major pre-release). The preload step in test-build-deploy.yml
mirrors the same rule.

Signed-off-by: Charlie Le <charlie_le@apple.com>
@dosubot dosubot Bot added ci/cd go Pull requests that update Go code labels Aug 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci/cd go Pull requests that update Go code size/L

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant