Suggested cache key for psalm in github actions

[ro0NL]

Hi,

Is there a suggested cache(-key) strategy for running psalm in github actions?

I'm currently including ${{ hashFiles('composer.lock', 'psalm-baseline.xml') }} in my key, without restoring any other keys.

Should i include psalm.xml as well for proper cache invalidation?

Note, after psalm runs, i always save the cache (thus regardless of exit code), to be restored upon next commit.

The issue is, sometimes we still see outdated psalm issues :(

[tayfuryldz]

You don't need to put psalm.xml into the GitHub Actions cache key for Psalm to invalidate entries when the config changes.

Psalm's current cache implementation already hashes the loaded config contents (plus the Psalm version and error level) into the cache subdirectory. The cache providers then add other dependencies such as composer.lock to their own cache hash. In other words, restoring the same outer .psalm/cache directory after a config change does not make Psalm blindly reuse entries generated for a different config hash.

For Actions I would therefore key the persisted cache around things that determine whether restoring the directory is useful, rather than trying to duplicate every one of Psalm's internal invalidation inputs. Including the OS/PHP/Psalm dependency state (often naturally represented by composer.lock) is sensible. Including psalm.xml is harmless but should not be required for correctness on current Psalm.

One thing I would not include in the cache key is psalm-baseline.xml merely to avoid stale diagnostics: the baseline controls reporting/suppression, while Psalm's internal config/cache machinery is responsible for analysis cache validity. Changing the outer Actions key every time the baseline changes mostly reduces cache reuse.

If you still get an actually stale diagnostic on current Psalm after restoring the cache, vendor/bin/psalm --clear-cache is a useful A/B test. If clearing fixes it, that is worth reducing to a Psalm cache invalidation bug, because changing psalm.xml itself should already select a different internal cache hash.