Empty release notes in MRs for gitlabci include: component updates

[chauncey-garrett]

Summary

Renovate MRs that update include: component: references in .gitlab-ci.yml show an empty Release Notes section — just the Compare Source link, no body — even though the target component project has both a populated CHANGELOG.md and GitLab Releases with rich descriptions.

Example of what the MR body looks like (generated by Renovate for a @1 → @2 component bump):

### Release Notes

<details>
<summary>group/project (group/project)</summary>

### [`v2.0.0`](https://gitlab.com/group/project/compare/1.2.4...2.0.0)

[Compare Source](https://gitlab.com/group/project/compare/1.2.4...2.0.0)

</details>

Expected: a body containing the release description (or CHANGELOG.md section).

Environment

• Renovate 41.x (Mend-hosted GitLab bot)
• Target component project is private, on gitlab.com
• MR label confirms datasource: renovate datasource::gitlab-tags
• Manager: gitlabci (the component is referenced via include: - component: $CI_SERVER_FQDN/group/project/component@1)
• Component project has: CHANGELOG.md at repo root, GitLab Releases with tag-based descriptions (created by the release: keyword)

What I looked at (source reading only)

I have not produced a confirmed minimal reproduction yet — these are observations from reading the source. Happy to produce one if this is interesting enough to pursue.

• lib/modules/manager/gitlabci/extract.ts correctly parses include: - component: …@ref and emits a dep with datasource: gitlab-tags, depName: <projectPath>, registryUrls: [https://<fqdn>]. sourceUrl is not set on the dep, but…
• lib/modules/datasource/gitlab-tags/index.ts:57 populates sourceUrl in the ReleaseResult via getSourceUrl(packageName, registryUrl).
• The lookup code (lib/workers/repository/process/lookup/index.ts:197–210) copies sourceUrl from the datasource result to the branch upgrade config.
• GitLabChangeLogSource is registered in api.ts, and lib/workers/.../changelog/gitlab/index.ts has both getReleaseNotesMd (changelog file) and getReleaseList (Releases API) implemented.

So the infrastructure looks wired up. I could not pinpoint from source alone which path is short-circuiting for this dep type. Candidates I considered but could not confirm:

• getReleaseNotesMd finds CHANGELOG.md but the heading-match loop in release-notes.ts:370–438 fails because release-it-generated changelog headings are ## [2.0.0] - 2026-04-16 (bracketed), and the title.includes(version) check against tokens split by space might not match in some cases.
• The Releases API call succeeds but getExactReleaseMatch / fallback in release-notes.ts:161–185 fails because the Releases API tag_name is a bare 2.0.0 with no depName prefix.

I may be wrong about both. Both are speculative.

What would help

If a maintainer can point at the most likely failure path for this exact setup (gitlabci + gitlab-tags datasource + target project has both CHANGELOG.md and GitLab Releases), I can build a minimal reproduction and file a focused PR. Without that, I'd be guessing.

AI assistance disclosure

Source reading and this discussion draft were done with Claude (Anthropic). Conclusions are from reading the code — I have not run Renovate locally against a reproduction. Claude also flagged one candidate root cause (partial-version handling in semver-partial.isGreaterThan) that on deeper review did not hold — including this for transparency in case it saves someone a detour.

[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