feat: add 'dotnet' monorepo

[jeremyhayes]

Changes:

Adds dotnet monorepo to config preset.

• https://github.com/dotnet/aspnetcore
• https://github.com/dotnet/efcore
• https://github.com/dotnet/extensions
• https://github.com/dotnet/runtime

Dotnet package releases are coordinated across several repositories.

• e.g. https://github.com/dotnet/core/releases/tag/v3.1.12

Documentation (please check one with an [x])

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

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added unit tests, or
• No new tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

We reserve the category "monorepo" for packages which are developed together and usually must be updated together, often with sync'd versions between packages.

Packages which some people would like grouped, or even many people - but not all - are fine to have a group:* entry in our presets but shouldn't be added as a monorepo. Which is it in this case?

[jeremyhayes]

It may be both. 😄

Individually, I think these repositories meet the "developed and updated together" definition of monorepo.

However dotnet has monthly releases coordinated across several repositories. I can't attest that every package is released every time. There are dependencies across these repositories - major/minor updates typically should be an all-or-nothing affair.

As an example of a coordinated release, here is the package list for yesterday's v3.1.12 release. As you can see, this is a substantive list of packages that, when renovated individually, can drown a CI system. Note that this list is a superset of the repositories currently in this PR.

• https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1.12/3.1.12.md#packages-updated-in-this-release

That said, I'm fine refactoring this to an opt-in group if that is more appropriate for renovate's built-in presets. One thought would be to "monorepo" the individual repositories, then a group/packages preset to opt-in to a consolidated group.

[rarkins]

Great, thanks. So do I understand it correctly that with the grouping you propose, the packages would all have a 3.1.12 version? If so then that's definitely criteria to classify this as a monorepo in Renovate terms. What I wanted to avoid was to group together packages that are only loosely related and could be upgraded separately if users preferred, but it sounds better to default to grouping them

[jeremyhayes]

Yep, everything in the proposed group shares a version. Here's a screencap of running with this config in a specific project:

[rarkins]

Thanks for taking the time to clarify

[renovate-release]

🎉 This PR is included in version 24.44.0 🎉

The release is available on:

• GitHub release
• 24.44.0

Your semantic-release bot 📦🚀