You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG]: release run lookup fails for signed/annotated tags #2146
The release workflow's auto-detection of the CI run ID breaks for signed release tags.
.github/RELEASE-core.md currently tells release managers to create signed tags with git tag -s .... Those are annotated tags. In ci/tools/lookup-run-id, the tag is resolved with:
COMMIT_SHA=$(git rev-parse "${REF}")
For an annotated tag, that returns the tag object SHA rather than the underlying commit SHA. We then pass that value to gh run list --commit, which is keyed on the commit SHA, so the lookup can fail to find the successful tag-triggered CI run.
This means the documented release path can fail even when the tag-triggered CI run completed successfully.
How to Reproduce
Create a signed or annotated tag for a commit on main.
Push the tag and wait for the tag-triggered CI workflow to finish successfully.
Run ci/tools/lookup-run-id --tag <tag> NVIDIA/cuda-python, or dispatch CI: Release and let it auto-detect the run ID.
The lookup may fail to find the successful run for that tag.
Expected behavior
Signed release tags should work on the documented happy path, and the release workflow should be able to resolve the successful tag-triggered CI run automatically.
Notes
I think the fix is just to peel the tag before passing it to gh run list, for example:
COMMIT_SHA=$(git rev-list -n 1 "${REF}")
or:
COMMIT_SHA=$(git rev-parse "${REF}^{commit}")
This looks release-blocking for cuda.core, since the release guide explicitly recommends git tag -s.
This issue does not make sense to me. The release workflow, including the CI tools lookup-run-id, is used exclusively by the team and it's been working very well for many releases. What prompted this issue?
My only point is that the current code doesn’t match the documented git tag -s flow, so if that path no longer matters I’m happy to close this as a docs/process mismatch rather than a blocker.
Activity
leofang commentedon May 29, 2026
This issue does not make sense to me. The release workflow, including the CI tools
lookup-run-id, is used exclusively by the team and it's been working very well for many releases. What prompted this issue?fallintoplace commentedon May 29, 2026
My only point is that the current code doesn’t match the documented
git tag -sflow, so if that path no longer matters I’m happy to close this as a docs/process mismatch rather than a blocker.