[wp-trac] [WordPress Trac] #57556: Configure feature branches on GitHub to trigger workflows to support development on forks

[WordPress Trac]

#57556: Configure feature branches on GitHub to trigger workflows to support
development on forks
------------------------------+-----------------------------
 Reporter:  flixos90          |      Owner:  (none)
     Type:  enhancement       |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  Build/Test Tools  |    Version:
 Severity:  normal            |   Keywords:
  Focuses:                    |
------------------------------+-----------------------------
 When contributing to WordPress core through GitHub, the workflow is to
 create new branch in a fork, and open a pull request from there to
 WordPress core.

 This works reasonably well for smaller pieces of work, but when it comes
 to larger features it is not a great development experience having to work
 in a single pull request for the entire effort. A simplified workflow can
 be to work in individual issues and pull requests within the fork, until a
 fully functional version of the feature or larger enhancement is ready for
 an actual WordPress core pull request.

 This workflow is already possible today, however one caveat is that as
 long as the development happens on the fork, the GitHub workflows are not
 triggered unless the work happens against the `trunk` branch. That however
 is not a good idea in itself as the `trunk` branch is the main development
 branch and not intended for work on specific features. It would make it
 impossible to work on multiple features in the same fork if they had to be
 developed against `trunk`.

 This ticket therefore proposes to add a certain branch pattern to the CI
 configuration of WordPress core's GitHub workflows, e.g. to ensure that
 they run for any branches satisfying the `feature/*` pattern.

 Of course in theory any fork could implement that individually, but that
 would eventually not be a great workflow as then every PR against the main
 `WordPress/wordpress-develop` repository would include that change, which
 it should not.

 Since no actual development happens within the `WordPress/wordpress-
 develop` repository directly, I'd argue there is no harm in adding this
 extra branch rule. What it would help though is to support the above
 workflow to develop greater features iteratively in a fork.

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