Expose changelogContent in custom datasource responses

[MindTooth]

Tell us more.

Expose changelogContent in custom datasource responses

Follow-up to #35327, which added changelogContent support to Renovate datasource releases.

I have started to make wrappers that provide releases: consumed by the custom datasource. However, currently there is no easy way to create a changelog. I hope that this will fix that.

Test branch: https://github.com/MindTooth/renovate/tree/feat/custom-datasource-changelog-content

Problem

Release already supports per-release changelogContent, and Renovate's lookup/changelog pipeline embeds it in the pull request body when the selected target release provides it.

However, a custom datasource validates its transformed response with ReleaseResultZod. The per-release schema accepts changelogUrl, but not changelogContent. As a result, Zod removes changelogContent from a custom datasource response before it reaches the existing changelog pipeline.

This means custom datasources cannot use the feature that was added in #36340.

Proposal

Allow this optional field on each custom datasource release:

changelogContent: z.string().optional(),

Place it alongside changelogUrl in lib/modules/datasource/custom/schema.ts.

For example:

{
  "releases": [
    {
      "version": "1.21.2",
      "changelogUrl": "https://example.invalid/releases/1.21.2",
      "changelogContent": "### Upgrade notes\n\n- Updated the catalog bundle.\n- This release is reachable through the declared upgrade graph."
    }
  ]
}

When Renovate selects 1.21.2, the existing changelogContent handling should embed that Markdown in the pull request and use changelogUrl as its link.

Scope

This deliberately does not add generic fetching from changelogUrl, change sourceUrl handling, or add a root-level response field. It only exposes the already-supported per-release content field through the custom datasource schema.

This is useful for custom APIs that generate transition-specific release notes, including catalog/graph-based datasources where the datasource can explain why a proposed upgrade is valid.

I have a small implementation with a schema test and documentation update ready if this direction is accepted.