Skip to content

[BUG]: release run lookup fails for signed/annotated tags #2146

Closed

Description

@fallintoplace

Type of Bug

Something else

Component

Infrastructure

Describe the bug

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

  1. Create a signed or annotated tag for a commit on main.
  2. Push the tag and wait for the tag-triggered CI workflow to finish successfully.
  3. Run ci/tools/lookup-run-id --tag <tag> NVIDIA/cuda-python, or dispatch CI: Release and let it auto-detect the run ID.
  4. 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.

Activity

  1. leofang commented on May 29, 2026

    @leofang
    Member

    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?

  2. fallintoplace commented on May 29, 2026

    @fallintoplace
    ContributorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    triageNeeds the team's attention

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions