Run coreml_static_int8 macOS tests on the nightly schedule only

[shoumikhin]

Problem

The CoreML backend test workflow (test-backend-coreml.yml) runs its macOS jobs on every commit. On busy days the coreml_static_int8 macOS jobs (the slowest variant) queue for hours and saturate the shared macOS runner pool, which blocks other required macOS jobs from starting. When those required jobs never run, no commit completes its required checks.

Fix

Run the heavier coreml_static_int8 macOS matrix only on the nightly schedule. Pushes and pull requests keep running the lighter coreml flow. This roughly halves this workflow's per-commit macOS load while keeping full coreml_static_int8 coverage nightly.

Note: this workflow runs macOS only (run-linux is not set), so Linux coverage is unchanged.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21609

• 📄 Preview Python docs built from this PR

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

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• [ALERT ONLY] - System Maintenance

✅ You can merge normally! (3 Unrelated Failures)

As of commit 1e96f73 with merge base 8422afd ():

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• pull / unittest / macos / macos-job (gh) (trunk failure)
• pull / unittest-buck / macos / macos-job (gh) (trunk failure)
• pull / unittest-editable / macos / macos-job (gh) (trunk failure)

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

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[digantdesai]

Thanks. Do you know what makes it so heavy, is it larger model weights only for int8?

[shoumikhin]

Not the weights. coreml_static_int8 runs the exact same models + operators suite as coreml, just with quantize=True (a PT2E prepare / calibrate / convert pass per test case) and a higher minimum deployment target (iOS17). Adding a quantization pass to every single case is what blows it up.

Measured on a recent main commit:

job	duration
coreml / models	12 min
coreml / operators	11 min
coreml_static_int8 / models	25 min
coreml_static_int8 / operators	181 min, cancelled at the 180 min cap

So the int8 operators job alone burns a full 3 hours of a macOS runner on every main commit and still does not finish. That is about 3.4 runner hours per commit for the int8 flow versus 23 minutes for the fp flow.

Separate follow up worth filing: the int8 operators suite has never completed inside the timeout, so today it produces no signal at all. It needs sharding, or the per-case quantize needs to get cheaper.