Feedback wanted: what's on your wishlist?

[jamietanna]

We (the Renovate maintainers) are looking to get an additional gauge of what's important to the community in terms of planned features/bug fixes.

In addition to our understanding of the needs of the community, requests from Mend's customers and the wider package management ecosystem, we'd like to see if we're missing any other signals.

Please follow the template below when commenting.

Please share a URL to an Issue/Discussion to more easily categorise the replies.
This means that it'd be very appreciated if you could ?? to see if there's already a feature request raised for it.

Template:

I am a (select multiple if appropriate):

- [ ] user
- [ ] person in a security-focussed role
- [ ] person in a legal-focussed role
- [ ] self-hosted administrator

<!-- NOTE: please only submit one distinct request per comment -->
Issue/Discussion I am interested in being implemented:

Why am I interested in this? <!-- This is optional, if you feel it's fairly self-explanatory - but additional context would be appreciated to help understand the needs -->

If someone has already posted the Issue/Discussion you're interested, please add an upvote to their comment. If there is any additional context you'd like to share about it, please add it in the threaded replies.

(Note that responding to this Discussion isn't definitely going to get it on our roadmap, but it'll help if we see a significant set of interest in a feature/bug that we've not seen indicated in other data before)

[Sironheart]

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Issue/Discussion I am interested in being implemented:
#38024

Why am I interested in this?
Especially in bigger ecosystems, the extends or the nestings/merges of different configurations, either from a central management or a per-repo, can be quite exhausting to understand/follow along.

Having a single point to look up the final position would be incredible. You wouldn't have to rely on having access to the pipeline logs or need to store them for some time to follow changes in those. You could enter the issue and see the most previously applied configuration. Having all information on a per-repository basis would be insanely valuable for (first) sanity checks.

[mschoettle]

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Issue/Discussion I am interested in being implemented: Config migration that keeps comments/formatting in JSON5/JSONC files (I am struggling to find the relevant issue, most relevant might be #27972)

Why am I interested in this?

We currently use JSON5 files to configure Renovate. We did this to use comments. I see that JSONC is supported now but there doesn't seem to be a way to use .jsonc files out-of-the-box. We've had to apply config migrations a few times but could not merge the PRs, and looking at the diff it was difficult to see what actually needed to change.

[guerda]

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Issue/Discussion I am interested in being implemented:

It would be great if Mend Renovate Cloud would support Codeberg.

Why am I interested in this?
Codeberg is a great repo hosting service which is less dependent on US services and it would be great if Mend Renovate would be usable with Codeberg too.

[guerda]

Ah, sorry, I meant the Developer Platform hosted by mend.io: https://developer.mend.io/

[SchroederSteffen]

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Issue/Discussion I am interested in being implemented:

• Renovate not creating PRs to update npm security vulnerabilities by Dependabot #28451

Why am I interested in this?
In most NPM projects, there are way more transitive security vulnerabilities reported than for direct dependencies.
As Renovate is not able to create PRs for transitive dependencies, this means that Renovate provides only little use to solve security updates.
We always have to manually trigger full lock file maintenances that bring in more updates than required.
Considering the recent increase in reported security vulnerabilities, it would be great if Renovate would support transitive security-related updates.

This was supported in the past but got removed:

• feat(npm)!: drop transitiveRemediation option #27985

[gaeljw]

transient transitive (for clarity :) )

[gaeljw]

This is not specific to NPM though. I guess it could make sense in most managers that support the ability to "override" a transitive dependency version (Maven/SBT would support that).

It means Renovate have knowledge of the transitive graph though. I guess it has with NPM lock file but not without specific manager knowledge (Maven/SBT dependency tree command to run/analyze).

I'm just thinking out loud :)

[SchroederSteffen]

transient transitive (for clarity :) )

Thank you! I edited my comment.

[carlos-lehmann]

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Even tho it's mentioned here, that Renovate don't and won't approve it's own MR, I'd like to mention it here that we'd like to work with CODEOWNERS in a self-hosted Gitlab. There's no open issue for it I'm afraid.

[rachelf42]

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Issue/Discussion I am interested in being implemented: organization level dashboard

Why am I interested in this?

i run my homelab in a micro-repo architecture, so have many different repos all with their own renovate dashboards

it would be great if i had a centralized place i could go to see a summary of all repos's dashboards for everything under my gitlab group, just to keep an eye on things

[gaeljw]

+1

I haven't tried it yet but I was planning to use https://github.com/mogenius/renovate-operator which includes such a dashboard (I think?)

[jamietanna]

From a Renovate CLI point of view, this isn't something we'll be looking at doing

For Renovate Self-Hosted Enterprise ("EE") this is something on the product backlog, and it's still undecided if this will land in the Self-Hosted Community, but it's likely!

[jankatins]

As a user, I implemented delayed updates. I want a knob to have CVE fixing security updates override that delay and such PRs should be created right away. Why: currently we have to fix CVE problems (because our pipeline will refuse such dependecies) but I can't use renovate to because it has the 10 days delay. So I have to update manually :-(

[jamietanna]

@jankatins delayed update in what sense? Using schedule or minimumReleaseAge?

[jankatins]

Minimum release age

But schedule would also be nice: currently we have two PR creation schedule defined in renovate and a scheduled pipeline runs every night. The renovate schedules are one weekly during the night when the scheduled pipeline run would trigger it and one schedule during day time and all days, which will trigger when one manually triggers the pipeline. Scheduling such cve fixing PRs "always" would open prs during all scheduled pipeline time, which would be a lot faster than "once a week"

[jamietanna]

Can you please raise a 'Request Help' Discussion? Minimum Release Age shouldn't apply to security updates, so we'll need to dig into it a little more to see why that's not working for you

[jankatins]

This is the first time I hear about that renovate can speed up security updates. Is there something I have to configure to get faster updates for security issues?

[jamietanna]

Nope, it should ""just work"" https://docs.renovatebot.com/key-concepts/minimum-release-age/#what-happens-to-security-updates - if you can raise a Discussion, we can investigate further

[jankatins]

As a user I would be interested in how lock file updates are working / can work with delayed updates. Currently I suspect that lock file updates do not work with delayed updates, as the package manager is not aware of delayed updates (or at least some are or are not configured to delay updates) and so would update directly to the latest version.

I would like to have a clear statement in the docs per package manager how delayed updates and lockfile updates work in such a case and if this does not work (= packages would be installed right away), it would be nice to get a workaround or at least a config to disable lockfile updates in such a case?

[jamietanna]

https://docs.renovatebot.com/key-concepts/minimum-release-age/#which-update-types-take-minimumreleaseage-into-account might cover this for you? We're also working on a more "in depth" docs for lockFileMaintenance generally which hopefully can explain this in more detail too

[cswilliams]

I'd love to see on the Dependency Dashboard how old a particular update is. I use minimumReleaseAge to prevent new updates but can't get any visibility on the dashboard about when a particular update may thaw out.

[wrslatz]

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Issue/Discussion I am interested in being implemented: #24849.

Why am I interested in this? Without this feature, projects using images with specific OS versions in the compatibility segment will eventually stop receiving updates from Renovate. This is unexpected and confusing for users I have worked with before, since the compatibility portion of the overall version itself can contain version information, and users expect it to be updated. Without this, projects get left on outdated and unmaintained Docker images.

See nodejs/docker-node#2326 as a recent example: the Node.js images dropped support for Alpine 3.21 and added support for Alpine 3.23. Any projects using tags like 22-alpine3.21 currently stop receiving any updates from Renovate. I would expect Renovate to raise a separate PR updating the compatibility version. I would still expect Renovate to not modify the compatibility (i.e. not change Alpine to something else), unless done via a manual replacements config.

An edge case to consider: when a new tag version only exists with updates to both compatibility versioning and other versioning. For example, moving from 20.20.0-alpine3.21 to 20.20.1-alpine3.23, where 20.20.0 never received an -alpine3.21 update.

[mschoettle]

I wanted to add that as well so I am adding it to this thread. Another relevant discussion regarding this topic happened here: #29501

[wrslatz]

Another related request: #27012

[wrslatz]

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Issue/Discussion I am interested in being implemented: Similar to #24795, but slightly different. I would like Renovate to be able to propose an update for a dependency as part of one or more groups and by itself at the same time. Happy to file a specific discussion for this, if it would be helpful (haven't filed one yet and couldn't find one).

Why am I interested in this? I work on complex projects where dependencies need manual review before merging. As part of the review, maintainers often decide manually, by reviewing dependency changelogs and other information, which dependencies should be updated. Today, maintainers using Renovate for dependency updates deal with this in one of two ways

1. Make all updates be ungrouped, and manually pull Renovate updates together in a separate PR
2. Group dependencies and then manually edit Renovate PRs to remove dependencies that are not desired

It would be helpful if Renovate would raise PRs that both

1. Update the dependency individually
2. Update the dependency as part of one or more groups (ideally multiple groups at a time)

An example: let's say I have a project with dependencies A, B, and C. I have a group config that combines all patch updates for these dependencies. In this specific scenario, all dependencies have patch updates available but I only want to bring in the patch update from dependency B. If Renovate raised a PR for the group and then for each dependency, I could then select the specific dependency to merge.

In another example, if I wanted patch updates for A and B, but not for C, I think we would need #24795 to achieve the desired end state.

[wrslatz]

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Issue/Discussion I am interested in being implemented: Ability to orchestrate specific immediate updates across an organization with ease. Searched and did not see an existing discussion aligning to this request, so I'm happy to open one if desired.

Why am I interested in this? Enterprises often need to drive dependency updates centrally, in response to vulnerabilities or security incidents or as a central team managing updates. This feature could also be useful for open source maintainers working across many projects. Renovate's current approach being config-driven, responding to repository events, with default scheduling/rate limiting, and triggering manual updates from the dependency dashboard do not scale well for enterprises. The ability to drive an update like "immediately update, across all repositories, dependency A to version X.Y.Z" would make Renovate more useful as a central dependency management tool instead of being federated.

This may be possible today via organization-level presets, aggressive self-hosted scheduling, and custom solutions built out on top of GitHub to trigger updates via dependency dashboards and aggregate all updates via the GitHub API, but it would be ideal if this was possible via Renovate more natively.

This could align well with a feature like that proposed in #41413 (comment).

[reduckted]

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Issue/Discussion I am interested in being implemented:

Testing configurations without merging to the default branch. There are a number of discussions about parts of this, but these three would result in a full solution:

• Use config from non-default branch (No Forking) #22264
• Errors are thrown when using platform=local #36538
• Include changed files in report #36558

Why am I interested in this?

Testing configurations is the number one pain-point for me. If I make a change to a repository's configuration, there is no way to know if it works until it's merged into the default branch. If you get it wrong, you have to make another change and try again.

If we could have Renovate work on a branch that is not the default branch, then we could have it perform a dry run on that branch, which would allow us to see what it would change. This must include running post-upgrade tasks so that we can verify they are defined correctly.

The second discussion I listed (#36538) is sort of a workaround for not being able to use a non-default branch. If a local repository could be used, then we can checkout the branch we want to test in that repository and run Renovate against it, meaning #22264 wouldn't be needed.

The third discussion would make seeing what Renovate would do as a result of the configuration changes much nicer. Currently you have to dig through debug log messages to work out what has changed. Having a JSON report of all of the changes that it would make means we can easily see exactly what would change. Using a JSON report also means we could then transform it into something more readable like a markdown document.