Deployment fails if files are not writable or owned by root about deploy-pages HOT 8 CLOSED

ℹ️ While it's not a complete fix, as this should indeed be handled on the server-side eventually, we have added a partial fix to the actions/upload-pages-artifact Action that should clear out such permissions: actions/upload-pages-artifact#34

Since you are using that Action with @v1 already, your future workflow runs will hopefully be successful without your cp ... workaround.

Please let us know if you're still running into issues.

from deploy-pages.

The permission problem itself might be resolved but in the example of OP, the directory for deployment is a symlink itself where the contents of ./result is not writeable. Judged by the warnings that should have been printed, your fix does not work for these cases, see https://github.com/Gerschtli/nix-formatter-pack/actions/runs/3499580588/jobs/5861357357.

Probably because chmod is running in . instead of inputs.path. But because chmod is not derefencing symlinks that may exist in inputs.path, you should probably run the cp --recursive --dereference before doing chmod.

from deploy-pages.

@sempruijs looks like this is the issue you've been encountering

from deploy-pages.

We made changes recently around that which should help. Closing.

from deploy-pages.

@yoannchaudet are those changes merged/released yet? I ran into the same issue, with nix, too.

from deploy-pages.

The permissions fix is included in https://github.com/actions/upload-pages-artifact/releases/tag/v1.0.6.

It's best effort and we don't change ownership on the files. If that's your issue, I am afraid you will need to handle that yourself with an extra chown command.

from deploy-pages.

Why is it not possible to take care of necessary ownership requirements with this action? I am glad to help out.

from deploy-pages.

Running into this aswell. Is the chown still the way to use this?

from deploy-pages.