Add auto-labeling workflow for PRs based on changed paths

[leofang]

Summary

• Adds actions/labeler v6 workflow to automatically apply module labels based on which directories a PR touches
• Adds .github/labeler.yml config with 4 directory-to-label mappings:
  • cuda_bindings/** → cuda.bindings
  • cuda_core/** → cuda.core
  • cuda_pathfinder/** → cuda.pathfinder
  • .github/** and ci/** → CI/CD
• Labels are only added, never removed (sync-labels: false by default in v6)
• Uses pull_request_target for fork PR support (safe — only reads PR metadata, no code checkout)
• Skips on non-NVIDIA forks via github.repository_owner == 'NVIDIA'

How it works with #1815

The auto-labeler runs on opened/synchronize and adds labels → this fires a labeled event → the metadata check from #1815 re-runs and sees the label(s). The two workflows complement each other naturally without needing explicit ordering.

Closes #1025

Test plan

• Open a test PR touching cuda_core/ — verify cuda.core label is applied
• Open a test PR touching .github/ or ci/ — verify CI/CD label is applied
• Open a PR touching multiple directories — verify multiple labels applied
• Verify manually added labels are not removed

🤖 Generated with Claude Code

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[mdboom]

Maybe include a link to the actions/labeler project docs?

[rwgk]

+1

[cpcloud]

The only time this would be false is on a fork, but who cares about that? If someone wants to label PRs on their fork, that doesn't affect anything in this repo, and who are we to prevent someone from labeling PRs on their fork?

[rwgk]

It's really just "don't bother running this where it doesn't apply." The guard just avoids running automation that would likely fail or be meaningless on forks, but it doesn't actively prevent anything. Seems like a good default to me.

[cpcloud]

Who's consuming these labels, and for what purpose?

[rwgk]

Archiving by-product of looking at this PR (generated by Cursor Opus 4.6 1M Thinking):

---

Label considerations for cuda_python/

Current state

PR #1818 introduces auto-labeling with four labels mapped to directory paths:

Label	Path(s)
cuda.bindings	cuda_bindings/**
cuda.core	cuda_core/**
cuda.pathfinder	cuda_pathfinder/**
CI/CD	.github/**, ci/**

cuda_python/ has no mapping and would not trigger any label.

Why cuda.bindings is not a fit for cuda_python/

cuda_python is a metapackage. Its setup.py declares dependencies on both
cuda-bindings and cuda-pathfinder:

install_requires=[
    f"cuda-bindings{matcher}{version}",
    "cuda-pathfinder~=1.1",
],

Labeling cuda_python/** changes as cuda.bindings would be misleading:
the metapackage is not part of the bindings package, and changes to it are
typically about project-wide docs, release notes, or packaging -- not the
bindings layer specifically.

Evidence from git history

Out of 101 commits touching cuda_python/, 28 (~28%) touch only
cuda_python/ (and sometimes root-level files like README.md) without
touching any of cuda_bindings/, cuda_core/, cuda_pathfinder/, .github/,
or ci/. Under the current labeler config these PRs would receive no label.

Those 28 commits break down as:

• Metapackage packaging and versioning -- setting up the pure-Python wheel,
  dynamic version/dependencies, version specifier fixes, tag regex changes.
• Project-wide docs and release notes -- adding release notes for
  cuda-python versions, Sphinx theme/tooling changes, doc build fixes, project
  list and description updates.
• Metapackage housekeeping -- README symlink, DESCRIPTION.rst cleanup,
  pathfinder mention in release notes.

These are legitimate, recurring changes with no natural home in the existing
four labels.

Recommendation

Introduce a cuda.python label mapped to cuda_python/**. This keeps every
subpackage directory covered by a label and avoids misattributing metapackage
work to a subpackage it does not belong to.

[rwgk]

I know it's still in draft, but it looks good to me.

Adding a cuda.python label would seem useful (in another PR):

#1818 (comment)

[rwgk]

It's really just "don't bother running this where it doesn't apply." The guard just avoids running automation that would likely fail or be meaningless on forks, but it doesn't actively prevent anything. Seems like a good default to me.

[rwgk]

+1