[error]The process '/bin/tar' failed with exit code 2

[de-jcup]

Problem description

Sometimes I got errors at my build showing

The process '/bin/tar' failed with exit code 2

as shown in next picture:

When using setup-go V1 I had today such problems with
https://github.com/Daimler/sechub/runs/564346427?check_suite_focus=true
But doing a retry it worked (same commit ID):
https://github.com/Daimler/sechub/runs/564357022?check_suite_focus=true

Problem seems to be already fixed for setup-node

At actions/setup-node#116 the same problem was found for setup-node action. There was a bugfix done and issue closed - so was this only fixed for setup-node? IMHO there should be another fix for go, or former bugfix did not work. Or the fix did not effect setup-go V1?

[VascoFerraro]

I have been seeing this since this morning.

[qnkhuat]

Same here. I got 2/12 success build today.

[bryanmacfarlane]

@VascoFerraro - please report the node issues in the setup-node repo. Note that nodejs is having outages this morning (where that targz is downloaded from).

@de-jcup I think the same thing may have happened with setup go.

I think both should validate the download targz after downloading with a sha or checksum before attempting to extract. In some failure cases, if it's being streamed and they are having issues, it can lead to an incomplete, zero byte or corrupt targz.

[de-jcup]

@bryanmacfarlane Thank you for your reply. Maybe it would be better for GitHub actions to have a cache mechanism or a proxy server for standard binaries/parts (e.g. gradle, maven, go, java , etc.) so become more independant from other servers?

At business I normally use repository servers (e.g. artifactory, NEXUS, etc.) to reduce network traffic, maybe even check security vulnerabilites in libraries and also become independent from external network.

Another option would be : GitHub does provide GitHub Packages itself. So maybe using GitHub Packages for those dependencies could be an option as well?

[bhautikpip]

Same here. I have been seeing this error since today morning. (https://github.com/aws/aws-xray-sdk-go/pull/194/checks?check_run_id=565254625)

[bryanmacfarlane]

@de-jcup We are working on a CDN cache to insulate from these type of issues and get better perf from locality of data centers with edge caching. We are also working on getting latest versions directly on the hosted VM images to short circuit any downloads at all in common cases:

actions/toolkit#382

In the meantime, you may also want to try setup-go@v2-beta which added some better error handling and retries. I'm hoping to release v2 today so maybe wait for that.

[bryanmacfarlane]

setup-go@v2 is released and has better error handling for this error (with retries). So I'm going to close this. There's a larger effort started to cache some of these distributions but that's tracked elsewhere.