TIA not recommended for CI?

[DKhalil]

In the docs it's clearly stated that the new TIA plugin isn't recommended for use in a CI. Why? What are the downsides here? In my mind having a test run on a CI being reduced from ~10 minutes to ~1 minute would be a huge gain.

[ibamzjr]

The warning is about using TIA as the only required CI gate, rather than about TIA being unable to run in CI.

A fresh CI worker normally has no baseline dependency graph. The first TIA run must build that graph with a coverage driver, so it does not provide the same 10 min -> 1 min benefit that you see after a local baseline already exists. More importantly, a merge gate should prove that the complete suite passes from a clean checkout instead of making its result depend on a cached graph.

A practical split is:

# Required pull-request job
./vendor/bin/pest --ci

Run that complete job in parallel or shard it if runtime is the problem. Then use a separate job on the default branch (or a scheduled job) to refresh the TIA baseline:

./vendor/bin/pest --tia --coverage --fresh

Publish that baseline as an artifact for developers, and configure local Pest with pest()->tia()->locally()->baselined() if that matches the team's workflow.

That preserves the fast feedback loop locally while keeping the required CI result deterministic. Pest's TIA documentation describes this same CI/local distinction and baseline workflow: https://github.com/pestphp/docs/blob/5.x/tia.md