Skip to content

ci: cache PHPStan's result cache between runs#2191

Open
SanderMuller wants to merge 1 commit into
tempestphp:3.xfrom
SanderMuller:phpstan-ci-result-cache
Open

ci: cache PHPStan's result cache between runs#2191
SanderMuller wants to merge 1 commit into
tempestphp:3.xfrom
SanderMuller:phpstan-ci-result-cache

Conversation

@SanderMuller

Copy link
Copy Markdown

The PHPStan static-analysis job currently runs with a cold cache on every push and PR. It re-analyses the whole codebase each time, because PHPStan's tmpDir (.cache/phpstan) isn't persisted between runs.

This caches it with PHPStan's documented CI recipe: restore the cache before the run, and save it afterwards with if: ${{ !cancelled() }} so it's still written when PHPStan exits non-zero on findings. .cache/ is already gitignored, so nothing else changes.

Effect:

  • Incremental runs reuse the result cache and only re-analyse changed files and their dependents.
  • Even after a composer update invalidates the result cache, PHPStan keeps a separate content-hash-keyed reflection cache in the same directory, so those runs stay faster too. (Locally, a result-cache-invalidated run of packages/ still used about 18% less CPU; no-change runs become near-instant.)

Results are unchanged: PHPStan invalidates the cache per file by content hash, and wholesale on a PHP or PHPStan version change.

Ref: https://phpstan.org/user-guide/result-cache

The PHPStan static-analysis job ran with a cold cache on every push and
PR, re-analysing the whole codebase each time, because PHPStan's tmpDir
(.cache/phpstan) was not persisted between runs.

Restore the cache before the run and save it afterwards (with
`if: !cancelled()` so it is written even when PHPStan exits non-zero on
findings), following PHPStan's documented CI recipe. `.cache/` is already
gitignored.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@xHeaven

xHeaven commented Jun 25, 2026

Copy link
Copy Markdown
Member

Not sure if this is necessary, we're planning on fully moving to Mago. @brendt, what do you think?

@innocenzi

Copy link
Copy Markdown
Member

Even if we migrate to Mago soon, it's nice to have this in the meantime imo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants