Move test-executorch-cuda-build to linux_job_v3 - #22890
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22890
Note: Links to docs will display an error until the docs builds have been completed. ❌ You can merge normally! (1 Unrelated Failure), 1 Unclassified FailureAs of commit cd66218 with merge base 9250dc3 ( UNCLASSIFIED FAILURE - DrCI could not classify the following job because the workflow did not run on the merge base. The failure may be pre-existing on trunk or introduced by this PR:
BROKEN TRUNK - The following job 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. |
This PR needs a
|
1373c1f to
3288dd2
Compare
Drops the driver-version / driver-download-url pins rather than porting them, because the job was mostly not using them: 12.6 minimum driver 560.28.03 -- R580 clears it 13.0 minimum driver 580.65.06 -- R580 is exactly this 13.4 asked for 615.71.09 -- see below Two of the three cells were already passing 580.65.06, which is what OSDC nodes ship from the EKS NVIDIA AMI, so those installs were a no-op. Only 13.4 wanted something newer, and CUDA minor version compatibility means a 13.x application runs on any driver supporting 13.0 provided it stays off newer driver APIs, so R580 is enough there too -- all three cells pass on this PR. Installing a driver per job is an EC2 idea regardless: on OSDC the driver belongs to the node and a pod cannot replace it. test_cuda_workflow.py asserted the old arrangement directly -- v2, a 40-hex revision, test-infra-ref equal to it, and both driver inputs verbatim. That test existed to keep the pin and the driver inputs in sync, which is not a thing that can drift once neither exists, so it now asserts the replacement invariant: v3 at main, and none of those three inputs set. The runner moves to mt-l-x86aavx2-11-41-a10g, sized for the g5.4xlarge that the linux.g5.4xlarge.nvidia.gpu label it came from already names. Authored with Claude Code.
3288dd2 to
cd66218
Compare
Drops the
driver-version/driver-download-urlpins rather than porting them, because the job was mostly not using them:Two of the three cells were already passing
580.65.06, which is what OSDC nodes ship from the EKS NVIDIA AMI — those installs were a no-op. Only 13.4 wanted something newer, and CUDA minor version compatibility means a 13.x application runs on any driver supporting 13.0, provided it stays off newer driver APIs. So R580 is likely enough there too.Installing a driver per job is an EC2 idea regardless: on OSDC the driver belongs to the node and a pod cannot replace it.
If 13.4 does fail, the fix is the R615 AMI in pytorch/ci-infra#1068, not this workflow. The failure would look like a test error rather than a build one —
test-cuda-build.shruns a CUDA matmul and exits 1 if the device is unavailable.Testing
https://github.com/pytorch/executorch/actions/runs/35148091997/job/104969392177?pr=22890