GeezerVison is showing github.com — Add a bot to notify people when their PR has a merge conflict · Issue #96 · python/core-workflow
Add a bot to notify people when their PR has a merge conflict #96DescriptionThe PyPA's repos have a bot (@BrownTruck) that posts on a PR when there is a merge conflict. See pypa/pip#4293 (comment) for an example. This seems like it would be useful for CPython too. ActivityMariatta commented on May 26, 2017 Seems interesting!
Although I'm worried if commenting on the issue may be too noisy for some of us (we got way too many emails) but I like the idea of adding needs rebase label to PRs that have merge conflicts. Mariatta commented on Jun 6, 2017 I checked BrownTruck repo and it doesn't have any license file 🤔
I still think it can be useful here.
@dstufft What do you think? Could we use BrownTruck for CPython? Can it work as is? (I haven't really looked at the codebase) Thanks 😃 Mariatta commented on Jun 6, 2017 Or maybe should ask at core-workflow mailing list first whether we all want this bot or not. dstufft commented on Jun 6, 2017 chetankm-cs commented on Oct 6, 2017 Hi, I would like to take this up.
Will add code to label any new pull request with merge conflict as needs rebase.
Should the code for this go into python/bedevere or this will be a new bot ? Mariatta commented on Oct 6, 2017 In #93 (comment) there is a concern that adding such code to bedevere might cause problem with hitting bedevere's rate limit. So it might need to be a new bot/app. Mariatta commented on Oct 10, 2017 #187 provides a prototype of querying open PRs using GraphQL to find out which ones have the merge conflict.
Some questions:
-
Is it enough that the bot applies the needs rebase label? or should the bot leave a comment too?
I prefer simply applying needs rebase label, less noisy.
-
Do we want this as daily cron job, or a webhook event?
I don't have any preference.
-
Is this a separate app, or part of bedevere?
Maybe easier to make it a part of bedevere, but what about rate limitations?
brettcannon commented on Oct 10, 2017 RE: label or comment: it depends on what the purpose of this is. If it's to just know which PRs have a merge conflict through a query then a label is enough. If it's to let the PR creator know they are out of sync then a comment is necessary. If it isn't for any of that then I don't know why we're doing this since you can pull up a PR to notice if there's a conflict. 😉
As for a webhook or cron job, a webhook might be easier as it avoids us setting up a cron job, but it does mean PRs that have conflicts will be perpetually behind as GitHub figures out which open PRs actually do have conflicts versus doing it once a day when merges are quiet. Mariatta commented on Oct 11, 2017 I personally just want a label, but leaving comments will be useful to the PR author.
If people don't mind the noise, then let's do both :) ezio-melotti commented on Jun 5, 2022 This seems obsolete, since GitHub already notifies about merge conflicts and even offer the option to resolve them from the web interface. Reacted by Erlend E. Aasland erlend-aasland commented on Jun 5, 2022
This seems obsolete, since GitHub already notifies about merge conflicts and even offer the option to resolve them from the web interface.
Seems like there is no way to filter searches by merge conflict. That would be a useful feature. Reacted by Jelle Zijlstra hugovk commented on Jan 6, 2023 Closing as duplicate of #479.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|