[wp-trac] [WordPress Trac] #64393: Change how we include Gutenberg in Core

Tue Feb 24 03:16:12 UTC 2026

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  reopened
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by desrosj):

 > Couldn't other commits cause similar issues when there are changes to
 the build process? Could we change it so that error logs are included?
 Could we figure out what the errors are? Do you have any suspicions on
 what the issue could be? I'm entirely unfamiliar with this area.

 It's always possible that changes to the build process can adversely
 effect the hosting tests. But ideally that is considered before making
 changes, or participants can be made aware of any changes required on
 their end to continue reporting. This tool is not perfect by any means,
 and adding some reporting when errors happen before reaching the `phpunit`
 command is a good idea. Without that though, we can only use the number of
 bots that report to determine when problems were introduced.

 > Could we measure again after the changset that skips the types?
 Yes, I intend to measure that once there's enough data to perform a fair
 comparison. At the time of my last comment, there was data for less than
 24 hours. I was planning to come back after a full week.

 > The performance issue sounds very important to you and I get that, we
 should definitely try to improve these as much as we can.

 There are 4 variables that are very important to consider and balance when
 it comes to making any changes to the project's build scripts and test
 workflows: completeness, speed, volume, developer experience.

 - Completeness: we should be confident that enough scenarios and
 combinations are tested to promote a strong level of confidence in any
 change. This mainly surfaces in two ways: the number of variable
 combinations (PHP/database versions, etc.), and the sheer number of paths
 tested (code coverage).
 - Volume: The workflows maintained across the project should be able to
 recover from drastic increases in contributor activity (leading up to beta
 1, during a Contributor Day, etc.) in a reasonable amount of time.
 - Speed: the build scripts and GitHub Actions workflows (both for
 automating tasks and running test suites) should be as fast as they can
 be.
 - Developer experience: the scripts should have as little friction and be
 as disruptive as possible so that contributors can get work done and
 others can be easily on-boarded.

 For GitHub Actions, the WP organization has a quota of 500 concurrent jobs
 at any given time. This is shared across ''all organization
 repositories'', not just the current one. The organization also receives a
 quota of free action minutes monthly. While public repositories do not
 consume these minutes (all public repositories are free), private
 repositories and private mirrors do. A meaningful increase in workflow
 runtime can result in a large bill.

 I just wanted to share this context because it's important to understand
 when trying to explain why these changes have been so problematic.

 > We actually raised performance issues with the Github Actions in the
 last release due to a huge amount of actions for a number of different
 environments, but that was subsequently reverted?

 The issues that were flagged during the previous release were caused
 because the volume that occurred was not handled reasonably and a large
 queue resulted due to the influx of activity. However, the solution that
 was implemented sacrificed completeness and resulted in a lower level of
 confidence in the changes due to fewer supported combinations being
 tested.

 There is ongoing work to create a new suggested list of combinations for
 `wordpress-develop` so that the volume of jobs triggered by a given commit
 or PR can be trimmed down without sacrificing completeness (there is a lot
 of overlap, but it should be done intentionally). There is also some
 exploration happening to remove the Docker requirement for running PHPUnit
 tests with the hope that the unit test suite will run faster overall,
 limiting the overall time it takes to run within each test job.

 The Build/Test Tool maintainers invest a lot of time and effort into
 ensuring these factors and outcomes are balanced fairly. However, based on
 the collective feedback on this ticket so far, all of these variables seem
 to have regressed considerably except completeness. I understand that
 there are several other issues being solved as a part of the changes here
 and I don't want to discount those. But the net cost of the solution in
 place right now is clearly negative.

 I appreciate the willingness to fix the performance issues. There seemed
 to have been good engagement with feedback immediately after [61438]. But
 over the last ~5 weeks, it has felt like the feedback given has been taken
 less and less seriously and instead just continuing to "plow ahead".

 > And If we actually merged both repositories, wouldn't the amount of
 additional code and additional tests cause an increase for the wordpress-
 develop repository?

 I think it would be the opposite. If there were a true monorepo, there
 would be one build script running, not two. This would mean that the
 overall volume of jobs would be nearly cut in half. Running unit tests,
 E2E tests, etc. would also likely take less time overall because instead
 of two separate workflows with several jobs running a build script before
 running tests, it would just be one workflow running the same set of
 combinations once.

 > Looking at the one test that went up by 100% (coding-standards.yml), why
 did the new build process affect that? Is it necessary to build Gutenberg
 to run that test?

 There are two jobs in the coding standards workflow: one that runs PHPCS,
 and one that runs JSHint. Before [61438] the build script was not
 necessary and did not run at all, only `npm ci`. However after the changes
 in [61438], the `postinstall` script runs the following:
 - Checks out the `gutenberg` repository at the specified commit hash.
 - Runs the `npm ci` command within the `gutenberg` folder.
 - Runs the entire `gutenberg` repository build script.
 - Copies the results of the build to the correct locations within
 `wordpress-develop`.

 Given the unwillingness to consider reverting so far, I've tried to think
 of some alternate ways to solve the problem outlined in the ticket
 description: making it easier to merge PHP changes from the `gutenberg`
 repository to `wordpress-develop`. It's still not 100% clear to me how
 some parts of the changes on this ticket are required to accomplish that
 goal (such as removing packages as npm dependencies), what other problems
 additional changes aim to solve, or what the actual requirements for 7.0
 are.

 I'm not comfortable with leaving the build script as is for this release.
 But I've come up with a proof of concept that I think simplifies
 everything greatly, and if others agree, it could be a reasonable
 compromise to consider.

 In my POC, I've removed the requirement to perform a `git checkout` or
 `git clone` and running the `gutenberg` build process is no longer
 necessary. The build process already runs for the Gutenberg repository
 several times within GHA workflows. In
 [https://github.com/WordPress/gutenberg/pull/75844 PR-75844] for the
 Gutenberg repository, the Build Gutenberg Plugin Zip workflow will now
 publish the built plugin to the GitHub Container registry tagged by the
 commit hash on `push` events. In [https://github.com/WordPress/wordpress-
 develop/pull/11019 PR-11019], the build scripts have been updated to pull
 down and extract this zip file before copying the files to the appropriate
 locations.

 There is one outstanding bug: the WordPress icons library files are not
 the same within the built plugin file as they were in the cloned
 repository. The mappings need to be updated for this. If I comment out the
 code responsible for copying these files, the build process is successful.

 This POC at least solves some the
 [https://docs.google.com/document/d/1spMXW3GxMtvyert4fEExEO5eBiefEmJwDyuBhhUA7TQ/edit?usp=sharing
 remaining challenges outlined in the Google Doc so far]:
 - This essentially reverses the performance problems, even on the first
 `npm install` (the 2 cURL requests does take extra time, but nowhere near
 the amount of time the current process does).
 - It avoids running a build process within a build process where one is
 obfuscated and harder to find.

 It possibly solves (testing needed):
 - The issues hosting test reporters (to be seen)
 - The issues with inconsistent hashes of generated script assets.

 It does not solve:
 - The broken contributor workflows, such as cloning the `gutenberg`
 repository to `src/wp-includes/plugins/gutenberg`.
 - Interacting with source history for many required files is still broken,
 affecting existing workflows.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:147>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform