[wp-trac] [WordPress Trac] #63752: Limit the number of GitHub Actions jobs that spawn for pull requests to forks

WordPress Trac noreply at wordpress.org
Fri Jul 25 20:04:06 UTC 2025


#63752: Limit the number of GitHub Actions jobs that spawn for pull requests to
forks
------------------------------+--------------------
 Reporter:  desrosj           |      Owner:  (none)
     Type:  enhancement       |     Status:  new
 Priority:  normal            |  Milestone:  6.9
Component:  Build/Test Tools  |    Version:
 Severity:  normal            |   Keywords:
  Focuses:                    |
------------------------------+--------------------
 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 [https://github.com/wordpress/wordpress-develop wordpress-
 develop] will almost always be subject to the
 [https://docs.github.com/en/actions/reference/actions-limits#job-
 concurrency-limits-for-github-hosted-runners 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63752>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list