Problems when running locally with Docker #517

Environment

Here's my current Docker versions, running on Linux Mint 21.3 (Kernel 5.15.0-186-generic):

Client: Docker Engine - Community
 Version:           29.6.2
 API version:       1.55
 Go version:        go1.26.5
 Git commit:        dfc4efb
 Built:             Thu Jul 16 16:12:23 2026
 OS/Arch:           linux/amd64
 Context:           default

Docker Compose version v5.3.1

Problems

I very recently opened the #516 PR to review, but while testing locally if the changes would run smoothly, I decided to try the offered Docker tutorial. I found two issues while doing that, and since I'm unsure whether I should open a new PR for it, I'll document them below to evaluation.

Ruby version on Dockerfile not building image

While building the image, I ran into the following error:

[4/4] RUN bundle install
3.351 Fetching gem metadata from https://rubygems.org/...........
6.276 Fetching gem metadata from https://rubygems.org/.
6.290 Resolving dependencies....
6.685 ffi-1.17.4-x86_64-linux-musl requires ruby version >= 3.0, < 4.1.dev, which is
6.685 incompatible with the current version, ruby 2.6.5p114
ERROR: process "/bin/sh -c bundle install" did not complete successfully: exit code: 5

I believe this might be caused by some Dependabot bump of the Ruby gems or similar workflow that might have stopped working with the Ruby version of the ruby:stretch image. I haven't tested Ruby locally yet, yet as it seems to be tied to its version, a fresh new installation of the CLI should not produce any error like this.

Error with Jekyll GitHub Metadata plugin

I'm unsure if this problem is related to the fact that I changed Ruby version or maybe lack of knowledge on the setup for Jekyll (at least this step wasn't explicit in the README.md), but after building the image, the container exited with the following error:

       Generating... 
    GitHub Metadata: No GitHub API authentication could be found. Some fields may be missing or have incorrect data.
    GitHub Metadata: Error processing value 'description':
   Liquid Exception: No repo name found. Specify using PAGES_REPO_NWO environment variables, 'repository' in your configuration, or set up an 'origin' git remote pointing to your github.com repository. in /_layouts/default.html
              ERROR: YOUR SITE COULD NOT BE BUILT:
                     ------------------------------------
                     No repo name found. Specify using PAGES_REPO_NWO environment variables, 'repository' in your configuration, or set up an 'origin' git remote pointing to your github.com repository.

As I said, I'm unsure if this is related to the Ruby version, Docker or a missed step on setting up the project. As far as I checked this page, the environment variable should be set when I cloned my fork, but it wasn't inside the container probably due to Docker. I tried changing the _config.yml and _config_local.yml files, rebuilding, but only when I added the PAGES_REPO_NWO on the Compose file matching my fork NWO it worked.

Proposed Solutions

I gladly would contribute with the repository by pushing a new PR with my proposed solutions, yet, this project is not small and certainly has its rules. Below I list my proposals, and I'll wait for guidance regarding them.

Ruby version on Dockerfile not building image

I tried updating the base image to ruby:3.4 and ruby:3.4-alpine, and it only worked on the first tag. From what I read of the output on the alpine version, it seems that it doesn't provide libraries used by Make, yet I didn't go further into messing with it. I'd suggest only updating to ruby:3.4 in this case. Additionally, the version key can be removed from docker-compose.yml.

Error with Jekyll GitHub Metadata plugin

Since I couldn't exactly trace the cause of this problem, I'm assuming it mostly is caused because of Docker not passing the PAGES_REPO_NWO environment variable to the container. Maybe a tip on the README regarding it, or a custom script to get it from Git and pass through? Or an explicit instruction to fill in the YAML files? What I'd suggest is to add it as an environment variable straight into the docker-compose.yml file, but I do believe there are better ways to attain the solution.