Release notes: packages sharing one sourceUrl lose their notes and can be attributed to the wrong package

[nicoa]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

44.96.2

Please tell us more about your question or problem

When several dependencies in one PR resolve to the same sourceUrl — the normal case for a monorepo that publishes many independently-versioned packages — Renovate treats them as one package for release-notes purposes. Two independent places key on the repository rather than on the package, which produces two distinct user-visible bugs.

Bug 1 — only the first package's release notes are rendered.

lib/workers/repository/update/pr/index.ts:

function getRepoNameWithSourceDirectory(upgrade: BranchUpgradeConfig): string {
  return `${upgrade.repoName!}${
    upgrade.sourceDirectory ? `:${upgrade.sourceDirectory}` : ''
  }`;
}
...
if (
  logJSON.hasReleaseNotes &&
  upgrade.repoName &&
  !commitRepos.includes(getRepoNameWithSourceDirectory(upgrade))
) {
  commitRepos.push(getRepoNameWithSourceDirectory(upgrade));
  upgrade.hasReleaseNotes = logJSON.hasReleaseNotes;
  ...
}

Without sourceDirectory the key is just repoName, so the first upgrade claims the repo and every subsequent upgrade from it is left with hasReleaseNotes = false and releases = [], logged as Removing duplicate release notes by the second pass keyed on notesSourceUrl. Since changelog/hbs-template.ts only emits a <details> per upgrade with hasReleaseNotes, the other packages disappear from the PR body — even though their releases exist and were fetched successfully.

This looks intentional for deps that genuinely share one changelog, but it is wrong when the deps are distinct packages that merely share a source repo.

Bug 2 — release notes can be attributed to the wrong package.

lib/workers/repository/update/pr/changelog/release-notes.ts, in addReleaseNotes():

const cacheKeyPrefix = sourceDirectory
  ? `${repository}:${sourceDirectory}`
  : `${repository}`;
...
const cacheKey = `${cacheKeyPrefix}:${v.version}${gitRefCachePart}`;
releaseNotes = await packageCache.get(cacheNamespace, cacheKey);

The key has no package component, so two packages from the same repo that share a version number collide, and whichever populates the cache first wins for both.

This is worse than cosmetic: the notes shown are plausible but belong to another package. In our case a major bump of @scope/api displayed another package's BREAKING CHANGES section under @scope/api's version headings, with anchors pointing at the other package's tags. A reviewer reading the PR to decide whether a major bump is safe is reading the wrong package's breaking changes.

Note getReleaseNotes() itself resolves this correctly — getExactReleaseMatch() builds a package-qualified tag regex — so the wrong result comes purely from the cache short-circuiting before that runs.

Why this is not more widely reported: in a fixed-version monorepo (all packages released together at the same version, one changelog) both bugs are invisible — the de-duplicated notes really are duplicates, and the colliding cache entries really are identical. They only become visible with independent versioning (Lerna version: independent), where @scope/a@2.0.2 and @scope/b@2.0.2 are unrelated releases with different bodies and different tags.

Suggested fix — include the package in both keys:

• getRepoNameWithSourceDirectory() → append packageName/depName, or fall back to it when sourceDirectory is unset, so per-package notes survive de-duplication while genuinely duplicate changelogs still collapse.
• cacheKeyPrefix in addReleaseNotes() → include packageName, so cached notes cannot leak across packages sharing a repo and a version number.

Happy to open a PR if you agree on the shape.

Workaround we deployed: setting sourceDirectory per package via packageRules, since it is the discriminator in both keys. It is supportsTemplating: true and compiled in workers/repository/updates/flatten.ts, so it can be derived rather than listed:

{
  "matchDatasources": ["npm"],
  "matchPackagePrefixes": ["@scope/"],
  "sourceUrl": "https://gitlab.com/org/monorepo",
  "sourceDirectory": "{{{replace '@scope/' 'packages/' packageName}}}"
}

This is a workaround rather than a fix: it overloads a field meaning "where the package lives in the repo" into "cache/dedup discriminator", it changes changelog-file lookup as a side effect, and it only works where the directory layout is derivable from the package name.

Reproduction shape (our repos are private, so this is a description rather than a link): a Lerna monorepo with "version": "independent" publishing N packages, each release tagged @scope/<pkg>@<version> with a matching GitLab Release. A consumer repo depends on three of them and groups them into one PR via packageRules. sourceUrl is set for the whole scope in packageRules, because GitLab's npm registry serves only the abbreviated packument (Packages::Npm::GenerateMetadataService::PACKAGE_JSON_ALLOWED_FIELDS) and therefore omits repository, so it cannot be derived from the npm datasource. Result: one <details> block instead of three, and version numbers that exist in two packages render the wrong package's body. The shared-sourceUrl condition is what matters, not GitLab specifically.

Logs (if relevant)

Our CI runs Renovate at the default info level, so the Removing duplicate release notes debug line is not captured. The evidence below is the rendered PR body, which shows both bugs at once — I can produce a LOG_LEVEL=debug run if that would help.

Rendered PR body — three grouped majors, one notes block, wrong attribution

| Package                | Change             |
|------------------------|--------------------|
| @scope/api             | ^1.30.0 -> ^3.0.0  |
| @scope/biapp-entities  | ^2.0.0  -> ^4.0.0  |
| @scope/logging         | ^1.16.0 -> ^2.0.0  |

### Release Notes

<details>
<summary>org/monorepo (@scope/api)</summary>          <-- only one block for three packages

### [`v3.0.2`](https://gitlab.com/org/monorepo/tags/@scope/api@3.0.2)
### [`v3.0.1`](https://gitlab.com/org/monorepo/tags/@scope/api@3.0.1)
### [`v3.0.0`](https://gitlab.com/org/monorepo/tags/@scope/api@3.0.0)

### [`v2.0.2`](https://gitlab.com/org/monorepo/tags/@scope/logging@2.0.2)   <-- wrong package
#### 2.0.2 ... **Note:** Version bump only for package @scope/logging

### [`v2.0.0`](https://gitlab.com/org/monorepo/tags/@scope/logging@2.0.0)   <-- wrong package
* feat!: bump pino to 10.3.1 in @scope/logging and @scope/api
##### BREAKING CHANGES
* pino moves from 8.x to 10.x ...                 <-- another package's breaking changes,
                                                      rendered under @scope/api's heading
</details>

@scope/api has its own 2.0.0/2.0.1/2.0.2 releases with different bodies; they were never shown. @scope/biapp-entities and @scope/logging have complete GitLab Releases for every version in range and got no block at all.

[jamietanna]

Thanks for the report - please re-shape it into our template so it's easier for us to triage!

[github-actions[bot]]

Hi there,
We notice that the Discussion you've created doesn't quite follow our template.
Please update the top-level comment in this Discussion to follow the structure of the template.
This improves the maintainers' time to triage, as key information is clearly indicated in the format we expect.
Thanks, the Renovate team

[nicoa]

Reshaped into the template - thanks. Renovate 44.96.2, self-hosted CLI on GitLab.

Our repos are private so I could not attach a public reproduction; I added the reproduction shape and a rendered PR body showing both symptoms instead, and I am happy to do a LOG_LEVEL=debug run if you want the Removing duplicate release notes line captured. Also glad to open a PR if the suggested keying looks right to you.