From 6f90cad622b4d7c6ad1d7041108eaf05e1ef7c05 Mon Sep 17 00:00:00 2001
From: Burak Yigit Kaya <byk@sentry.io>
Date: Sat, 1 Aug 2026 00:46:49 +0000
Subject: [PATCH] fix(action): restrict prev-nightly lookup to same major.minor
 series
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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).
---
 action/action.yml | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/action/action.yml b/action/action.yml
index b932982..9906929 100644
--- a/action/action.yml
+++ b/action/action.yml
@@ -232,10 +232,28 @@ runs:
 
         echo "${GH_TOKEN_IN}" | oras login "${REGISTRY}" -u "${ACTOR}" --password-stdin
 
-        # Newest versioned nightly tag strictly older than the one being built.
+        # Newest versioned nightly tag strictly older than the one being built,
+        # restricted to the same major.minor series as the current build.
+        # Without this filter, `sort -V` orders every 0.41 nightly after every
+        # 0.40 nightly (0.41 > 0.40), and the loop below walks past all 0.40
+        # tags and onto the 0.41 tag — even though the current build hasn't
+        # pushed its own tag yet, so the `if [ "$tag" = ... ]` break never
+        # triggers. Result: PREV_TAG becomes the 0.41 nightly, and the patch
+        # is 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. See getsentry/cli#1329 for the exact scenario.
         TAGS=$(oras repo tags "${FULL_REPO}" 2>/dev/null | grep "^${NIGHTLY_TAG_PREFIX}[0-9]" | sort -V || echo "")
+        # MAJOR_MINOR is e.g. "0.40" — restricts the loop to tags in the
+        # same series. First build of a new series falls through with
+        # PREV_TAG="" and the existing skip-empty-PREV path handles it.
+        MAJOR_MINOR=$(echo "${VERSION}" | cut -d. -f1,2)
+        # -F (fixed-string): the dot in MAJOR_MINOR is literal, not a regex
+        # metachar. In practice MAJOR_MINOR is always digits.digits and the
+        # upstream grep filters to ^nightly-[0-9], so this can't mis-match
+        # — but be defensive.
+        SAME_SERIES_TAGS=$(printf '%s\n' "$TAGS" | grep -F "${NIGHTLY_TAG_PREFIX}${MAJOR_MINOR}." || true)
         PREV_TAG=""
-        for tag in $TAGS; do
+        for tag in $SAME_SERIES_TAGS; do
           if [ "$tag" = "${NIGHTLY_TAG_PREFIX}${VERSION}" ]; then
             break
           fi