Skip to content
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

Java toolchain cache entries are not differentiated by architecture #138

Closed
hfhbd opened this issue Apr 9, 2024 · 3 comments · Fixed by #305
Closed

Java toolchain cache entries are not differentiated by architecture #138

hfhbd opened this issue Apr 9, 2024 · 3 comments · Fixed by #305
Assignees
Labels
bug Something isn't working
Milestone

Comments

@hfhbd
Copy link
Contributor

hfhbd commented Apr 9, 2024

If you use a matrix with different RUNNER_ARCHs, like macos-latest (x64) and macos-14 (M1), the jdk cache is restored but it is specific to the arch causing a cache miss.

@bigdaz
Copy link
Member

bigdaz commented Apr 9, 2024

I think you're saying that the same 'java-toolchains' cache entry published from macos-latest will be restored on a later job running on macos-14. But this restored toolchain is specific to the x64 architecture and thus cannot be used on macos-14.

This would run a bit counter to the "cache entries are specific to operating system" rule that we observe with the GitHub Actions cache (#27).

Can you please confirm/clarify?

@hfhbd
Copy link
Contributor Author

hfhbd commented Apr 9, 2024

I think you're saying that the same 'java-toolchains' cache entry published from macos-latest will be restored on a later job running on macos-14. But this restored toolchain is specific to the x64 architecture and thus cannot be used on macos-14.

Yes, exactly.

I will test it, but according to the docs, enableCrossOsArchive is only about Windows:

enableCrossOsArchive - An optional boolean when enabled, allows Windows runners to save or restore caches that can be restored or saved respectively on other platforms.

I also don't know, if action/cache uses RUNNER_ARCH at all, because macos-14 is the first public runner using arm, beside the private Linux/Windows beta.

@bigdaz
Copy link
Member

bigdaz commented Apr 10, 2024

OK thanks for clarifying.
If you're interested in submitting a PR, then I in the end we'll need to have this context when generating the cache key here: https://github.com/gradle/actions/blob/main/sources/src/caching/gradle-home-extry-extractor.ts#L225-L227

A simple approach might be to simply append the RUNNER_ARCH value to the 'artifactType' for this entry: so you'd have artifactType == 'java-toolchains-x86'.

@bigdaz bigdaz changed the title Add RUNNER_ARCH to JDKs cache key Java toolchain cache entries are not differentiated by architecture Apr 10, 2024
@bigdaz bigdaz added the bug Something isn't working label Apr 10, 2024
@bigdaz bigdaz self-assigned this Jul 19, 2024
bigdaz added a commit that referenced this issue Jul 20, 2024
Previously, including RUNNER_OS was enough to prevent leaking incompatible
content between Gradle User Homes. With the introduction of macos-14,
we now need to differentiate between different runner architectures as well.

Fixes #138
@bigdaz bigdaz closed this as completed in e6688f3 Jul 20, 2024
@bigdaz bigdaz added this to the v4.0.0 milestone Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants