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

[WordPress Trac]

#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):

 Replying to [comment:134 ellatrix]:
 > > It's very difficult to follow through the process to figure out where
 the issue actually is, what changes have been made to related code, etc. I
 recognize some of this is due to my own personal habits, but this is how I
 have been investigating.
 >
 > Wasn't this the same previously for all GB related code? We'd have to
 search both repos?

 The build processes were separate in the past and it was much more clear
 which one encountered a specific problem. Now the one in wordpress-develop
 calls the one from the Gutenberg repository and it can be difficult to
 track down where error messages originate from.

 I'm going to concede this point because there are other issues that are
 more concerning so far.

 > > The distributed hosting tests are still broken for many of the hosts
 participating.
 >
 > Could you link to these? It's hard to understand what's happening
 without specifics.

 The [https://make.wordpress.org/hosting/test-results/ distributed host
 tests are found here]. It's hard to know why a number of hosts stopped
 reporting without performing direct outreach because error logs don't
 send, only the PHPUnit output for completed runs. But at one point the
 WP.org GitHub Actions runner was the only one reporting for a number of
 commits and there is a clear drop off immediately after [61438].

 Looking at [61418] (which I chose because there was a 12-24 hour gap
 between this one and [61419] and some bots run daily or once every several
 hours), only 5 of the 14 hosts that reported for that changeset have
 reported results for any of the 25 most recent commits. Looking at the
 changesets following [61438], there were many where only the w.org GH bot
 reported. While some have recovered, it's concerning that many of the bots
 reporting prior to the build scripts changes have not.

 > > There are reports of GitHub Actions workflows failing within private
 forks.
 >
 > Could you also link to these reports to understand the issues?

 I cannot share links publicly because of their private nature. But the
 specific errors that I am aware of seem to have been resolved after
 [61673]. Will continue monitoring this.

 > > GitHub Action workflows that run the build script were taking 30-40%
 longer after the changes here.
 >
 > Is that fixed since [61673]?

 There is not enough data to know for sure yet. But I went back and looked
 at the data for two time periods and compared each workflow:
 - December 1, 2025 through January 4, 2026
 - January 6, 2026 through February 15, 2026

 The GitHub Actions performance metrics page presents an average run time
 metric, number of workflow runs, and a percentage of failures. I only
 looked at the average run time for this and only for workflows that run
 `npm install` or `npm ci`. By comparison, here is the percentage change in
 average run time:
 - `coding-standards.yml`: +99.42%
 - `end-to-end-tests.yml`: +16.18%
 - `javascript-tests.yml`: +2.53% (negligible)
 - `local-docker-environment.yml`: +55.33%
 - `performance.yml`: +5.35%
 - `phpunit-tests.yml`: +17.32%
 - `test-build-processes.yml`: -41.14% (I am uncertain why this decreased
 so drastically)
 - `test-coverage.yml`: +4.6%
 - `upgrade-develop-testing.yml`: +8.86%

 I have the
 [https://docs.google.com/spreadsheets/d/1W21a72P88TCPxpXOzhP_RBjGH5ui8FZMZJNMlMqCtMw/edit?usp=sharing
 data in a spreadsheet for viewing]. These metrics are not 100% because I
 believe the average run time includes runs that fail early.

 I'm [https://github.com/WordPress/wordpress-develop/pull/10971 looking
 into caching] the `gutenberg` directory in GHA workflows, but I'm not
 seeing any meaningful change in the overall runtime so far.

 > > Consistent tooling and standards
 > > Better visibility
 >
 > What's different here from before? We didn't have these benefits of a
 monorepo before either? A huge amount of files were not version
 controlled. There's only a tiny fraction of files that have changed to be
 no longer version controlled in core.

 The version history has now ended for the files added to `.gitignore`
 where previously you could track every single change made to block files
 (one example) made in the context of one repository (`wordpress-develop`
 or `gutenberg`). Now the only way to track the progression of a file's
 history is to find when the `refs` changed and then compare the files in
 question in the `gutenberg` repository.

 I've noticed a new issue over the last 24 hours and I don't have an
 explanation for it. I was looking at updating developer dependencies for
 the release as part of #64230. The typical process I follow is to:
 - Apply the available updates that look safe and reasonable according to
 the changelogs/release notes.
 - Push a PR to run the automated testing.
 - If that passes, compare the contents of the `build` directory locally
 after running `npm build` with that of the `master` branch of
 core.svn.wordpress.org ([https://github.com/wordPress/wordpress mirrored
 to GitHub as WordPress/WordPress])
 - There should be no unexpected changes found in the comparison.

 However, I'm finding that even when no changes are made to the actual
 files, I'm seeing the file hashes changing and most of the related build
 files are changing as a result. I've been unable to figure out what is
 causing those changes, or why the build server is not doing the same with
 every commit.

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