Fail to setup java in PR checks due to bad checksum

[joel-costigliola]

Description:
AssertJ pull requests java cross version checks fail at the setup java stage whatever the java version was.

Task version:
actions/setup-java@v2

Platform:

• Ubuntu 20.04.4 LTS

Runner type:

• Hosted

Repro steps:
Here's one of the failing PR assertj/assertj#2543 and the links to the specific builds:

• https://github.com/assertj/assertj-core/runs/5706828170?check_suite_focus=true
• https://github.com/assertj/assertj-core/runs/5706828217?check_suite_focus=true
• https://github.com/assertj/assertj-core/runs/5706828198?check_suite_focus=true
• https://github.com/assertj/assertj-core/runs/5706828168?check_suite_focus=true

Expected behavior:
java to be properly setup as in https://github.com/assertj/assertj-core/runs/5685164626?check_suite_focus=true
(the above link is not a PR build, it's the build triggered for main branch commits)

Actual behavior:
Downloading the java azul jdk worked but the decompressing it does not, the restored data doesn't match checksum.
All the failing builds show similar errors.

Trying to resolve the latest version from remote
Resolved latest version as 17.0.2+8
Trying to download...
Downloading Java 17.0.2+8 (Zulu) from https://cdn.azul.com/zulu/bin/zulu17.32.13-ca-jdk17.0.2-linux_x64.tar.gz ...
Extracting Java archive...
/usr/bin/tar xz --warning=no-unknown-keyword -C /home/runner/work/_temp/4160a47d-370c-4f77-8610-65294de88b34 -f /home/runner/work/_temp/95a2431e-b54b-48e7-ab29-bad47a79e990
Java 17.0.2+8 was downloaded
Setting Java 17.0.2+8 as the default

Java configuration:
  Distribution: zulu
  Version: 17.0.2+8
  Path: /opt/hostedtoolcache/Java_Zulu_jdk/17.0.2-8/x64

Creating settings.xml with server-id: github
Writing to /home/runner/.m2/settings.xml
Received 255852544 of 264648343 (96.7%), 243.8 MBs/sec
Received 264648343 of 264648343 (100.0%), 204.7 MBs/sec
Cache Size: ~252 MB (264648343 B)
/usr/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/c197f31d-a0c2-4fe2-b324-ae73abf4d33a/cache.tzst -P -C /home/runner/work/assertj-core/assertj-core
/*stdin*\ : Decoding error (36) : Restored data doesn't match checksum 
/usr/bin/tar: Child returned status 1
/usr/bin/tar: Error is not recoverable: exiting now
Error: Tar failed with error: The process '/usr/bin/tar' failed with exit code 2

[joel-costigliola]

The main branch build fails with the same error now: https://github.com/assertj/assertj-core/runs/5707355339?check_suite_focus=true

[scordio]

It seems that the cache entry got corrupted and there is no way to clean that entry manually (actions/cache#2). There might be two possible workarounds:

• Use a different cache key, but actions/setup-java doesn't expose this option so adding back actions/cache configurations would be required.
• Disable caching for at least 7 days so that the cache entry gets evicted automatically (eviction policy).

[marko-zivic-93]

Hello @joel-costigliola
Thank you for your report!
We will investigate this issue and come back to you with updates as soon as possible!

[blommish]

Any progress? We'r seeing the same issues

[scordio]

For the time being, we went with:

Disable caching for at least 7 days so that the cache entry gets evicted automatically (eviction policy).

and a few more days are needed to see if this is actually solving the issue.

[joschi]

Same issue here: https://github.com/dropwizard/dropwizard/runs/5783823439?check_suite_focus=true

[dmitry-shibanov]

Hello everyone. The toolkit/cache and actions/setup-java were updated to resolve some issues related to cache availability. Could you please try to enable cache and confirm that everything works as expected.

[dmitry-shibanov]

Hello everyone. For now I'm going to close the issue. If you have any concerns feel free to ping us.