CI: Skip mobile unit tests

[tyxla]

What?

Skipping the mobile unit tests.

Part of #71336.

Why?

As we're moving forward with the React 19 upgrade, they will inevitably break, so we're disabling them for the time being.

See #71336 for more info.

How?

Just skipping them.

Testing Instructions

• Make sure the mobile unit tests don't run
• Make sure the rest of the unit tests keep running.

Testing Instructions for Keyboard

None

Screenshots or screencast

None

[Mamaduka]

Should we add a comment explaining why this is disabled, probably linking to #71336?

[tyxla]

Good call - added in cb86ff8

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: desrosj <desrosj@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

Let's ship it

[github-actions]

Flaky tests detected in cb86ff8.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17212441341
📝 Reported issues:

• [Flaky Test] Redirection after template creation #60678 in /test/e2e/specs/site-editor/site-editor-url-navigation.spec.js
• [Flaky Test] ensures List View global shortcut works properly #51533 in /test/e2e/specs/editor/various/list-view.spec.js

[desrosj]

Wanted to play deveil's advocate here.

• Do we know that tests will actually break?
• If so, how badly?
• What is the level of effort to fix them at the same time as upgrading?

My strong preference is to update all tests at the same time as upgrading so that the tests never fail or need to be disabled. Any gap between disabling tests and re-enabling them comes with a level of risk that we need to weigh.

[Mamaduka]

@desrosj, I think that's the known issue from the previous attempt - #61521.

As far as I know, the Gutenberg Mobile project is on hold for now, and not many of us have enough experience with its architecture or React Native to handle the required upgrades. cc @dcalhoun @oguzkocer

[tyxla]

@desrosj yep, as @Mamaduka mentioned, the Gutenberg Mobile project is not getting any attention at this time, and I've confirmed with the team that they're not planning to work on it actively. This also means that there won't be much capacity to work on this non-trivial React-19-compatible RN upgrade, which is a blocker to making these tests and Gutenberg Mobile work.

I had some conversations with the team, and we agreed this is the best path forward for the web project. This also means that if there are any follow-up fixes or patches on the RN packages necessary, they will be done in the relevant branches and not in trunk.

@desrosj just to be sure that I've answered your questions:

Do we know that tests will actually break?

Yes, we've confirmed with upgrading to React 19, and making React 19 work with RN requires a non-trivial upgrade.

If so, how badly?

Quite broken as per #61521.

What is the level of effort to fix them at the same time as upgrading?

Fixing them means upgrading RN to a compatible version (v0.78 or newer), which I confirmed with the mobile team is a non-trivial upgrade and requires a lot of work that can't be prioritized at this time.

[dcalhoun]

I affirm what @Mamaduka and @tyxla shared. Upgrading React Native to fix the test failures is not a feasible option for the mobile team at this time.

I feel @tyxla's summary in #71336 accurately describes the context and rationale for this action:

While breaking Gutenberg Mobile on trunk doesn't seem to be an ideal next step, it's a necessary one. The WP Mobile project is actively exploring paths forward for the block editor in the mobile apps, aiming to reduce complexity and improve alignment with the Gutenberg web project. There is currently little to no active work on the Gutenberg Mobile project. Therefore, to avoid encumbering the web project and its surrounding community, we must upgrade React and accept that doing so introduces technical debt for Gutenberg Mobile; technical debt that will need to be paid in the future in one form or another.

[desrosj]

Thanks for clarifying!