No pre-merge validation on PRs — build breakage and Markdown issues only surface post-merge #66

Problem

No GitHub Actions workflows run on pull requests. The only active workflow — Build & Deploy to GitHub Pages — triggers on push to master, which means:

• A PR that breaks the Jekyll build (e.g. a bad _config.yml change, an incompatible gem bump, a typo in a layout) merges cleanly and only fails after it's on master, blocking the site from redeploying until someone reverts or fixes forward.
• Markdown quality issues in posts (bare URLs, unlabeled fenced code blocks, etc.) have no automated check. The repo owner has previously flagged bare links on a PR as something that should be caught — right now that feedback has to be given manually every time.

Motivation

Catch these issues in the PR before merge, where they're cheap to fix, rather than after merge when they can block deploys or ship low-quality content.

Proposed changes

Build-test workflow — path-filtered

Run bundle exec jekyll build on PRs that touch files which can actually influence the build: .ruby-version, Gemfile, Gemfile.lock, _config.yml, _data/**, _includes/**, _layouts/**, _plugins/**. Editing a blog post shouldn't trigger it — that's what the lint workflow is for. Reuses the same Ruby container and cache key as the deploy workflow so PR builds warm-start from master's cache.

Markdown lint workflow — scoped to changed files

Run markdownlint-cli2 on PRs touching *.md, but only against files changed in the PR (diffed against github.event.pull_request.base.sha). This lets the rules land without a mass-fix pass over years of existing posts — old content only gets linted when someone edits it.

Lint config — .markdownlint-cli2.yaml

Start from default: true. Disable MD013 (line-length — disruptive for prose) and MD033 (no-inline-html — Jekyll posts frequently embed HTML). Keep MD034 (no-bare-urls — repo-owner feedback) and MD040 (fenced-code-language) enabled from defaults. Easy to tighten or loosen later.

Resolution

Addressed by #65.