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
Run actions/setup-java@v1/bin/tar xzC /home/runner/work/_temp/temp_1966052730 -f /home/runner/work/_temp/7c187b07-8201-4bf2-b87d-247013d1c81dgzip: stdin: not in gzip format/bin/tar: Child returned status 1/bin/tar: Error is not recoverable: exiting now##[error]The process '/bin/tar' failed with exit code 2##[error]Node run failed with exit code 1
After doing some googling, this looks to be the most relatable problem, but I notice it's not being downloaded the Oracle site, rather from this site so I don't think cookies are the issue. Has anyone else also encountered this error?
~ ##[group]Run actions/setup-java@v1
~ with:
~ java-version: 1.8
~ architecture: x64
~ ##[endgroup]
~ [command]/bin/tar xzC /home/runner/work/_temp/temp_1728142126 -f /home/runner/work/_temp/2cb0bc34-a362-42f1-9238-54ed8d5abeb1
~
~ gzip: stdin: not in gzip format
~ /bin/tar: Child returned status 1
~ /bin/tar: Error is not recoverable: exiting now
~ ##[error]The process '/bin/tar' failed with exit code 2
~ ##[error]Node run failed with exit code 1
Looks like some added .sig files (.tar.gz.sig) on the CDN were being confused for the .tar.gz files by installer.ts. The .sig files have been removed from the CDN for now, but are the tool-cache seems to have cached them.
Reacted by Matthew Buckett, Alex Scott, Paul Merlin, Christian Zöller, Daniel Walsh, sensuikan1973 and Sergei Grinev
Looks like the caches for the .sig stuff have now expired and things work again for all versions (6,7,8,9,10,11,12,13). Will work on an installer.ts change and pull request to make sure .tar.gz is expected at end of filename (to ignore .tar.gz.sig) before we re-enable .sig files on the CDN.
In case somebody is looking for a GitHub Action for setting up a Java development environment based on the AdoptOpenJDK OpenJDK distribution: joschi/setup-jdk
Yes, I just had it this very minute, I was setting up Actions to allow for dependabot to work better, but it failed hard and I cant test my actions anymore.
Run actions/setup-java@v1
/bin/tar xzC /home/runner/work/_temp/temp_789591268 -f /home/runner/work/_temp/8bfc74d5-fdd6-4f22-9a32-228ac7a8aa77
gzip: stdin: not in gzip format
/bin/tar: Child returned status 1
/bin/tar: Error is not recoverable: exiting now
##[error]The process '/bin/tar' failed with exit code 2
##[error]Node run failed with exit code 1
This affected things that picked up "latest" (e.g. 8, 8.0.x, but not e.g. 8.0.222). Unfortunately, the new October 15 update releases posted earlier today for 7, 8, 11, and 13 all came with matching .sig files. The new .sig files are now removed to prevent the problem with setup-java. Integrating the the PR (#24) will help avoid this sensitivity to non-jdk contents being posted to the cdn..
@joschi there are quite a few OpenJDK distributions one can pick from, of which Zulu is one. There is plenty of choice, include the likes of Amazon’s Corretto, Bellsoft’s Liberica, Alibaba’s Dragonwell, and IBM’s AdoptOpenJDK. Of the set, Zulu happens to be the community OpenJDK distribution with the longest track record of delivering free, 100% OSS and consistently updated builds for OpenJDK 6,7,8,9,10,11,12, and 13, spanning back quite a few years. Older versions (like 7u181 or 8u131) may not seem “sexy”, but since CI and testing configs often freeze specific JDK versions to test against (usually in addition to testing on latest/greatest), a track record for prompt availability of new versions coupled with well maintained, long term stable archives of all builds across a wide version and date range is one of the key things driving the choice of OpenJDK distribution CI systems default to.
@giltene I don't want to start a big discussion here. I like Zulu and it served me well over the years, but people might want to use the AdoptOpenJDK distribution (not related to IBM), which is a bit clumsy to use with this GitHub Action.
Activity
bijancn commentedon Sep 29, 2019
I also see this issue. Here for example https://github.com/starship/starship/pull/383/checks?check_run_id=240449201
pzygielo commentedon Sep 29, 2019
Experiencing the same for
java-version: 1.8as well.larryxiao625 commentedon Sep 29, 2019
I have got this error too in Java-version:1.8
zhzy0077 commentedon Sep 29, 2019
Having the same problem. It was fine several hours ago.
conorthedev commentedon Sep 29, 2019
Also having this issue on my repo
joschi commentedon Sep 29, 2019
Same problem here with Java 1.8, 11, and 13.
dropwizard/dropwizard#2945
hossain-khan commentedon Sep 29, 2019
Getting same error in
giltene commentedon Sep 29, 2019
Looks like some added .sig files (.tar.gz.sig) on the CDN were being confused for the .tar.gz files by installer.ts. The .sig files have been removed from the CDN for now, but are the tool-cache seems to have cached them.
buckett commentedon Sep 29, 2019
@giltene I've just kicked off a build and the install worked correctly this time, thanks for the fix.
giltene commentedon Sep 29, 2019
Looks like the caches for the .sig stuff have now expired and things work again for all versions (6,7,8,9,10,11,12,13). Will work on an installer.ts change and pull request to make sure .tar.gz is expected at end of filename (to ignore .tar.gz.sig) before we re-enable .sig files on the CDN.
larryxiao625 commentedon Sep 29, 2019
It seems that the java 1.8 works fine with my project. Thanks for your fixing.
joschi commentedon Sep 29, 2019
The actions/setup-java GitHub Action seems to work again. 🎉
In case somebody is looking for a GitHub Action for setting up a Java development environment based on the AdoptOpenJDK OpenJDK distribution:
joschi/setup-jdk
JoeHegarty commentedon Oct 15, 2019
This has started to fail for us again today. Anyone else experiencing it?
Scoppio commentedon Oct 15, 2019
Yes, I just had it this very minute, I was setting up Actions to allow for dependabot to work better, but it failed hard and I cant test my actions anymore.
thuguerre commentedon Oct 15, 2019
I noticed the same kind of error on my workflow. all worked well yesterday
jawher commentedon Oct 15, 2019
A workaround until this PR is merged is to use the @giltene's fork (cf. his PR to fix the issue: #24):
vinodkone commentedon Oct 15, 2019
yes, I'm seeing it in my project too.
giltene commentedon Oct 16, 2019
Should be back to normal now.
This affected things that picked up "latest" (e.g. 8, 8.0.x, but not e.g. 8.0.222). Unfortunately, the new October 15 update releases posted earlier today for 7, 8, 11, and 13 all came with matching .sig files. The new .sig files are now removed to prevent the problem with setup-java. Integrating the the PR (#24) will help avoid this sensitivity to non-jdk contents being posted to the cdn..
thuguerre commentedon Oct 16, 2019
That's OK for me now. Thanks @giltene !
joschi commentedon Oct 16, 2019
In case anyone is interested in using the OpenJDK distributions from AdoptOpenJDK instead of Azul's Zulu:
https://github.com/marketplace/actions/setup-java-environment-based-on-adoptopenjdk
Disclaimer: I'm the maintainer of that GitHub Action.
giltene commentedon Oct 16, 2019
@joschi there are quite a few OpenJDK distributions one can pick from, of which Zulu is one. There is plenty of choice, include the likes of Amazon’s Corretto, Bellsoft’s Liberica, Alibaba’s Dragonwell, and IBM’s AdoptOpenJDK. Of the set, Zulu happens to be the community OpenJDK distribution with the longest track record of delivering free, 100% OSS and consistently updated builds for OpenJDK 6,7,8,9,10,11,12, and 13, spanning back quite a few years. Older versions (like 7u181 or 8u131) may not seem “sexy”, but since CI and testing configs often freeze specific JDK versions to test against (usually in addition to testing on latest/greatest), a track record for prompt availability of new versions coupled with well maintained, long term stable archives of all builds across a wide version and date range is one of the key things driving the choice of OpenJDK distribution CI systems default to.
joschi commentedon Oct 16, 2019
@giltene I don't want to start a big discussion here. I like Zulu and it served me well over the years, but people might want to use the AdoptOpenJDK distribution (not related to IBM), which is a bit clumsy to use with this GitHub Action.
More options, better ecosystem. 🎉
konradpabjan commentedon Nov 22, 2019
PR #27 has gone in which had some small changes to prevent this error from happening again.
Closing. If this happens in the future, either reopen this issue or create a new one.
petermetz commentedon May 21, 2021
@konradpabjan It looks like the same issue has resurfaced just now: https://github.com/hyperledger/cactus/pull/978/checks?check_run_id=2635662049#step:2:19
(I think)
Update: Hmm, 10 minutes later it doesn't fail anymore.