[BE] Skip binary smoke tests in PR#87340
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/87340
Note: Links to docs will display an error until the docs builds have been completed. ✅ No Failures, 1 PendingAs of commit 4a81047: This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
From the discussion with @atalman, here are some concerns in doing this:
This is indeed a trade-off between devx (running binary smoke tests twice in PR and master while asking people to wait for it) and coverage. |
|
@pytorchbot rebase -b master |
|
@pytorchbot successfully started a rebase job. Check the current status here |
|
Successfully rebased |
2a8cbf6 to
4a81047
Compare
My thought behind this:
ciflow/trunkfor every PR and the smoke testlinux-binary-manywheelis the job with the longest duration at the moment (2.6h at p90 on https://hud.pytorch.org/metrics). This is a long pole TTSlinux-binary-manywheelfailed whiletrunksucceeded. These binary build failures were flaky or cancelled or were old (CUDA 10.2). It means that trunk signals can safely cover binary smoke test signals, making the latter redundant in PRSo, it makes sense to skip this relatively slow step and run it only in trunk. Also here is the Rockset query for reference. It query all the occurrences (ciflow/trunk) where
linux-binary-manywheelfailed whiletrunksucceeded, thuslinux-binary-manywheelcould block merge.