Prevent Local gradle build cache collisions #2778
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
by ensuring that find_gradle_jobs and check jobs always use different cache keys
#1874 surfaced a glitch in the GitHub Actions caching of our CI jobs. This manifested as PR tests being skipped.
For background/interest:
Our belief was that this could relate to the
find_gradle_jobs
CI job - it works by disabling the gradle test executor so that it can quickly (simulating a fullcheck
) find out which gradle tasks need to be executed.We initially believed that we could be accidentally pushing the cached result of these no-op test tasks to the remote gradle cache in S3, but the configuration is solid to avoid this problem.
We subsequently realised that actually the leakage is occurring via GitHub Actions caching: the final
restore_key
for thecheck
job would match the key output during thefind_gradle_jobs
, and thus there is a possibility that the local gradle cache could be shared.Quite simply, the no-op test task was being put into the local gradle cache, and some % of the time was being used as a signal that tests were already executed.