Skip to content

Weekly compatibility tests against oldest supported PyTorch - #745

Open
swahtz wants to merge 1 commit into
mainfrom
weekly-compat-tests
Open

Weekly compatibility tests against oldest supported PyTorch#745
swahtz wants to merge 1 commit into
mainfrom
weekly-compat-tests

Conversation

@swahtz

@swahtz swahtz commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Implements the weekly testing regime described in the installation docs (Notes on Testing, Compatibility, and Distribution): test fvdb-core weekly against the oldest PyTorch version that publishes wheels for the lowest CUDA version implied by the "stable PyTorch's latest two CUDA versions" policy. For the PyTorch 2.13 matrix (#738) that is PyTorch 2.9.1 with CUDA 13.0 (verified against the versions published on download.pytorch.org/whl/cu130).

Changes:

  • .github/versions.json: new weekly_compat block recording the tested torch/cuda versions, so they get reviewed and updated alongside the rest of the version matrix each cycle.
  • .github/workflows/load-versions.yml: new outputs compat-torch-version, compat-torch-full-version, compat-cuda-version, compat-cuda-tag, and compat-cuda-patch (the container-image patch is looked up from the existing cuda.versions map, so the compat CUDA must be one of the supported versions — which the policy guarantees).
  • .github/workflows/weekly-compat.yml: new scheduled workflow (Saturdays 8am UTC + workflow_dispatch) mirroring the cu130.yml pipeline without the pull_request_target merge plumbing: provision EC2 CPU runner → build wheel/gtests against the compat PyTorch/CUDA pin → provision EC2 GPU runner → run gtests and Python unit tests → tear down runners.
  • CHANGES.md: note the new weekly compatibility testing under 0.6.0.

Notes:

  • Doc tests (pytest --markdown-docs) are intentionally omitted: the documentation examples pin the current in-development versions, not the compat versions.
  • Passes actionlint, zizmor --persona=regular, and the repo's EC2 runner-token policy check locally.
  • The weekly_compat values are a deliberate second source of truth from torch.version: at each new dev cycle (like PyTorch 2.13 #738), whoever bumps the matrix consults PyTorch's release compatibility matrix and updates weekly_compat per the policy.

🤖 Generated with Claude Code

@swahtz
swahtz marked this pull request as ready for review August 20, 2026 01:56
@swahtz
swahtz requested review from a team as code owners August 20, 2026 01:56
@swahtz
swahtz requested review from areidmeyer and matthewdcong and removed request for a team August 20, 2026 01:56
@swahtz
swahtz changed the base branch from pytorch_213 to main August 20, 2026 01:56
@swahtz swahtz added this to the v0.6 milestone Aug 20, 2026
Implements the weekly testing regime documented in docs/installation.rst
(Notes on Testing, Compatibility, and Distribution): build and test main
against the oldest PyTorch version that publishes wheels for the lowest
CUDA version implied by the stable-PyTorch policy. For the PyTorch 2.13
matrix that is PyTorch 2.9.1 with CUDA 13.0.

- .github/versions.json: record the tested versions under weekly_compat
  so they are updated alongside the rest of the version matrix.
- load-versions.yml: expose compat-torch-version, compat-torch-full-version,
  compat-cuda-version, compat-cuda-tag, and compat-cuda-patch outputs.
- weekly-compat.yml: new scheduled workflow (Saturdays 8am UTC, plus
  manual dispatch) mirroring the cu130 build/test pipeline without the
  PR-merge plumbing: EC2 CPU runner builds the wheel and gtests against
  the compat PyTorch/CUDA pin, then an EC2 GPU runner runs gtests and
  the Python unit tests. Doc tests are omitted since the documentation
  examples target the current in-development versions.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>
@swahtz
swahtz force-pushed the weekly-compat-tests branch from 86e763e to a5858a1 Compare August 20, 2026 03:37
@swahtz swahtz added the CI Issues related to the Github actions CI/CD. For build issues use CMake/Build label Aug 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CI Issues related to the Github actions CI/CD. For build issues use CMake/Build

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant