Skip to content

CI: test and document both bindings majors on main - #3176

Draft
rwgk wants to merge 23 commits into
rwgk/cb12-on-main-04-ci-buildsfrom
rwgk/cb12-on-main-05-ci-tests-docs
Draft

rwgk wants to merge 23 commits into
rwgk/cb12-on-main-04-ci-buildsfrom
rwgk/cb12-on-main-05-ci-tests-docs

Conversation

@rwgk

@rwgk rwgk commented Oct 21, 2026 •

Copy link
Copy Markdown
Contributor

— codex GPT-6 on behalf of Ralf —

Layer 5 of 8; last of the review group #3174 + #3175 + #3176, which lands as one merge. This PR is the group's full-CI target. Previous: #3175. Next: #3177. Stack map at the bottom.

The current tagging proposal can land shared prerequisite #3314 first, create the retained v12.9.11a0 milestone, then restack both alternatives onto that commit and remove the bootstrap.

What this PR does

The test side of running both bindings majors from main, plus the documentation that explains the result.

  • test-wheel-linux.yml, test-wheel-windows.yml: matrix rows are annotated from the registry by the new ci/tools/select_test_matrix.py (replaces a jq program duplicated in both files). Rows whose toolkit matches a registered root test that root's wheels from this run; older-toolkit rows test Core against published floor bindings. Job names say what runs, for example pathfinder+bindings12+core12+meta12 / py3.12, CTK12.9.1 (wheels; bindings PR). A PR cannot silently lose a required local-wheel row. CI tools come from the workflow revision (.ci-control), so nightly can test an older artifact source with current tooling.
  • ci-nightly.yml: extracts only ci/versions.yml from the artifact-source archive, reads that registry, and stops with a clear message if that source predates it (rollout recipe in ci/README.md).
  • coverage.yml, ci-pixi-source-test.yml: registry-driven; the pixi smoke selects roots from the plan and runs the version preview bootstrap for the CUDA 12 root. Scheduled GPU source tests cover both registered environments; manual dispatch selects one. The container checkout explicitly trusts its workspace before the bootstrap.
  • build-docs.yml: tooling from a .ci-control checkout, package data from the release source; CUDA 13 docs built against the checkout's bindings; build_docs.sh keeps .dev and rc versions out of the stable directory.
  • CUDA 12 test maintenance ported from CUDA 13: NVML runner adaptations (Orin/Thor, PCI info, driver >= 13.4 refcount skip, flaky energy test removed) and serialization of the process-global coredump test (Mike's Fix coredump tests on free-threaded builds #3226, marker on the CUDA 12 copy).
  • Docs: CONTRIBUTING.md (CI overview), ci/README.md (reading CI jobs and summaries, nightly rollout, historical reruns), both roots' install pages, CUDA 12 driver baseline correction.

After the group merges

  • main builds, tests, and documents both majors; CUDA 12 bindings for Core come from the same run, not from the 12.9.x branch.
  • CUDA 13 releases keep working (tag CI builds only the matching line). CUDA 12 releases from main need Release: select bindings artifacts from tagged package configuration #3177.
  • Nightly needs its first successful post-merge main run before auto-detection works; until then dispatch it with a compatible run-id (recipe in ci/README.md). Docs reruns and dry runs for tags from before the registry need the 13.4.x branch tooling.

Where to look

All changes (35 files; 34 without the lockfile, +1,116 / -510)

Workflows: test-wheel-linux.yml, test-wheel-windows.yml, ci-nightly.yml, coverage.yml, ci-pixi-source-test.yml, build-docs.yml, .github/actions/doc_preview/action.yml (pin bump).

Tools: select_test_matrix.py (new), run-tests, lookup-run-id (orphaned --artifact option removed), tests (test_select_test_matrix.py new; test_merge_cuda_core_wheels.py; workflow-text tests removed).

CUDA 12 tests: cuda_bindings_12/tests/nvml/{test_cuda.py,test_init.py,test_pynvml.py,util.py}, cuda_bindings_12/tests/test_cuda.py.

Docs and environments: CONTRIBUTING.md, ci/README.md, ci/ci-pipeline.mmd, cuda_bindings_12/docs/{README.md,source/install.md,source/release/12.X.Y-notes.rst}, cuda_bindings_13/docs/{README.md,build_docs.sh,source/install.rst,source/support.rst}, cuda_bindings_13/pixi.toml + lock (docs feature builds bindings from source), cuda_core/docs/source/install.rst, cuda_python/docs/{README.md,environment-docs.yml}, toolshed/setup-docs-env.sh.

Review history and validation
Stack map: review scopes and merge units
Layer PR Scope Merge unit
1 #3172 import cuda_bindings_12/, byte-identical to the 12.9.x branch merged
2 #3173 integrate the import with the shared build tooling merged
3 #3174 registry, packaging, version selectors, developer environment, guidance group: #3174 + #3175 + #3176 land together
4 #3175 build both majors from main; planner; version preview bootstrap group
5 #3176 test, document, nightly, coverage; first CI-complete state group
6 #3177 releases driven by the tagged source's configuration after the group
7 #3178 maintenance policy, manual backport workflow, retire backport_branch after #3177
8 #3182 three CUDA 12 runtime fixes independent of the CI layers; stacked only for ordering

Layers 3 to 5 are review boundaries, not working intermediate states: #3174 alone breaks CI (workflows still read the removed cuda.build.version), and #3175 alone fails actionlint (callers pass an input the test workflows only accept in #3176). The plan is to review them separately and land the reviewed group as one merge. #3176 is the full-CI target for the group.

The staged stack #3314-#3322 is the alternative in which every layer is mergeable on its own; both stacks reach the same end state, except that the staged stack keeps compatibility routes for older artifact sources and retained CUDA 13 tags.

@rwgk rwgk added this to the cuda.bindings next milestone Oct 21, 2026
@rwgk rwgk added enhancement Any code-related improvements CI/CD CI/CD infrastructure cuda.bindings Everything related to the cuda.bindings module labels Oct 21, 2026
@rwgk rwgk self-assigned this Oct 21, 2026
@copy-pr-bot

copy-pr-bot Bot commented Oct 21, 2026

Copy link
Copy Markdown
Contributor

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

rwgk commented Oct 22, 2026

Copy link
Copy Markdown
Contributor Author

/ok to test 9b8ac76

@rwgk

rwgk commented Oct 22, 2026

Copy link
Copy Markdown
Contributor Author

/ok to test 19865b0

@mdboom

mdboom commented Nov 2, 2026

Copy link
Copy Markdown
Contributor

The following concerns I had from my last review are still not complete:

  1. Push a real v12.9.11a0 tag and delete the synthetic-tag machinery.

There is a significant amount of complexity here to work around the fact that we don't have an existing v12.9.X tag on main. Adding a prerelease tag of some sort on main would allow us to remove all of it. I have not all read the verbose comments since I made this request but my agent tells me there is no mention of it (a decision to not do it, because X... for example). This is the one I think it the most important because it is truly temporary and unnecessary content.

  1. De-duplicate the current/maintenance blocks in build-wheel.yml.

This is 345 lines of repeated boiler plate that we could remove.

  1. Move the test-matrix jq into Python.

This was partially addressed. There is still some jq usage remaining we don't have to be 100%, but my klanker identified a couple additional simplifications:

Not worth moving

  • The caller's matrix_filter. This is the jq -c '${{ inputs.matrix_filter }}' line.
    • Every caller passes the same one-liner shape: map(select(.ENV.MODE == "nightly-pytorch")). There are about 13 of them in ci-nightly.yml.
    • Moving this to Python means replacing the free-form jq expression with a different interface.
    • That could be a --mode argument or a Python filter language. Each caller would change, and you would still have the same mode strings.
    • That is more work and a bigger surface than the jq expression it replaces.
  • The MATRIX_ENV line. echo "$MATRIX_ENV" | jq -r 'to_entries[] | "\(.key)=\(.value)"' >> "$GITHUB_ENV" is already a single standard line. A Python helper would add a file and a call without simplifying anything.

Worth simplifying

  • The step-summary table. This is the jq -r '.include[] | "| \(.SUITES) | ..."' line, duplicated in both wheel workflows. It is cosmetic output. Per your inline note on simplification 6, it would be better to print the matrix JSON, as the plan summary now does. That would delete the jq and the duplication together.
  • The yq | jq | python pipeline. Once the table is gone, select_test_matrix.py could read ci/test-matrix.yml and apply the architecture filter itself. The yq -o json ... map(select(.ARCH == ...)) step would then move into Python and the jq filter would be the only shell JSON handling left. That is a modest gain. It is optional and mostly a matter of taste.

I'd leave matrix_filter and MATRIX_ENV as they are and drop the summary table. That gives most of the benefit of your simplification 2 without the filter interface change.

(I did not finish reviewing this, because I understand #3182 and #3322 are superceding this).

@rwgk

rwgk commented Nov 2, 2026

Copy link
Copy Markdown
Contributor Author

— codex GPT-6 on behalf of Ralf —

Thanks, Mike. I agree that a retained v12.9.11a0 tag would let us delete the temporary bootstrap helper, its tests, the metadata field, and the workflow calls.

The earlier response deferred this until the validated per-line configuration lands on main. The simplification is still unimplemented; the remaining question is its timing.

There is a tag-placement issue to handle: main’s CUDA 13 version selector still matches v*[0-9]*. Placing a CUDA 12 tag at main’s current head could therefore make CUDA 13 builds derive a CUDA 12 version.

One straightforward sequence is:

  1. Land the per-line selectors.
  2. Create the retained milestone on validated main history.
  3. Immediately remove the bootstrap machinery.

Waiting until after integration is a conservative ordering choice, not a setuptools-scm requirement. If we want the deletion before integration, we could evaluate a safe earlier tag anchor or a small preparatory selector PR.

I’d like to settle that ordering explicitly so this temporary machinery has a concrete removal point.

@rwgk

rwgk commented Nov 2, 2026

Copy link
Copy Markdown
Contributor Author

Thanks Mike. I've been organizing this work into safe, meaningful steps. I'd like to complete and validate the migration off 12.9.x first, then make these maintainability improvements separately. That keeps each review focused and makes regressions easier to isolate.

For these two suggestions in your follow-up review, I propose follow-ups:

De-duplicate the current/maintenance blocks in build-wheel.yml.

I agree this would improve maintainability. I propose extracting the shared implementation after migration, preserving the toolkit-switching and wheel-merging sequence.

The step-summary table. … it would be better to print the matrix JSON

Agreed. I propose replacing both tables with the matrix JSON while retaining the caller’s matrix_filter and simple MATRIX_ENV export, as you recommend.

I'd be happy to prepare two follow-up PRs now to address your requests, and stack them above #3182, so they can be reviewed alongside the migration and merged afterward. Would that work for you?

rwgk added 22 commits November 3, 2026 22:14
Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>
Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>
Relocate the established hardware, driver, visibility and timing accommodations from the source-integration layer. Preserve their contents exactly; the FieldId correction moves with the test maintenance.

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

Use verified workflow-owned Python for registry, nightly, coverage and Pixi helpers. Preserve hardened interpreter PATH in early documentation bootstrap shells and keep historical sources separate from control tools.

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

Require checksum-bearing driver matrices for nightly source overrides and current control-workflow security fixes before dispatching historical release tooling. Keep immutable release sources and fail-closed verification unchanged.

Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>
Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>
Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>
Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>
@rwgk
rwgk force-pushed the rwgk/cb12-on-main-05-ci-tests-docs branch from 6bbd456 to a8089af Compare November 4, 2026 06:18
Signed-off-by: Ralf W. Grosse-Kunstleve <rgrossekunst@nvidia.com>

This branch has not been deployed

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

Labels

CI/CD CI/CD infrastructure cuda.bindings Everything related to the cuda.bindings module cuda.core Everything related to the cuda.core module cuda.pathfinder Everything related to the cuda.pathfinder module enhancement Any code-related improvements

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants