feat(pr): add changelogsLocation to post changelogs as a PR comment

[jasonwbarnett]

Changes

Adds a new changelogsLocation config option with two values:

• body (default): unchanged behavior, the changelogs/release notes are part of the PR body.
• comment: the changelogs are posted as a PR comment instead, and the {{{changelogs}}} field of the PR body holds a short notice pointing at the comment.

Implementation notes:

• getPrBody() swaps getChangelogs() for getChangelogsCommentNotice() when changelogsLocation=comment, so a custom prBodyTemplate needs no changes.
• The comment is ensured under the topic Release Notes via platform/comment.ts, which already hashes content in the repo cache, so an unchanged changelog costs no API call.
• It is ensured before the "PR does not need updating" early return, because with the changelogs in a comment the PR body no longer changes when the release notes do.
• No-ops when there are no release notes (e.g. fetchChangeLogs=off), and logs instead of commenting under --dry-run.

Context

Motivation: GitHub (and other platforms) seed the squash commit message from the PR body, so today every Renovate PR that carries release notes dumps the whole changelog into the repository history.
In our monorepo we worked around this with a GitHub Actions workflow that lifts the Release Notes section out of the PR body after the fact and re-posts it as a comment.
This option makes that workaround unnecessary.

Please select one of the following:

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

Happy to open a Discussion first, or to rename the option / change its values, if you'd prefer that.

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI-generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Code, unit tests and docs were drafted with Claude Code (Claude Opus 5) and reviewed by me.

Use of AI in replying to PR comments

Who answers review comments:

• @username will read and reply directly.
• An agent will draft replies and @jasonwbarnett will read them before they are posted.
• Nobody has explicitly committed to replying.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests, but ran on a real repository, or
• Both unit tests + ran on a real repository

[jamietanna]

I'd like to see this running against a real repository, please - helps confirm what this looks like

It'd also be good to check what happens when a PR is updated (and new changelogs are added into it) - will this now update that comment?

This might also be something we need to track in the repo cache, if it's not handled automagically

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ jasonwbarnett
❌ Jason Barnett

---

Jason Barnett seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jasonwbarnett]

Done, running against a real repository with public Actions logs: https://github.com/altana-ai/renovate-changelogs-comment-demo

The workflow checks out this feature branch, installs it, and runs pnpm start against that repo with changelogsLocation: 'comment', persisting the renovate repository cache between runs.

• stage1: PRs #6 and #7 are opened, the release notes land in a Release Notes comment, and the PR body carries only the pointer.
• stage2: the version caps are lifted, so the same PRs are updated to newer versions with more release notes. The existing comment is edited in place (DEBUG: Comment updated, same comment id, now spanning v3.9.1 to v3.9.6), so no duplicate comment.
• stage2 again, unchanged: no comment log lines at all and the comment updated_at is untouched.

On the repo cache point: it is handled by the existing ensureComment wrapper in lib/modules/platform/comment.ts, which hashes the comment content into repoCache.prComments[prNumber][topic]. That is why the third run makes no API call, and it means this change needed no new cache state of its own.

The demo did catch a bug, now fixed on the branch: the comment rendered ### Release Notes twice, because the comment topic already supplies that heading while getChangelogs() embeds one as well. I split the rendering out and added getChangelogsCommentContent() for the comment path, with tests.

[jasonwbarnett]

Also checked the default path for regressions, in a separate control repository so the two runs stay clean: https://github.com/altana-ai/renovate-changelogs-body-demo

Same feature branch, same fixture, same workflow, with changelogsLocation left at its default.

• stage1: PRs #1 and #2 open with the release notes in the PR body, under the usual --- separator and ### Release Notes heading. Zero comments on either PR.
• stage2: the caps are lifted and the bodies grow to hold every intermediate release note (prettier v3.9.1 to v3.9.6, zod v4.3.1 to v4.4.3). Still zero comments.

At the unit level, the getChangelogs() inline snapshot is unchanged by the refactor, so the body output is byte for byte what it was before.

[jasonwbarnett]

For completeness, what the demos actually do.

Each workflow_dispatch run checks out this branch, installs it, restores the renovate repository cache from the previous run, and runs pnpm start against the demo repo at LOG_LEVEL=debug. Nothing is mocked: real PRs, real comments, real API calls.

The fixture pins prettier@3.9.0 and zod@4.3.0. A workflow input picks the stage, which only changes how far renovate may bump them: stage1 caps them with allowedVersions, stage2 removes the caps, so the existing PRs get more release notes than before.

That gives four cases:

1. create, stage1 with changelogsLocation: 'comment',
2. update, stage2 on the same PRs, the case you asked about,
3. no-op, stage2 repeated with nothing changed,
4. default, stage1 then stage2 in the control repo with the option unset.

Results and per-run links are in each repo's README.