Skip to content

Enable nightly build to test 2.14 - #3955

Merged
atalman merged 1 commit into
mainfrom
2-14-enable-nightly
Sep 2, 2026
Merged

Enable nightly build to test 2.14#3955
atalman merged 1 commit into
mainfrom
2-14-enable-nightly

Conversation

@atalman

@atalman atalman commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

Summary

Branch-cut step to start testing the 2.14 release in tutorials. Mirrors #3929 ("Enable nightly build to test 2.13").

  • .jenkins/build.sh: pin torch==2.14.0 (from the test channel, cu130) on the USE_NIGHTLY path and the commented reference line; update the 2.13 -> 2.14 comment.

Unlike #3929, no workflow change is needed: the push on main trigger in .github/workflows/build-tutorials-nightly.yml is still enabled from the 2.13 cycle, so the nightly tutorials build already runs on main and will pick up the 2.14 RC binaries with this pin.

.ci/docker/requirements.txt is intentionally left at torch==2.13 — that gets bumped to 2.14 at the later "move to stable binaries" step, once 2.14 is released.

Verification

torch==2.14.0+cu130 is published on the test channel, so the pin resolves:

https://download.pytorch.org/whl/test/cu130/torch/
  torch-2.14.0+cu130-cp312-cp312-manylinux_2_28_x86_64.whl
  torch-2.14.0+cu130-cp312-cp312-manylinux_2_28_aarch64.whl

cu130 remains the right channel for 2.14: CUDA 13.0 is the stable CUDA version in the 2.14 release matrix.

Release playbook reference (2.13 -> 2.14)

step 2.13 2.14
enable nightly build to test the RC #3929 this PR
move to stable binaries after release (2.13 equivalent) follow-up

Branch-cut step to start testing the 2.14 release in tutorials, mirroring
#3929 for 2.13. The push-on-main trigger in build-tutorials-nightly.yml is
already enabled, so only the pin moves this time.
@pytorch-bot

pytorch-bot Bot commented Aug 26, 2026

Copy link
Copy Markdown

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/tutorials/3955

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit 689fd38 with merge base d445c1f (image):
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@meta-cla meta-cla Bot added the cla signed label Aug 26, 2026
@atalman
atalman merged commit 21b2c56 into main Sep 2, 2026
24 checks passed
atalman added a commit that referenced this pull request Sep 2, 2026
…3960)

Fixes: #3816

`beginner_source/introyt/autogradyt_tutorial.py` fails on torch 2.14:

```
File "beginner_source/introyt/autogradyt_tutorial.py", line 493, in <module>
    with torch.autograd.profiler.profile(use_cuda=run_on_gpu) as prf:
TypeError: profile.__init__() got an unexpected keyword argument 'use_cuda'
```

`use_cuda` was the deprecated alias for `use_device` and has been
removed in 2.14:

| ref | `profile.__init__` |
| --- | --- |
| `v2.13.0` | `use_cuda=False, # Deprecated` alongside `use_device=None`
|
| `v2.14.0-rc10` | `use_cuda` gone entirely; `use_device=None` remains |

Switch to the supported spelling:

```diff
-with torch.autograd.profiler.profile(use_cuda=run_on_gpu) as prf:
+with torch.autograd.profiler.profile(use_device="cuda" if run_on_gpu else None) as prf:
```

`run_on_gpu` is already computed a few lines above from
`torch.cuda.is_available()`, so behaviour is unchanged on both CPU and
GPU runners.

## Where this is failing

Surfaced by the nightly lane once #3955 moved it from 2.13.0 to 2.14.0
-- [failing
run](https://github.com/pytorch/tutorials/actions/runs/33655943733/job/100334388632).
`build-tutorials-nightly.yml` sets `USE_NIGHTLY=1`, so
`.jenkins/build.sh` installs `torch==2.14.0` from the test channel.

It will also start failing on the regular PR/push gate once #3959 lands,
since that moves `.ci/docker/requirements.txt` from `torch==2.13` to
`torch==2.14`. `.jenkins/get_files_to_run.py` shards every tutorial
across the workers, so this file runs on every build.

Standalone so it can land ahead of, and independently of, #3955 / #3959.

## Note on the trailing katex traceback

The `sphinxcontrib.katex` `FileNotFoundError: '/tmp/tmp...'` at the end
of that log is secondary -- Sphinx raises the gallery `ExtensionError`
first, then the katex `build-finished` handler trips over an
already-removed temp dir while unwinding. It should disappear with this
fix. It is unrelated to the `yarn global add katex` pin in #3959.

AI assistance (Claude) was used for this change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants