Allow a GHPullRequest to set auto-merge

[roxspring]

I've been using the API to generate PRs for our main repository in a similar vein to dependabot, and would really like to be able to set those to auto-merge (which has been allowed in our repository):

ghPullRequest.requestAutoMerge();

Clearly this isn't supported by the Java API, presumably because it's not supported by the GitHub REST API either. However it is supported by via a couple (oh, the irony!) of GraphQL API queries:

query GetPullRequestID {
  repository(name: "$repo", owner: "$owner") {
    pullRequest(number: "$prnum") {
      id
    }
  }
}

mutation EnableAutoMergeOnPullRequest {
  enablePullRequestAutoMerge(input: {pullRequestId: "$pullRequestID", mergeMethod: MERGE}) {
    clientMutationId
  }
}

Rather than boiling the ocean by requesting general purpose public GraphQL support (#521), I wonder whether it might be acceptable to implement some low level GraphQL support that could be used internally to implement specific features not available in the REST API, such as enabling auto-merge on a PR. Perhaps in time this could become the basis for some general support but the immediate goal would be to enable access to APIs.

[bitwiseman]

@roxspring
Interesting idea. If you have time to do this, PR welcome. Especially as something not exposed publicly or implemented in the internal namespace.

[seate]

@bitwiseman
May I make PR for this issue? If it is allowed, Can you give me a permission for the test of enabling auto merge of PR?

[bitwiseman]

@seate
This isn't an issue I would suggest for a first-time contributor, but you are welcome to do so.

Please go ahead and submit your PR without the recorded test data. Once you've done that, I'll grant permissions and you can record test data.

[seate]

@seate This isn't an issue I would suggest for a first-time contributor, but you are welcome to do so.

Please go ahead and submit your PR without the recorded test data. Once you've done that, I'll grant permissions and you can record test data.

Really Thanks for your grantion. I'll try hard for the PR.

[seate]

@bitwiseman
I'm sorry to border you. But I have a question of this issue.

I'm currently considering which approach would be better:

1. Supporting GraphQL by implementing it directly. (for example, by writing queries as strings)
2. Supporting GraphQL by using an existing library like graphql-java.

In my opinion, if the number of GraphQL APIs required is very small, directly implementing GraphQL support would be better to keep the 'github-api' library lightweight. However, using a GraphQL library offers better scalability for future expansion.

Which approach do you think is preferable? Could you give me a advise on the direction that I should take?

[bitwiseman]

The problem with using another library is that you also take on all the dependencies of that library. graphql-java has runtime dependencies on antlr and guava. If we don't have to add them, I'd rather not.

Start with the one-off style, to get the functionality added quickly.

After we get that in, then maybe propose a separate PR that shows how it would work to use graphql-java.

[seate]

The problem with using another library is that you also take on all the dependencies of that library. graphql-java has runtime dependencies on antlr and guava. If we don't have to add them, I'd rather not.

Start with the one-off style, to get the functionality added quickly.

After we get that in, then maybe propose a separate PR that shows how it would work to use graphql-java.

Ok thank you for your advise. Then I will work with 'one-off' way first