Commit 6f2968e
committed
fix: fail the release job when the latest-release lookup errors (#DS-3378)
The badge decision read the release currently holding Latest with
`2> /dev/null || true`, so auth, rate-limit and transient GitHub failures all
came back as an empty `current` — indistinguishable from "this repository has
no releases yet". Empty means "nothing holds the badge", so a 19.x patch tagged
during a GitHub blip would have created itself with `--latest=true` and taken
the badge off 20.x. Verified against the pre-fix line with a stubbed gh: a 503
on the lookup yields `--latest=true` for tag 19.9.0.
Same treatment the existence check above already got: "release not found" is
the answer for a repository with no releases at all — checked against
github/gitignore with gh 2.97.0, it is the same string the tag lookup returns —
and there the first release does legitimately take the badge. Anything else
fails the job. stdout and stderr stay separate here because stdout carries the
tag name, so the message goes through a file rather than the `2>&1 1>/dev/null`
swap used above.1 parent 7cf2f5a commit 6f2968e
1 file changed
Lines changed: 15 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
121 | 121 | | |
122 | 122 | | |
123 | 123 | | |
124 | | - | |
| 124 | + | |
| 125 | + | |
| 126 | + | |
| 127 | + | |
| 128 | + | |
| 129 | + | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
| 136 | + | |
| 137 | + | |
| 138 | + | |
125 | 139 | | |
126 | 140 | | |
127 | 141 | | |
| |||
0 commit comments