run-tests has failed on every push and pull request since 10 June 2026. All six matrix jobs — PHP 8.3 and 8.4 across Laravel 11, 12 and 13 — fail identically, and the failure is not a failing test:
WARN No code coverage driver available
##[error]Process completed with exit code 1.
That is the entire output of the Execute tests step. No test names, no counts, no assertion failures. vendor/bin/pest --ci is exiting 1 before it runs anything. The coverage warning is a red herring — the workflow sets coverage: none deliberately, so it is expected and harmless.
When it started, and why
The first failing run is the one for 4281b73 "Add Laravel 13 support: modernise dev toolchain and CI matrix" on 10 June. The run 17 minutes earlier, on f48e382, passed. That commit widened the Pest constraint:
- "pestphp/pest": "^v3.2.2",
+ "pestphp/pest": "^3.8 || ^4.0",
CI installs dependencies with composer update --prefer-stable, so from that commit on it resolves Pest 4. The suite has never run under Pest 4 successfully.
Locally it still passes, which is why this went unnoticed:
composer.lock pins pestphp/pest v3.7.1- on 3.7.1,
vendor/bin/pest --ci — the exact CI command — runs the full suite and exits 0
So local and CI are running different major versions of the test runner, and only one of them works.
A second, related problem
The locked v3.7.1 does not satisfy the declared ^3.8 || ^4.0. The lockfile was never regenerated when the constraint changed, so composer.json and composer.lock disagree about what this package is even testable against. Whatever is decided below, the lock needs regenerating.
Why it matters
2.4.2 shipped on 7 September with no CI verification at all — the fix in #118 was verified only locally and in the consuming application. Every release since 10 June has been in the same position. A package with a red pipeline that nobody can act on is worse than one with no pipeline: the signal is there and everyone has learned to ignore it.
What to do
Two routes, and the choice is worth making deliberately:
- Make the suite Pest 4 compatible. Right if the package should support current tooling. Needs someone to run Pest 4 locally and find out what actually breaks — the silent exit is not self-explaining and may be a
phpunit.xml.dist incompatibility rather than the --ci flag.
- Pin back to
^3.8 and regenerate the lock. Gets CI green quickly and honestly, and defers Pest 4 to its own piece of work.
Either way, regenerate composer.lock so local and CI agree.
Reproducing
The failure is not reproducible on a normal checkout, because the lock protects you. To see it:
composer update --prefer-stable
vendor/bin/pest --ci
That is what CI does, and it is the shortest path to the real error message.
run-testshas failed on every push and pull request since 10 June 2026. All six matrix jobs — PHP 8.3 and 8.4 across Laravel 11, 12 and 13 — fail identically, and the failure is not a failing test:That is the entire output of the
Execute testsstep. No test names, no counts, no assertion failures.vendor/bin/pest --ciis exiting 1 before it runs anything. The coverage warning is a red herring — the workflow setscoverage: nonedeliberately, so it is expected and harmless.When it started, and why
The first failing run is the one for
4281b73"Add Laravel 13 support: modernise dev toolchain and CI matrix" on 10 June. The run 17 minutes earlier, onf48e382, passed. That commit widened the Pest constraint:CI installs dependencies with
composer update --prefer-stable, so from that commit on it resolves Pest 4. The suite has never run under Pest 4 successfully.Locally it still passes, which is why this went unnoticed:
composer.lockpinspestphp/pest v3.7.1vendor/bin/pest --ci— the exact CI command — runs the full suite and exits 0So local and CI are running different major versions of the test runner, and only one of them works.
A second, related problem
The locked
v3.7.1does not satisfy the declared^3.8 || ^4.0. The lockfile was never regenerated when the constraint changed, socomposer.jsonandcomposer.lockdisagree about what this package is even testable against. Whatever is decided below, the lock needs regenerating.Why it matters
2.4.2shipped on 7 September with no CI verification at all — the fix in #118 was verified only locally and in the consuming application. Every release since 10 June has been in the same position. A package with a red pipeline that nobody can act on is worse than one with no pipeline: the signal is there and everyone has learned to ignore it.What to do
Two routes, and the choice is worth making deliberately:
phpunit.xml.distincompatibility rather than the--ciflag.^3.8and regenerate the lock. Gets CI green quickly and honestly, and defers Pest 4 to its own piece of work.Either way, regenerate
composer.lockso local and CI agree.Reproducing
The failure is not reproducible on a normal checkout, because the lock protects you. To see it:
That is what CI does, and it is the shortest path to the real error message.