Trouble with permissions

[EugeneVdovenko]

I have a problem when docker run

Bundler::PermissionError: There was an error while trying to write to /usr/gem/cache. It is likely that you need to grant write permissions for that path.

[envygeeks]

Update the Docker image.

[38leinaD]

I just pulled the docker image a few minutes ago (first time user) and seeing also errors like this:

Errno::EACCES: Permission denied @ rb_file_s_rename - (/home/jekyll/.gem/ruby/2.7.0/cache/jekyll-asciidoc-3.0.0.gem, /usr/gem/cache/jekyll-asciidoc-3.0.0.gem)
An error occurred while installing jekyll-asciidoc (3.0.0), and Bundler cannot continue.
Make sure that `gem install jekyll-asciidoc -v '3.0.0' --source 'https://rubygems.org/'` succeeds before bundling.

When I do the gem install command that is mentioned it works. Running bundle install again will bring me to the next dependency failing with the permissions error.

[EugeneVdovenko]

I have same

Errno::EACCES: Permission denied @ rb_file_s_rename - (/home/jekyll/.gem/ruby/2.7.0/cache/rexml-3.2.4.gem, /usr/gem/cache/rexml-3.2.4.gem)

[JuanJoanJon]

Same problem as @38leinaD and @EugeneVdovenko when docker-building this Dockerfile if using jekyll/builder:4.0

Not happening with jekyll/builder:3.8

[envygeeks]

Because images aren't altered once a version has changed so 3.8 would still be way before bundler started causing all these issues for us. I've an idea for a work around, it would be nice if one of you could provide a snapshot of your project so I could use it to test.

[EugeneVdovenko]

I have a empty jekyll project from GitLab Pages (gitlab.com/pages/jekyll/) and YML for docker-compose. Link bellow:

proj.zip

[envygeeks]

Please provide it as a Git repo. I do not download ZIP's and use them, thanks!

[EugeneVdovenko]

Please provide it as a Git repo. I do not download ZIP's and use them, thanks!

https://github.com/EugeneVdovenko/docker-jekyll

[fabacab]

I'm not sure if this helps any, but one thing I noticed just now is that in certain scenarios, including on GitHub Actions, we seem to have been getting different images than the ones @envygeeks actually published. More specifically, despite jekyll/builder@sha256:a8345b1d5316347dccd73ed4e96cb08e29bd8b2634bb727fb4d9311fe1e3ec89 being published on Docker Hub, my GitHub Actions that had Dockerfiles with lines like FROM jekyll/builder were not pulling this image digest down. They were pulling a (presumably) older image. Importantly, these older images did not include a call to default-gem-permissions that has been added to address these permission issues in the latest published image (the one with digest sha256:a8345b1d5316347dccd73ed4e96cb08e29bd8b2634bb727fb4d9311fe1e).

I had to explicitly change my Dockerfile's FROM line to include the specific image digest I wanted in order to get GitHub Actions's runner environments to invalidate the old image's tag and pull down the new one.

Unfortunately, this only solved half the problem for me, because I'm still running into the issue described in #269, but I'm hoping this may help someone else as I continue to work through my own build's issues.

[envygeeks]

@meitar add a pre-command docker rm jekyll/builder:latest and see if that helps.

[fabacab]

@meitar add a pre-command docker rm jekyll/builder:latest and see if that helps.

Hmm, how does one do this in GitHub Actions? Asked another way, can you be more specific about what you are suggesting I try when you describe "adding a pre-command"?

I ask because if you look at the build logs for any such job, you'll note that containers for the Actions are built ahead of time, before any step in the job is executed. This makes it unclear to me whether or not docker rm can be effective, since by the time such a command in a GitHub Action's workflow is executed, the container has already been built and will not be recreated.

This is why I opted to pin the Docker container's base image for the Action itself to a specific SHA256 digest. That way, at least, I knew exactly which code was being built.

I don't understand why using a plain tag did not work since you have clearly published the updated versions of the container images to Docker Hub, but I believe GitHub caches aggressively for obvious performance reasons and as we all know, caching is hard. Shrug?

As always, thanks again!