Not in gzip format

[alexander-scott]

Hi, I am getting an error when running the setup-java step in the following configuration:

    - uses: actions/setup-java@v1
      with:
        java-version: '12.x'

The error I get is the following:

Run actions/setup-java@v1
/bin/tar xzC /home/runner/work/_temp/temp_1966052730 -f /home/runner/work/_temp/7c187b07-8201-4bf2-b87d-247013d1c81d

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

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?

[bijancn]

I also see this issue. Here for example https://github.com/starship/starship/pull/383/checks?check_run_id=240449201

[pzygielo]

Experiencing the same for java-version: 1.8 as well.

[larryxiao625]

I have got this error too in Java-version:1.8

[zhzy0077]

Having the same problem. It was fine several hours ago.

[conorthedev]

Also having this issue on my repo

[joschi]

Same problem here with Java 1.8, 11, and 13.

dropwizard/dropwizard#2945

[hossain-khan]

Getting same error in

• https://github.com/amardeshbd/android-barebone/commit/53ccf2935b70c4de9ef03a83faebd033d677bbad/checks
• https://github.com/amardeshbd/android-barebone/commit/bfa508fd067c00716b9eb2b400b5fd3165a34baa/checks

~ ##[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

[giltene]

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]

@giltene I've just kicked off a build and the install worked correctly this time, thanks for the fix.

[giltene]

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]

It seems that the java 1.8 works fine with my project. Thanks for your fixing.

[joschi]

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]

This has started to fail for us again today. Anyone else experiencing it?

[Scoppio]

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

[thuguerre]

I noticed the same kind of error on my workflow. all worked well yesterday

[jawher]

A workaround until this PR is merged is to use the @giltene's fork (cf. his PR to fix the issue: #24):

- name: Set up JDK 11
  uses: giltene/setup-java@master
  with:
    java-version: 11

[vinodkone]

yes, I'm seeing it in my project too.

[giltene]

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]

That's OK for me now. Thanks @giltene !

[joschi]

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]

@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]

@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]

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]

@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.