Add variable to indicate whether pull request has conflicts

[johntconklin]

This request is for a variable that indicates whether the pull request has conflicts. While the plugin can be configured to invoke the webhook based on whether the pull request has, or has no, conflicts; if it is configured to call unconditionally the conflict state is not available.

I'll explain my use case to demonstrate how this can be useful. I don't use the plugin to directly trigger any services. Instead, I have a python script that handles POST requests using the EVERYTHING_URL in the query string, reformats that as a JSON struct, and then posts that to a RabbitMQ exchange using the routing key "<PULL_REQUEST_TO_REPO_PROJECT_KEY>.<PULL_REQUEST_TO_REPO_NAME>.<PULL_REQUEST_ACTION>".

This has a couple advantages. The first is a many-to-one PUB/SUB channel, where agents/handlers subscribe to specific events they are prepared to handle. Gate builds on OPEN, RESCOPED_FROM, and RESCOPED_TO; package builds on MERGED, automated code review (Coverity, Semmle, etc.) on OPEN, RESCOPED_FROM; chatbot on most. When new automation requirements arise, all we need do is subscribe to the queue.

The second advantage is that the events are now durable. Once the python script enquques the message, we know it will get to the agent/handler. Of course, the handler needs some smarts in case the ultimate target of the agent cannot process the message (crashed, down for maintenance, etc.). In the general case it can hold of acknowledging receipt of the message until it has confirmed it's been processed.

But one drawback, as far as I can see, there is no variable that indicates whether the pull request is conflicting. That would be useful so that an agent that triggers builds could avoid doing so if the PR has conflicts.

[tomasbjerre]

A temporary solution would be to have 2 notifications right? One that triggers for conflicting and one that triggers for non-conflicting.

[johntconklin]

Indeed, that's what I'm doing now.