internal/contributebot: merge in pull requests triggered by comment #687

zombiezen · 2018-11-13T18:37:59Z

Is your feature request related to a problem? Please describe.

[Go Cloud contributors sit in front of their PRs], since the process for submission is:
while branch is not up-to-date with master {
  press update branch button
  wait for Travis run to finish
}
click squash-and-merge
This loop is especially expensive, as the longer you wait, the more likely the branch is not up-to-date and thus causing the cycle to increase iterations.

Describe the solution you'd like

Contribute Bot could be in charge of merging in changes via a comment like /merge, only reporting back if the build failed. The commit message could be derived from the PR title and first comment.

Describe alternatives you've considered

We could use off-the-shelf solutions, but the amount of effort required to get them working would be roughly equivalent to just getting Contribute Bot to do it.

Solutions we found:

Bulldozer
Refined GitHub, a browser extension, but @vangent has not gotten this to work.
mergify.io
Kubernetes's Prow
Bors-NG

The text was updated successfully, but these errors were encountered:

zombiezen · 2018-11-14T19:05:12Z

/cc @ijt FYI

These events will be necessary for merges, but currently aren't used. Adding them now to clear them from the subscription backlog. Updates google#687

These events will be necessary for merges, but currently aren't used. Adding them now to clear them from the subscription backlog. Updates #687

Detailed design is still a little far away, but I want to ensure that the high-level functionality presented to the maintainers is desirable before proceeding. Updates google#687

#1009) Detailed design is still a little far away, but I want to ensure that the high-level functionality presented to the maintainers is desirable before proceeding. Updates #687

…tions Part of the merge functionality. Already added to production Contribute Bot application configuration. No-ops added in previous commits. Updates google#687

Makes RoundTrip easier to understand, but also allows the cached token to be reused for other purposes (like Git tool access). Updates google#687

WIP; DO NOT SUBMIT missing tests This is not hooked up to anything else in Contribute Bot yet. Subsequent commits will call syncPullRequest when they need to merge a pull request's branch into the pull request branch. I use a Git subprocess in gitSync for two reasons: 1. The merge process can be tested hermetically. 2. Using Git directly does not consume GitHub API quota, whereas using the [GitHub Git Database API][] would. [GitHub Git Database API]: https://developer.github.com/v3/git/ Updates google#687

Contribute Bot will use this to track pull requests that should be kept in sync with the head branch. Adding the label before Contribute Bot uses it. Updates google#687

…upstream WIP; DO NOT SUBMIT This is an incremental (but significant) step toward accomplishing google#687. It does not submit PRs, but it manages them so that they are more likely to be in a mergeable state. Since this is taking some shortcuts, I am not updating the design doc with details of this change yet, but this proves (to me at least) the feasibility of an approach where all state is stored in GitHub. Hopefully this eases enough maintainer toil that I can do design work for the remaining elements on a more relaxed schedule. When a pull request is labeled with "ready to submit", Contribute Bot calls syncPullRequest to update the pull request. Using a label makes validation easy because only users with write access to a repository can make this change. On any branch push to the repository, Contribute Bot will search for any open pull requests with the "ready to submit" label that have a base branch of the updated branch. Contribute Bot will call syncPullRequest for all the matching pull requests. If any errors occur while merging, Contribute Bot will remove the "ready to submit" label and leave a comment. This gives notification of required manual intervention. Updates google#687

…tions Part of the merge functionality. Already added to production Contribute Bot application configuration. No-ops added in previous commits. Updates google#687

Makes RoundTrip easier to understand, but also allows the cached token to be reused for other purposes (like Git tool access). Updates google#687

This is not hooked up to anything else in Contribute Bot yet. Subsequent commits will call syncPullRequest when they need to merge a pull request's branch into the pull request branch. I use a Git subprocess in gitSync for two reasons: 1. The merge process can be tested hermetically. 2. Using Git directly does not consume GitHub API quota, whereas using the [GitHub Git Database API][] would. [GitHub Git Database API]: https://developer.github.com/v3/git/ Updates google#687

Contribute Bot will use this to track pull requests that should be kept in sync with the head branch. Adding the label before Contribute Bot uses it. Updates google#687

…upstream This is an incremental (but significant) step toward accomplishing google#687. It does not submit PRs, but it manages them so that they are more likely to be in a mergeable state. Since this is taking some shortcuts, I am not updating the design doc with details of this change yet, but this proves (to me at least) the feasibility of an approach where all state is stored in GitHub. Hopefully this eases enough maintainer toil that I can do design work for the remaining elements on a more relaxed schedule. When a pull request is labeled with "ready to submit", Contribute Bot calls syncPullRequest to update the pull request. Using a label makes validation easy because only users with write access to a repository can make this change. On any branch push to the repository, Contribute Bot will search for any open pull requests with the "ready to submit" label that have a base branch of the updated branch. Contribute Bot will call syncPullRequest for all the matching pull requests. If any errors occur while merging, Contribute Bot will remove the "ready to submit" label and leave a comment. This gives notification of required manual intervention. I've changed the built container to include a copy of Git. This does bump up the container to requiring debian-slim, but I don't see a good way around that. Updates google#687

zombiezen · 2018-12-27T22:34:08Z

@vangent and I brainstormed how to move this feature forward incrementally before the holidays. Basically, this can be broken down into two major technical pieces:

Keep requested PRs up-to-date with master — call this auto-sync. This requires watching for push events and label events and performing Git merges where appropriate.
Squash and merge PRs into master when all checks pass — call this auto-merge. This requires watching for check run events, verifying that no unapproved commits slip in between the time a maintainer kicks off the submit and the merge event, and then invoking the GitHub API to merge the pull request.

Auto-merge is not very useful without auto-sync, but auto-sync is useful even without auto-merge.

I have a working auto-sync implementation ready to go. To keep the implementation simple for the first pass, the trigger is a GitHub label named "ready to submit" instead of a comment. You can see this in action on zombiezen/go-cloud-bot-test#8, one of my test PRs: I added the "ready to submit" label, I made an upstream commit, the bot merged it into the PR, and then I merged the change in manually.

My WIP branch is here: master...zombiezen:contribute-bot-merge

I'll start sending out PRs: one per commit on the branch. The first handful are small cleanups, but the last few add the real functionality. Once this is in, I'll update the detailed design with a fuller understanding of both the auto-sync and auto-merge.