New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Result cache not used because the metadata do not match" reported on every CI build. #4542
Comments
This bug report is missing a link to reproduction on phpstan.org. It will most likely be closed after manual review. |
To add to this, the referenced change was released in 0.12.72 and downgrading to 0.12.71 fixes the issue as expected. |
Fixed, thank you! phpstan/phpstan-src@6367eb6 |
Thank you, @ondrejmirtes. I should have mentioned that the SHA-1 hash is also stored at |
Fixed in master, thanks. |
I confirmed that updating to master solved this issue for us. Thank you! |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Bug report
phpstan/phpstan-src@f11c0f0 (originally discussed on #4495 (comment)) means that changes to
/vendor/composer/installed.php
can now invalidate the result cache.Running
composer install
after HEAD has changed causes this file to be regenerated even whencomposer.lock
has not changed because HEAD's SHA-1 hash is written to/vendor/composer/installed.php
:This is particularly evident in a CI build process where
composer.install
is being run every time. In practice, we are seeing every build report "Result cache not used because the metadata do not match" even though our Composer dependencies (composer.lock
) are not changing. Is there a workaround for this issue? Or an alternate solution to solve the original issue that doesn't so aggressively invalidate the cache?Thank you in advance, and thank you for creating this wonderful tool!
The text was updated successfully, but these errors were encountered: