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.
Problem
No GitHub Actions workflows run on pull requests. The only active workflow —
Build & Deploy to GitHub Pages— triggers onpushtomaster, which means:_config.ymlchange, an incompatible gem bump, a typo in a layout) merges cleanly and only fails after it's onmaster, blocking the site from redeploying until someone reverts or fixes forward.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 buildon 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-cli2on PRs touching*.md, but only against files changed in the PR (diffed againstgithub.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.yamlStart from
default: true. DisableMD013(line-length — disruptive for prose) andMD033(no-inline-html — Jekyll posts frequently embed HTML). KeepMD034(no-bare-urls — repo-owner feedback) andMD040(fenced-code-language) enabled from defaults. Easy to tighten or loosen later.Resolution
Addressed by #65.