ci: use a maintained commitlint action fork

[robinbowes]

What

Points the commitlint job at yo61/commitlint-github-action — a maintained fork running commitlint v21 on Node 24.

Why

Dependabot PRs fail the commitlint job on body-max-line-length, while the pre-commit lint job passes the same commit. Same commit, same commitlint.config.mjs, different verdict.

@commitlint/ensure v20 added an exemption for long lines containing a URL:

const URL_REGEX = /\bhttps?:\/\/\S+/;
value.split(/\r?\n/).every((line) => URL_REGEX.test(line) || ensure(line, max));

wagoid/commitlint-github-action@v6.2.1 is the latest release and pins @commitlint/ensure: ^19.0.3, so CI enforced a stricter rule than the config intends. Dependabot bodies are markdown link lists — one real example is 314 characters on a single line.

Upstream is unmaintained: no commit to master since 2025-01-14, and the v20 bump (PR #837) has been open and mergeable since July with no response.

The fork

yo61/commitlint-github-action@v6.3.0 — all @commitlint/* at ^21, Node 24.19.0 LTS (v21 needs node >= 22.12), commitlint-plugin-function-rules at ^5 (v4's peer range caps at <20 and breaks npm ci), published to ghcr.io from a pushed tag. Actions SHA-pinned, least-privilege permissions, actionlint and zizmor clean.

Verified against the action's own load+lint path with a real commitlint.config.mjs:

Case	Result
Dependabot commit, 314-char body line	valid
Sentence-case subject with subject-case: [0]	valid — the .mjs override is honored
Malformed commit	rejected

Commit subjects stay validated for Dependabot as well as humans, rather than exempting bot commits.

[yo61-lastlight]

Replaces the stale wagoid/commitlint-github-action (pinned @commitlint/ensure ^19) with a direct, version-pinned npx commitlint run (v21.2.x) that matches the pre-commit hook's config-conventional ^21.1.0, fixing the version skew that made CI reject long Dependabot commit bodies the pre-commit hook accepted. The permission change (pull-requests: read -> contents: read) is correct since the range now comes from local git via fetch-depth: 0 rather than the GitHub API. Diff is small, well-commented, and consistent with the rest of the workflow's SHA-pinning conventions. No Critical or Important issues found.

[yo61-lastlight]

Prior review (at 09bc2fc, before this push) had no findings and approved the switch from wagoid/commitlint-github-action to a direct commitlint invocation — that part still holds. This push adds a tracked package.json/package-lock.json under .github/commitlint so Dependabot can track the pin, per the issue. That change breaks the job: commitlint.config.mjs at the repo root extends "@commitlint/config-conventional", but the package is only installed into .github/commitlint/node_modules, which Node's module resolution cannot reach from the repo root (it walks up from the config's directory, not sideways into a subdirectory). Reproduced locally — same MODULE_NOT_FOUND the live "Conventional Commits" job hit at this head SHA (run 31493134220, job 93784202108, conclusion failure), which is also why mergeable_state is currently "blocked".

[yo61-lastlight]

[Critical] config-conventional is unresolvable from the repo root — the job fails

commitlint.config.mjs (repo root) does extends: ["@commitlint/config-conventional"]. The package is installed only into .github/commitlint/node_modules (via npm ci with working-directory: .github/commitlint), but the lint step runs ./.github/commitlint/node_modules/.bin/commitlint --config commitlint.config.mjs from the repo root. Node's resolution for the extends target starts at the config file's directory (repo root) and walks up, never into a subdirectory's node_modules, so it can't find the package there. Reproduced locally: npm ci in .github/commitlint, then running the binary from repo root throws Error: Cannot find module "@commitlint/config-conventional" from "<repo root>" — the exact failure in the live run at this head SHA (Conventional Commits job, run 31493134220, conclusion: failure). The job is currently red on this PR; every future PR's commitlint check will fail the same way regardless of commit message quality.

Suggested change

	./.github/commitlint/node_modules/.bin/commitlint \
	- name: Lint commit messages
	working-directory: .github/commitlint
	env:
	BASE_SHA: ${{ github.event.pull_request.base.sha }}
	HEAD_SHA: ${{ github.event.pull_request.head.sha }}
	run: |
	set -euo pipefail
	./node_modules/.bin/commitlint \
	--config ../../commitlint.config.mjs \
	--from "$BASE_SHA" --to "$HEAD_SHA" --verbose

[yo61-lastlight]

pr-review is waiting for cluster capacity — it'll start automatically when a slot frees.

[yo61-lastlight]

Prior-findings ledger: the earlier CHANGES_REQUESTED review (config-conventional unresolvable from the repo root because the fix at that time vendored a package.json under .github/commitlint) no longer applies — this push replaces that commit entirely and returns to the simpler approach from the issue/PR body: point the workflow at yo61/commitlint-github-action@v6.3.0 (docker action, configFile input) instead of wagoid's. Verified fixed, not just claimed: the pinned SHA 31e5e0454f... matches the fork's v6.3.0 tag and its action.yml (configFile input present, image ghcr.io/yo61/commitlint-github-action:6.3.0), the fork's publish-image workflow ran successfully on that tag push and smoke-tested the pulled image, and this PR's own CI at the current head SHA (d7d2234) shows the Conventional Commits job pulling and running the fork action successfully alongside the rest of the matrix passing. Diff is a single 7-line change to .github/workflows/ci.yaml, SHA-pinned with a version comment consistent with the workflow's existing conventions. No Critical or Important issues found.