v2.13.0-rc1: [release 2.13] Apply Release only changes to 2.13 branch (#186959)

• [release 2.13] Apply Release only changes to 2.13 branch

Release-only changes for the release/2.13 branch cut, produced by

running scripts/release/apply-release-changes.sh. The script repoints

reusable workflows and composite actions from @main to @release/2.13,

rewrites templates to release/2.13 (with checkout_pr_head=False so PRs

build the merge base rather than the PR head), pins the XLA checkout to

the r2.13 branch, pins the disabled/unstable jobs and disabled-tests S3

JSON blobs to fixed versionIds, sets RELEASE_VERSION_TAG=2.13 for the

workflow-regeneration lint check, and drops the pull_request-specific

checkout ref from the linux binary build/test workflows.

Only files that are tracked in release/2.13 are included. The 2.12 PR

additionally touched .ci/manywheel/build_cuda.sh and a few workflow

files (torchbench/nitpicker/quantization-periodic) that are not tracked

in this checkout, so they are intentionally omitted here.

Test Plan:

Ran the release script and linter:

DRY_RUN=disabled ./scripts/release/apply-release-changes.sh

lintrunner -a

lintrunner reported only pre-existing ACTIONLINT shellcheck warnings on

generated workflow lines unrelated to the release-version edits, and made

no changes to the staged files. Verified every staged hunk is a

release-only edit (@main -> @release/2.13, main -> release/2.13, XLA

r2.13 pin, S3 versionId pins, RELEASE_VERSION_TAG=2.13, and the

pull_request ref removal) with no submodule or unrelated changes.

This PR was authored with the assistance of Claude Code.

• [release 2.13] Pin Linux manywheel builder docker images

Release builds should use a fixed, reproducible build toolchain instead

of the floating builder image tags that main tracks (e.g.

pytorch/manylinux2_28-builder:cuda12.6). For 2.12 the binary build

workflows resolved the image dynamically via calculate-docker-image; for

2.13 we freeze that resolved image as a literal pin.

The pin is applied in the generator (generate_binary_build_matrix.py)

rather than in the generated YAML directly, so re-running

.github/regenerate.sh (and the lint job that asserts the generated files

are up to date) reproduces the pinned tags. wheel_container_image_tag_prefix()

appends the pin only for the linux manywheel OSes (linux, linux-aarch64,

linux-s390x), since only those builds run inside these containers;

windows and macos keep the plain tag prefix.

The pin suffix is the .ci/docker tree hash, f38ba0b10220982e39441d29d203d803a2b56c92

(git rev-parse HEAD:.ci/docker), which is exactly the tag that

.github/actions/binary-docker-build (and the s390x equivalent) publish

as ${prefix}-${CI_FOLDER_SHA}. It matches the image already published on

Docker Hub, e.g.

pytorch/manylinux2_28_aarch64-builder:cpu-aarch64-f38ba0b10220982e39441d29d203d803a2b56c92

Test Plan:

Regenerated the workflows in release mode and verified the result:

RELEASE_VERSION_TAG=2.13 python3 .github/scripts/generate_ci_workflows.py

• Every image: and matrix docker_image_tag_prefix in the three linux
  
  manywheel generated workflows now carries the -f38ba0b... suffix
  
  (cpu, cpu-aarch64, cuda12.6/13.0/13.2, rocm7.1/7.2, xpu, cpu-s390x);
  
  no linux builder image remains floating.


• Windows and macos generated workflows are unchanged (plain cpu,
  
  cuda12.6, ...), confirming the pin is linux-only.


• Re-running the generator a second time produced byte-identical output
  
  (md5sum unchanged), so the regeneration/lint up-to-date check is
  
  stable.

Note: the local linters that shell out to uv could not run in this

environment; the change was format-checked manually.

This PR was authored with the assistance of Claude Code.