Build/Test Tools: Smoke test the upgraded site over HTTP

[adimoldovan]

Trac ticket: https://core.trac.wordpress.org/ticket/66036

Add a light smoke test after the upgrade via cli completed.

Upgrade Tests currently stop at wp core version, which reads a string off the filesystem then report success.

This PR adds one step at the end of the job that moves the site to port 8889, serves it with PHP's built-in server, and makes a few curl requests to validate the site works.

Request	Must contain
GET /	content="WordPress <version>", matched against wp core version, Hello world!, and </html>
GET /?rest_route=/	a whole JSON body whose name is Upgrade Test
GET /wp-admin/upgrade.php	No Update Required and </html>
GET /?p=99999999	HTTP 404
POST /wp-login.php	wordpress_logged_in_ in the cookie jar
GET /wp-admin/	id="wpadminbar" and </html>

The step then fails if PHP wrote a fatal error to the server log. That catches a fatal during shutdown, which leaves every response whole.

Each check asserts a marker that a working install must produce, and also </html>.

On a failure the step prints the response body and the server log.

The server starts with -d opcache.jit=disable. Without that it crashes.

The step skips multisite. A network keeps its domain in wp-config.php and in the site and blogs tables, and WordPress strips only :80 and :443 from the host before it matches a network, so a move to another port needs more than an option update.

It sets DISABLE_WP_CRON and WP_HTTP_BLOCK_EXTERNAL. A cron spawn is a request no check asked for, and the update checks on /wp-admin/ leave the runner for api.wordpress.org. WP_Http::block_request() exempts the site's own host, so the site can still talk to itself.

Why not the existing Playwright tests

They need Node, npm ci, a browser download, npm run build, and a Docker environment. This job has none of those. Their global setup also switches the theme to Twenty Twenty-One and deletes every post, so it would wipe the upgraded site before it tested it.

Effect on other branches

Branches 6.6 to 7.1 call reusable-upgrade-testing.yml@trunk, so this step runs on their upgrade jobs too. Branches 6.4 and 6.5 call the older upgrade-testing-run.yml and do not change. upgrade-develop-testing.yml calls this workflow too, and runs on any change to src/**.php.

All the markers exist in the source of every branch from 6.6 to trunk, and every caller runs Ubuntu.

Follow-up

A follow-up should add the same check to install-testing.yml, and moves this block into a composite action that both workflows can call.

Testing Instructions

The workflow runs on any pull request that touches upgrade-testing.yml or reusable-upgrade-testing.yml, so this one exercises it.

To run locally:

1. Start a database:

   docker run -d --name wp-smoke-db -e MYSQL_ROOT_PASSWORD=root \
     -e MYSQL_DATABASE=test_db -p 13306:3306 mysql:8.4
   

2. In an empty directory, install an older version and upgrade it:

   wp core download --version=7.0
   wp config create --dbname=test_db --dbuser=root --dbpass=root --dbhost=127.0.0.1:13306
   wp core install --url=http://localhost/ --title="Upgrade Test" --admin_user=admin \
     --admin_password=password --admin_email=me@example.org --skip-email
   wp core update --minor && wp core update-db
   wp core update && wp core update-db
   

3. Copy the run: block of the new "Post-upgrade smoke check" step into smoke.sh and run it with
   RUNNER_TEMP=/tmp SITE_PORT=8889 WP_ADMIN_USER=admin WP_ADMIN_PASSWORD=password bash -e smoke.sh.
   It prints seven ok lines and exits 0.

4. Confirm it catches a broken site. Each case below is one file in wp-content/mu-plugins/.
   Write it, run the script again, then delete it. The WP_CLI guard keeps WP-CLI working, so the
   break reaches the step over HTTP rather than stopping the first wp command.

   File content	Expected failure
   <?php if ( ! defined( "WP_CLI" ) ) { boom_undefined(); }	::error::/ returned HTTP 500
   <?php add_action( "wp_footer", function () { boom_undefined(); } );	::error::/ did not contain: </html>
   <?php if ( ! defined( "WP_CLI" ) ) { register_shutdown_function( function () { boom_undefined(); } ); }	::error::the server logged a fatal error
   <?php add_filter( "template_redirect", function () { if ( is_404() ) { status_header( 200 ); } }, 1 );	::error::a missing post returned 200, expected 404

   The third case leaves every response whole and is caught only by the log check.

5. Confirm it catches missing content: wp post delete 1 --force, then run the script again. It
   fails with ::error::/ did not contain: Hello world!.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Drafting the workflow step and tracing the opcache.jit crash mentioned above. I ran the local verification described here and reviewed the result.

[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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props adrianmoldovanwp, lancewillett.

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

[lancewillett]

The upgrade workflow smoke check landed in https://core.trac.wordpress.org/changeset/63447. The install workflow follow-up remains as next step.

A follow-up should add the same check to install-testing.yml, and moves this block into a composite action that both workflows can call.

@adimoldovan Do you already have a PR for that?

[lucatume]

The code looks correct and I've left a comment that is not a blocker.

Leaving a note here to pick your brain: this script is 100+ lines of bash code to be read inline into a script that is not syntax highlighted. Moving this to a dedicated .sh script used by the workflow would (pro) make it read like a bash file (and allow to add self-tests) but (con) require the actions/checkout step to pull it in (likely from trunk).

[lucatume]

The option to show posts on front is implied and currently correct and aligned with defaults. What would make this deterministic is to set it explicitly with wp option update show_on_front posts in the script setup phase.

[adimoldovan]

Will also address this in the follow-up PR.

[adimoldovan]

The code looks correct and I've left a comment that is not a blocker.

Leaving a note here to pick your brain: this script is 100+ lines of bash code to be read inline into a script that is not syntax highlighted. Moving this to a dedicated .sh script used by the workflow would (pro) make it read like a bash file (and allow to add self-tests) but (con) require the actions/checkout step to pull it in (likely from trunk).

Valid concern, and my plan was to do that in the follow-up that adds this same check in the install workflow.