Getting deployment_perms_error when trying to run this action since June 16

[idanarye]

Two days ago (June 16) this action stopped working. This is the first run where I've seen it fail - https://github.com/idanarye/bevy-yoleck/actions/runs/5293695779/jobs/9592352399.

When I look at the logs, I see these lines repeating 5 times after the Created deployment for <...>, ID: <...> log:

Getting Pages deployment status...
Current status: deployment_in_progress

And then these lines repeating over a hundred times:

Getting Pages deployment status...
Current status: deployment_perms_error

Followed by:

Error: Timeout reached, aborting!
Error: Timeout reached, aborting!
Canceling Pages deployment...
Canceled deployment with ID <...>

Note that:

• I've upgraded from v1 to actions/deploy-pages@v2, but the problem still repeats.
• When I tried to rerun older runs that did pass, this action failed.

So I think maybe something was changed in GitHub that either broke this action or caused it to require some additional configuration/permissions.

Note that six hours before that first failed run linked above I had a run that managed to pass and deploy the pages: https://github.com/idanarye/bevy-yoleck/actions/runs/5285227962/jobs/9563650017. So whatever changed probably happened during these six hours.

[onbjerg]

We get this too, opened up a PR to bump to v2 but sad that this seems like it would not fix it. Did you by chance find a workaround?

[idanarye]

@onbjerg I could not. The error is about permissions, so I tried adding more permissions that maybe could have been related (specifically I tried deployments: write and actions: write. They probably don't matter, but I was just trying things out) but it didn't work.

[onbjerg]

Hitting the endpoint manually using gh seems to yield a response of e.g.

{
  "status": ""
}

which is a bit odd. The deployments do show up under the "Environments" tab of the repository as well, all marked as failed, even though you can explore the deployments and they seem to look fine 🤷🏻‍♂️

I did this to test:

gh api /repos/<owner>/<repo>/deployments
# use the latest deployment id
gh api /repos/<owner>/<repo>/pages/deployments/<id>

This seems to follow what the action itself does

[idanarye]

The deployments do show up under the "Environments" tab of the repository as well, all marked as failed, even though you can explore the deployments and they seem to look fine

I've just checked in my repo, and the deployment does not update - I'm still getting the ones from the last successful deploy from before June 16. But the "Last deployed" in the "GitHub Pages" setting does update.

[ViliamVadocz]

I am encountering the same issue: failing job.
My workflow file is a bit simpler that @idanarye's. Maybe this will help with reproducibility.

[xxchan]

Same here. Begin to fail from 2 days ago
https://github.com/risingwavelabs/risingwave/actions/workflows/doc.yml

also

          I am hitting this error in my recent rustdoc deployments: https://github.com/DCNick3/shin/actions/runs/5300334374/jobs/9593874612

Is there anywhere I can find details about the "incorrect file permissions"?

Originally posted by @DCNick3 in #187 (comment)

[xxchan]

cc @tsusdere

[YiMysty]

👋 there is a README updated today.
https://github.com/actions/upload-pages-artifact#file-permissions

You can use the similar command to troubleshooting the incorrect file permissions :)

[yoannchaudet]

Apologies for not getting the documentation published on time.

If you get a permissions issue, that means your artifacts are not in the form we expect. You can fix that with an extra step, see https://github.com/actions/upload-pages-artifact#file-permissions (as per @YiMysty above 🙇).

We used to proactively fix permissions on your behalf but for many sites (with lots of files), that would delay Pages deployments by a lot and not be needed. We decided to just surface the error slightly better and document a mitigation step. Also note that this typically only happens if you have a custom workflow (dockers builds can be impacted).

[onbjerg]

Hopefully that was just it, although I feel like this should have been a breaking version bump on @actions/upload-pages-artifact? 😄

[onbjerg]

It worked!

Just a note here from me, turns out that the only file with incorrect permissions for my Rust based project was the .lock file that Cargo had snuck in to my rustdoc build 😄

[idanarye]

That did the trick.

[antonengelhardt]

Thanks everyone. It worked.

Additionally, i added the following for my Rust project:

echo "<meta http-equiv=\"refresh\" content=\"0; url=build_wheel\">" > target/doc/index.html

Maybe the final workflow file is more informative

[JamesMGreene]

@onbjerg

Hopefully that was just it, although I feel like this should have been a breaking version bump on @actions/upload-pages-artifact? 😄

I agree. I'm going to revert that change in the v1 line for upload-pages-artifact and cut a new v2.0.0 / v2 release for the chmod removal. Sorry about that! 😅

I'll drop an update here once that's cleaned up.

[JamesMGreene]

@onbjerg Updates on actions/upload-pages-artifact: 🚀

• The chmod commands have been added back in v1.0.10 and the latest v1 major tag
• The chmod commands have been removed (again) in v2.0.0 and the new v2 major tag

Thanks again for the constructive feedback! 🙇🏻

[JamesMGreene]

The part that most concerns me now is that it sounds like the deployment_perms_error status wasn't treated as a terminating/final status, which it should've been. 🤔

And then these lines repeating over a hundred times:

Getting Pages deployment status...
Current status: deployment_perms_error

Followed by:

Error: Timeout reached, aborting!
Error: Timeout reached, aborting!
Canceling Pages deployment...
Canceled deployment with ID <...>

We should still investigate and/or write a test for that scenario. 🧪

[JamesMGreene]

Ah, the repetitive error status polling until timing out was unfortunately a clerical error on our part: we had not yet published the latest release containing the changes from PR #187.

If you update to use v2.0.3 or the latest v2 major tag, the repetitive status polling should now be gone in the case of an file permissions error.

Such errors will need to be corrected before attempting to deploy, by doing something similar to one of the following:

• correcting your file permissions ahead of time so that they are already correct in git when checking them out from the repository
• using the actions/upload-pages-artifact@v1 tag, specifically (@v2 removed the formerly built-in chmod fix as it causes unnecessary slowdowns if your file permissions are already correct)
• adding another step into your Actions workflow before uploading the Pages artifact to fix any invalid permissions, e.g. the example fixes included in the README of actions/upload-pages-artifact@v2