- As discussed in
https://github.com/Homebrew/brew/pull/16337#issuecomment-1855668516,
then we won't have the chicken/egg problem of fixing cops for syntax
that's unsupported on Ruby 2.6 _before_ we set the TargetRubyVersion
to 3.1, but if we set it too early then all the taps will fail.
This prevents situations where the Intel runners have a 360 minute
timeout but the ARM runners only have 45 minutes.
See Homebrew/homebrew-core#130284.
1. Use the maximum timeout possible for GitHub-hosted macOS runners
2. When using a short timeout, use an even shorter timeout on ARM
runners.
Our ARM runners are typically at least twice as fast as our Intel
runners on any given job. So, if it takes an ARM runner over half the
timeout to complete a job, it's almost certain that the Intel runner
will not complete the job within the timeout.
Setting an even shorter timeout on the ARM runners will help us abandon
jobs that are unlikely to be completed within the timeout well before we
hit the requested timeout.
This makes our dependent tests run on a GitHub macOS runner if
compatible with the requested timeout.
This will also allow builds on a GitHub runner on macOS if requested
with the environment variable `HOMEBREW_MACOS_BUILD_ON_GITHUB_RUNNER`.
This environment variable will need to be set in the workflow as
appropriate (e.g. when requested by a label).
This will allow us to set a slightly longer timeout on Intel Big Sur,
which is useful because the Intel Big Sur runner often exceeds our short
time limit by itself.
The `GitHubRunnerMatrix` takes a list of testing formulae, deleted
formulae, and the available runners and constructs the matrix of active
runners for any given test job.
