Build the Linux wheels on OSDC runners - #22753
Open
huydhn wants to merge 2 commits into
Open
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22753
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (3 Unrelated Failures)As of commit 0d1e0b6 with merge base 12f7141 ( BROKEN TRUNK - The following jobs failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
meta-cla
Bot
added
the
CLA Signed
This PR needs a
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
This was referenced Sep 11, 2026
huydhn
added a commit
to pytorch/test-infra
that referenced
this pull request
Sep 11, 2026
The release runner groups are org-level and shared, but the script assumed a single consumer: it computed a desired allow-list from pytorch/pytorch and PATCHed selected_workflows to exactly that set. Pointing a second repository at the same groups would have had each run remove the other's entries, so the two would fight on every release. Reconcile only the entries prefixed with the target repo and carry the rest through untouched. reconcile_repo_access already added without removing, so it needed no change beyond taking the repo for its log lines. --repo selects the target, defaulting to pytorch/pytorch so the existing caller is unaffected. The version anchor is the one part that cannot be shared: pytorch/pytorch reads CURRENT_CANDIDATE_VERSION from generate_binary_build_matrix, which other repos do not publish, so they anchor on their newest protected release/X.Y branch instead. Reading a version file would be wrong for repos whose main carries the next dev version -- executorch's version.txt says 1.6.0 while its newest branch is release/1.5. Tests cover the scoping (other repos' entries survive, a stale entry for the target is still replaced, pytorch/executorch-examples is not mistaken for pytorch/executorch, an empty desired set still refuses to write) and the anchor. For pytorch/executorch#22753.
huydhn
added a commit
to pytorch/test-infra
that referenced
this pull request
Sep 11, 2026
The release runner groups are org-level and shared, but the script assumed a single consumer: it computed a desired allow-list from pytorch/pytorch and PATCHed selected_workflows to exactly that set. Pointing a second repository at the same groups would have had each run remove the other's entries, so the two would fight on every release. Reconcile only the entries prefixed with the target repo and carry the rest through untouched. reconcile_repo_access already added without removing, so it needed no change beyond taking the repo for its log lines. --repo selects the target, defaulting to pytorch/pytorch so the existing caller is unaffected. The version anchor is the one part that cannot be shared: pytorch/pytorch reads CURRENT_CANDIDATE_VERSION from generate_binary_build_matrix, which other repos do not publish, so they anchor on their newest protected release/X.Y branch instead. For pytorch/executorch#22753.
huydhn
force-pushed
the
osdc/wheel-release-runners
branch
from
September 11, 2026 21:06
048bb93 to
a57dc3e
Compare
huydhn
changed the title
huydhn
marked this pull request as ready for review
September 12, 2026 22:03
huydhn
added a commit
to pytorch/vision
that referenced
this pull request
Sep 12, 2026
Same shape as pytorch/executorch#22753: _select-release-runner.yml is the single place the labels are named, and the callers pass its outputs to build_wheels_linux.yml. Release-isolated mt-rel-l-* on the refs these workflows publish from (nightly, main, release/* and the v* candidate tags), regular mt-l-* everywhere else including pull requests. No path returns an EC2 label. x86_64 cpu/rocm/xpu mt-l-x86iavx512-8-64 mt-rel-l-x86iavx512-44-340 x86_64 cuda mt-l-x86aavx2-29-113-a10g mt-rel-l-x86aavx2-29-113-l4 aarch64 any mt-l-arm64g4-16-62 mt-rel-l-arm64g3-44-340 The x86 matrix mixes four CPU rows (cpu, rocm10_0, rocm7_14, xpu) with three cuda ones, and a single runner override cannot express that: it either puts the CPU builds on a GPU runner or takes the device away from the cuda rows, whose smoke test guards its CUDA checks with torch.cuda.is_available() and so skips them silently. pytorch/test-infra#8789 adds a runner-gpu input for exactly this, applied to the cuda rows only, so the split is expressed by the caller and the per-row selection stays in the shared workflow rather than in a script here. aarch64 needs only the one label: OSDC has no arm64 GPU runner, which matches today, since its cuda rows already build on an m7g box with no device. The rocm rows build ROCm wheels on an ordinary CPU builder and need no AMD hardware. Depends on pytorch/test-infra#8789 for runner-gpu, and because without it build_wheels_linux.yml cannot run on an OSDC pod at all. Authored with Claude Code.
One input on the matrix generator. pytorch/test-infra#8789 adds runner-fleet, which maps each row's validation_runner to its ARC equivalent: release-isolated on the refs these workflows publish from, regular otherwise, so pull request builds move off EC2 too. x86_64 cpu mt-l-x86iavx512-8-64 mt-rel-l-x86iavx512-44-340 x86_64 cuda mt-l-x86aavx2-29-113-a10g mt-rel-l-x86aavx2-29-113-l4 aarch64 any mt-l-arm64g4-16-62 mt-rel-l-arm64g3-44-340 The cuda x86_64 rows keep a device, which they need: test_cuda_linux.py exports a model through the CUDA partitioner and runs it against eager, and on a CPU runner that check would skip rather than fail. Depends on pytorch/test-infra#8789, which also carries the two fixes build_wheels_linux.yml needs to run on an OSDC pod at all. Authored with Claude Code.
huydhn
force-pushed
the
osdc/wheel-release-runners
branch
from
September 12, 2026 22:58
a57dc3e to
a759ebb
Compare
Drop before merging. Points both the matrix generator and the wheel build at that PR's branch, and the test-infra checkout with them, so CI here exercises runner-fleet and the two OSDC fixes it carries. Against test-infra main the runner-fleet input does not exist and the call is rejected outright.
huydhn
added a commit
to pytorch/test-infra
that referenced
this pull request
Sep 12, 2026
The release runner groups are org-level and shared, but the script assumed a single consumer: it computed a desired allow-list from `pytorch/pytorch` and PATCHed `selected_workflows` to exactly that set. Pointing a second repository at the same groups would have had each run remove the other's entries, so the two would fight on every release. Now it reconciles only the entries prefixed with the target repo and carries the rest through untouched. `reconcile_repo_access` already added without removing, so it needed no change beyond taking the repo for its log lines. `--repo` selects the target, defaulting to `pytorch/pytorch`, so the existing caller is unaffected. The version anchor is the one part that cannot be shared: `pytorch/pytorch` reads `CURRENT_CANDIDATE_VERSION` from `generate_binary_build_matrix`, which other repos do not publish, so they anchor on their newest protected `release/X.Y` branch instead. Reading a version file would be wrong for repos whose main carries the next dev version — executorch's `version.txt` says `1.6.0` while its newest branch is `release/1.5`. Tests: 31 pass. New coverage for the scoping (other repos' entries survive, a stale entry for the target is still replaced, `pytorch/executorch-examples` is not mistaken for `pytorch/executorch`, an empty desired set still refuses to write) and for the anchor. For pytorch/executorch#22753.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Takes all four Linux wheel workflows off EC2.
One input on the matrix generator. pytorch/test-infra#8789 adds
runner-fleet, which maps each row'svalidation_runnerto its ARC equivalent — release-isolated on the refs these workflows publish from, regular otherwise, so PR builds move off EC2 too.mt-l-x86iavx512-8-64mt-rel-l-x86iavx512-44-340mt-l-x86aavx2-29-113-a10gmt-rel-l-x86aavx2-29-113-l4mt-l-arm64g4-16-62mt-rel-l-arm64g3-44-340The cuda x86_64 rows keep a device, which they need:
test_cuda_linux.pyexports a model through the CUDA partitioner and runs it against eager, and on a CPU runner that check would skip rather than fail.Depends on pytorch/test-infra#8789.
Authored with Claude Code.