Docker image permission issue when run in GitHub Action

[theory]

What version of Hugo are you using (hugo version)?

❯ docker run ghcr.io/gohugoio/hugo:v0.136.5 version                      
hugo v0.136.5+extended linux/arm64 BuildDate=unknown VendorInfo=docker

Does this issue reproduce with the latest release?

Yes.

It looks like b5852d0 fixed #12946, but now, using v0.136.5, I get a new error:

Error: error building site: failed to acquire a build lock: open /github/workspace/.hugo_build.lock: permission denied

I suspect this is because the Docker image runs as hugo:hugo by default, but GitHub, for better or worse, requires that processes in Docker run as root in order to have permission to write files and whatnot.

[jmooring]

cc: @dvdksn

[dvdksn]

You can probably just add the lock file to dockerignore and it'll work.

Can you share your workflow and Dockerfile please.

[theory]

Here's my workflow, and here is the project Dockerfile.

[bep]

Error: error building site: failed to acquire a build lock: open /github/workspace/.hugo_build.lock: permission denied

Possible workaround:

hugo  --noBuildLock  

[dvdksn]

@bep how do you feel about letting this image run as root? There have already been quite a few issues related to permissions. Users wouldn't typically run this image in production, but as a build step, so I don't really think running as root would be a security concern.

[jmooring]

Users wouldn't typically run this image in production

Why not?

It seems like we began this effort (many hours now) without a clear definition of intended use:

• Local builds?
• CI/CD container?
• CI/CD build step?

I created an image several months ago as a learning/testing exercise, and use it with both GitHub Pages and GitLab Pages as demonstrated with this test site:

• https://github.com/jmooring/hugo-docker-test/blob/main/.github/workflows/hugo.yaml
• https://github.com/jmooring/hugo-docker-test/blob/main/.gitlab-ci.yml

It can also be used for local builds.

I'm not advocating that we use this test image, but its composition intentionally targeted the use cases above.

Other than documentation and support I don't have a stake in this. But it would be good if the target stopped moving.

[bep]

I'm not advocating that we use this test image, but its composition intentionally targeted the use cases above.

I don't see any Docker file referenced, so it's hard to say anything about this particular image, but a quick glance at your CI setup, I'm guessing it's setup differently (without e.g. Node/NPM).

Users wouldn't typically run this image in production

1. Building a Hugo site for production is the primary use case for this, and both CI container and CI build step (assuming there's a difference) should work (assuming the platform OS/arch is supported).
2. Local development should work, but that sounds like a secondary use case to me.
3. Hugo's server is a development server, so running hugo server in production is not something we will support/encourage.

[theory]

Using --noBuildLock just gets the build to the next permission issue:

Error: error copying static files: mkdir /github/workspace/public: permission denied

I created an image several months ago as a learning/testing exercise, and use it with both GitHub Pages and GitLab Pages as demonstrated with this test site:

From the Dockerfile, it looks like you never set the user, so it will run as root, which is what GitHub actions, at least, require.

[theory]

1. Building a Hugo site for production is the primary use case for this, and both CI container and CI build step (assuming there's a difference) should work (assuming the platform OS/arch is supported).

If you mean it builds the static files and they get deployed somewhere, but the image itself isn't spun up to serve the site or do anything else for a production server, then it seems as though it doesn't matter whether it runs as root or not.

[dvdksn]

If you mean it builds the static files and they get deployed somewhere, but the image itself isn't spun up to serve the site or do anything else for a production server, then it seems as though it doesn't matter whether it runs as root or not.

This is what I meant. We only care about static output generated from the container. So the user privileges in the container are only relevant at build-time (and/or during development), which is why I think running as root is probably fine for this image.

[theory]

This is what I meant. We only care about static output generated from the container. So the user privileges in the container are only relevant at build-time (and/or during development), which is why I think running as root is probably fine for this image.

I think so, too.

[bep]

OK, I have spent some time on this today, and my conclusions are:

• This works if we remove the USER setups in the Dockerfile, e.g. run as root.
• I wouldn't mind running as root in GitHub Actions.
• I would not like if docker run ... server ran as root when started on my development PC.

And when I say I above, I'm also assuming a lot of other Hugo users' having the same view on things.

I don't have a practical solution for this, I'm afraid; I suspect the solution might be to set up a separate "Hugo GitHub Action".

[theory]

Well, GitHub actions don't run the ENTRYPOINT, so you can use gosu in the entry point script to create and execute as a less privileged user. Here's an example.

[phante]

Hi,
I think this kind of problem can be generalized for all CI/CD systems that are based on containerized images.

I also encountered it using Woodpecker CI because in that case the git repository pull step is done with root user and therefore the Hugo image is not able to write inside the directory tree.

On my pipeline I solved it by adding between the workspace download and the hugo execution a step that changes the owner of the file inside the workspace to hugo (uid 1000).

[razonyang]

I'd like to share an idea to create another tag for the root user image with GitHub Actions matrix and Docker build-args, which doesn't require to create another Dockerfile or GitHub workflow, then people can choose the image they want.

The keys are as follows:

1. Define user name in matrix on GH workflow, e.g. user: ['root', 'hugo'].
2. Pass the user name via Docker build-args, e.g USER=${{matrix.user}}.
3. Override the USER directive, declare (ARG USER=root) and assign (USER: $USER).
4. Finally, change the image tag based on the user name and push.