search

actions / setup-go

Set up your GitHub Actions workflow with a specific version of Go
MIT License
1.4k stars 517 forks source link

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

Closed de-jcup closed 4 years ago

de-jcup commented 4 years ago

Problem description

Sometimes I got errors at my build showing

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

as shown in next picture: image

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 https://github.com/actions/setup-node/issues/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 commented 4 years ago

I have been seeing this since this morning.

pipeline

qnkhuat commented 4 years ago

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

bryanmacfarlane commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

https://github.com/actions/toolkit/pull/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 commented 4 years ago

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.