Fix commit pagination, check the release branch, and freeze the changelog

[cjbarth]

Four corrections, found by rebuilding this project's own changelog with the 5.1.0 code and reading the result.

Read every page of a branch's commits

_getAllCommitsForBranch advanced page before testing it, so while (page < totalPages) stopped one page short of what GitHub reported. For this repository that meant 300 of master's 347 commits, and every tag pointing into the unread page failed the reachability filter that the commits, issues and milestones data sources apply — its section simply vanished from the changelog.

Regenerating kept 36 of 47 tags. It now keeps 44; the other three are not on master at all, which no amount of paging changes.

The other three paginated calls use a recursion form that tests before advancing, so they were already correct.

Check the release branch, and tidy what is written

Tags are checked against GitHub and the commits of a release are read from the local clone, so the two have to agree. A missing or moved tag already stops the run, but the branch the unreleased section is built from was only checked to exist — a clone left behind would quietly describe work nobody else can see. The check is skipped when the version being prepared is already tagged, since the branch is not read at all then.

Two output fixes alongside it: a release whose commits are all filtered left a heading with nothing under it instead of saying there was nothing to list, and a commit subject with a space at either end put that space inside the link text, which reads as [ text ] and fails a markdown linter.

Give the markdown what a linter asks for

.markdownlint.json disabled MDO13 — letter O, and a stray colon — so line-length was never actually turned off and every long line in the repository was an error.

With that fixed, three fenced blocks needed a language, and the two sample releases were quoted rather than fenced, so their headings counted towards the document's heading levels and made the heading after each one look like a jump from h2 to h4. Fencing them as markdown silences that and shows them as what gren writes.

Freeze this project's changelog and build it from pull requests

The releases up to 5.0.0 cannot be regenerated: the older sections came from the upstream project's issue tracker, which this repository does not have, and three tags sit on a version-bump commit that never merged into master. frozenBefore keeps all of it as it reads, and releases from here are built from pull requests.

Two things follow. A commit that reaches master without a pull request is reported after generating rather than written to the changelog. And the catch-all group is load-bearing — without it, a pull request whose labels match no group is dropped in silence.

The changelog is regenerated once here to drop the release commits and to order the releases of a single day by version rather than arbitrarily.

Verification

• 125 tests with a token, 86 without — CI runs the second, since Gren.spec.js skips itself when GREN_GITHUB_TOKEN is unset.
• npm run changelog reproduces the committed CHANGELOG.md byte for byte, and a release simulation adds only the new section.
• The commits, issues and milestones data sources behave exactly as before; nothing here changes what they read or emit beyond the two output fixes.

🤖 Generated with Claude Code