ci(release): keep rolling pointers off pre-release tags - #910
Conversation
A `vX.Y.Z-rc.N` tag published `:latest` and overwrote `openapi-latest.json`, so the moment a release was built it was also the default anyone pulling `api7/aisix` got — leaving no point at which a candidate exists as a real, installable artifact but is not yet what users receive. A pre-release tag now publishes only its own version-pinned image tag and its version-pinned OpenAPI spec. `:latest` gains a `!contains(ref_name, '-')` guard, and the `openapi-latest.json` upload (plus its CloudFront path) is skipped for pre-releases. metadata-action already omits `:X.Y` and `:X` for pre-release semver, so no other rolling tag moves. Stable-tag behaviour is unchanged.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 49 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
Comment |
There was a problem hiding this comment.
Pull request overview
Prevents prerelease tags from updating stable Docker and OpenAPI rolling pointers.
Changes:
- Excludes prereleases from the
latestimage tag. - Publishes versioned prerelease OpenAPI specs without replacing or invalidating
openapi-latest.json. - Documents stable and prerelease publishing behavior.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
`release-draft` asked GitHub to auto-detect where the "What's Changed" range starts. With `-rc.N` candidate tags now preceding every release, that auto-detection can land on a candidate and collapse the changelog to the near-empty rc → final delta. Start the range at `/releases/latest`, which GitHub defines as the newest published release that is neither draft nor prerelease. Falls back to auto-detection when there is none, i.e. the first-ever release.
Problem
A
vX.Y.Z-rc.Ntag is treated exactly like a stable release: it publishes:latestand overwritesopenapi-latest.json. So the moment a release is built it is also what anyone pullingapi7/aisixgets — there is no point in the pipeline where a candidate exists as a real, installable artifact but is not yet the default users receive. That is the point where release QA needs to run.Change
A pre-release tag now publishes only its own version-pinned artifacts:
:latestgains a!contains(github.ref_name, '-')guard.metadata-actionalready omits{{major}}.{{minor}}and{{major}}for pre-release semver (asrelease-draft.ymlalready notes), so with this guard no rolling tag moves at all.openapi-<version>.jsonfor a candidate — QA and the docs build can read it — but skipsopenapi-latest.jsonand drops it from the CloudFront invalidation list.vX.Y.Z-rc.Ntherefore yields:X.Y.Z-rc.N+:sha-<short>and nothing else.release-draft.ymlalready flags-rctags as prerelease, keeps the release a draft, and omits the rolling-tag sentence from the notes — but it asked GitHub to auto-detect where the changelog range starts, and with candidate tags now preceding every release that can land on a candidate and collapse "What's Changed" to the near-empty rc → final delta. It now starts the range at/releases/latest, which GitHub defines as the newest published release that is neither draft nor prerelease, falling back to auto-detection for the first-ever release.Behaviour change
Stable tags are unaffected — same tags, same uploads, and the changelog range they get is the one auto-detection was already producing. Only pre-release tags behave differently, and they have never been used in this repo.
Tests
Workflow trigger conditions are not reachable from the repo's test suites; the real proof is the first
-rctag. Locally verified:actionlintclean on both changed files,bash -non everyrunblock, the pre-release branch of the OpenAPI upload simulated over both tag shapes (v0.9.0→ publishes latest,v0.9.0-rc.1→ does not), and the changelog-range branch simulated for a stable tag, a candidate tag, and a repo with no published release. The# commentsits above thetags:block rather than inside it, so nothing depends on howmetadata-actionparses comments in that input.