Psalm reports errors on GitHub Actions but not locally

[sebastianbergmann]

Not sure whether this is a bug in Psalm but I am observing this weird behaviour right now:

When I run Psalm on https://github.com/sebastianbergmann/comparator locally then I get:

$ ./tools/psalm --config=.psalm/config.xml
Scanning files...
Analyzing files...

░░░░░░░░░░░░░░░░░

------------------------------
No errors found!
------------------------------
45 other issues found.
You can display them with --show-info=true
------------------------------
Psalm can automatically fix 16 of these issues.
Run Psalm again with 
--alter --issues=MissingReturnType,MissingParamType --dry-run
to see what it can fix.
------------------------------

Checks took 0.64 seconds and used 50.479MB of memory
Psalm was able to infer types for 90.9707% of the codebase

When the same version of Psalm (with the same configuration and baseline) is run on the same code on GitHub Actions then I get:

.
.
.
------------------------------
24 errors found
------------------------------
33 other issues found.
You can display them with --show-info=true

See https://github.com/sebastianbergmann/comparator/runs/1335576035?check_suite_focus=true for details.

This started happening after the update to Psalm 4.1.0 and only seems to affect PropertyNotSetInConstructor issues that are ignored by the baseline.

[psalm-github-bot]

Hey @sebastianbergmann, can you reproduce the issue on https://psalm.dev ?

[davidbyoung]

I also have this issue. FWIW if you switch your required version to dev-master, you'll get the latest commit, which appears to work correctly. Pulling in ^4.1@dev pulls in this commit, which seems to be broken.

[sebastianbergmann]

That does not explain the difference in behaviour locally vs. GitHub Actions I described.

[davidbyoung]

psalm.dev is using dev-master (latest commit) whereas the latest 4.1 release isn't the latest commit. Do you know which version/commit you're using in GitHub Actions?

[muglug]

@davidbyoung I think you're chasing up the wrong tree, something is definitely a little broken but I'm not sure where.

[muglug]

OH @sebastianbergmann I think I know what's happening. Psalm uses the composer lockfile to figure out whether its version has changed, and then to bust cache, but you're short-circuiting that by using the Phar.