Add workflow for marking (and unmarking) merge conflicts

[oscargus]

References to other Issues or PRs

Brief description of what is fixed or changed

Using this action, PRs with merge conflicts will be automatically marked (and unmarked when fixed). It is not so obvious to test without actually merging, but Matplotlib uses it since a week at I think it really helps.

Other comments

Release Notes

NO ENTRY

[sympy-bot]

✅

Hi, I am the SymPy bot (v167). I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

• No release notes entry will be added for this pull request.

Click here to see the pull request description that was parsed.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->


#### Brief description of what is fixed or changed

Using this action, PRs with merge conflicts will be automatically marked (and unmarked when fixed). It is not so obvious to test without actually merging, but Matplotlib uses it since a week at I think it really helps.

#### Other comments


#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
NO ENTRY
<!-- END RELEASE NOTES -->

[sympy-bot]

🟠

Hi, I am the SymPy bot (v167). I've noticed that some of your commits add or delete files. Since this is sometimes done unintentionally, I wanted to alert you about it.

This is an experimental feature of SymPy Bot. If you have any feedback on it, please comment at sympy/sympy-bot#75.

The following commits add new files:

• 742c1ab:
  • .github/workflows/checkconflict.yml

If these files were added/deleted on purpose, you can ignore this message.

[oscarbenjamin]

Will this apply retrospectively?

[oscargus]

Yes. It goes through all the PRs and updates the flags every time it is executed. (So seemingly a bit inefficient after the first run, but I guess that PRs actually can un-conflict without being modified).

[oscargus]

253 PRs marked

[asmeurer]

I'm unclear what exactly this does. I found a few PRs that had merge conflicts, and I didn't see any labels or additional checks on them.

[oscargus]

That's weird... My experience is that it works pretty well. Here are all that it has marked anyway: Merge conflict

[asmeurer]

Here's two random PRs I found without the label #22845 #22831

[asmeurer]

The newest PR with the label is #20033 so maybe it just ran into some API limit or something and stopped there. Hopefully it is able to mark them in future runs.

[oscargus]

The newest in that list is from Sep 1 2020 though, so maybe unlikely that there are no after that...

OK, there was a warning about maximum retries: Warning: reached maximum allowed retries

I guess that GitHub may have been slow when it was run. Took 14 minutes to not process all 574 open PRs. For Matplotlib it often takes 4 minutes to process about 340 open PRs (but recently sometimes 8 minutes). Let's give it a few more pushes to master to hopefully get through.

[oscargus]

I restarted it and it seems to have passed #20033 already after a minute...

[asmeurer]

More likely that was the script running into the API rate limits https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting. Scripts can only make 5000 requests per hour, so if each PR takes n requests it will only be able to mark 5000/n PRs. If it's able to only handle new PRs since each run, it won't be a problem, but if it has to go through every PR every time it runs it will never get to the newest PRs.

[oscargus]

Now it finished in 6 minutes. I think it waits for 120 seconds each time it fails and retries five times in total before giving up. Probably to not hit that limit too often.

402 PRs with merge conflicts in total.

[asmeurer]

I guess it is working. I noticed a similar issue reported upstream eps1lon/actions-label-merge-conflict#86. If it repeatedly gets rate limited we'll have to figure something out. Otherwise I guess it will be fine. Although I'm a little unclear just which account this gets rate limited against. Is it @eps1lon's account, or @sympy, or something else?

[ThePauliPrinciple]

Would it make sense to similarly mark PRs that have not passed the tests (yet)? Or can we already somehow search for that?

[oscargus]

I think that can make sense. Didn't find any dedicated action from a quick check though. Seems like one can, sort of, mimic that running dedicated flows for success() and failure() though: https://stackoverflow.com/questions/60453924/running-a-github-actions-step-only-if-previous-step-has-run