-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
is version 3.1.0 broken? #944
Comments
Yes. We have the same bug. Reverting to v3.0.2 fixes for us. This occurs only on our self hosted runners |
Thank you for reporting this, looking into this now! |
We are repointing |
We're also facing the same unzipping error ^ |
Same error here : Download action repository 'actions/checkout@v3' (SHA:2541b1294d2704b0964813337f33b291d3f8596b) |
It looks like the whole GH universe is going to add their copy of the error here :-D We have hundreds of failed builds, but I personally am not sure the action is the problem. |
same here
|
This is a failure to download the tar archive at 2541b12 from the Alas, it simply seems that the tarball returned by https://github.com/actions/checkout/tarball/2541b1294d2704b0964813337f33b291d3f8596b is empty: $ file ~/Downloads/actions-checkout-v3-0-g2541b12.tar.gz
~Downloads/actions-checkout-v3-0-g2541b12.tar.gz: empty EDIT: The tarball from 93ea575 for |
actually we tried |
For those that are getting the |
I don't really know if v3.1.0 is broken but we can see that Also this morning I started to see failures from this action, and the outcome was the same even after doing a rerun,
Funny bit is that https://www.githubstatus.com/ reports all green, when in fact checkout no longer works |
we ran into the tar issue and are pointing to |
Seems like everyone with problems is running I think we have to wait for Github to fix it. |
@casperbakker I wonder how long does it takes for them to report the outage, if they will ever do it. That reminded me of the non-sense naming issue with runners, where |
I confirm that bump to |
deployed a walkaround on my end using:
|
@ssbarnea It's been reported, a few minutes ago:
|
UPDATE: the comment below is regarding the 'permission denied' exception happening on jobContainers introduced in v3.1.0, and is unrelated to the Thanks for reporting this so quickly! SummaryIn short: the jobContainers in these workflows seem to follow an unsupported path. Namely,
I believe the jobContainer operates as the user 'circleci' in the workflow you linked. We will roll out the changes again as we haven't seen issues with the officially supported paths. It is recommended 'not use the USER instruction in your Dockerfile'. I understand this introduces some friction, so see below for workarounds and a technical summary. Detailed Summary
This can have a couple of outcomes:
The jobContainers in the above workflow seem to run into 2/b. FixAs per the docs, don't modify the default user in the Dockerfile. If that's not feasible for you: 👇 Workarounds (unsupported)
We will roll out the changes again as we haven't seen issues with the officially supported paths. |
Follow-up in #956 |
Yesterday the world was fine, today not so much.
To fix my issue today I just downgrade to V2, this literally worked yesterday and did not today.
Bad run: https://github.com/runatlantis/atlantis/actions/runs/3185910307/jobs/5196021098
Good run: https://github.com/runatlantis/atlantis/actions/runs/3185943896/jobs/5196059932
error:
Thanks.
The text was updated successfully, but these errors were encountered: