[no-ci] ci: use same-run CUDA 12 bindings for Core and metapackages by rwgk · Pull Request #3318 · NVIDIA/cuda-python

rwgk · 2026-10-31T05:27:19Z

— codex GPT-6 on behalf of Ralf —

Layer 4 of 7 of the staged "CUDA 12 bindings on main" stack. Previous: #3317. Next: #3319. Stack map at the bottom.

What this PR does

Cuts the last dependency on the 12.9.x branch inside PR CI. Everything that needs CUDA 12 bindings during a main run now takes the wheel built in the same run.

cuda.core's cu12 half is built against the same-run CUDA 12 wheel. The lookup-run-id --branch 12.9.x artifact download disappears from build-wheel.yml.
Core's cu12 Cython test extensions are built and uploaded (<core artifact>-cu12-tests), with stale-output cleanup between the two ABI builds.
A CUDA 12 metapackage wheel is built (CUDA_PYTHON_BUILD_MAJOR=12) next to the CUDA 13 one.
The temporary Maintenance bindings jobs from [no-ci] ci: build and test local CUDA 12 bindings #3317 go away. Instead the regular test matrices annotate each row from the registry (BINDINGS_ROOT, BINDINGS_SOURCE, artifact names): 12.9.1 rows test bindings, Core, and metapackage from this run's wheels; 13.0.x / 12.6.x rows keep testing Core against published floor bindings.
sdist checks run once per package root (matrix over the registry).
cuda_python/setup.py + pyproject.toml: a selector table {"12": "v12.*", "13": "v13.*"}; an unambiguous exact CUDA 12 tag selects CUDA 12; otherwise CUDA 13 is the default. CUDA_PYTHON_BUILD_MAJOR explicitly selects either line; dependencies follow the resolved version, so a CUDA 12 sdist rebuilt outside Git keeps CUDA 12 dependencies. The CUDA 12 metapackage depends on bindings only; CUDA 13 also on Core and Pathfinder. Covered by test_cuda_python_setup.py.

Rows match the registry by toolkit major/minor (ctk_target), while artifact names retain the registry's full build-toolkit version. One real tagged-source → sdist → wheel metadata test replaces the mocked metapackage setup tests.

After this merges

PR CI is self-contained for both CUDA majors; nothing reads the 12.9.x branch any more except nightly for older artifact sources (handled in ci: retire legacy branch-based bindings maintenance #3322).
Releases are unchanged: CUDA 13 from main as today, CUDA 12 still from 12.9.x tooling until [no-ci] ci: release CUDA 12 bindings from main #3319.
Steady-state runner work is about the same as [no-ci] ci: build and test local CUDA 12 bindings #3317: the separate maintenance test jobs are replaced by richer 12.9.1 rows in the regular jobs.

Where to look

.github/workflows/build-wheel.yml: "Constrain maintenance cuda.core to the same-run cuda.bindings wheel" and "Build maintenance cuda.core Cython tests".
.github/workflows/test-wheel-linux.yml: the jq block that annotates matrix rows (mirrored in the Windows file).
cuda_python/setup.py: line selection and version-derived dependencies.

All changes (14 files, +350 / -237)

.github/workflows/build-wheel.yml: same-run CUDA 12 constraint for Core, maintenance metapackage wheel, maintenance Core Cython tests, removal of the prior-branch lookup.
.github/workflows/ci.yml: removal of the three temporary jobs; sdist jobs matrixed over package_roots; bindings-config passed to all test jobs.
.github/workflows/test-sdist-linux.yml, test-sdist-windows.yml: bindings-package input replaces cuda-version; per-root build, Pathfinder sdist only for the current root.
.github/workflows/test-wheel-linux.yml, test-wheel-windows.yml: registry-driven row annotation; maintenance-bindings input removed.
ci/tools/env-vars: MAINTENANCE_CUDA_MAJOR, registry-driven test routing, Core Cython artifact suffix, metapackage artifact name.
cuda_python/setup.py, cuda_python/pyproject.toml, ci/tools/tests/test_cuda_python_setup.py (new).
Docs: cuda_python/AGENTS.md, cuda_python/docs/README.md, cuda_core/docs/source/install.rst.

Validation

Full CI passed at the pre-rebase head 2f2eb43e (run 41188280375).
Local validation at 2f970418c6a33272fc2b1729e0d0627dba8d3cf4: 317 CI-tool tests and configured workflow lint passed. Full-stack CI on #3322 passed at 126ed74fb5bbfbc91a04e50557cf936efef4da7f (105 successful jobs; one expected skip).

Stack map: cumulative capabilities by layer

Layer	PR	Capability added
1	#3314	behaves exactly as before; CI has one reader for the two bindings roots; CUDA 13 versions can no longer match a `v12.*` tag
2	#3315	lets a developer build, test, and document `cuda_bindings_12/`; the PR-time CPU source-build smoke covers both roots; three CUDA 12 runtime fixes are in
3	#3317	builds the CUDA 12 bindings wheel itself and runs its GPU tests; `cuda.core` and the metapackage still consume `12.9.x` artifacts
4	#3318	uses same-run CUDA 12 wheels everywhere; PR CI no longer reads the `12.9.x` branch
5	#3319	can release CUDA 12 from a `v12.9.N` tag on `main`; CUDA 13 releases are unchanged
6	#3321	builds and tests only what a change needs, per bindings root, reusing baseline artifacts
7	#3322	adopts the schema-2 registry, removes backport automation, adds metadata checks and maintenance docs; `12.9.x` is frozen

Layers #3314 and #3315 have merged. The remaining five migration PRs (#3317, #3318, #3319, #3321 and #3322) will land together using GitHub’s atomic stack merge, with full CI on #3322 as described in the landing plan. #3434 follows separately, after a successful post-migration main CI run supplies complete artifacts for both CUDA majors.

copy-pr-bot · 2026-10-31T05:27:23Z

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.

rwgk · 2026-10-31T09:20:07Z

/ok to test 2f2eb43

github-actions · 2026-10-31T09:37:34Z

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

mdboom

In addition to my comments below, my bot had this to say:

🤖 Registry join can silently disable bindings tests (medium): matrix rows are matched to the registry by exact CUDA_VER == toolkit_version. If versions.yml goes from 13.4.2 to 13.4.3 and the matrix rows aren't updated, those rows silently become floor and skip the bindings and Cython tests with no error. The old logic compared major and minor only. The fix is to join on ctk_target.

mdboom · 2026-11-03T17:05:58Z

+      BUILD_MAINTENANCE_BINDINGS: >-
+        ${{ !inputs.single-cuda-major &&
+            (inputs.workplan == '' ||
+             fromJSON(inputs.workplan).modules.bindings.needs_build ||
+             fromJSON(inputs.workplan).modules.bindings.needs_test ||
+             fromJSON(inputs.workplan).modules.core.needs_build ||
+             fromJSON(inputs.workplan).modules.core.needs_test ||
+             fromJSON(inputs.workplan).modules.python.needs_build ||
+             fromJSON(inputs.workplan).modules.python.needs_test) }}


This should be a single entry in the workplan JSON and computed from compute_ci_plan.py (so we don't have this logic reimplemented in JS and scattered in the .yml files).

— codex GPT-6 on behalf of Ralf —

The expression is transitional: #3321 replaces it with per-root decisions computed by compute_ci_plan.py. The final workflow consumes those planner flags. planner; consumer.

mdboom · 2026-11-03T17:06:57Z

      - name: Prepare local maintenance SCM milestone
-        if: ${{ !inputs.single-cuda-major && (env.BUILD_BINDINGS == 'true' || env.TEST_BINDINGS == 'true') }}
+        if: ${{ env.BUILD_MAINTENANCE_BINDINGS == 'true' }}
        run: |
          python -m ci.tools.bindings_scm_version \
            --package-root "${MAINTENANCE_BINDINGS_ROOT}" --sha "${{ github.sha }}"


See many previous comments about bindings_scm_version workaround and how it simplifies all of this.

— codex GPT-6 on behalf of Ralf —

Agreed; this caller is now removed with the common retained-milestone cleanup, as recorded in the updated #3315 reply.

mdboom · 2026-11-03T17:09:10Z

+      - name: Build maintenance cuda.core Cython tests
+        if: ${{ !inputs.single-cuda-major && env.TEST_CORE == 'true' }}
+        run: |
+          # The current package's test extensions were built in this same source tree.
+          # Remove generated outputs so Cython and the compiler cannot reuse them.
+          find "${{ env.CUDA_CORE_CYTHON_TESTS_DIR }}" -maxdepth 1 -type f \
+            \( -name 'test_*.cpp' -o -name 'test_*.so' -o -name 'test_*.pyd' \) -delete
+          if [[ -d "${{ env.CUDA_CORE_CYTHON_TESTS_DIR }}/build" ]]; then
+            find "${{ env.CUDA_CORE_CYTHON_TESTS_DIR }}/build" -type f -delete
+          fi
+          pip uninstall -y cuda-bindings cuda-core
+          pip install ${{ env.MAINTENANCE_BINDINGS_ARTIFACTS_DIR }}/*.whl
+          if ${{ env.BUILD_CORE == 'true' }}; then
+            core_wheel=$(find "${{ env.CUDA_CORE_ARTIFACTS_DIR }}/cu${MAINTENANCE_CUDA_MAJOR}" -maxdepth 1 -type f -name '*.whl' -print -quit)
+          else
+            core_wheel=$(find "${{ env.CUDA_CORE_ARTIFACTS_DIR }}" -maxdepth 1 -type f -name '*.whl' -print -quit)
+          fi
+          if [[ -z "${core_wheel}" ]]; then
+            echo "No cuda.core wheel found" >&2
+            exit 1
+          fi
+          pip install "${core_wheel}" --group ./cuda_core/pyproject.toml:test
+          pushd ${{ env.CUDA_CORE_CYTHON_TESTS_DIR }}
+          bash build_tests.sh
+          popd
+
+      - name: Upload maintenance cuda.core Cython tests
+        if: ${{ !inputs.single-cuda-major && env.TEST_CORE == 'true' }}
+        uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9  # v7.0.2
+        with:
+          name: ${{ env.CUDA_CORE_ARTIFACT_NAME }}-cu${{ env.MAINTENANCE_CUDA_MAJOR }}-tests
+          path: ${{ env.CUDA_CORE_CYTHON_TESTS_DIR }}/test_*${{ env.PY_EXT_SUFFIX }}
+          if-no-files-found: error
+


Any way to reduce the duplication here between the current and maintenance versions?

— codex GPT-6 on behalf of Ralf —

Agreed that sharing this implementation would improve maintainability. I propose doing the extraction after migration, preserving toolkit switching, stale-output cleanup, wheel reuse and merging order. This remains open pending agreement on that sequencing; it is not implemented here.

Do we have an issue filed to not forget to come back to this? This is exactly the kind of thing where they will get unintentionally out-of-sync, creating hard-to-diagnose problems.

— codex GPT-6 on behalf of Ralf —

Tracked in #3402. The issue records a focused post-migration extraction, preserving toolkit switching and the wheel-merging sequence.

mdboom · 2026-11-03T17:12:47Z

@@ -0,0 +1,65 @@
+# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.


These tests seem to be so full of monkeypatches as to provide minimal value.

Let's ask the agent if any of these issues would "fail naturally" in the course of running the CI itself, and if so, remove them.

— codex GPT-6 on behalf of Ralf —

Removed the mocked selector-wiring cases and replaced them with one real tagged-source → sdist → wheel metadata check. The selector-free sdist rebuild is worth retaining: existing sdist CI keeps the selector set, and incorrect extra dependencies could install successfully. implementation.

mdboom · 2026-11-03T17:25:37Z

+build_major = os.environ.get("CUDA_PYTHON_BUILD_MAJOR", "13")
+if build_major not in {"12", "13"}:
+    raise ValueError(f"CUDA_PYTHON_BUILD_MAJOR must be 12 or 13, got {build_major!r}")


Using an environment variable for this seems like a big foot gun. For example, if I'm making a release on a tag v12.9.10 but forget to set this environment variable, the build will fail in an obscure way. I would expect this to need to be set in the release.yml workflow in order to do the right thing, but I don't see that change in this or any PRs further up the stack.

I think it would be better to implement our own custom version number lookup before importing setuptools_scm. It would look for an exact tag match for v12.X.Z and if so, set SETUPTOOLS_SCM_PRETEND_VERSION to that exact value. Otherwise fallback to setuptools_scm's default behavior with the 13.* pattern. Then this will do the right thing by default.

— codex GPT-6 on behalf of Ralf —

Direct builds at an unambiguous exact CUDA 12 tag select CUDA 12 automatically. Explicit selection wins; untagged or dual-tag commits default to CUDA 13. Setuptools-scm derives the version normally. Implementation.

Correction to my earlier reply: the current-line CI wheel build was missing its explicit selector at this prefix. That gap is now fixed in #3319; both wheel builds then select their major explicitly. release.yml consumes the prebuilt artifacts.

Explicit selection still wins; untagged or dual-tag commits default to CUDA 13.

So, let's say we tag v12.9.10 and v13.5.4 at the exact same commit. How does CI support releasing both of them? (I'm not saying it doesn't, I'm saying it's non-obvious how one would do it).

— codex GPT-6 on behalf of Ralf —

The new dual-tag procedure explains this explicitly: each tag has its own CI run, and each line is released separately with component=cuda-bindings and component=cuda-python. Run lookup matches both tag and SHA; artifact names and validation separate the lines. The missing current-line selector is fixed in #3319's wheel build, so tag creation order cannot select the wrong major. Local backend-wheel builds verified both orders.

rwgk

— codex GPT-6 on behalf of Ralf —

The patch-version mismatch from your review is fixed: registry rows match by ctk_target, while artifact names retain the registry's full build version. The final implementation and regression test cover differing patch pins.

All five inline comments now have direct replies. The mocked metapackage tests were replaced with a real tagged-source → sdist → wheel check, and exact CUDA 12 tags select that namespace automatically. Bootstrap removal is now complete after the retained milestone and restack; shared Core-build extraction remains a proposed post-migration follow-up.

rwgk · 2026-11-06T09:05:12Z

/ok to test d750903

mdboom

I still think we have some decisions to resolve on this one, namely the double-tagging and releasing both cuda_python versions from that branch. This may be answered by something further up the stack (which I haven't read yet). If I'm satisfied with that, I'll come back and approve this.

mdboom · 2026-11-06T19:13:10Z

+            text=True,
+        ).splitlines()
+        if any(tag.startswith("v12.") for tag in tags) and not any(tag.startswith("v13.") for tag in tags):
+            build_major = "12"


I think this will be really confusing if a commit is tagged with both versions (which is going to be quite common).

cuda_bindings has separate directory trees for each version. cuda_python is trying to mush them together, which creates this confusion. I wonder if following the same pattern for cuda_python as cuda_bindings would be the better choice?

— codex GPT-6 on behalf of Ralf —

To make the two layouts concrete for discussion:

Today, cuda_python/ contains one build recipe for both release lines. CI selects the major with CUDA_PYTHON_BUILD_MAJOR; direct builds can infer it from an unambiguous tag, with CUDA 13 as the default otherwise.

The split would give each line its own source directory, mirroring the bindings layout. Using illustrative names:

cuda_python_12/ # v12.* versions and CUDA 12 dependencies cuda_python_13/ # v13.* versions and CUDA 13 dependencies

The build command would select the line directly:

pip wheel ./cuda_python_12 pip wheel ./cuda_python_13

Both directories would still produce versions of the same PyPI package, cuda-python. The CUDA 12 metapackage depends on its bindings line; the CUDA 13 metapackage also includes Core and Pathfinder.

The shared layout keeps the recipe in one place and relies on explicit selection in CI. The split makes that selection visible in the directory and removes the environment/tag-default choice from each recipe, at the cost of maintaining two build roots and keeping their common packaging metadata aligned.

This records the alternatives as a basis for deciding which layout is clearer to maintain.

copy-pr-bot · 2026-11-07T17:49:12Z

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.

coderabbitai · 2026-11-08T07:21:43Z

No actionable comments were generated in the recent review.

Summary

Summary by CodeRabbit

New Features
- The CUDA Python metapackage supports CUDA 12 and CUDA 13 builds, selecting the matching CUDA Bindings dependency. CUDA 13 builds also include CUDA Core and CUDA Pathfinder.
- CUDA Python source distributions can build wheels with version-matched dependencies, including CUDA 12 builds.
Documentation
- Nightly CUDA Core installation instructions include Python 3.15 and free-threaded Python 3.15 examples.
- Clarified which package documentation is built together and how to build CUDA 12 documentation separately.

cuda-python packaging now selects CUDA-major tags and dependencies. CI workflows use configured bindings-package metadata for wheel and sdist builds and tests, including maintenance package artifacts.

Changes: CUDA packaging and CI

Layer / File(s)	Summary
CUDA-major package selection `cuda_python/setup.py`, `cuda_python/pyproject.toml`, `ci/tools/tests/*`, `cuda_python/AGENTS.md`, `cuda_python/docs/README.md`	cuda-python selects CUDA 12 or CUDA 13 SCM tags and dependencies based on the build major or checkout tags. A test covers a CUDA 12 sdist-to-wheel build. Packaging guidance and documentation describe package roots and build behavior.
Maintenance wheel builds `.github/workflows/build-wheel.yml`	The workflow builds maintenance cuda-python and cuda.bindings wheels under the configured conditions. It also builds cuda.core Cython tests using maintenance bindings and a selected core wheel.
Package-aware sdist testing `.github/workflows/ci.yml`, `.github/workflows/test-sdist-*`	CI runs sdist tests across configured package roots. Linux and Windows workflows derive build settings and artifact paths from the package input.
Registry-driven wheel testing `.github/workflows/ci.yml`, `.github/workflows/test-wheel-*`, `ci/tools/env-vars`, `cuda_core/docs/source/install.rst`	Wheel-test matrices use registry metadata to select build versions and artifacts. CI removes maintenance-bindings job checks. Environment exports and nightly-wheel documentation are updated.

Possibly related issues

NVIDIA/cuda-python#3402 — The issue describes same-run bindings constraints and toolkit switching in build-wheel.yml, which this PR changes.
NVIDIA/cuda-python#3432 — This PR removes prior-branch artifact lookup paths as part of the artifact-source changes tracked by the issue.

Possibly related PRs

NVIDIA/cuda-python#3317 — Both PRs change maintenance bindings inputs and build outputs in the same workflows.
NVIDIA/cuda-python#3322 — This PR consumes the bindings registry contract and configuration introduced by that PR.
NVIDIA/cuda-python#3319 — The maintenance CUDA 12 artifacts built here are inputs to the release artifact selection in that PR.

Suggested reviewers: mdboom, leofang

Change: Other

Merge Risk: Minimal · up to 1d4a0

This change builds and tests CUDA 12 packages from same-run artifacts and selects the CUDA major in cuda-python packaging. No concrete merge-blocking risk is identified in the supplied evidence.

Security architecture risk: Low · up to 1d4a0

The reviewed changes retain existing CI permissions and continue gating the replacement test jobs. No introduced security defect was confirmed. Repository access controls and behavior during interrupted runs or reruns remain unverified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

observed — The inspected execution boundary includes repository wheel outputs and Linux and Windows GPU runners. Linux custom-driver rows already support privileged containers with host PID access. This is consequential existing CI authority, not a newly added container privilege in this PR.

Trust Boundaries and Controls

observed — Normal wheel-test downloads explicitly select the current workflow run unless a reusable-workflow caller supplies another run ID. Therefore SHA-based artifact names alone do not establish a cross-run collision vulnerability. The inspected CI callers do not supply an alternate run ID.

Resilience and Maintainability Implications

observed — The artifact-download wrapper retries failures while preserving the same name, destination, run, and token inputs. Its final attempt is not marked continue-on-error. Missing maintenance wheel or test-extension uploads are configured as errors, supporting failure containment rather than silent omission.

- [ ] Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

Source mode: Auto

Repository: NVIDIA/cuda-python

Branch: rwgk/cb12-staged-03-bindings-ci

File: .coderabbit.yaml

Commit: d179cd9

Layers: Repository YAML

Review profile: CHILL

Plan: Enterprise

Run ID: `17a72230-d188-4e36-bb7e-a281e6817be2`

Commits

Reviewing files that changed from the base of the PR and between `357aca4` and `1d4a047`.

Files selected for processing: 2

`.github/workflows/build-wheel.yml`

`.github/workflows/test-wheel-linux.yml`

Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 10 remain after this review.

coderabbitai

Nitpick comments: 1

cuda_python/setup.py: 1

26-30: Trivial · Maintainability & Code Quality · Low value

suggestion: The static-analysis command-injection hints do not apply here. The command is a fixed argument list. cwd derives from __file__. No external input reaches the call. Keep the code as is.

One reliability note: git tag raises CalledProcessError or FileNotFoundError if git is missing or the checkout is unusable. This can happen with safe.directory ownership errors in containers. The build then fails instead of defaulting to CUDA 13. Consider catching (subprocess.CalledProcessError, OSError) and keeping the CUDA 13 default.

Review info

Run configuration

Source mode: Auto

Repository: NVIDIA/cuda-python

Branch: rwgk/cb12-staged-03-bindings-ci

File: .coderabbit.yaml

Commit: 8728407

Layers: Repository YAML

Review profile: CHILL

Plan: Enterprise

Run ID: `37c026f3-094c-4340-9248-be93871680fc`

Commits

Reviewing files that changed from the base of the PR and between `8728407` and `cdebef2`.

Files selected for processing: 14

`.github/workflows/build-wheel.yml`

`.github/workflows/ci.yml`

`.github/workflows/test-sdist-linux.yml`

`.github/workflows/test-sdist-windows.yml`

`.github/workflows/test-wheel-linux.yml`

`.github/workflows/test-wheel-windows.yml`

`ci/tools/env-vars`

`ci/tools/tests/test_bindings_config.py`

`ci/tools/tests/test_cuda_python_setup.py`

`cuda_core/docs/source/install.rst`

`cuda_python/AGENTS.md`

`cuda_python/docs/README.md`

`cuda_python/pyproject.toml`

`cuda_python/setup.py`

Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 9 remain after this review.

rwgk · 2026-11-09T00:17:00Z

— codex GPT-6 on behalf of Ralf —

Following up on the Git-error fallback suggestion in this review: keeping the explicit failure here is intentional. Standalone sdists already skip this Git query. In a real checkout, silently defaulting to CUDA 13 could conceal failed CUDA 12 tag detection, and the subsequent SCM version lookup may still fail.

The summary's optional Cython-cache note is also acknowledged. CI does not enable that cache; extending its cross-major handling is deferred from this migration.

rwgk · 2026-11-09T00:42:45Z

/ok to test 3121920

Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>

rwgk · 2026-11-13T03:06:15Z

/ok to test 1d4a047

rwgk added this pull request to stack #3316 October 31, 2026 05:27

github-actions Bot added CI/CD CI/CD infrastructure cuda.core Everything related to the cuda.core module labels Oct 31, 2026

rwgk added this to the cuda.bindings next milestone Oct 31, 2026

rwgk added enhancement Any code-related improvements cuda.bindings Everything related to the cuda.bindings module and removed cuda.core Everything related to the cuda.core module labels Oct 31, 2026

rwgk self-assigned this Oct 31, 2026

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from c8ce319 to ea19ebc Compare October 31, 2026 05:38

github-actions Bot added the cuda.core Everything related to the cuda.core module label Oct 31, 2026

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from ea19ebc to 44b64de Compare October 31, 2026 06:03

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from 44b64de to 4b8376e Compare October 31, 2026 07:49

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from 4b8376e to 2f2eb43 Compare October 31, 2026 08:03

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from 2f2eb43 to b252422 Compare November 1, 2026 22:38

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from b252422 to 55b92f8 Compare November 2, 2026 03:53

mdboom requested changes Nov 3, 2026

View reviewed changes

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from 55b92f8 to 2f97041 Compare November 4, 2026 06:08

rwgk commented Nov 4, 2026

View reviewed changes

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from d750903 to 9270131 Compare November 6, 2026 18:02

mdboom requested changes Nov 6, 2026

View reviewed changes

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from 9270131 to 79ea1c7 Compare November 6, 2026 19:28

rwgk mentioned this pull request Nov 6, 2026

CI: Extract shared CUDA Core wheel-build implementation after the CUDA 12 migration #3402

Open

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from 79ea1c7 to cdebef2 Compare November 7, 2026 17:49

rwgk marked this pull request as ready for review November 8, 2026 07:16

coderabbitai Bot reviewed Nov 8, 2026

View reviewed changes

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from cdebef2 to 3121920 Compare November 9, 2026 00:10

mdboom approved these changes Nov 9, 2026

View reviewed changes

rwgk changed the title ~~ci: use same-run CUDA 12 bindings for Core and metapackages~~ [no-ci] ci: use same-run CUDA 12 bindings for Core and metapackages Nov 12, 2026

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from 3121920 to 357aca4 Compare November 12, 2026 21:18

rwgk added 4 commits November 12, 2026 18:58

ci: use same-run CUDA 12 bindings for Core and metapackages

a167b29

Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>

Address migration review: simplify configuration and tooling

9d65c74

Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>

Fix tagged metapackage builds and preserve toolkit patch coverage

6a6919a

Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>

Use retained CUDA 12 milestone for source distributions

1d4a047

Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>

rwgk force-pushed the rwgk/cb12-staged-04-consumers branch from 357aca4 to 1d4a047 Compare November 13, 2026 03:04

rwgk merged commit 677bde7 into main Nov 13, 2026
31 checks passed

rwgk deleted the rwgk/cb12-staged-04-consumers branch November 13, 2026 05:25

		@@ -0,0 +1,65 @@
		# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.

Conversation

rwgk commented Oct 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this PR does

After this merges

Where to look

Uh oh!

copy-pr-bot Bot commented Oct 31, 2026

Uh oh!

rwgk commented Oct 31, 2026

Uh oh!

github-actions Bot commented Oct 31, 2026

Preview will be ready when the GitHub Pages deployment is complete.

Uh oh!

mdboom left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwgk Nov 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwgk Nov 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwgk left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwgk commented Nov 6, 2026

Uh oh!

mdboom left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

copy-pr-bot Bot commented Nov 7, 2026

Uh oh!

coderabbitai Bot commented Nov 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

rwgk commented Nov 9, 2026

Uh oh!

rwgk commented Nov 9, 2026

Uh oh!

rwgk commented Nov 13, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

rwgk commented Oct 31, 2026 •

edited

Loading

rwgk Nov 4, 2026 •

edited

Loading

rwgk Nov 4, 2026 •

edited

Loading

rwgk left a comment •

edited

Loading

coderabbitai Bot commented Nov 8, 2026 •

edited

Loading