Build/Test Tools: Check the upgraded site over HTTP.

[adimoldovan]

Trac ticket:

Upgrade Tests end at wp core version, which reads a string off the filesystem. A site that upgrades to the right version and then fatals on every page reports green.

This adds one step at the end of the job. It moves the site to port 8889, serves it with PHP's built-in server, and makes eight requests.

Request	Must contain
GET /	content="WordPress <version>", matched against wp core version, and </html>
GET /?p=1	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 /wp-login.php	id="loginform" 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>. A fatal part way down a page leaves an HTTP 200 that holds half a document, and every other marker sits near the top.

On a failure the step prints the response body and the server log. It costs about 5 seconds and uses jq, which is already on the runner image.

The JIT

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

The runner sets opcache.jit to tracing with a 256M buffer. Stock PHP ships the JIT off. opcache.enable_cli does not keep the JIT away from php -S, because opcache counts the built-in server as a web SAPI rather than as the CLI.

Measured on the runner image, one cold server per cycle, PHP 8.4 and 8.5, WordPress 7.1:

php -S	Crashes
JIT on	38 of 1600
JIT off	0 of 1600

nginx with PHP-FPM crashed the same way, 19 of 400. Every core dump put the crash inside opcache.so:

Core was generated by `php -S 127.0.0.1:8889 -t .'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f1f77346226 in ?? () from /usr/lib/php/20240924/opcache.so

The site under test still runs the configuration a WordPress host runs.

The rest of the setup

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.

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.

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 reproduce the job 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 nine 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::/?p=1 returned HTTP 404.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Drafting the workflow step and this description, and running the crash measurements quoted above. I ran the local verification described here and reviewed and edited the result.