Drop the coreml_static_int8 operators job, which has never once finished

[shoumikhin]

Addresses #21623.

What is broken

Every night, the CoreML backend workflow runs this job on a macOS runner:

test-backend-macos (coreml_static_int8, operators)

It has never finished. It runs for the full 180 minute limit, gets killed, and reports cancelled. That is about three macOS runner hours per night, every night, for no result at all, on a runner pool that is already the scarcest resource we have.

For comparison, in a recent nightly run:

job	outcome
coreml / operators	passed in 11m41s
coreml_static_int8 / models	passed in 26m41s
coreml_static_int8 / operators	killed at 3h00m50s

So it is specifically the combination of the heavier quantized flow with the much larger operators suite that does not fit.

Why we cannot just make it faster

The suite already runs with pytest -n auto, so it is using every core on the runner. There is no sharding support in _test_backend.yml to split it across several runners. Adding that is real work, and it is the right long term answer, but it is not something to land while the job is burning runner hours nightly.

The fix

Stop scheduling that one combination.

_test_backend.yml builds its matrix as every flow crossed with every suite, so today the only way to shape it is to change the flow list, which would also drop coreml_static_int8 / models, and that one passes and is worth keeping.

This adds an optional exclude input to _test_backend.yml that is wired straight into strategy.matrix.exclude. It defaults to an empty list, so nothing changes for any other backend. test-backend-coreml.yml then uses it to drop the single coreml_static_int8 plus operators pair.

After this change the nightly CoreML run is coreml / models, coreml / operators and coreml_static_int8 / models, all three of which actually complete.

When to revert this

When the operators suite can be sharded across runners, or when the quantized flow gets fast enough to fit in the limit. #21623 tracks that.

How this was verified

Two separate things needed checking: that the new input is inert for every other
caller, and that the exclude entry removes the job we mean and nothing else.

• Inert by default. With this branch's _test_backend.yml, the nine other
  callers of that reusable workflow still expand to every flow crossed with both
  suites. An exclude list that matches no combination is simply ignored by
  GitHub Actions, so the empty default is a no-op.
• Correct entry. test-backend-coreml.yml only runs coreml_static_int8 on the
  nightly schedule, so a pull request run would not show the effect at all. It
  was therefore dispatched on a scratch branch with both flows forced on. The
  resulting job list was (coreml, models), (coreml, operators) and
  (coreml_static_int8, models). The (coreml_static_int8, operators) pair was
  gone and nothing else moved.

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit f3e0024 with merge base 730b77a ():

FLAKY - The following job failed but was likely due to flakiness present on trunk:

• pull / test-qnn-testsuite-linux / test-backend-linux (qnn, models) / linux-job (gh) (detected as infra flaky with no log or failing log classifier)

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.