-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support multiple commits per branch/PR #7288
Comments
@rarkins I'm very interrested by this. Configuration-wise, this could be implemented with a Implementation-wise, I have no idea if this is hard (not a TypeScript dev). |
This issue is welcoming PR to try to address this feature? |
It's tagged as status:requirements because there's a lot of unknowns here so research/advised first. PRs are welcome if that's rhetorical easiest way to explore, but will only be merged if the result is maintainable! |
That sounds like a fun weekend ahead! Thank you @rarkins ! |
FYI I believe that this would be a pre-requisite: #21558 But unfortunately we needed to revert the feature twice due to regression errors |
I have not had that much time to work on this one, it is particularly important to me, so keep it on top of my list! I was thinking that perhaps instead of doing a commit per change which becomes complex, because I have not given too much thought to all the supported technologies by Renovate but initially thinking of node and the It breaks the principle of atomic commits but it is just easier to say a big commit with a lot of changes and keep one commit and the other things we have discussed here as keeping track of n-commits and so on go away. |
Any thoughts on the above @rarkins , not the best solution but would be a lot better as a first change to start showing all the changes :)? |
It's already possible to populate the commit message body with a list of updates (https://docs.renovatebot.com/configuration-options/#commitbodytable) and does not solve this issue |
Oh, I did not know that that was brilliant! It solves my issue :) Based on that, I will shift my focus from this ticket as https://docs.renovatebot.com/configuration-options/#commitbodytable does what I need! |
I've started using renovate with grouping ( Occasionally, especially with the If each dependency update was done as a separate commit, running |
This is a featured I'd very much like to have, due to the interaction with semantic-release. It generates one entry in the release notes for each commit merged. For example: I currently have my package rules set up to combine all the patch updates together into one PR. This makes Renovate less noisy, but results in a commit message like
If Renovate did individual commits for each dependency, then I could get one PR but my release notes would still list all the individual dependencies that were updated. Best of both worlds. |
What would you like Renovate to be able to do?
Support an option to separate commits instead of having only one.
Did you already have any implementation ideas?
There are a few challenges to solve:
Changing our logic to commit multiple times in a branch instead of just at the end. Currently we build up a long list of changed files and then perform a single commit once all updates are applied.
Knowing when to split and when to join. For example, separate each updated npm dependency into a separate commit, and then the combined lock file update to yet another afterwards? Even if all the initial commits on their own would fail tests and only the last commit is a truly valid state? And what about postUpdateOptions like de-duping and tidying - combine them into the previous commit or separate them?
How to detect if a branch is modified or not. Currently we only fetch to depth 2, but depth of our commits could potentially become dozens or hundreds in theory. Perhaps it's still good enough to simply check the gitAuthor of the latest commit and assume the branch is unmodified if the author is "us"?
Are there any workarounds or alternative ideas you've tried to avoid needing this feature?
The current approach of a single commit works very well.
Is this a feature you'd be interested in implementing yourself?
Maybe
The text was updated successfully, but these errors were encountered: