You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
ferki
added
triage needed
A potential bug that needs to be reproduced and understood
bug
Confirmed bugs
and removed
triage needed
A potential bug that needs to be reproduced and understood
labels
Oct 30, 2021
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:
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 logThe text was updated successfully, but these errors were encountered: