Running WP-CLI in CI: what the checks actually look like

This is the last part. You have learned the commands, written scripts, made them idempotent, promoted one to a real command and given cron a clock. What remains is making all of it run without anyone having to remember.

Cheap checks first

The first rule of pipeline design is to put fast, cheap checks at the front. Booting WordPress is slow, so anything catchable before that step should be caught before that step.

The self-contained script from part four earns its keep here. A check written in plain PHP that includes no WordPress files needs neither a database nor an install and finishes in seconds, so it filters out most rule violations in the very first stage.

A disposable WordPress

The next stage stands up a real install. Building it fresh every run is the point — with no leftover state, you can believe the results.

wp core download --path=wp
wp config create --path=wp --dbname=ci --dbuser=ci --dbpass=ci --dbhost=127.0.0.1
wp core install --path=wp --url=http://localhost --title=CI --admin_user=ci --admin_email=ci@example.test --skip-email
wp theme activate acme-child --path=wp
wp plugin activate acme-core --path=wp

Do not forget --skip-email, or the install genuinely tries to send a notification. And this stage never points at a production database — credentials belong in the pipeline’s secret store, not the repository.

The checks worth running

Here is where the series pays out: the things built in earlier parts become the checks themselves.

wp plugin list --status=active --field=name --path=wp
wp option get blog_public --path=wp
wp core verify-checksums --path=wp
wp plugin verify-checksums --all --path=wp
wp eval-file bin/lint-content.php --path=wp
wp acme checklist run --format=json --path=wp

verify-checksums is unusually valuable. It compares core and plugin files against the published releases, which reveals where somebody edited files directly on the server. That saves you the update where those edits vanish and nobody can work out why.

Keeping a wp db export as a build artefact means a failed run can be downloaded and opened locally exactly as it was.

The exit code is the contract

A pipeline does not read your log. It reads the exit code. Which is why the distinction from part six matters here — a command ending in WP_CLI::error() exits 1 and fails the build, while a warning is recorded and passes.

In other words, deciding what deserves an error when you wrote the command was really deciding what blocks a deploy. Postpone that decision and you end up with a pipeline that goes red often and that nobody looks at.

When a single plugin fatals during boot, --skip-plugins --skip-themes gets the remaining checks running — but record the fact as a failure. The workaround exists for diagnosis, not for passing.

Closing the series

Across eight parts we moved clicks to commands, commands to scripts, a script to a proper command, and finally all of it to a pipeline. One principle ran through it: anything verified once should never depend on a person remembering it again.

WordPress is a good tool for this kind of work. It ships an official CLI, its data model is open, and hooks let you attach almost anywhere. Where things go wrong, it is rarely the tool that is missing — it is the procedure.

If you would rather have this put in place on a running site in one go, our optimization program handles upgrades, performance and security review as a single job, and the order we actually work in is published step by step on the process page. The background reading for this whole series is collected in the development workflow archive.