Repository navigation
Run the throwaway CI test database without durability guarantees #387
Description
The test database on CI is throwaway, yet it runs with full durability, so every table creation, import and write waits on disk syncs. On CI, the Linux SQLite jobs tend to finish faster than the MySQL jobs of the same package.
Restoring the cached install took 299 ms on a regular MariaDB and 79 ms on one without disk syncs, running from memory. A whole local cache-command run went from 126 to 114 seconds with only that change.
The change belongs in the shared workflow in wp-cli/.github (the database configuration of the functional tests), not in this package. The test results should not change, since no test relies on the database surviving a crash.
Measuring: take the baseline from #384, then open a draft PR, run the same CI jobs against it and record both results here before we decide.
Activity
schlessera commentedon Oct 30, 2026
Measurement
Measured on GitHub Actions with the full test matrix of
core-commandandcache-command, run onmeasure/*branches of wp-cli/core-command#350 and wp-cli/cache-command#137. All runs use wp-cli-tests at the same base commit (9298472) and differ only in the database durability settings of wp-cli/.github#312, used through the reusable workflow of that branch.The metric is the Behat wall time of each job, from the start of the Behat step to its last summary, for the 49 Linux jobs present in all runs. "Total" is the sum over these jobs, "per job" the median of each job's change against the mean of the two baseline runs. Both baselines run the identical code, so their spread is the noise level: about ±1% for
cache-commandand about ±5% forcore-command. All runs executed the same scenarios (about 4,518 forcore-commandand 1,162 forcache-commandacross the Linux jobs).core-commandtotalcore-commandper jobcache-commandtotalcache-commandper jobThere is no measurable gain. Unlike on a local machine, where restoring the cached installation went from 299 to 79 ms without disk syncs, the runners' disks are evidently fast enough for the syncs not to matter. I'd suggest closing wp-cli/.github#312 unless the numbers look different for other packages.