fix(ci): surface API response when CLI download test fails to parse version - #12907
Open
pujitha24 wants to merge 6 commits into
Open
fix(ci): surface API response when CLI download test fails to parse version#12907pujitha24 wants to merge 6 commits into
pujitha24 wants to merge 6 commits into
Conversation
…ersion
Motivation
The nightly rad CLI download workflow has produced over 130 "CLI nightly
test failed" issues over the past year, each closed by maintainers as an
unexplained transient failure. The CI log always cuts off right after
"GitHub API call successful" with no further script output before make
reports a bare "Error 1", giving maintainers nothing to diagnose.
Approach
build/test-cli-download.sh extracts the release version with:
RAD_VERSION=$(echo "$api_response" | grep "tag_name" | grep -v rc | awk ... | sed ...)
if [ -z "$RAD_VERSION" ]; then
echo "Failed to extract RAD_VERSION from API response"
exit 1
fi
The script runs under `set -euo pipefail`. When the GitHub API response
contains no "tag_name" line (for example, an API error body instead of a
releases array), the pipeline returns a non-zero status, and under
`set -e` the `RAD_VERSION=$(...)` assignment statement itself aborts the
script immediately with that status -- before the `[ -z "$RAD_VERSION" ]`
check, and its error message, are ever reached. The intended diagnostic is
dead code.
The fix adds `|| true` to the assignment so the pipeline's non-zero status
no longer kills the script early, letting execution reach the existing
empty-value check, which now also prints the raw API response body so a
future failure is actually diagnosable. The success path is unchanged:
`|| true` only affects the exit status used by `set -e`, not what the
command substitution captures on stdout.
This does not claim to fix the specific historical cause of issue radius-project#12906
(GitHub did not preserve that run's raw API response, so it can't be
confirmed) -- only that the script's own error handling was unreachable
dead code, which is fixed here and independently useful for whatever
causes the next occurrence.
Validation
- bash -n build/test-cli-download.sh: syntax OK.
- shellcheck --rcfile .github/linters/.shellcheckrc build/test-cli-download.sh:
clean, mirrors the repo's `make lint-shell` CI target and its pinned
config (`make lint-shell` itself could not run locally because its
Go-based tool installer needs disk space this sandbox does not have --
an environment limitation, not a code issue).
- Ran build/test-cli-download.sh linux amd64 rad "" "" against the live
GitHub API: unchanged happy-path output, script exits 0, and the real
rad_linux_amd64 binary downloads successfully.
- Reproduced the failure mode directly: with api_response mocked to a
GitHub-style API error body ({"message":"API rate limit exceeded ..."}),
the pre-fix script exits 1 with zero output after "GitHub API call
successful" (matching the exact log pattern from issue radius-project#12906);
the post-fix script exits 1 and prints the diagnostic
"Failed to extract RAD_VERSION from API response:" followed by the
response body.
Report: radius-project#12906
Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
Assisted-by: claude-sonnet-5 (via Claude Code)
pujitha24
had a problem deploying
to
external-contributor-approval
September 4, 2026 02:02 — with 
GitHub Actions
Error
GitHub Actions
Error
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The script’s earlier curl failure handling is still likely unreachable under set -e when curl fails inside command substitution, leaving a remaining silent-failure path in the same workflow.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR improves diagnosability of the nightly rad CLI download test by ensuring version extraction failures from the GitHub Releases API don’t terminate the script prematurely under set -euo pipefail, and by printing the API response body when extraction fails.
Changes:
- Prevent premature exit when the version-extraction
greppipeline finds no matches (allowing the explicit empty-value error branch to run). - Emit the raw GitHub API response when
RAD_VERSIONcannot be extracted.
File summaries
| File | Description |
|---|---|
| build/test-cli-download.sh | Makes the version-extraction step resilient to non-matching grep under set -e and prints the API response on extraction failure for easier debugging. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+78
to
+82
| # Extract version from API response using grep, awk, and sed. | ||
| # `|| true` stops a non-matching grep (e.g. an API error response with no | ||
| # "tag_name") from tripping `set -e` here, before the empty-value check below | ||
| # can report a useful error. | ||
| RAD_VERSION=$(echo "$api_response" | grep "tag_name" | grep -v rc | awk 'NR==1{print $2}' | sed -n 's/"\(.*\)",/\1/p') || true |
Comment on lines
+85
to
+86
| echo "Failed to extract RAD_VERSION from API response:" | ||
| echo "$api_response" |
pujitha24
requested a deployment
to
external-contributor-approval
September 4, 2026 15:30 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
pujitha24
had a problem deploying
to
external-contributor-approval
September 8, 2026 18:42 — with
GitHub Actions
Error
GitHub Actions
Error
pujitha24
had a problem deploying
to
external-contributor-approval
September 9, 2026 14:44 — with
GitHub Actions
Error
GitHub Actions
Error
pujitha24
had a problem deploying
to
external-contributor-approval
September 10, 2026 12:04 — with
GitHub Actions
Error
GitHub Actions
Error
pujitha24
requested a deployment
to
external-contributor-approval
September 11, 2026 11:55 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
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
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.
Summary
Fixes a silent-failure bug in
build/test-cli-download.sh(used by the nightly rad CLI download workflow) where, underset -euo pipefail, a non-matchinggrepwhile extracting the release version from the GitHub API response would abort the script immediately -- before the script's own[ -z "$RAD_VERSION" ]error-handling branch (and its diagnostic message) could ever run. The fix (|| trueon the extraction pipeline) lets that branch execute as intended, and it now also prints the raw API response body so a future failure is actually diagnosable.Reason for change
The nightly rad CLI download workflow has generated 130+ "CLI nightly test failed" issues over the past year, each closed by maintainers as an unexplained transient failure because the CI log always cuts off right after "GitHub API call successful" with no further output before
makereports a bare "Error 1". The script's own error-reporting code for this exact case was unreachable dead code due to aset -e/pipefailinteraction with agreppipeline. This change does not claim to know the root cause of the underlying API failures (GitHub does not retain the raw API response from past runs, so it can't be confirmed to have been a rate-limit response specifically) -- only that the diagnostic dead-code bug is real, reproducible, and now fixed, so the next occurrence will actually be diagnosable.Fixes #12906
How to test
To see the fix in action, mock
api_response(e.g.api_response='{"message":"API rate limit exceeded"}') in place of thecurlcall and re-run the script: before the fix it exits 1 with no output after "GitHub API call successful"; after the fix it prints the response body before exiting 1.Note:
make lint-shellcould not be run directly in this sandbox because its Go-based tool installer needs disk space that isn't available here (an environment limitation, not a code issue);shellcheckwas run directly against the repo's pinned.shellcheckrcas a faithful substitute for that specific CI check.File change summary
build/test-cli-download.sh|| trueso a non-matchinggrepin the version-extraction pipeline no longer silently kills the script underset -e; print the raw API response body when version extraction fails.