Skip to content

ci: keep markdownlint from failing on generated changelogs - #3

Merged
andrewshell merged 1 commit into
mainfrom
fix/markdownlint-changelog-headings
Aug 4, 2026
Merged

ci: keep markdownlint from failing on generated changelogs#3
andrewshell merged 1 commit into
mainfrom
fix/markdownlint-changelog-headings

Conversation

@andrewshell

Copy link
Copy Markdown
Contributor

The failure

The Markdown job failed on the release PR (chore(main): release 0.1.1), not on any feature branch:

CHANGELOG.md:12 error MD024/no-duplicate-heading Multiple headings with the same content [Context: "Changelog"]

Two separate causes, both latent until a release actually existed.

1. Hand-written prose in a bot-owned file. CHANGELOG.md carried a note under its # Changelog heading. Release Please inserts each release directly after that heading, which demoted the note to its own ## Changelog section below the new entry:

# Changelog

## [0.1.1](...) (2026-08-03)
### Bug Fixes
* ...

## Changelog          <- collides with the H1
Maintained by [Release Please](...)

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.md documents 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:

Changelog Config Result
Release branch, as-is current MD024 [Context: "Changelog"] — reproduces CI
Prose removed, two releases current MD024 [Context: "Bug Fixes"] — would fail at 0.1.2
Prose removed, two releases this PR
Release branch, as-is this PR

Also linted a simulated two-release changelog with both ### Bug Fixes and ### Features repeated: clean.

Not fixed here

The generated changelog lists the same change twice:

* **opml:** stop dynamic OPML categories accumulating redirected feeds (fab26a6)
* **opml:** stop dynamic OPML categories accumulating redirected feeds (cb968e7)

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

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>
@coderabbitai

coderabbitai Bot commented Aug 4, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@andrewshell, you've reached your PR review limit, so we couldn't start this review.

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 2a96cec3-fb30-4864-bbce-b2bb2d47a361

📥 Commits

Reviewing files that changed from the base of the PR and between fab26a6 and 13cf6b1.

📒 Files selected for processing (2)
  • .markdownlint-cli2.jsonc
  • CHANGELOG.md

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@andrewshell
andrewshell merged commit 3be34bc into main Aug 4, 2026
3 checks passed
@andrewshell
andrewshell deleted the fix/markdownlint-changelog-headings branch August 4, 2026 00:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant