[rwgk]

codex on behalf of Ralf:

Summary

Build CUDA 12 and CUDA 13 bindings from their source roots on main, replacing branch-sourced maintenance artifacts.

• For ordinary PRs, reuse unaffected artifacts only from a successful push CI run on the PR base branch at the exact merge-base commit, with the complete required artifact set; otherwise build and test everything. Bindings release tags deliberately select only their matching bindings/metapackage line, without a reusable baseline.
• For a bindings-only change, rebuild its bindings and matching metapackage, reuse the unchanged merged Core wheel, and retain Core tests against the affected bindings major. Core source changes rebuild both ABI variants.
• Build both bindings lines and matching metapackages when required; route artifact downloads and source-distribution checks through the selected root.
• Write each line's build paths and artifact names through the Python bindings_config write-build-env command, with a small shell wrapper for platform setup.
• Keep concise component/major names in the PR checks view, including meta12 and meta13. The workplan summary exposes its JSON, including exact baseline identity and build/test decisions.
• Test meaningful outcomes: selected coverage, correct release artifacts, complete merged Core wheels, and SCM milestones. Remove tests tied to Markdown wording, workflow text, or the exact shape of gh commands.
• Keep the planner bootstrap and host-side wheel-build interpreters on main's hardened Python setup, preserving verified sccache and certificate safeguards.

Version Bootstrap and Platform Boundary

Copying maintenance sources does not make their later branch tags ancestors of main. Package versions still follow standard setuptools-scm progression from the selected line's reachable tags. When suitable history is absent, bindings_scm_version.py creates a local preview tag at a validated ancestor in a disposable build checkout. Existing suitable tags take precedence; the helper never pushes or moves tags.

A plain maintenance checkout is not guaranteed to derive the intended next patch version before an appropriate milestone is reachable. The local preview instructions use an independent disposable clone because linked worktrees share tags. Preview targets are coordinated across release branches: if another branch consumes the intended version, reserve the next unused target before building again. Minor-selector changes likewise need a matching milestone. A retained milestone on validated main history, followed by removal of temporary bootstrap calls, remains a separate follow-up; no retained tag is created by this PR.

Windows ARM64 builds omit CUDA 12 because that toolkit has no Windows ARM64 build. Linux and Windows x86-64 retain both registered majors. The next layer supplies the matching test-workflow interfaces.

Stack / Review Boundary

Previous: #3174. Next: #3176. The stack overview lists all six open PRs and the intended workflow.

#3174 through #3176 are intended to land together, with separate review scopes and cumulative CI at #3176; the first two are incomplete intermediate states. Release routing (#3177), maintenance policy (#3178), and the runtime fixes (#3182) follow that group. The complete proposed source tree is at #3182.

Baseline: main 03b4153574b3.

Suggested Review Order

1. ci/tools/compute_ci_plan.py - build/test selection and exact-baseline reuse.
2. ci/tools/env-vars and bindings_config.py - the small shell wrapper and Python build-environment writer.
3. .github/workflows/build-wheel.yml - builds, baseline downloads, and Core wheel merging.
4. ci/tools/bindings_scm_version.py and the Linux / Windows sdist workflows - temporary local version bootstrap and source-package checks.
5. ci/tools/download-wheels - keep unrelated toolkit lines and test artifacts out of release staging.

Counterpart Review

Inspected both bindings build paths and SCM selectors, their metapackage selection, the merged Core wheel and its two ABI variants, and the Linux/Windows sdist consumers. Both majors use the same planner and environment writer; Windows ARM64 deliberately excludes CUDA 12. The shared backend helper and synchronized test-bootstrap invariants remain intact.

The security refresh also checks shared .github/workflows/ci.yml and build-wheel.yml against both bindings roots' build metadata and the Linux/Windows sdist consumers. One hardened host-interpreter path serves both majors; container-specific package builds retain their existing separation.

Validation

Current local checks pass in full Git checkouts: 333 CI-tool tests at #3176, 346 at #3182, and 15 focused packaging tests. Full pre-commit run --all-files passes at both refreshed heads, including actionlint and Lychee. The tooling suite includes Git-based Pixi workspace discovery; it is not an archive-only suite. The local CUDA 13.4 TestVenv build and full QA run passed, covering Pathfinder, CUDA 13 bindings, PTDS, Cython interoperability, and Core. CUDA 12 native coverage is provided by the hosted matrix.

Planner regressions cover bindings-only Core reuse, matching-major testing, and full rebuilds when an exact baseline is unavailable. Local Git tests cover SCM bootstrap/progression and preservation of existing tags. An earlier direct comparison matched all 26 build-environment values on Linux x86_64 and aarch64.

Current hosted CI for the #3174-#3176 integration: run, attempt 1, at 34664b270a324b5fa7d401d52c964ecf7ea1b84a - passed, 105/105 jobs. This is the cumulative integration boundary for native builds, GPU tests, source/sdist checks, and documentation.

This intermediate layer is not independently actionlint-clean: callers pass bindings-config, while reusable test workflows still require build-ctk-ver; #3176 completes those interfaces.

Historical hosted artifact-reuse evidence (before this security refresh). Two temporary draft PRs exercised the production resolver unchanged against successful frozen baseline run 40426114619, at feb25b1b3d3c1744b680bf54ff10986ed4e59953. Both actual workplans matched the expected selective plans; neither fell back to a full rebuild. These runs predate the current interpreter/CA and driver-checksum integration; they establish the earlier reuse behavior, not validation of the refreshed heads or suitable nightly override IDs.

• CUDA 12 source-change case, #3237: run 40456909677 rebuilt CUDA 12 bindings/metapackage wheels while reusing Core, Pathfinder, and CUDA 13 wheels. All 28 build jobs passed, including bindings and Core Cython test-extension builds on Linux x86-64, Linux ARM64, and Windows. A re-uploaded Linux CPython 3.12 Core wheel is byte-identical to its baseline wheel. All 20 selected GPU tests (13 Linux and 7 Windows) and the final aggregate passed on the first attempt. That historical run completed successfully; no fixes or retries were needed.
• Linux test-workflow case, #3238: run 40460578171 skipped every package-wheel build, downloaded and re-uploaded the baseline packages, and successfully built all selected Cython test extensions and Core test binaries. All 45 expected reused package artifacts were present in that rehearsal run. All 42 selected GPU tests (24 x86-64 plus 18 ARM64 Linux rows, covering both CUDA majors) and the final aggregate passed on the first attempt. The seven planned Windows, sdist, and Core API skips were accepted.

Both historical workflows passed on their first attempts, including documentation/link checks and their final aggregates. No fixes or retries were needed. These probes cover the two scenarios above; no separate Core-only or metapackage-only hosted probe is claimed.

Checklist

• Focused tests protect selection, packaging, and release outcomes that could fail silently.
• This description identifies the layer's scope and validation boundary.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[mdboom]

The most important thing here is to fix the cuda-core rebinding logic.

[rwgk]

— codex GPT-6 on behalf of Ralf —

With Codex's help, I rechecked all six of Mike's inline comments here. Each already had a substantive reply. We drafted fresh answers from the current code, verified their source references, and compared them with the earlier replies. We also compared a fresh overall summary with those answers and the earlier cross-PR response.

One additional cleanup is retained as a single inline follow-up: the remaining cosmetic workplan-label generation and its eight workflow consumers are now removed. Earlier replies had already reported removing the Markdown table and label-dependent tests; the new change removes the remaining planner-label machinery.

The cleanup follow-up is in the planner thread. The other fresh replies and the overall recap are collected here to document the comparison without repeating them in the original threads.

Six previous replies paired with fresh drafts, plus the overall summary

Each link opens the previously posted reply. The indented text is the fresh comparison draft. Only the further planner-label cleanup is a new implementation update.

• Previous reply: Dependency graph names both bindings

  • Fresh comparison draft: Updated the dependency graph to identify both bindings versions explicitly.

• Previous reply: Reuse unchanged Core for bindings-only changes

  • Fresh comparison draft: A bindings-only change now reuses the unchanged merged Core wheel from an exact successful baseline, while testing Core against the affected bindings major. The planner regression and source-impact rules retain full rebuilds for Core/shared changes or an unavailable baseline.

• Previous reply: Descriptive registry step name

  • Fresh comparison draft: The renamed step now reads “Read bindings configuration and select supported build platforms,” covering both outputs.

• Previous reply: bindings_packages variable naming

  • Fresh comparison draft: Renamed it to bindings_packages throughout the workplan function.

• Previous reply: Replace nested comprehension

  • Fresh comparison draft: Removed the nested comprehension. The planner retains the workplan JSON needed for diagnosis; cosmetic plan-label scaffolding and label-coupled tests are removed in the refreshed version.

• Previous reply: Windows ARM64 single-major condition

  • Fresh comparison draft: Kept the single-major condition specific to current CUDA 13: maintenance CUDA 12 is unavailable on Windows ARM64. When current becomes CUDA 14, maintenance CUDA 13 should also build; >=13 would incorrectly keep that maintenance root disabled.

• Overall summary: compared with the earlier cross-PR response and the six individual replies linked here.

  • Fresh comparison draft:

    Unnecessary Core rebuilds are addressed in the workplan: a bindings-only change rebuilds that bindings/metapackage pair and tests the affected Core ABI, while reusing unchanged Core from an exact successful baseline. Core/shared changes and unavailable baselines retain full rebuilds.

    The dependency graph, registry-step name and bindings_packages naming are updated. Cosmetic plan scaffolding is removed while expandable workplan JSON remains. The Windows ARM64 single-major condition deliberately stays specific to current CUDA 13, so a later CUDA 14/maintenance13 pair can build both.

    Extracting the current/maintenance build blocks into a composite action remains the previously disclosed follow-up; it is not claimed as completed here.