Describe the bug
558aa9a introduced a CACHE_VERSION variable to the CI cache key, so the cache could be invalidated by changing the value of that variable (=without committing to the codebase). This variable is defined as a repository secret, which is not available for pull requests from forks.
This causes using a brand new cache for PR from forks, which also means e.g. empty list of known perlcritic violations, leading to accepting the new state whatever it is (via Test::Perl::Critic::Progressive thinking it is its first run).
How to reproduce it
Steps to reproduce the behavior:
- Fork the repo
- Send a pull request
- Check the cache key value in the build log
Shortest code example that demonstrates the bug:
Expected behavior
Pull requests from forks should use the same caches as internal pull requests (and should be tested the same way too).
Circumstances
Debug log
Describe the bug
558aa9a introduced a
CACHE_VERSIONvariable to the CI cache key, so the cache could be invalidated by changing the value of that variable (=without committing to the codebase). This variable is defined as a repository secret, which is not available for pull requests from forks.This causes using a brand new cache for PR from forks, which also means e.g. empty list of known perlcritic violations, leading to accepting the new state whatever it is (via Test::Perl::Critic::Progressive thinking it is its first run).
How to reproduce it
Steps to reproduce the behavior:
Shortest code example that demonstrates the bug:Expected behavior
Pull requests from forks should use the same caches as internal pull requests (and should be tested the same way too).
CircumstancesDebug log