Limit the number of GitHub Actions jobs that spawn for pull requests to forks

[desrosj]

A common contributor workflow is to open a pull request where both the HEAD and BASE branches belong to the fork to track and continually test the effectiveness of ongoing work. Once it's ready, a new pull request is opened where the BASE branch belongs to wordpress-develop.

Forks of ​wordpress-develop will almost always be subject to the ​GitHub Free plan limitations for GitHub actions of 20 concurrent jobs and 500MB of storage for GitHub-hosted runners.

Within the GitHub Actions workflows, there are some conditions guarding against running certain workflows given specific circumstances with the primary safeguard disabling workflows for all push events to forks. A few other examples of this are using path filtering to trigger events more efficiently (see [59252], [59254], and [59725]), skipping jobs that utilize costly runner images (see [50485]), requiring a pull request with the BASE branch belonging to the fork to run workflows at all (see [49781]), and disabling workflows entirely when triggered by Dependabot (see [60080]).

Despite these guard rails, the number of jobs spawned quickly builds a queue that can take hours to complete (the PHPUnit workflow currently spawns 214 jobs alone).

Given that the expectation is for a pull request to be opened submitting the code back to wordpress-develop when ready, forks should only run a small subset of test combinations to allow for feedback from workflows in a more reasonable amount of time. The full test suite will run once a proper pull request is opened later on.

This limits the number of jobs that can run when a pull request is opened within a fork to a maximum of:

• 29 jobs that run in a minute or less.
• 6 jobs that take between 1 and 3 minutes.
• 18 jobs that take longer.

These jobs are spread out across 10 different workflows, and the maximum only occurs when the required run criteria for all 9 workflows is met. When only PHP files are modified, there are 28 jobs across 7 workflows with 14 taking less than 2 minutes and just 12 taking longer.

Trac ticket: Core-63752.

This limits the number of jobs that can run when a pull request is opened within a fork to a maximum of:

• 29 jobs that run in a minute or less.
• 6 jobs that take between 1 and 3 minutes.
• 18 jobs that take longer.

These jobs are spread out across 10 different workflows, and the maximum only occurs when the required run criteria for all 9 workflows is met. When only PHP files are modified, there are 28 jobs across 7 workflows with 14 taking less than 2 minutes and just 12 taking longer.

Trac ticket: Core-63752.

I've made adjustments to the conditions to support running the full test suite for private forks that may or may not exist within the organization while still limiting forks outside of the org.

[desrosj]

In 60534:

Build/Test Tools: Spawn fewer jobs in GitHub Actions on forks.

The GitHub Actions workflows currently limit when jobs run for forks by short-circuiting any that are triggered by push events when not running within the wordpress-develop repository.

Because the large majority of forks are not created under organizations, they will be subject to the individual account limit of 20 concurrent jobs (40 for pro accounts) at any given time instead of the 500 concurrent job limit that applies to the WordPress organization. This means that a single pull request back to a fork can take several hours to complete the workflow jobs that are spawned.

This revises the conditional statements to further limit the number of jobs that spawn within a fork while still allowing the full test matrices for forks within the WordPress organization and pull requests back to wordpress-develop.

These adjustments result in a maximum of 53 jobs when all workflows configured to run within forks are triggered. Of these, ~66% will run in less than 3 minutes, and ~55% will run in less than 1 minute.

Props jorbin, johnbillion.
Fixes #63752.