ci: keep markdownlint from failing on generated changelogs - #3
Conversation
The Markdown job failed on the first release PR Release Please opened: CHANGELOG.md:12 MD024/no-duplicate-heading [Context: "Changelog"] Two causes, both latent until a release existed. CHANGELOG.md carried a hand-written note under its `# Changelog` heading. Release Please inserts each release directly after that heading, which demoted the note to a `## Changelog` section below the new entry -- colliding with the H1, and sinking further down the file with every future release. The file says not to edit it by hand; the note it carried is already in README.md under "Commits", so drop it and let Release Please own the file outright. That alone would fail again at the second release: MD024 compares every heading in the document, and each release section carries its own `### Bug Fixes`. Scope it to siblings, so headings only collide when they share a parent. Verified by linting a simulated two-release changelog: fails with the current configuration, passes with this one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 7 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The failure
The Markdown job failed on the release PR (
chore(main): release 0.1.1), not on any feature branch:Two separate causes, both latent until a release actually existed.
1. Hand-written prose in a bot-owned file.
CHANGELOG.mdcarried a note under its# Changelogheading. Release Please inserts each release directly after that heading, which demoted the note to its own## Changelogsection below the new entry:It would also sink further down the file with every future release. The file already says not to edit it by hand, and the note duplicates what
README.mddocuments under "Commits", so this drops it and lets Release Please own the file outright.2. That alone is not enough. MD024 compares every heading in the document, and each release section carries its own
### Bug Fixes. Removing the prose fixes 0.1.1 and then fails at 0.1.2. Scoping the rule to siblings means headings only collide when they share a parent, which is what a changelog needs.Verification
Reproduced locally against the exact file from the release branch, then confirmed both parts are necessary:
MD024 [Context: "Changelog"]— reproduces CIMD024 [Context: "Bug Fixes"]— would fail at 0.1.2Also linted a simulated two-release changelog with both
### Bug Fixesand### Featuresrepeated: clean.Not fixed here
The generated changelog lists the same change twice:
That is because #1 was brought in with a merge commit, so Release Please counted both the merge (via the PR title) and the branch commit behind it. Squash-merging PRs avoids it — worth considering as the repo default, since Release Please assumes one commit per change. The 0.1.1 entry can be tidied by hand in the release PR if you care; it does not affect the lint.
🤖 Generated with Claude Code