[doc-only] Fix release notes checks for backport releases

[rwgk]

Description

Fixes #2141.

This PR makes the manual release workflow safe and usable for backport tags such as v12.9.7, where the tag source tree can predate current release tooling and docs metadata. It also adds a docs-only repair path so already-published releases can have versioned docs regenerated without touching PyPI or GitHub release assets.

Background

The release workflow originally checked out the requested release tag before running release-note checks. That broke for older backport tags because v12.9.7 did not contain the current ci/tools/check_release_notes.py tooling.

After fixing that, the v12.9.7 release exposed two more older-tag compatibility issues:

• build-docs.yml expected ci/versions.yml, but v12.9.7 still had ci/versions.json.
• Release notes for backport versions are maintained on main, so building docs directly from the old tag omitted newer *-notes.rst files.

This PR handles those compatibility gaps while preserving the intended model: versioned docs are still built from the release tag, with only release-note and version-selector metadata overlaid from the workflow branch.

Changes

• Add backport-git-tag handling to the release-note checker.

  • Mainline cuda-bindings / cuda-python releases must explicitly state a planned backport tag or not planned.
  • Actual backport releases can leave this input blank.
  • Missing backport notes on an actual backport release warn instead of blocking the valid package release.

• Run release-note checks from the workflow branch instead of from the release tag checkout.

  • This avoids depending on older tags containing current CI tooling.

• Support older docs version metadata.

  • build-docs.yml now reads ci/versions.yml when present and falls back to ci/versions.json for older tags.

• Overlay release-note sources before release docs builds.

  • For release builds, the workflow sparse-checks out release notes from the workflow branch.
  • It overlays each selected component’s docs/source/release/*-notes.rst into the checked-out release tag tree.
  • It also overlays docs/source/release.rst; if an older tag has stale release.md, that file is removed so Sphinx uses the overlaid release.rst index.

• Add a docs-only release workflow mode.

  • full-release remains the default and preserves current package publication behavior.
  • docs-only runs release-note checks, resolves the artifact run ID, builds docs, and deploys docs.
  • docs-only skips GitHub release draft checking/creation, source archive upload, GitHub release wheel upload, TestPyPI, and PyPI.

• Keep old Furo-based cuda-python version selectors complete.

  • nv-versions.json remains the source of truth.
  • During release-note overlays, the workflow derives the legacy versions.json consumed by older cuda-python docs from nv-versions.json.
  • The checked-in cuda_python/docs/versions.json is refreshed to match the complete version list.

Validation

Focused tests:

• ci/tools/tests/test_check_release_notes.py

Manual release workflow validation:

• First v12.9.7 attempt failed in docs because the tag had ci/versions.json, not ci/versions.yml.

  • Analysis posted at [doc-only] Fix release notes checks for backport releases #2143 (comment)
  • Failed run: https://github.com/NVIDIA/cuda-python/actions/runs/26529691326

• After adding the legacy metadata fallback, the cuda-bindings v12.9.7 full release succeeded.

  • Analysis posted at [doc-only] Fix release notes checks for backport releases #2143 (comment)
  • Successful run: https://github.com/NVIDIA/cuda-python/actions/runs/26530929936

• After adding release-note overlays and docs-only, the cuda-bindings 12.9.7 docs-only repair succeeded and published the missing release-note page without touching PyPI or GitHub release assets.

  • Successful run: https://github.com/NVIDIA/cuda-python/actions/runs/26533255369
  • Published page: https://nvidia.github.io/cuda-python/cuda-bindings/12.9.7/release/12.9.7-notes.html

• The cuda-python v12.9.7 full release succeeded and published the metapackage.

  • Analysis posted at [doc-only] Fix release notes checks for backport releases #2143 (comment)
  • Successful run: https://github.com/NVIDIA/cuda-python/actions/runs/26534545238
  • Published PyPI package: https://pypi.org/project/cuda-python/12.9.7/

• After fixing the release.md / release.rst index conflict, the cuda-python 12.9.7 docs-only repair succeeded and made the full overlaid release-note list visible.

  • Analysis and screenshots posted at [doc-only] Fix release notes checks for backport releases #2143 (comment)
  • Successful run: https://github.com/NVIDIA/cuda-python/actions/runs/26539882504
  • Release-note index: https://nvidia.github.io/cuda-python/12.9.7/release.html

• After deriving legacy versions.json from nv-versions.json, the final cuda-python 12.9.7 docs-only repair succeeded and restored the complete old Furo version selector.

  • Analysis and screenshot posted at [doc-only] Fix release notes checks for backport releases #2143 (comment)
  • Successful run: https://github.com/NVIDIA/cuda-python/actions/runs/26541582007
  • Version metadata: https://nvidia.github.io/cuda-python/versions.json

Notes

The broad release-note overlay can produce harmless Sphinx warnings when an older tag contains historical *-notes.md files and the workflow branch overlays corresponding *-notes.rst files. This is intentional: it allows docs-only repair runs to propagate fixes to historical release notes maintained on the workflow branch into already-published versioned docs.

The top-level release index conflict is handled separately by removing stale release.md when an overlaid release.rst is present, because those two files map to the same Sphinx document name.

[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.

[rwgk]

First 12.9.7 Release Attempt Failure Analysis

Workflow run:

• https://github.com/NVIDIA/cuda-python/actions/runs/26529691326

Good news: the new release-notes check passed. The failure is later, in the reusable docs workflow:

Build release docs / Build docs
Step: Read build CTK version

BUILD_CTK_VER=$(yq '.cuda.build.version' ci/versions.yml)
Error: open ci/versions.yml: no such file or directory

Run inputs:

• workflow branch: fix_check-release-notes_for_backport_branch
• workflow commit: 28fe783c7b
• component: cuda-bindings
• git tag: v12.9.7
• artifact run ID: 26491171597

Root cause:

build-docs.yml is loaded from the PR 2143 branch, but the docs job then checks out inputs.git-tag, i.e. v12.9.7, before building docs. The current build-docs.yml expects this checked-out tree to contain:

ci/versions.yml

However, the v12.9.7 tag predates the repo layout change from JSON to YAML.
That tag contains:

ci/versions.json

with:

{
  "cuda": {
    "build": {
      "version": "12.9.1"
    }
  }
}

So this is the same general compatibility class as issue #2141: a current workflow is being run against an older backport tag whose source tree predates some workflow/tooling assumptions.

Recommended fix:

Update .github/workflows/build-docs.yml so the Read build CTK version step supports both layouts:

• prefer ci/versions.yml when present;
• fall back to ci/versions.json for older tags such as v12.9.7;
• keep the existing MAJOR.MINOR.MICRO validation.

This should let the v12.9.7 docs job proceed while preserving the current path for newer tags.

[rwgk]

12.9.7 Release Run Log Analysis

Workflow run:

• https://github.com/NVIDIA/cuda-python/actions/runs/26530929936

Summary: the run succeeded, and the core release path looks healthy.

What succeeded:

• check-release-notes passed with git-tag: v12.9.7, component: cuda-bindings, and blank backport-git-tag.
• The docs job used the ci/versions.json fallback from PR 2143 and derived BUILD_CTK_VER=12.9.1.
• The docs job built and deployed the cuda-bindings 12.9.7 docs.
• TestPyPI publishing succeeded.
• PyPI publishing succeeded.
• The GitHub release draft now has the expected cuda_bindings-12.9.7 wheels, source archive, and checksum assets.
• The top-level versioned docs URL is live: https://nvidia.github.io/cuda-python/cuda-bindings/12.9.7/

Benign warnings/noise observed:

• Git checkout emits the standard default-branch-name hint about master.
• actions/download-artifact emits Node Buffer() deprecation warnings.
• Some non-matching artifact download steps are skipped as expected.

Remaining issue:

The versioned 12.9.7 docs are live, but they do not contain the 12.9.7 release notes page:

https://nvidia.github.io/cuda-python/cuda-bindings/12.9.7/release/12.9.7-notes.html

currently returns 404.

The same release-note page does exist in the 13.3.0 docs:

https://nvidia.github.io/cuda-python/cuda-bindings/13.3.0/release/12.9.7-notes.html

Root cause:

build-docs.yml still builds docs from the release tag source tree. For this run, that means it checked out v12.9.7 and built docs from that tag. The v12.9.7 tag predates cuda_bindings/docs/source/release/12.9.7-notes.rst. Those release notes are maintained on main, not on the backport tag.

So PR 2143 now fixes:

• using current release-check tooling instead of tag-local tooling;
• accepting blank backport-git-tag for backport releases;
• supporting old ci/versions.json in docs builds.

But it does not yet make backport versioned docs include release-note files that exist only on main.

Recommendation:

Add one more narrow fix to PR 2143: before building release docs, overlay the component's docs/source/release/*-notes.rst files from the workflow source branch into the checked-out release tag tree.

Important constraints:

• Keep this limited to release-note source files.
• Do not overlay the full docs tree from main; the actual versioned docs should still be built from the release tag source.
• This should apply only to release docs builds, where inputs.is-release is true.

That should make a rerun of the v12.9.7 cuda-bindings release docs publish:

https://nvidia.github.io/cuda-python/cuda-bindings/12.9.7/release/12.9.7-notes.html

while preserving the intended source-of-truth model for backport release notes.

[rwgk]

Plan: Add a Docs-Only Release Workflow Mode

Motivation

The 12.9.7 release run succeeded for publishing, but exposed a docs-only follow-up need: the generated cuda-bindings/12.9.7/ docs exist, while the 12.9.7 release-note page is still missing from that versioned docs tree.

Rerunning the whole release workflow is unnecessarily risky after wheels have already been published to PyPI and uploaded to the GitHub release. We need a safe way to repair or regenerate release docs without touching package publication or release assets.

Proposed UI

Add a new workflow_dispatch choice input to .github/workflows/release.yml:

release-action:
  description: "What to run"
  required: true
  type: choice
  options:
    - full-release
    - docs-only
  default: full-release

The default should preserve current behavior.

Behavior

full-release:

• Current behavior.
• Run release-note checks.
• Build and deploy release docs.
• Upload source archive and wheels to the GitHub release.
• Publish wheels to TestPyPI.
• Publish wheels to PyPI.

docs-only:

• Run release-note checks.
• Determine or use the artifact run-id.
• Build and deploy release docs.
• Skip GitHub release creation/checking.
• Skip source archive upload.
• Skip GitHub release wheel upload.
• Skip TestPyPI.
• Skip PyPI.

Rationale

Use docs-only rather than a skip-pypi boolean because the desired operation is narrower than just skipping PyPI. A docs fixup rerun should also avoid touching GitHub release assets. The name docs-only makes the safety boundary obvious at dispatch time.

The docs job should still keep determine-run-id, because building docs installs wheels from the tag-triggered CI artifacts. For docs-only repair runs, the user can either provide run-id explicitly or let the workflow auto-detect the successful tag CI run as it does today.

docs-only should not require check-tag, because checking/creating a GitHub release is not part of a docs repair. This also avoids accidental release draft creation when the user only wants to regenerate docs.

Implementation Plan

1. Add the release-action input to .github/workflows/release.yml.

2. Gate check-tag so it runs only for full-release:

if: ${{ inputs.release-action == 'full-release' }}

3. Keep determine-run-id and check-release-notes for both modes.

4. Keep the docs job for both modes, with unchanged inputs to .github/workflows/build-docs.yml.

5. Gate publishing/upload jobs so they run only for full-release:

• upload-archive
• publish-testpypi
• publish-pypi

6. Adjust job needs carefully so docs-only is not blocked by a skipped check-tag job.

   The simplest shape is:

   • doc needs check-release-notes and determine-run-id.
   • upload-archive and publish-testpypi need check-tag, check-release-notes, determine-run-id, and doc, and are gated with release-action == 'full-release'.
   • publish-pypi remains downstream of publish-testpypi.

7. Add a short inline comment near the release-action input or gated jobs so future maintainers understand that docs-only is for repairing published release docs without touching package artifacts.

Validation

Since this is workflow control-flow only:

• inspect the rendered diff carefully;
• run git diff --check;
• if actionlint is available, run it on .github/workflows/release.yml;
• manually verify the intended dependency graph:
  • docs-only: determine-run-id -> check-release-notes -> doc;
  • full-release: current release path, including check-tag, docs, archive, TestPyPI, and PyPI.

[rwgk]

Analysis: 12.9.7 docs-only release run

Workflow run:

• https://github.com/NVIDIA/cuda-python/actions/runs/26533255369

Summary

The docs-only release run succeeded and fixed the missing cuda-bindings 12.9.7 release notes page:

https://nvidia.github.io/cuda-python/cuda-bindings/12.9.7/release/12.9.7-notes.html

The run used the new docs-only path from PR 2143 and behaved as intended:

• check-release-notes succeeded.
• determine-run-id succeeded and auto-detected the successful tag-triggered artifact run: 26491171597.
• check-tag was skipped, so the workflow did not check or create a GitHub release draft.
• Build release docs / Build docs succeeded.
• Upload source archive was skipped.
• Publish wheels to TestPyPI was skipped.
• Publish wheels to PyPI was skipped.

This confirms that the docs-only mode repaired release documentation without touching PyPI or GitHub release assets.

Relevant log details

The release notes checker found the expected backport notes:

Release notes present for backport tag v12.9.7, component cuda-bindings.

The docs workflow ran the new overlay steps:

• Checkout release notes source
• Overlay release notes from workflow source

The docs build completed successfully and deployed the regenerated release docs:

build succeeded, 165 warnings.
commit-message: Deploy release docs: v12.9.7
Completed deployment successfully!

Warning analysis

The most notable warning class was:

WARNING: multiple files found for the document "release/12.8.0-notes": release/12.8.0-notes.md, release/12.8.0-notes.rst

This is caused by the broad release-note overlay. Some older release tags still contain historical notes as .md files, while the workflow source branch contains migrated or updated .rst files for the same release-note stems. After overlaying the .rst files into the tag checkout, Sphinx sees both source formats for some documents and warns about the ambiguity.

These warnings are non-fatal and did not prevent the docs build or deployment. The target page for the repair, 12.9.7-notes.html, now exists and renders correctly.

Decision

We should keep the broad overlay behavior for PR 2143.

Although it can produce harmless duplicate-source warnings when an older tag has .md release notes and the workflow branch has .rst release notes for the same versions, the broader behavior is useful: if historical release notes are corrected or improved on main, a docs-only rerun can propagate those fixes into already-published versioned docs.

For this manual repair workflow, that benefit is more important than avoiding non-fatal Sphinx warning noise. No further fix is recommended for PR 2143 based on this run.

[rwgk]

Analysis: cuda-python 12.9.7 release run

Workflow run:

• https://github.com/NVIDIA/cuda-python/actions/runs/26534545238

Summary

The cuda-python full release run for v12.9.7 succeeded.

The run completed all expected full-release jobs successfully:

• determine-run-id
• check-tag
• check-release-notes
• Build release docs / Build docs
• Publish wheels to TestPyPI
• Upload source archive / upload
• Publish wheels to PyPI

The workflow auto-detected the successful tag-triggered artifact run:

Auto-detected run ID: 26491171597

The release-note check passed for the backport release:

Release notes present for backport tag v12.9.7, component cuda-python.

Package publication

The package publication path looks good.

The workflow downloaded and validated the expected metapackage wheel:

cuda_python-12.9.7-py3-none-any.whl
Checking dist/cuda_python-12.9.7-py3-none-any.whl: PASSED

Both TestPyPI and PyPI uploads succeeded:

Uploading cuda_python-12.9.7-py3-none-any.whl
Response from https://test.pypi.org/legacy/:
         200 OK

Uploading cuda_python-12.9.7-py3-none-any.whl
Response from https://upload.pypi.org/legacy/:
         200 OK

PyPI now has cuda-python==12.9.7, and its dependency metadata is correct:

cuda-bindings~=12.9.7
cuda-bindings[all]~=12.9.7; extra == "all"

GitHub release assets

The upload job succeeded and uploaded the source archive, checksum, and cuda-python wheel to the existing v12.9.7 draft release.

The GitHub release is still a draft, which matches the current workflow behavior:

isDraft: true
assetCount: 24

The assets include:

• cuda-python-v12.9.7.tar.gz
• cuda-python-v12.9.7.tar.gz.sha256sum
• cuda_python-12.9.7-py3-none-any.whl
• the previously uploaded cuda_bindings-12.9.7 wheels

Docs result

The docs build and deployment job succeeded:

build succeeded, 26 warnings.
commit-message: Deploy release docs: v12.9.7
Completed deployment successfully!

The cuda-python 12.9.7 release notes page exists and renders the intended content:

https://nvidia.github.io/cuda-python/12.9.7/release/12.9.7-notes.html

The page includes:

• cuda.bindings 12.9.7
• cuda.pathfinder 1.5.5

Docs warning and remaining issue

One docs issue remains. The cuda-python release-notes page exists, but it is not linked from the cuda-python/12.9.7/release.html release index/sidebar.

The relevant warnings are:

WARNING: multiple files found for the document "release": release.md, release.rst
...
/home/runner/work/cuda-python/cuda-python/cuda_python/docs/source/release/12.9.7-notes.rst: WARNING: document isn't included in any toctree

Root cause: the old v12.9.7 tag has cuda_python/docs/source/release.md. PR 2143's overlay adds cuda_python/docs/source/release.rst from the workflow branch, but it does not remove the stale release.md. Sphinx therefore sees both release.md and release.rst for the same document name and appears to keep using the old release.md index. That stale index does not list the overlaid 12.9.7 release notes.

This differs from the earlier cuda-bindings docs repair: the cuda-bindings tag already used release.rst, so overlaying release.rst cleanly updated the release index there.

Recommendation

Treat the package release itself as successful. No PyPI or GitHub asset follow-up is needed for cuda-python==12.9.7.

Before calling PR 2143 complete, add one more docs-overlay fix:

• when overlaying a component's docs/source/release.rst, remove a stale destination docs/source/release.md for that component;
• then rerun the release workflow in docs-only mode for component: cuda-python, git-tag: v12.9.7.

That should keep the already-successful package release untouched while regenerating the cuda-python 12.9.7 docs with the overlaid release index, so 12.9.7-notes.html is linked from the release notes page/sidebar.

[rwgk]

Analysis: cuda-python 12.9.7 docs-only run and version selector

Workflow run:

• https://github.com/NVIDIA/cuda-python/actions/runs/26539882504

Workflow log analysis

The docs-only run succeeded and used the intended safety path.

The completed jobs were:

• determine-run-id: success
• check-release-notes: success
• check-tag: skipped
• Build release docs / Build docs: success
• Upload source archive: skipped
• Publish wheels to TestPyPI: skipped
• Publish wheels to PyPI: skipped

The workflow ran from branch fix_check-release-notes_for_backport_branch at commit ac092a09d3.

The run auto-detected the existing successful tag-triggered artifact run:

Auto-detected run ID: 26491171597

The release-note check passed:

Release notes present for backport tag v12.9.7, component cuda-python.

The overlay step used the latest PR 2143 fix:

HEAD is now at ac092a0 Prefer overlaid release notes index

The previous top-level source conflict is fixed. The prior run emitted:

WARNING: multiple files found for the document "release": release.md, release.rst

This run no longer emits that warning.

The docs build succeeded:

build succeeded, 10 warnings.
commit-message: Deploy release docs: v12.9.7
Completed deployment successfully!

The remaining warnings are expected from the intentionally broad historical release-note overlay:

WARNING: multiple files found for the document "release/11.8.6-notes": release/11.8.6-notes.rst, release/11.8.6-notes.md
WARNING: multiple files found for the document "release/12.6.1-notes": release/12.6.1-notes.rst, release/12.6.1-notes.md
WARNING: multiple files found for the document "release/12.6.2-notes": release/12.6.2-notes.md, release/12.6.2-notes.rst
WARNING: multiple files found for the document "release/12.8.0-notes": release/12.8.0-notes.md, release/12.8.0-notes.rst

These warnings are non-fatal and consistent with the intended behavior: newer .rst release-note sources from the workflow branch are overlaid onto older tag checkouts that may still contain old .md note files.

The generated cuda-python 12.9.7 release-note index is now complete:

https://nvidia.github.io/cuda-python/12.9.7/release.html

It includes 12.9.7 and the later mainline release notes through 13.3.0.

Version selector analysis

The incomplete bottom-left Versions list is separate from the release-note toctree issue.

The older v12.9.7 docs use a legacy Furo sidebar template from the release tag:

<script src="{{ pathto('_static/javascripts/version_dropdown.js', 1) }}"></script>
<script>
  var jsonLoc = "{{ pathto('../versions.json', 1) }}";
  var targetLoc = "{{ pathto('../', 1) }}";
  add_version_dropdown(jsonLoc, targetLoc, currentVersion);
</script>

That legacy dropdown reads:

https://nvidia.github.io/cuda-python/versions.json

That file currently contains only:

latest
12.9.0
12.8.0
12.6.2
12.6.1

This exactly matches the incomplete version selector shown in both screenshots.

The newer complete version metadata exists separately:

https://nvidia.github.io/cuda-python/nv-versions.json

It includes:

latest
13.3.0
13.2.0
13.1.1
13.1.0
13.0.3
13.0.2
13.0.1
13.0.0
12.9.7
12.9.6
12.9.5
12.9.4
12.9.3
12.9.2
12.9.1
12.9.0
12.8.0
12.6.2
12.6.1

Newer docs use nv-versions.json through the nvidia_sphinx_theme switcher, but older Furo-based docs like v12.9.7 use versions.json through version_dropdown.js. Our release-note overlay fixes did not update this legacy versions.json, so the bottom-left selector stayed unchanged.

Recommendation

Keep nv-versions.json as the authoritative version list, and generate or update the legacy versions.json from it for cuda_python docs.

For compatibility with older published docs, versions.json should contain the same version keys as nv-versions.json, mapping each version to its relative docs folder:

{
  "latest": "latest",
  "13.3.0": "13.3.0",
  "13.2.0": "13.2.0",
  ...
  "12.6.1": "12.6.1"
}

Then rerun the release workflow in docs-only mode for component: cuda-python, git-tag: v12.9.7. This should update the legacy Versions selector without touching PyPI or GitHub release assets.

---

https://nvidia.github.io/cuda-python/12.9.7/release.html before commit ac092a0:

---

After commit ac092a0:

[rwgk]

Analysis: cuda-python 12.9.7 docs-only run after version-selector fix

Workflow run:

• https://github.com/NVIDIA/cuda-python/actions/runs/26541582007

Summary

The docs-only repair run succeeded and behaved as intended.

The run used branch fix_check-release-notes_for_backport_branch at commit e951445

That is the commit adding the legacy versions.json repair for old Furo-based cuda-python docs.

Job behavior

The workflow followed the expected docs-only path:

• check-release-notes: success
• determine-run-id: success
• check-tag: skipped
• Build release docs / Build docs: success
• Upload source archive: skipped
• Publish wheels to TestPyPI: skipped
• Publish wheels to PyPI: skipped

This confirms the run did not touch PyPI, TestPyPI, source archives, or GitHub release assets.

The workflow auto-detected the same successful tag-triggered artifact run as before:

Auto-detected run ID: 26491171597

The release-note check passed:

Release notes present for backport tag v12.9.7, component cuda-python.

Docs build

The docs build and deployment succeeded:

build succeeded, 10 warnings.
commit-message: Deploy release docs: v12.9.7
Completed deployment successfully!

The overlay step ran and the log shows the expected generated/overlaid metadata files, including nv-versions.json and versions.json.

The previous top-level release.md vs. release.rst conflict remains fixed; the log does not show:

WARNING: multiple files found for the document "release": release.md, release.rst

The remaining warnings are expected and non-fatal:

• duplicate historical *-notes.md / *-notes.rst release-note source files from the broad overlay;
• one 12.X.Y-notes.rst orphan warning;
• one pre-existing docutils warning from index.rst.

Version selector

The deployed legacy selector metadata is now complete.

https://nvidia.github.io/cuda-python/versions.json now contains:

latest
13.3.0
13.2.0
13.1.1
13.1.0
13.0.3
13.0.2
13.0.1
13.0.0
12.9.7
12.9.6
12.9.5
12.9.4
12.9.3
12.9.2
12.9.1
12.9.0
12.8.0
12.6.2
12.6.1

The v12.9.7 page still uses the old Furo dropdown script:

../versions.json

but that file now has the complete version list, so the bottom-left legacy selector is complete as shown in the screenshot.

Conclusion

The release-notes index and the legacy version selector are now both repaired for cuda-python 12.9.7 docs.

No further workflow or docs repair is recommended based on this run.

---

[rwgk]

/ok to test

[github-actions]

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