Repairing Gutenberg GitHub Actions Workflows: Inside Operation Tall Stack

While WordPress actively supports its latest major release, security patches are regularly backported to legacy branches. All versions of WordPress starting from 4.7 onward operate in a security-only support state. Because the Gutenberg repository contains the editor software powering WordPress 5.0 and above, maintaining functional automated test suites in Gutenberg’s historical wp/X.Y release branches is essential for verifying security backports before shipping them to millions of sites.

Over time, changes in external dependencies, environment configurations, and runner images caused the continuous integration (CI) infrastructure across these legacy branches to degrade. To address this systemic rot, contributors initiated Operation Tall Stack—a structured, multi-branch remediation campaign designed to restore full CI pass rates and modernize testing pipelines across all targeted release branches.

The Critical Role of Legacy wp/X.Y Release Branches

In the Gutenberg repository, major release snapshots are stored in wp/X.Y branches (such as wp/6.1, wp/5.8, etc.). These branches mirror the code bundled into corresponding releases of wordpress-develop. When a security vulnerability affects the block editor, developers must write a fix, backport it to every vulnerable wp/X.Y branch, validate the changes via CI, and package the patch for release.

Without functional GitHub Actions workflows on these release branches, patch verification becomes a manual, error-prone endeavor. Automated checks must run predictably to confirm that security modifications do not introduce regressions into older editor versions.

Infrastructure Rot: Why Gutenberg CI Workflows Failed

Software environments evolve even when release branch code remains frozen. The failure of Gutenberg’s legacy testing infrastructure stems from several compounding maintenance gaps:

• Outdated Actions and Runners: GitHub Actions workflow files referenced deprecated runner images, unpinned third-party actions, or outdated action versions that no longer execute on modern GitHub infrastructure.
• Misconfigured Event Filters: Weakly scoped branch filters and broken event targeting caused workflow triggers to execute unnecessarily or omit execution entirely on specific pull requests.
• Tooling Breakdown: Local and remote development tools—including wp-env, Composer, and PHPUnit—broke as remote package registries, PHP versions, and upstream dependencies changed over time.
• Flaky Test Suites: Unmaintained test suites accumulated intermittent test failures caused by strict environment assumptions, broken network hooks, or unpinned dependencies.

Inside Operation Tall Stack: Standardizing Gutenberg Repairs

Operation Tall Stack addresses infrastructure breakage by standardizing repairs across more than 20 release branches (currently featuring active PRs for branches ranging from wp/7.1 down to wp/5.7). The project utilizes a systematic approach where fixes are developed, staged, and verified across each branch before submission to the main WordPress/gutenberg repository.

Key remediation goals of the operation include:

• Removing non-functional or obsolete workflow jobs that serve no purpose on a frozen release branch.
• Updating and strictly pinning GitHub Actions and runner images.
• Adding safeguard controls, such as explicit job timeouts and workflow linting.
• Pinning test execution environments to the specific PHP and Node.js versions natively supported by each corresponding WordPress release.
• Repairing wp-env, Composer, and PHPUnit integration environments.

Technical Architecture of the Stacked Pull Request Strategy

Remediating historical branches requires modifying thousands of lines of workflow logic. Rather than submitting massive, monolith diffs per branch, Operation Tall Stack organizes updates into stacked pull requests.

Each wp/X.Y branch features its own dedicated stack comprising between 18 and 32 individual pull requests. The technical structure follows strict conventions:

• One Problem per PR: Every pull request addresses a single localized issue (e.g., pinning a specific runner or fixing a Composer dependency conflict).
• Bottom-Up Dependency Stacking: Pull requests are linked sequentially. PR #2 is branched from PR #1, PR #3 from PR #2, and so on. The continuous integration suite on the uppermost PR validates the cumulative state of the entire stack.
• Uniform Branch and PR Naming: Across all branches, identical fixes use the exact same branch name convention (fix-actions-X.Y/<fix-name>) and matching PR titles. A fix occupies the same relative vertical position in every stack.
• Traceability and Backport References: Every PR description cites the specific error output or failing CI run it fixes, referencing upstream commit hashes or trunk PRs where applicable.

Strict Governance and Package Release Constraints

Because release branches represent immutable historical snapshots shipped to end-users, strict boundaries govern what changes can occur during workflow remediation:

• No npm Package Releases: Workflow repairs are strictly forbidden from publishing new package versions to the npm registry. The sole exception is wp-env, which functions strictly as an internal development environment tool rather than production code shipped to users.
• AI Generation with Mandatory Human Review: Initial PR stacks were drafted using AI tools to accelerate code generation. However, all draft PRs are marked unverified until human contributors review, test, and approve them.

Efficient Review Strategy: Matrix-Based Fix Division (GB-84853)

Reviewing nearly 500 individual pull requests across 20+ release branches top-to-bottom would create extreme context switching for contributors. To streamline the review process, the Gutenberg team established a horizontal matrix review strategy under issue GB-84853 (linked to overarching ticket GB-82780).

Instead of reviewing an entire branch stack from bottom to top, contributors claim and review a single fix row across all applicable wp/X.Y branches. Because the same problem uses identical code shapes across every branch, a reviewer can evaluate one specific fix across all versions in a single session without switching operational context.

Step-by-Step Review Protocol for Community Contributors

Contributors wishing to assist in reviewing Operation Tall Stack pull requests must follow a standardized protocol on issue GB-84853:

1. Claim a Fix Row: Comment on tracking issue GB-84853 to claim an unassigned fix identifier from the review matrix, and update the review table with your name. Claim only one fix row at a time.
2. Review the Complete Set: By claiming a row, you commit to providing an explicit review (approval or requested changes) for every PR in that specific row across all active release branches.
3. Provide Progress Updates: If a review session cannot be completed within 24 hours, post a comment detailing progress (e.g., indicating which branch versions have been approved and which remain outstanding).
4. Maintain Repository Rulesets: Anyone in the community can perform code reviews. However, merging requires at least one approving review from a member of the WordPress GitHub organization who holds write access to the repository.

Phase 2 Horizon: Adopting Reusable GitHub Actions Workflows

Restoring CI functionality across release branches represents Phase 1 of the broader maintenance roadmap. Once all stacks are approved and merged, Phase 2 will transition the Gutenberg repository to reusable workflows.

Following the structural precedent set in wordpress-develop (Trac #61213), Phase 2 will consolidate functional workflow logic into central files located on the trunk branch. Legacy release branches will simply invoke those central reusable workflows, eliminating cross-branch drift and ensuring long-term maintainability without requiring recurring stack overhauls.

Primary reference: Review the original announcement for exact release details. This article is an independent explanation and does not reproduce the source text.