Let groovy know whether github hasn't checked the mergeability of a pull request

[ha5la]

The mergeable flag can be null while github hasn't yet decided if the PR is mergeable or not.

See https://github.com/eclipse-egit/egit-github/blob/a30aa361f65d5ccbaca1aedd12651ff2636a3ed9/org.eclipse.egit.github.core/src/org/eclipse/egit/github/core/PullRequest.java#L98-L99
See https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#get-a-pull-request

Testing done

I tested this manually on a local jenkins instance. I couldn't make github return a response with missing mergeable flag but I made sure that my change doesn't break the normal workflow when the flag is present with a value of true or false.

I also added an integration test that runs automatically.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[efip-ns]

It's true that mergeable flag can suddenly turn into null while GitHub is busy determining the mergeability of the pull request.

In my testing, curl to {repo}/{owner}/pulls/{id} API repeated each second:

{"merged":false,"mergeable":true,"mergeable_state":"unstable"}
{"merged":false,"mergeable":true,"mergeable_state":"unstable"}
{"merged":false,"mergeable":true,"mergeable_state":"unstable"}
{"merged":false,"mergeable":true,"mergeable_state":"unstable"}
{"merged":false,"mergeable":null,"mergeable_state":"unknown"}
{"merged":false,"mergeable":true,"mergeable_state":"clean"}
{"merged":false,"mergeable":true,"mergeable_state":"unstable"}
{"merged":true,"mergeable":null,"mergeable_state":"unknown"}

So the mergeable flag turns into null several seconds before the PR is merged by the pipeline.

With that, I think that simply reflecting this fact by changing boolean to Boolean (and so, allowing nulls) may be not the best course of action.

Most of the code written till this stage is either

if (pullRequest.mergeable) { /* merge it */ }

or

if (!pullRequest.mergeable) { /* throw the towel with error */ }

One can easily see that adding a possibility of null will, for all intents and purposes, be treated by the existing code as if it was false.

I would suggest, in case the mergeable state turns into null, instead sleeping for a second or two and retrying, once or twice. In case it insists on staying null, return that.