deploy-pages: Getting `deployment_perms_error` when trying to run this action since June 16

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.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 5
  • Comments: 17 (4 by maintainers)

Commits related to this issue

Most upvoted comments

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

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

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 😄

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

@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! 🙇🏻

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.

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