CI: Detect changed paths and gate cuda.bindings tests

[cpcloud]

Summary

• Adds a detect-changes job to ci.yml using native git merge-base + git diff --name-only to classify which top-level modules changed in a PR
• Composes gating outputs respecting the dependency graph: cuda_pathfinder → cuda_bindings → cuda_core
• Threads skip-bindings-test input through test-wheel-linux.yml and test-wheel-windows.yml so cuda.bindings tests are skipped when only unrelated modules changed
• Splits the overloaded SKIP_CUDA_BINDINGS_TEST env var into two orthogonal flags: USE_BACKPORT_BINDINGS (artifact fetch for CTK major mismatch) and SKIP_CUDA_BINDINGS_TEST (test-time gate)
• Non-PR events (push to main, tag, schedule) unconditionally run everything
• Build-side gating outputs are emitted but not yet consumed (follow-up PR)

Closes #299

🤖 Generated with Claude Code

[github-actions]

Doc Preview CI
🚀 View preview at https://nvidia.github.io/cuda-python/pr-preview/pr-1908/
https://nvidia.github.io/cuda-python/pr-preview/pr-1908/cuda-core/
https://nvidia.github.io/cuda-python/pr-preview/pr-1908/cuda-bindings/
https://nvidia.github.io/cuda-python/pr-preview/pr-1908/cuda-pathfinder/
Preview will be ready when the GitHub Pages deployment is complete.

[rwgk]

Generated with Cursor GPT-5.4 Extra High Fast

---

Reviewed the final tree for PR 1908 at commit d205955

actionlint passed on the touched workflows, so the notes below are about CI behavior / control flow, not YAML syntax.

1. High: detect-changes can fail without clearly failing the final required status

Evidence

• All three test jobs now depend on detect-changes:
  • .github/workflows/ci.yml:284
  • .github/workflows/ci.yml:309
  • .github/workflows/ci.yml:334
• The terminal checks job does not depend on detect-changes directly and only inspects:
  • doc
  • test-linux-64
  • test-linux-aarch64
  • test-windows
    at .github/workflows/ci.yml:365
• The shell logic in checks only treats failure and cancelled as errors:
  • .github/workflows/ci.yml:394
  • .github/workflows/ci.yml:398

Why this matters

• If detect-changes fails, the downstream test jobs can become skipped because a required dependency did not complete successfully.
• In that state, checks may still exit 0 because it does not treat those skipped results as an error.
• Result: a broken path-detection step could suppress or reduce CI coverage without producing a clearly failing final status.

Agent hint

• Re-check GitHub Actions needs semantics for always() plus an upstream failed prerequisite leading to downstream skipped.
• The most direct fix is probably one of:
  • add detect-changes to checks.needs and explicitly require needs.detect-changes.result == 'success'
  • or treat unexpected skipped test jobs as fatal when doc_only != true
• Preserve the intended [doc-only] skip behavior while making accidental skips fail closed.

2. Medium: diff baseline is hardcoded to origin/main

Evidence

• detect-changes computes the merge base against origin/main at .github/workflows/ci.yml:118.
• The repo also maintains a release/backport branch in ci/versions.yml:4:
  • backport_branch: "12.9.x"

Why this matters

• For PR 1908, whose base is main, this is fine.
• If the same pull-request/* CI path is ever used for PRs targeting 12.9.x or another non-main branch, changed-path classification will be wrong.
• Wrong classification can suppress outputs such as test_bindings, which means under-testing on backport / release PRs.

Agent hint

• First confirm whether pull-request/* branches are ever created for non-main PR bases in this repo.
• If yes, derive the true PR base branch before git merge-base instead of assuming main.
• Because this workflow runs on pushes to pull-request/*, github.base_ref may not be available; one workable approach is to resolve the PR number from github.ref_name and query gh pr view --json baseRefName.
• If non-main PR bases are impossible by construction, add a short comment documenting that invariant so future readers do not "fix" it incorrectly.
• This area already had churn within the PR history, so the next agent should validate the actual branch-generation semantics before changing behavior.

Bottom line

• I did not find a concrete bug in the USE_BACKPORT_BINDINGS / SKIP_CUDA_BINDINGS_TEST split itself.
• The two findings above are the only items that looked important enough to hand back to the PR author.

[rwgk]

Cursor GPT-5.4 Extra High Fast generated:

---

Reviewed the current final tree for PR 1908 at commit c11f901.

Findings

1. Medium: detect-changes can under-classify cross-package renames

Evidence

• .github/workflows/ci.yml:134 builds the changed-path list with:
  • git diff --name-only "$base"...HEAD
• .github/workflows/ci.yml:141 through .github/workflows/ci.yml:146 classify changed modules only from those reported paths.
• The resulting test_bindings output then drives:
  • .github/workflows/ci.yml:308
  • .github/workflows/ci.yml:333
  • .github/workflows/ci.yml:358

Why this matters

• In a pure rename or move, git diff --name-only can report only the destination path.
• That means a refactor like cuda_bindings/... -> cuda_core/... can produce bindings=false even though the bindings package lost code.
• In that case, skip-bindings-test may become true and reduce CI coverage for the PR.
• The same shape of issue can apply to moves across shared prefixes.

Agent hints

• The simplest fail-closed fix is probably:
  • use git diff --no-renames --name-only "$base"...HEAD
  • this reports both old and new paths for renames/moves, which is better for path-based gating
• A more explicit alternative is:
  • use git diff --name-status -M "$base"...HEAD
  • when status is R*, inspect both the old path and the new path
• If the PR author prefers to keep the current implementation for now, at least add a short comment documenting the rename blind spot so future readers do not assume the gating is exact.
• A focused regression check would be valuable here, even if it is just a small shell-based test or script fixture for the detect-changes truth table.

Notes

• The two earlier findings from my first review look addressed in the current branch.
• Base-branch resolution now uses PR metadata via nv-gha-runners/get-pr-info in .github/workflows/ci.yml:115 through .github/workflows/ci.yml:124, which looks appropriate for pull-request/<N> refs that may target non-main branches.
• The final checks job now includes detect-changes in needs at .github/workflows/ci.yml:382 and explicitly requires it to succeed at .github/workflows/ci.yml:416, so a broken gating step should no longer hide behind skipped downstream jobs.
• I did not find a new issue in the USE_BACKPORT_BINDINGS / SKIP_CUDA_BINDINGS_TEST split; that part still looks coherent.
• Residual caution: this is still a static CI review. I do not see a dedicated automated check for the detect-changes truth table, so future refactors could regress rename/path handling fairly easily.

Bottom line

• I see one remaining medium-confidence CI edge case around rename handling.
• Otherwise, the previously reported issues appear fixed.

[rwgk]

I think this is fine to merge-as-is and work on the

detect-changes can under-classify cross-package renames

finding in a follow-on PR. I'm fine either way.

[cpcloud]

Thanks @rwgk — both findings addressed:

Finding 1 (High) — detect-changes could silently cascade into skipped tests. Added detect-changes to checks.needs with an explicit needs.detect-changes.result == 'success' guard, so a gating-step failure now fails the final status rather than producing a green run with reduced coverage. Commit c11f901. The legitimate [doc-only] skip path is unaffected (detect-changes stays success in that case).

Finding 2 (Medium) — diff baseline hardcoded to origin/main. Confirmed via copy-pr-bot config that pull-request/<N> branches are populated regardless of the PR's base (including 12.9.x), so the hardcode was indeed wrong for backport PRs. Resolved the real base at runtime via nv-gha-runners/get-pr-info@main (already used elsewhere in this repo) and pass it to git merge-base. Fails loudly if the base can't be resolved rather than silently falling back. Commit f410ba6.

[leofang]

Thanks, @cpcloud @rwgk! I noticed this fails on the main branch, could you take a look?
https://github.com/NVIDIA/cuda-python/actions/runs/24566662170/job/71828554003

[rwgk]

It's failing in the last line here:

      - name: Detect changed paths
        id: filter
        if: ${{ startsWith(github.ref_name, 'pull-request/') }}
        env:
          BASE_REF: ${{ fromJSON(steps.pr-info.outputs.pr-info).base.ref }}

Maybe the env is evaluated even if the if evaluates to false?