-
Notifications
You must be signed in to change notification settings - Fork 990
-
Notifications
You must be signed in to change notification settings - Fork 990
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
Reuse an open PR when updating a dependency instead of superseding it #2264
Comments
Makes sense to me - I don't think anyone's particularly attached to the old PRs. It's not a totally trivial change, but I should be able to get to it pretty quickly. Thanks for the feedback! |
It makes perfect sense to me too, one of the advantages is also that the assignees/reviewers are kept |
@greysteil Is it already fixed? |
It's not - this is probably a full day's work on my side. I'll get to it, but have had a bunch of other higher priorities. In the meantime, assignees and reviewers are now copied over from the old PRs. 😎 |
Another reason this would be nice to have is so that PR comments aren't lost when a new PR is opened. Sometimes I find myself leaving a PR comment to the effect of:
When the PR gets superseded by a minor version bump, the comment gets left behind. It would be handy if you could mark comments that should be carried over, but I guess maintaining a single PR is even better! |
This could also avoid unnecessary I mean generaly |
@greysteil are you still working on this? I have the exact same problem as @lewisblackwood—if I have extra context on a gem I'll leave a comment in the PR, but if the PR is superseded that comment gets lost forever. |
Thanks @feelepxyz for keeping all these tickets open despite zealous stalebot! 🙂 |
Again, more than two years have passed. Any progress on it, or is it at least still contained in the backlog? |
I don't have anything to share in terms of roadmap, it's a feature we are interested in but it's unlikely that we'll be able to take it on in the near future. One thing we'll need to think about (or just live with) is that we mention the version number in the branch that we open the PR from, this is potentially confusing. An option would be to not mention the version in branch names when this configuration option is enabled. |
One question that comes to mind for me is: Why was this system even made like this? |
Ah jeez. Yeah, I've hit this too. The existing behaviour is literally insane and meets no expectation of usability. I'm certainly not going to put my customers through getting a ton of noise from Dependabot when there's no reasonable expectation of action behind it. I'm happy to chat with whomever in product is open to a discussion, otherwise I'll have to turn down dependabot for my projects until such a time that it doesn't cause abusive notifications and issue counter increments in a repository. |
Hey there. Any updates on it? |
Any plans to enable this feature ? |
So, branches could instead be named "dependabot/npm/@types/node" and only superseded when the dependency's name changes. Somewhat surprisingly, git allows the |
And on top of that, it'd be nice if in the monthly grouped PRs, there was a way to issue a command to refresh the updates again to be the latest (instead of latest at the time of PR creation, which could be like 2 weeks ago for example). |
This feature is hugely requested by the community, is here anyone with the skills needed to implement it? |
The churn in PRs was getting annoying. If dependabot/dependabot-core#2264 is resolved, we can consider switching back to daily.
I agree. 6 years after, it's already requested. I checked if it were possible to do it myself. Sadly, I never used Ruby and it seems difficult for someone that never touch this repo, but is quick for dependabot's dev. I hope they will do it in 2024. |
Btw, |
???, the whole point of this issue from the very first comment is to stop doing exactly that |
they're a bot. I can't believe this hasn't been fixed. @jakecoffman are you going to Universe? Can we at least talk about this? |
Hi guys,
I think that when there's a new bump release on a package that has an already opened PR, you can just upgrade that PR avoiding to open a new one.
Let's see this history, that happened in just 3 days:
Bump webpack from 4.1.1 to 4.6.0 chrvadala/react-svg-pan-zoom#99
Superseded by chrvadala/react-svg-pan-zoom#101
Bump webpack from 4.1.1 to 4.7.0 chrvadala/react-svg-pan-zoom#101
Superseded by chrvadala/react-svg-pan-zoom#106
Bump webpack from 4.1.1 to 4.8.1 chrvadala/react-svg-pan-zoom#106
The text was updated successfully, but these errors were encountered: