Run lint, PHPUnit, and QUnit in GitHub Actions

[lancewillett]

Summary

Automattic/o2 had no working CI. Its only config was a .travis.yml last touched in 2020, and Travis stopped running it long ago, so every recent pull request reported zero status checks. The regression tests added with #249, #250, #251, and #252 never ran automatically.

This adds a GitHub Actions workflow with three jobs on pull requests and pushes to master:

• lint: grunt travis:lint (PHP syntax check + JSHint), unchanged from the Travis wiring.
• phpunit: MySQL service, bin/install-wp-tests.sh, grunt travis:phpunit. The WordPress test library now requires the Yoast PHPUnit Polyfills, so a composer.json with PHPUnit and the polyfills as dev deps is the minimum that lets the existing suite boot. The Grunt task now calls vendor/bin/phpunit.
• qunit: new grunt qunit task via grunt-contrib-qunit, run inside an unpacked WordPress tree so the existing tests/qunit/index.html can keep loading jQuery and Underscore from wp-includes as it does today. The page's QUnit CDN pin moves from 2.0.1 to 2.26.0, the oldest the headless runner supports; opening the page manually in a browser still works.

Also: the npm test script points at the real tasks, .travis.yml is removed, and the README badge points at the Actions workflow.

Verification

Locally, on this branch:

• grunt travis:lint: 80 files lint free.
• grunt travis:phpunit against MySQL 8 and WordPress 7.1: 82 tests, 143 assertions, OK.
• grunt qunit inside a WordPress tree: 5 tests, 0 failed.
• Revert check: undoing only the inc/tags.php change from Preserve encoded text when linking hashtags #249 makes TagsTest::test_tag_links_keeps_encoded_html_as_text fail. Undoing only the js/editor/editor.js change from Keep editor content inside the textarea #252 makes the QUnit editor test fail. Restoring each fix turns the suite green again.

Out of scope on purpose: PHP/WordPress version matrix, phpcs, coverage. Single PHP 8.3 job set only.

🤖 Generated with Claude Code

[lancewillett]

b0a48b1: the first run failed only in the phpunit job because ubuntu-latest no longer ships Subversion, which bin/install-wp-tests.sh uses to fetch the WordPress test library. Added an apt install step for it before the script runs. Lint and QUnit passed on the first run.

[lancewillett]

bcf16e8: questioned whether Subversion is really needed. It is not. bin/install-wp-tests.sh now takes tests/phpunit/includes from a sparse, blobless clone of the wordpress-develop git mirror (about 3 seconds and 2 MB; the files are byte-identical to the svn checkout). The apt step from b0a48b1 is gone, along with the redundant mysqli extension line in setup-php and the composer.json description. Verified locally: 82 PHPUnit tests pass against the git-fetched library.

[lancewillett]

848a336: changes from a review pass (Codex adversarial, core review, simplifier, supply-chain lenses).

• Workflow token is now contents: read.
• bin/install-wp-tests.sh no longer downloads db.php from a personal repo's master branch and loads it as a WordPress drop-in. WordPress has used mysqli natively for years; the suite passes without it.
• The phpunit job calls vendor/bin/phpunit directly. It no longer installs Node or downloads puppeteer's Chrome just to run a Grunt passthrough.
• phplint excludes vendor and node_modules. With composer installed it was scanning 1027 third-party PHP files alongside o2's 51.
• HACKING.txt gets a short Testing section covering composer install, the install script, and how to run each suite.