Problem
The Build & Deploy to GitHub Pages workflow has been failing at the Set up job step. Root cause: actions/cache@v1 runs on a Node runtime version that GitHub has retired, so the action can no longer start on current runners. Because this step runs before any build logic, every push to master fails to deploy.
Motivation
The site is not redeploying on new commits. Beyond fixing the immediate failure, this is a good moment to harden the workflow and set up automated dependency updates so the same class of breakage doesn't recur silently.
Proposed changes
Workflow actions — pinned to full commit SHAs
Pinning SHAs (with a trailing # vX.Y.Z comment so the version stays visible) protects against a maintainer's tag being repointed at malicious code, as recommended by GitHub's hardening guide.
actions/checkout@v2 → v6.0.2actions/cache@v1 → v5.0.5 (this is the fix for the failure)peaceiris/actions-gh-pages@v3 → v4.0.0
Ruby bump — 3.2.2 → 3.4.9
Coordinated across three files so the repo stays internally consistent:
container: in github-pages.yml → ruby:3.4.9-bookworm.ruby-version → 3.4.9 (so local tooling matches CI)Gemfile.lock regenerated under Ruby 3.4.9 (the old BUNDLED WITH 2.2.22 is incompatible with Ruby 3.4's DidYouMean API)
Cache key — include .ruby-version
Previous key was ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}. A Ruby ABI change (3.2 → 3.4) with an unchanged Gemfile.lock would restore gems with native extensions compiled against the old Ruby — likely to crash at load. Expanded to hashFiles('**/Gemfile.lock', '.ruby-version') so future Ruby bumps invalidate the cache cleanly.
Dependabot (.github/dependabot.yml)
Weekly update schedules for:
github-actions — so pinned SHAs get bumped automatically rather than silently going stalebundler — so Gemfile gems keep receiving updates
Note: Dependabot does not touch .ruby-version or the container: key in workflows — future Ruby bumps remain a manual, coordinated action.
Resolution
Addressed by #63.
Problem
The
Build & Deploy to GitHub Pagesworkflow has been failing at theSet up jobstep. Root cause:actions/cache@v1runs on a Node runtime version that GitHub has retired, so the action can no longer start on current runners. Because this step runs before any build logic, every push tomasterfails to deploy.Motivation
The site is not redeploying on new commits. Beyond fixing the immediate failure, this is a good moment to harden the workflow and set up automated dependency updates so the same class of breakage doesn't recur silently.
Proposed changes
Workflow actions — pinned to full commit SHAs
Pinning SHAs (with a trailing
# vX.Y.Zcomment so the version stays visible) protects against a maintainer's tag being repointed at malicious code, as recommended by GitHub's hardening guide.actions/checkout@v2→v6.0.2actions/cache@v1→v5.0.5(this is the fix for the failure)peaceiris/actions-gh-pages@v3→v4.0.0Ruby bump — 3.2.2 → 3.4.9
Coordinated across three files so the repo stays internally consistent:
container:ingithub-pages.yml→ruby:3.4.9-bookworm.ruby-version→3.4.9(so local tooling matches CI)Gemfile.lockregenerated under Ruby 3.4.9 (the oldBUNDLED WITH 2.2.22is incompatible with Ruby 3.4'sDidYouMeanAPI)Cache key — include
.ruby-versionPrevious key was
${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}. A Ruby ABI change (3.2 → 3.4) with an unchanged Gemfile.lock would restore gems with native extensions compiled against the old Ruby — likely to crash at load. Expanded tohashFiles('**/Gemfile.lock', '.ruby-version')so future Ruby bumps invalidate the cache cleanly.Dependabot (
.github/dependabot.yml)Weekly update schedules for:
github-actions— so pinned SHAs get bumped automatically rather than silently going stalebundler— so Gemfile gems keep receiving updatesNote: Dependabot does not touch
.ruby-versionor thecontainer:key in workflows — future Ruby bumps remain a manual, coordinated action.Resolution
Addressed by #63.