CI: pin jekyll/builder image and install gems from the lockfile

[mcfnord]

Problem

jekyll_site_ci is currently failing on every PR (e.g. #1145), in the Build the site in the jekyll/builder container step:

Bundler::Definition#materialize': Could not find jekyll-4.3.3, jekyll-polyglot-1.8.1,
jekyll-minifier-0.1.10, jekyll-paginate-v2-3.0.0, ... in locally installed gems

while the container is running Jekyll 4.4.1.

Root cause

The build ran inside the floating jekyll/builder:latest image and relied entirely on the gems baked into that image (there was no bundle install). Docker Hub recently republished latest as Jekyll 4.4.1, whose bundled gem set no longer matches the committed Gemfile.lock (Jekyll 4.3.3, jekyll-polyglot 1.8.1, ...). Bundler can't reconcile the lockfile against the image's preinstalled gems, so it fails in Definition#materialize and jekyll build exits 1.

This is environmental, not a defect in any page content — it broke all open PRs at once when the upstream tag moved. (There is no jekyll/builder:4.3.3 tag on Docker Hub, so the lockfile could no longer be satisfied by latest.)

Fix

• Pin the image to a fixed tag (jekyll/builder:4.4.1) so it can no longer silently drift.
• Run bundle install && bundle exec jekyll build so the committed Gemfile.lock is authoritative and the image only needs to supply Ruby + Bundler.

This unblocks #1145 and the other open PRs. Supersedes the empty WIP #1155.

Note

An alternative would be to regenerate Gemfile.lock against 4.4.1 and keep the fast no-install path, but that requires confirming the plugins (jekyll-polyglot / jekyll-minifier / jekyll-paginate-v2) are 4.4-compatible. Installing from the lockfile is the lower-risk unblock.

🤖 Generated with Claude Code

[pljones]

Just to be clear -- this will fail here because of the problem it's trying to fix. We need to force the merge?

[pljones]

Um. Maybe this needs to go to release? @ann0see @gilgongo @ignotus666 ?

[ignotus666]

Yes. Then that update will be automatically merged into next-release.

[mcfnord]

Retargeted to release and trimmed the branch to just the single jekyll.yml commit (it was cut from next-release, hence the earlier 56 unrelated translation files — those are gone now).

As noted above, jekyll_site_ci will still fail on this PR since the check runs the old workflow from the base; it needs a force-merge, after which the fix flows into next-release automatically.