ci(release): reserve legacy Docker publication for v2 - #1353
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
frahlg
added
the
no-changeset
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8fbdb3d983
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| : "${GITHUB_REPOSITORY:?GITHUB_REPOSITORY is required}" | ||
| : "${GH_TOKEN:?GH_TOKEN is required}" | ||
|
|
||
| bash scripts/check-legacy-release-line.sh "${FTW_RELEASE_TAG}" |
There was a problem hiding this comment.
When release-assets.yml is rerun from master to recover a pre-change v2 tag, the publish job checks out that tag at the workspace root and the current helpers under .release-workflow. This lookup therefore searches the old tag's scripts/ directory, where the newly added guard does not exist, and fails after the exact stable image aliases may already have been written; the documented recovery run can never reach latest-alias or GitHub release publication. Resolve the guard relative to BASH_SOURCE so it comes from the same helper checkout.
AGENTS.md reference: AGENTS.md:L226-L229
Useful? React with 👍 / 👎.
| tag="${1:?release tag is required}" | ||
| if [[ "${tag}" =~ ^v2\.[0-9]+\.[0-9]+(-beta\.[0-9]+)?$ ]]; then |
There was a problem hiding this comment.
The exhaustive release-path case in .github/scripts/classify-test-changes.sh does not include this new script. Consequently, a future PR that changes only the allowed release-line regex is classified with every suite disabled, skipping release-workflow-test and the new allowed/blocked-tag coverage; add this path to the classifier and its contract test.
Useful? React with 👍 / 👎.
1 participant
The current Docker release workflows still accept a 3.x or native 0.x tag even though installed 1.x and 2.x boxes read the shared GitHub and GHCR discovery slots. An accidental publication there could send an old box across the migration boundary.
This change checks the release line before the current beta workflow creates a tag, before the current asset workflow builds or publishes a stable release, and before the paired
:latestalias promotion changes any image or GitHub release state. These paths accept onlyv2.X.Yandv2.X.Y-beta.N. Native 0.x needs a separate workflow with exact tags; the old shared latest slots stay on 2.x. The shipping update guide now distinguishes this accepted direction from the current updater.Validation:
make verifypassed, including tests that 2.x tags pass and 1.x, 3.x, and 0.x tags fail before alias mutation. Both edited workflow YAML files parse.This guards workflow code from this commit onward. Existing immutable 3.x tag refs still contain their older workflow code, and
release.ymlcan prepare a stable draft beforerelease-assets.ymlruns. The next release-policy change must add the same pre-tag check torelease.ymlonce open PR #1045, which already edits that file, is resolved. Until then, do not dispatch a 3.x stable promotion from an older ref. This PR does not publish a release or migrate a box.