Impossible to automate PR creation


#1

Here at Greenkeeper we couldn’t be more excited about Integrations, because we can now act on our own behalf and no longer have to use user tokens for that :thumbsup:

Greenkeeper sends automated pull requests to update dependencies and monitors compatibility by creating branches and looking at the status API results.

As soon as we heard about the announcement we started looking into what’s required to do the switch, because it would solve a lot of the many small problems that we’re experiencing with the oAuth Application.

We’ve done first successful experiments, but we’ve now hit a blocker that makes our entire use case impossible at this point.
Using the pull request API it is possible to create pull requests with only an existing base branch. Using the content API it is possible to update a file, but it is not possible to push the results to a new branch, only to the source branch.
For our current oAuth Application we’re using the Git Data API to create branches, and then create pull requests from them.
As the entire Git Data API is unavailable to GitHub Integrations it’s now impossible to change the content of a file and go through a pull request first.

I don’t think that this is a reasonable limitation, because changing the content on the default branch directly is a dangerous and unwanted thing to do, not only for bots, but also for humans. Thanks to required status checks it wouldn’t work most of the time anyway. This means the API currently supports a commonly discouraged workflow, while blocking the recommended way of going through pull requests and reviews.

An ideal solution would be to add a feature to the Content API to update a file, but push the results to a different branch. For now it would be really amazing if you could just allow the Git Data API for integrations, so we can at least use our current solution.

It would be really great to hear your thoughts on this and, if at all possible, a rough time frame on when or if changes like these could go live. I know that it’s not an easy thing to publicly communicate a timeframe, but having a rough idea would really help us decide on how to move forward here.
Integrations are really a great way to make our service work with GitHub – almost like most of the features are directly from our wishlist – but as a small company that has to focus and prioritize it would be of utmost value to know if it’s worth spending our time on Integrations now, or on the existing application – knowing that we can help improve our users experience immediately, while having to rewrite stuff for Integrations in the midterm to longterm future.

Thanks so much for you awesome work on this,

Stephan


Request support for additional endpoints for Integrations
#2

Hey @boennemann,

We do plan to enable the Git Data API for access by Integrations. As far as timeline goes, this is slated in the near-term of our roadmap.

Thanks also for sharing your thoughts around some higher-level solutions to some of the workflow you’re looking to enable. All of those sound like interesting ideas!

We’ll follow up once we’ve enabled the Git Data API to let you know.


#3

@jmilas Thanks for the reply.

We figured we’ll be using our read/write access on the git repository in the meantime. Permission wise everything the Git Data API would allow us to do is already available to us via cloning and executing git commands – just that that’s a lot of overhead.

We can’t wait to throw that code away again, and go back to the Git Data API :slight_smile:


#4

Hi @boennemann :wave:

I’ve enabled the Git Data API for integrations, and update our documentation to reflect it.

Please let me know if you run into any issues using the Git data API.

Thanks!


#5

@tarebyte Exciting news! Thanks so much.


#6

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.