feat(release notes): Show release notes from monorepo

[sergVedmak]

Changes:

• fix few cache key

• UPD 11.11.2021 change summary of release notes collapsible section from repoName to depName

• UPD 11.11.2021 change summary of release notes collapsible section from repoName to repoName (depName), only if pull request updates several dependencies and some dependencies have the same repoName

• UPD 11.11.2021 change logic to deduplicate release notes

current logic: Iterate over each dependency update in pull request and compare repo source url. If there is another update with the same repo source url, hide the release notes

new logic: Each dependency update has releases with releaseNotes. When the release notes are in the process of being received, I save source of release notes in notesSourceUrl field. It can be link to changelog.md file or gihub/gitlab release api, without specifying a specific version. Then, iterate over each dependency update, get notesSourceUrl from first release notes and check that there is no another dependency with same notesSourceUrl.

Examples:

Update react, react-is, renovate in one pull request. react and react-is sources are located in monorepo, have different sourceDirectory in package.json and have same changelog source. Deduplicate release notes

Update our private packages. They are located in monorepo, have different sourceDirectory in package.json and have different changelog.md. Do not deduplicate release notes and add depName to summary of collapsible section

Context:

First problem: If there are two packages and they are located in the monorepo, only the first package will receive the update notes. Changes in cache keys fix this problem.

Second problem: Release notes are shown via collapsible section. Summary of this section is repository name. If we group two packages from monorepo in one merge request, will appear two collapsible sections with same summary.

Documentation

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

How I've tested my work

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

[sergVedmak]

related issue #10954

[rarkins]

@sergVedmak thanks for digging into this problem! Can you answer me one question:

If there are two packages from the same monorepo, and with different sourceDirectory, but the same (shared) release notes from the repo, will those duplicated release notes be both displayed, or will they be de-duplicated somehow?

[sergVedmak]

@sergVedmak thanks for digging into this problem! Can you answer me one question:

If there are two packages from the same monorepo, and with different sourceDirectory, but the same (shared) release notes from the repo, will those duplicated release notes be both displayed, or will they be de-duplicated somehow?

Yes, both duplicated release notes will be displayed. I will try to find a new solution for this case and update the pull request

[sergVedmak]

I ended up with a new solution and updated the request description. There are a description of the work of the new deduplication logic and screenshots with examples

[sergVedmak]

I ended up with a new solution and updated the request description. There are a description of the work of the new deduplication logic and screenshots with examples

@rarkins can you check my changes? (I can't re-request review)

[rarkins]

@sergVedmak I will review the code soon, thanks. Can you also describe what changes you found necessary or not necessary to make with changelog caching as a result of these changes?

[sergVedmak]

I'm not sure if I understood the question correctly. I don't think that my changes in cache keys must be in changelog(release notes)

One thing: new logic for de-duplicate with notesSourceUrl won't work correctly if there are cached release notes(without notesSourceUrl information) for some package in cache. I tested working with a clean cache

[rarkins]

So, we still need to check:

• Are any changes to changelog caching necessary due to these changes?
• Will it play nicely with a non-clean cache?

[sergVedmak]

• no
• no, it don't play nicely always. duplicated release notes may appear in some situations with non-clean cache

[rarkins]

In that case we should bump the cache key version so that existing cached notes get expired and new ones fetched and set with the new key

[sergVedmak]

can you help me to find the place, where I need to bump the cache key version?

[rarkins]

I added an example but currently on mobile so may have missed others which need to be changed too

[sergVedmak]

Thanks, I have updated one more key

[sergVedmak]

is there any news about this?

[sergVedmak]

@viceice can you check my answers to your comments, please?

[viceice]

see comments

[rarkins]

Looks ok to me, but has this final version been tested e2e in real repos?

[viceice]

Yeah, LGTM. Please do some new e2e tests.

[rarkins]

@sergVedmak please let us know once you're confident to merge, thanks

[sergVedmak]

I created two repo with same dependencies

sergVedmak/emotion-renovate#1 - PR from Renovate Github App (current behavior). Release notes shown only for first dependency

sergVedmak/emotion-renovate-2#2 - PR from local running renovate with final version of this changes . Each dependency has its own release notes

[sergVedmak]

Is the test from the previous comment enough? or do I need to check something else?

[rarkins]

Thanks @sergVedmak for a really great PR

[renovate-release]

🎉 This PR is included in version 29.30.0 🎉

The release is available on:

• GitHub release
• 29.30.0

Your semantic-release bot 📦🚀