Is this a duplicate?
Type of Bug
Silent Failure
Component
Infrastructure
Describe the bug
ci/cleanup-pr-previews is supposed to remove preview folders for closed, merged, and deleted PRs. The deleted-PR case never matches.
For a PR that no longer exists, gh api ... --jq '.state' exits non-zero but still prints the 404 JSON body to stdout. The || echo "not_found" fallback is then appended to that output instead of replacing it:
|
PR_STATUS=$(gh api repos/"${REPOSITORY}"/pulls/"${PR_NUMBER}" \ |
|
--header "Accept: application/vnd.github+json" \ |
|
--jq '.state' 2>/dev/null || echo "not_found") |
PR_STATUS becomes {"message":"Not Found",...}not_found. That falls through to the *) branch, which logs UNKNOWN and keeps the folder.
This is happening now with docs/pr-preview/pr-2308 on gh-pages. #2308 no longer exists (both the pulls and issues endpoints return 404), and its preview has been there since 2026-07-07. The last scheduled run logged:
[UNKNOWN] PR #2308 has unexpected status: {"message":"Not Found","documentation_url":"https://docs.github.com/rest/pulls/pulls#get-a-pull-request","status":"404"}not_found
...
Folders to remove: 0
https://github.com/NVIDIA/cuda-python/actions/runs/36217108226
How to Reproduce
Run the script in dry-run mode from the repo root (read-only; it needs GH_TOKEN):
GH_TOKEN="$(gh auth token)" ci/cleanup-pr-previews --dry-run
Relevant output on current main:
[CHECK] Checking PR #2308...
[UNKNOWN] PR #2308 has unexpected status: {"message":"Not Found","documentation_url":"https://docs.github.com/rest/pulls/pulls#get-a-pull-request","status":"404"}not_found
...
Total PR preview folders: 25
Open PRs: 24
Folders to remove: 0
One of the 25 folders belongs to a PR that no longer exists, but nothing is marked for removal.
The failing call on its own:
PR_STATUS=$(gh api repos/NVIDIA/cuda-python/pulls/2308 \
--header "Accept: application/vnd.github+json" \
--jq '.state' 2>/dev/null || echo "not_found")
printf '[%s]\n' "$PR_STATUS"
With gh 2.97.0 this prints:
[{"message":"Not Found","documentation_url":"https://docs.github.com/rest/pulls/pulls#get-a-pull-request","status":"404"}not_found]
Expected behavior
A 404 from the pulls endpoint is classified as not_found, and the folder is removed. A fix should keep other failures (network errors, 5xx) out of the removal path, so a transient API error can't delete an open PR's preview.
#2914 also edits this script, though not these lines. I can send a small fix for the status check, before or after #2914 lands, whichever is easier to review.
Is this a duplicate?
Type of Bug
Silent Failure
Component
Infrastructure
Describe the bug
ci/cleanup-pr-previewsis supposed to remove preview folders for closed, merged, and deleted PRs. The deleted-PR case never matches.For a PR that no longer exists,
gh api ... --jq '.state'exits non-zero but still prints the 404 JSON body to stdout. The|| echo "not_found"fallback is then appended to that output instead of replacing it:cuda-python/ci/cleanup-pr-previews
Lines 137 to 139 in f9ed2bd
PR_STATUSbecomes{"message":"Not Found",...}not_found. That falls through to the*)branch, which logs UNKNOWN and keeps the folder.This is happening now with
docs/pr-preview/pr-2308on gh-pages. #2308 no longer exists (both the pulls and issues endpoints return 404), and its preview has been there since 2026-07-07. The last scheduled run logged:https://github.com/NVIDIA/cuda-python/actions/runs/36217108226
How to Reproduce
Run the script in dry-run mode from the repo root (read-only; it needs
GH_TOKEN):GH_TOKEN="$(gh auth token)" ci/cleanup-pr-previews --dry-runRelevant output on current
main:One of the 25 folders belongs to a PR that no longer exists, but nothing is marked for removal.
The failing call on its own:
With gh 2.97.0 this prints:
Expected behavior
A 404 from the pulls endpoint is classified as
not_found, and the folder is removed. A fix should keep other failures (network errors, 5xx) out of the removal path, so a transient API error can't delete an open PR's preview.#2914 also edits this script, though not these lines. I can send a small fix for the status check, before or after #2914 lands, whichever is easier to review.