Curry checks that committers in a GitHub Pull Request have signed Chef's CLA in Super Market.

curry.md

Curry

Curry checks that committers in a GitHub Pull Request have signed Chef's CLA in Super Market.

Intro

The general goal of curry is to verify that committer(s) opening a pull request in a Chef Inc. repo have signed a CLA. If they have signed a CLA, Super Market will leave a comment letting Chef Inc. know that the user has signed a CLA. If they have not, Super Market will leave a comment letting Chef Inc. and the committer(s) know they have not signed a CLA, while instructing the committer(s) to sign a CLA. When the Pull Request is opened, a ticket is opened in the ticket tracking system being used (in Chef's case, JIRA).

Major parts of Curry include:

• Ability for Chef Admins to specify the repositories (and projects in corresponding ticket tracking system) that notify Super Market when a Pull Request was opened and updated. This let's GitHub know what repositories it should be the hub for when sending POSTs to Super Market via PubSubHubbub.
• Handling POSTs to the Super Market API end point from GitHub when a Pull Request is opened and updated.
• Commenting on Pull Requests based upon the committer(s) CLA verification status.
• Opening a ticket in the ticket tracking system with the information surrounding the Pull Request.
• If committer(s) had not signed a CLA when the Pull Request was opened but sign a CLA, Super Market will leave another comment in the Pull Request letting Chef Inc. know that a committer has signed a CLA (and what committers still need to sign a CLA).

Flow diagram of the process.

Information

• GitHub has some awesome docs on using hooks with JSON or PubSubHubbub.

Implementation Details

• Super Market will subscribe to a GitHub repository Hub to receive POST requests at Super Market API end point when a Pull Request is created or updated in the GitHub repository. This will be using the PubSubHubbub protocol (Hubbub for short).
• There will be an interface for managing what GitHub repositories Super Market is subscribed to.
• Interfacing with JIRA (the current issue tracker) with the Jira Ruby gem to open issues when a Pull Request is opened on a subscribed repository.
• Leaving comments on subscribed GitHub repositories with the Octokit.rb gem.
• Use Sidekiq to process background jobs.

Approach

1. Spec out and develop interface for managing GitHub repository subscriptions.
2. Create API endpoint to receive Hubbub updates from the GitHub repository.
3. Handle checking committers in the Pull Request to see if they have signed a CLA.
4. Use Octokit to leave a comment on the Pull Request based upon their CLA signing status.
5. Handle when committers have not signed a CLA but then sign a CLA.
6. Use the JIRA Ruby gem to open an issue in the corresponding project.

One thing I think we should discuss with Chef:

Given that they are moving towards using LeanKit internally, it seems like JIRA is just an added layer of complexity in managing and tracking work to be done. I'm assuming Chef will be using the "Portfolio" version on LeanKit. If that's the case, then they support a really nice GitHub integration:

"Automatically add cards to designated boards as GitHub issues are created. Once cards reach the final lane or get archived, the GitHub issues are marked resolved. Configure destination boards/lanes, source item to destination card types and priorities mapping."

And since PRs also create GitHub issues, it seems like a Win/Win for reducing complexity and simplifying the workflow, not to mention reducing the barrier to entry and things for contributors to track.

Can we use the commit status API instead? I think a comment is intrusive.

Also, we probably want a batch job that goes through existing PRs and "rechecks" the status. Maybe that's a v2 though

I'm with @sethvargo on using the commit status API. Are there any reasons why we wouldn't do that and use comments instead?

As for checking existing PRs, the ideal solution might be that when a somebody signs a CLA, see if there are any open PRs that Curry has previously seen as unresolved by that user and go put a new message on them. Agreed that that's probably a v2 feature that has lots of unanswered questions.

IMO it might be preferable to leave JIRA completely out of this release, since there might be a lot of complexity around the avoidance of opening duplicate issues. All of the linking we now do between JIRA and GitHub is now manual, and it may have to stay that way for a while.

The LeanKit/GitHub integration sounds really cool, but lets learn how to make a board and use LeanKit before we get there.

Overall this all looks sound, and it a huge improvement over having a human do it.