fix(action): restrict prev-nightly lookup to same major.minor series - #44
Merged
Conversation
The `prev-ghcr` step walked past all 0.40 nightly tags and onto a
stray 0.41 nightly because `sort -V` orders 0.41 > 0.40
lexicographically. At the time this step runs, the current build's
own tag hasn't been pushed yet, so the loop's
`if [ "$tag" = ... ]` break never triggers — the loop ends
naturally after iterating every existing tag, and PREV_TAG becomes
the 0.41 nightly.
Result: patches were generated FROM the 0.41 binary and stamped
with `from-version: 0.41.x-dev.Y` — useless to any user on the
0.40 series.
Fix: filter TAGS to only those in the same major.minor series as
the current build before iterating. `MAJOR_MINOR` is parsed from
VERSION (`echo "${VERSION}" | cut -d. -f1,2` → e.g. `0.40`).
For `0.40.0-dev.X` builds the loop only sees
`nightly-0.40.x-dev.*` tags; for `0.41.0-dev.X` only
`nightly-0.41.x-dev.*`. First build of a new series falls through
with PREV_TAG="" and the existing skip-empty-PREV path handles it
cleanly.
Also uses `grep -F` (fixed-string) so the dot in MAJOR_MINOR is
treated literally rather than as a regex metacharacter — defensive
parity with the rest of the script.
Port of getsentry/cli#1329's same-series filter into the action
(so consumers adopting `generate-ghcr` don't need to re-implement
this safeguard).
Contributor
|
This was referenced Aug 1, 2026
BYK
added a commit
to getsentry/cli
that referenced
this pull request
Aug 1, 2026
BYK/binpatch#44 ported the same-series filter from #1329 into the binpatch action's prev-ghcr step, so consumers adopting `generate-ghcr` no longer need to re-implement this safeguard. This bumps both the runtime dep (`binpatch` ^0.4.1 → ^0.4.2) and the action ref (BYK/binpatch/action@0.4.1 → @0.4.2) so the migration actually picks up the action's own fix.
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.
The
prev-ghcrstep walked past all 0.40 nightly tags and onto a stray 0.41 nightly becausesort -Vorders 0.41 > 0.40 lexicographically. At the time this step runs, the current build's own tag hasn't been pushed yet, so the loop'sif [ "$tag" = ... ]break never triggers — the loop ends naturally after iterating every existing tag, and PREV_TAG becomes the 0.41 nightly.Result: patches were generated FROM the 0.41 binary and stamped with
from-version: 0.41.x-dev.Y— useless to any user on the 0.40 series.Fix
Filter TAGS to only those in the same major.minor series as the current build before iterating.
MAJOR_MINORis parsed from VERSION (echo "${VERSION}" | cut -d. -f1,2→ e.g.0.40). For0.40.0-dev.Xbuilds the loop only seesnightly-0.40.x-dev.*tags; for0.41.0-dev.Xonlynightly-0.41.x-dev.*. First build of a new series falls through with PREV_TAG="" and the existing skip-empty-PREV path handles it cleanly.Also uses
grep -F(fixed-string) so the dot in MAJOR_MINOR is treated literally rather than as a regex metacharacter.Relationship to getsentry/cli#1329
This is the action-side port of getsentry/cli#1329's hand-rolled
MAJOR_MINORfilter. getsentry/cli is migrating to use this action (PR #1330) so this fix lands ahead of the migration completing.Verification