GitHub Actions for CI

Prerequisites: Pull Requests and Code Review Workflow; a repository with the ruleset from that project already in place.

Targeted versions: This project pins actions/checkout@v6 and actions/setup-node@v6 — both current stable major versions as of this writing (checkout is at v6.0.2, released January 2026; a v7 exists as a beta but isn't yet the recommended default for new workflows). Runner images use ubuntu-latest. Node.js examples target Node 24, the current Active LTS line as of June 2026 (Node 22 remains supported under Maintenance LTS through April 2027, so pin to '22' instead if that's what your project needs). Action major versions bump on a regular cadence and older ones eventually stop receiving Node.js-runtime updates from GitHub — check each action's own releases page before pinning long-term rather than trusting any version number to stay current indefinitely. Verified against docs.github.com/actions and the actions/checkout and actions/setup-node repositories, July 2026.

A GitHub Actions workflow is a YAML file living in .github/workflows/ in your repo. It declares triggers (on: — push, pull_request, a schedule, a manual dispatch, and more), one or more jobs (which run in parallel on separate, isolated runner machines by default), and each job is a sequence of steps that either uses: a reusable packaged action (like checking out your code) or run: a raw shell command.

The piece that makes this genuinely useful rather than just "tests run somewhere" is what you built in the previous project: a ruleset that requires status checks to pass before a PR can merge. Once this project's workflow reports a status back to GitHub on every PR, you can go back and mark it required — at which point a red X on a pull request isn't just informational, it's an actual, enforced gate. That's the goal this project builds toward.