Add a bot to notify people when their PR has a merge conflict

[JelleZijlstra]

The 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.

[Mariatta]

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]

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]

Or maybe should ask at core-workflow mailing list first whether we all want this bot or not.

[dstufft]

It's Apache Licensed, I just forgot to add a LICENSE file (it's in the file headers). I didn't really try to make it very modular, but PRs are accepted! Or the code for this lives in https://github.com/pypa/browntruck/blob/master/browntruck/rebase.py so you can copy it out into bedevere or something.

[chetankm-cs]

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]

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]

#187 provides a prototype of querying open PRs using GraphQL to find out which ones have the merge conflict.

Some questions:

1. 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.

2. Do we want this as daily cron job, or a webhook event?
   I don't have any preference.

3. Is this a separate app, or part of bedevere?
   Maybe easier to make it a part of bedevere, but what about rate limitations?

[brettcannon]

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]

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]

This seems obsolete, since GitHub already notifies about merge conflicts and even offer the option to resolve them from the web interface.

[erlend-aasland]

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.

[hugovk]

Closing as duplicate of #479.