Feedback wanted: what's on your wishlist? #41413
Replies: 13 comments 15 replies
-
|
I am a (select multiple if appropriate):
Issue/Discussion I am interested in being implemented: Why am I interested in this? 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. |
Beta Was this translation helpful? Give feedback.
-
|
I am a (select multiple if appropriate):
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 |
Beta Was this translation helpful? Give feedback.
-
|
I am a (select multiple if appropriate):
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? |
Beta Was this translation helpful? Give feedback.
-
|
I am a (select multiple if appropriate):
Issue/Discussion I am interested in being implemented: Why am I interested in this? This was supported in the past but got removed: |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
I am a (select multiple if appropriate):
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 :-( |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
I'd love to see on the Dependency Dashboard how old a particular update is. I use |
Beta Was this translation helpful? Give feedback.
-
|
I am a (select multiple if appropriate):
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 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 |
Beta Was this translation helpful? Give feedback.
-
|
I am a (select multiple if appropriate):
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
It would be helpful if Renovate would raise PRs that both
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. |
Beta Was this translation helpful? Give feedback.
-
|
I am a (select multiple if appropriate):
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). |
Beta Was this translation helpful? Give feedback.
-
|
I am a (select multiple if appropriate):
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:
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. |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
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:
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)
Beta Was this translation helpful? Give feedback.
All reactions