App
GitHub
We're publishing some packages which are used by our applications and as part of an improvement of the package publishing process we're now generating and including a CHANGELOG file in the package.
We thought that this would be enough to get the Release Notes section to show in the PRs created by Renovate but it turns out it's not the case. Checking other packages I realized that the release notes are probably coming from GitHub's releases page instead.
Is there a reason why the CHANGELOG file isn't used instead? I feel it would make more sense for release notes to come from a file within the package rather than the platform where the source code of the package is hosted.
We do support changelog files, but there's a number of things that could possibly be going wrong. Please answer the following:
What type of dependency is it? e.g. npm?
Where is it hosted? npmjs.com or self-hosted?
Is the source repository on github.com?
Does the package correctly reference the source repository?
What is the exact filename?
What formatting/convention are you using inside the changelog file?
We do support changelog files, but there's a number of things that could possibly be going wrong. Please answer the following:
What type of dependency is it? e.g. npm?
npm
Where is it hosted? npmjs.com or self-hosted?
self-hosted. we configured everything needed to pull from our private registry already in the renovate.json file
Is the source repository on github.com?
yes
Does the package correctly reference the source repository?
~yes~ UPDATE: no, it doesn't
What is the exact filename?
CHANGELOG.md
What formatting/convention are you using inside the changelog file?
conventional commits
@rarkins see the update above, the package.json file doesn't reference the repo (it's a monorepo btw)
So in that case Renovate has no sourceUrl to know where to look. Are you using a shared CHANGELOG.mde in the root of the monorepo or one changelog per package?
A CHANGELOG per package. What should I put in that package's package.json file to make it pick up the release notes from the CHANGELOG.md file?
thanks @rarkins, will try. so, with all that in place, Renovate should be able to generate PR release notes using the CHANGELOG.md file in the repository, right?
In theory yes, although nested changelog retrieval is definitely not something I've extensively tested. At the very least we're ready for testing and reproducing any bugs
Hi @rarkins. We tried it out and now we get a Release Notes section in the PRs for the package, so it's a step forward! Unfortunately though, we don't get the list of changes. Here's what it looks like:

The CHANGELOG.md file contains changes in the form generated by conventional changelog. Here's the top of that file (sensitive data redacted):
# Changelog
All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.
### [0.10.2](https://github.com/{...}) (2019-10-19)
### Features
* some feature ([#123](https://github.com/{...})) ([123](https://github.com/{123}))
### Bug Fixes
* some bug fix ([#456](https://github.com/{...})) ([456](https://github.com/{...}))
Can you give an example of what you鈥檙e expecting instead?
I would expect the list of changes as described in the changelog
Woke up in a bad mood today? :) Apologies, I wasn't clearer because I thought it was straightforward. I expect to see the list of features, bug fixes and so on exactly as specified in the changelog. That's among the things that allow assessing whether the upgrade is safe. Right now it only shows what is the new version number, which is superfluous as that's obvious from the PR title and th change in the package file.
Sorry, I misunderstood the part you had pasted in previously. I thought the changelog markdown content you added was already in the PR, and you were expecting more (a list of commits, etc). I deleted my comment and minimized yours.
What you're seeing implies that Renovate is not actually detecting the Changelog.md in the source repository. It looks like it's detecting the tags in the source repo and linking accordingly (please confirm that the 0.10.2 link in your screenshot links to the correct location).
It's alright, thanks for your support. The link in the screenshot links to {repo}/compare/v0.10.1...v0.10.2, not sure if that's the intended behavior. To summarize the current situation, it's all as described here except that I've now added this section in the package.json file.
Without that, no Release Notes section was appearing in the Renovate PR.
With that, now there is a Release Notes section as shown in the screenshot but no summary of changes (features, bugs, ...)
Hi @rarkins, I'm posting an update because the appearance of the release notes unfortunately seems to have been triggered by us publishing a Release to GitHub, and indeed the Changelog file doesn't seem to be picked up. We were trying several things and at some point we published a release. For the next version bump we didn't publish the release and the release notes in the Renovate PR have disappeared again, meaning that indeed it's not picking up the Changelog. Other ideas?
We might only be able to solve this after reproducing it publicly so that it can be debugged from the CLI. Before then though, it might be easier for you to reproduce it internally and share the logs. Can you do this?
package.json depending on the same package and out of date versionHi @rarkins, thanks for your support so far. Here's a repro on a public repository.
Note: Version bump only for package root
whereas it would say
Note: Version bump only for package renovate-monorepo-package
if Renovate was picking them up from the nested package's changelog file.
I hope this helps troubleshoot the issue
Thanks for reproducing it. I have now moved it into the main repo as it seems we need code changes and not config changes.
I think the logic error occurs in here: https://github.com/renovatebot/renovate/blob/abe166e69af432cdc1ac4453c1eb6b64a0639053/lib/workers/pr/changelog/release-notes.js#L141-L158
It needs to be adapted to consider the sourceDirectory first, if present.
Thanks for looking into this @rarkins.
From what I see in the code nested changelog files don't seem to be supported. I've set up renovate locally to see if I could contribute an improvement, but it looks like this would be an entirely new feature, and I'm not sure how to go about it. The function you linked to above probably needs to be modified quite a bit to account for nested packages, so it would have to have knowledge of monorepos and the specific package manager.
I am easily missing something as I'm not familiar with the Renovate codebase, but a straightforward implementation would require to look into the specific package we're trying to bump, read its package.json file, figure out what is the path of the package in order to pick up the right CHANGELOG file. But surely there is more complexity than this to make sure that we're staying compliant with tech stacks other than Node.js.
@simoneb I was hoping that there would be a variable sourceDirectory passed through to the changelog step that can then be used to directly look for the changelog. I'll try to debug your example to see if that's true
@simoneb are you using git, git+https or https? in your repository declaration in package.json?
@simoneb are you using
git,git+httpsorhttps? in your repository declaration inpackage.json?
A mix of the various options across different repositories. Is there one option that is expected to work?
I could update the repro to include that and see if it works.
If the change log is only in the published npm package will renovate discover this and use it for the release notes, or does it reach out to the source repository and extract it from there? In my scenario, the CHANGELOG is not sourced, and only exists in each package distribution on the registry.
Only the source repo. We don't download/extract artifacts from registries
Most helpful comment
Hi @rarkins, thanks for your support so far. Here's a repro on a public repository.
whereas it would say
if Renovate was picking them up from the nested package's changelog file.
I hope this helps troubleshoot the issue