Removed https://gitlab.com/F-Schmidt/uulm-mcp23008. This is my first library which will be renamed and restructured. The new libraries uulm-mcp23008-core and uulm-mcp23008-user (or similar) will follow soon. They will also provide examples and have a much better documentation.
Due to the limitations imposed by by using both `pull_request_target` and `issue_comment` events to trigger the
"Manage PRs" workflow, the PR diff used for the validation is procured via a GitHub API request.
It is necessary to check that the pull request state matches that of the diff, which is achieved via the `sha` parameter
of the GitHub API request used to merge. This can not be determined from the `github` context provided by GitHub Actions
to the workflow for either of the trigger events, so the pull request metadata is requested from the GitHub API at the
same time as the diff.
This situation requires different handling by the `merge-fail` job. Fortunately, the two failure causes result in
different values from the merge request workflow step's `status` output.
Previously, the "Manage PRs" workflow made a comment suggesting to resolve the merge conflict after any failure to merge
a pull request. This comment is worded in a way that makes it somewhat applicable to other causes, but still might cause
the submitter to waste time unnecessarily trying to figure out how to merge a nonexistent merge conflict when the failure
had a different cause.
The 405 response is not specific to a failure due to merge conflict, but I believe that all failures due to merge
conflict will result in a 405. This means that the check is not perfect, but will make spurious mentions of merge
conflict resolution less likely at least.
A review is requested from a maintainer any time the merge fails, so they will be able to investigate and provide
assistance if necessary.