fix(helm-deploy-eks): pass makeLatest=legacy so GH re-evaluates latest on prod#155
Merged
Merged
Conversation
…t on prod
Surfaced 2026-07-13 on encodium/batch: rc.9 stayed pinned as 'latest'
even after later rc iters were successfully promoted (all had prerelease
flipped to false).
Root cause: GH REST PATCH /releases/{id} only reevaluates the 'latest'
designation if the request explicitly includes make_latest. Per GH docs:
'If not defined, the release will not be reevaluated.' The ncipollo/
release-action documents makeLatest=legacy as its default but when the
input is omitted it doesn't include the field in the outgoing PATCH.
Fix: pass makeLatest=legacy explicitly. GitHub then compares this
release against the current latest by semver + creation date and
re-designates if higher. For RT v2 tag shape (vX.Y.Z-rc.<date>.<iter>),
every promoted rc becomes latest when semver-higher than the previous
latest. Rollback deploys of older rc's correctly leave the newer rc
as latest (legacy doesn't downgrade).
PR SummaryLow Risk Overview Without that field on Reviewed by Cursor Bugbot for commit 67f0fb4. Bugbot is set up for automated code reviews on this repo. Configure here. |
pdodgen-revparts
added a commit
that referenced
this pull request
Jul 13, 2026
…on rc tags) (#156) fix(helm-deploy-eks): switch makeLatest legacy → true (legacy semver broken) Follow-up to #155. Tested `legacy` against encodium/batch rc.9 vs rc.12 on 2026-07-13 and it did NOT re-designate. GH's semver comparator appears to treat `2026-07-09` in the prerelease identifier as an alphanumeric segment (hyphens present), then compares subsequent segments incorrectly — so `-rc.2026-07-09.12` does not rank above `-rc.2026-07-09.9` in its impl. Switching to `make_latest: true`. Semantic under RT v2: 'latest release' = whatever is currently running in prod. Every successful prod deploy re-designates latest. Rollback deploys of older rc's correctly move latest backwards to reflect what's actually deployed — which is what you want during an incident anyway (latest = truth of what's live). Main-branch clean tags (`vX.Y.Z`) go through a different action on create (not PATCH) and use normal semver ordering — not affected by this change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom
encodium/batch's releases page shows an older rc as 'latest' even though newer rc iters were successfully promoted to prod after it (all have
prerelease: false).Root cause
GitHub REST
PATCH /releases/{id}only reevaluates the 'latest' designation if the request explicitly includesmake_latest. Per GH docs: 'If not defined, the release will not be reevaluated.'The ncipollo/release-action documents
makeLatest: legacyas its default, but when the input is omitted it doesn't include the field in the outgoing PATCH — so we hit the no-reevaluation case. Every promoted rc keeps the flag from the FIRST one that had it, regardless of what came after.Fix
Pass
makeLatest: legacyexplicitly. GitHub then re-evaluates on every prod deploy:Rollback safety:
legacyNEVER downgrades. If prod is on rc.12 and someone deploys rc.7 as a rollback, GH sees rc.7 < rc.12 and leaves rc.12 as latest. That's the semantic we want.Companion
A one-time API repair of encodium/batch's current state is planned to nudge GH into re-evaluating rc.12 — not part of this PR.