Add PR build test and markdown lint workflows

[JohnRDOrazio]

Closes #66.

Summary

Currently nothing runs on a PR before merge — breakage only surfaces post-merge via the Build & Deploy to GitHub Pages action on master. This PR adds two pull-request workflows so PRs get validated in flight:

• pr-build-test.yml — runs bundle exec jekyll build on PRs that touch build-influencing files.
• pr-markdown-lint.yml — runs markdownlint-cli2 on Markdown files changed in the PR.

Stacks on top of #63 (it assumes the Ruby 3.4.9 container and regenerated Gemfile.lock from that PR). Until #63 merges, the diff view on this PR will include those files too; once #63 lands I'll rebase and the diff collapses to just the three new files.

Design choices

Build test is path-filtered, not on every PR

Watches the files that can actually break a Jekyll build: .ruby-version, Gemfile, Gemfile.lock, _config.yml, _data/**, _includes/**, _layouts/**, _plugins/**, and the workflow itself. Editing a blog post doesn't trigger it — that's what the lint workflow is for.

Reuses the same ruby:3.4.9-bookworm container and the same vendor/bundle cache key as the deploy workflow (${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock', '.ruby-version') }}). GitHub Actions cache falls through from the PR branch to the base branch, so PR builds warm-start from the cache that master's deploy already populated.

Markdown lint is scoped to changed files

Running markdownlint-cli2 against the whole tree would surface violations in years of existing posts on day one. Instead the workflow computes the changed .md files with git diff --name-only --diff-filter=d "$BASE_SHA"...HEAD -- '*.md' (where BASE_SHA is github.event.pull_request.base.sha) and passes only those paths to the linter. Rules apply going forward; old content only gets checked if/when someone edits it.

Newline-delimited xargs -d '\n' -r handles filenames robustly and skips the run entirely if the list is empty (belt-and-suspenders with the explicit [ -z ] check).

actions/checkout is invoked with fetch-depth: 0 because the default shallow clone doesn't include the base commit needed for the diff.

Lint rules

.markdownlint-cli2.yaml starts from default: true and adjusts two rules:

• MD013 (line-length) — off. Prose content with long sentences shouldn't fail CI over wrapping.
• MD033 (no-inline-html) — off. Posts on this site embed raw HTML (images, paragraphs, figures) frequently.

Notable rules kept enabled from defaults:

• MD034 no-bare-urls — explicit feedback from the repo owner on a past PR: bare links shouldn't end up in posts.
• MD040 fenced-code-language — code blocks should declare a language.

Everything else stays at the default — easy to tighten or loosen in follow-up PRs.

Action versions — pinned to full SHAs

Consistent with #63. New pin added:

• actions/setup-node@48b55a0… (v6.4.0)

markdownlint-cli2@0.22.1 is pinned in the workflow via npm install -g. Bumps are manual for now; if autoupdates matter, future work is to introduce package.json + an npm entry in Dependabot.

Test plan

• Merge this PR and confirm both workflows show up as required/optional checks on subsequent PRs.
• Open a trivial test PR that edits a Markdown file — confirm PR markdown lint runs and PR build test does not.
• Open a trivial test PR that touches _config.yml — confirm PR build test runs.

🤖 Generated with Claude Code

[mkasberg]

Looks like this PR is stacked with your other one. The two workflow files in the last two commits look good to me!

[mkasberg]

This is fine... Nitpicking, but if it were up to me I'd simplify:

• Since this project already uses ruby, use a gem instead like markdownlint.
• Instead of running this as a separate workflow, just add a step to the other workflow (before or after the jekyll build) to lint markdown.
• Get rid of the path guards on both workflows. Presumably, most PRs are changing either markdown or Jekyll files. It's simpler (and less error-prone in the future) to just run a single test workflow on every PR.

Don't feel too strongly though, what's here will work 🤷‍♂️