Integrate with probot?

[ColinEberhardt]

https://probot.github.io/

[BPScott]

Hah, that's fortuitous timing. Hi Colin, I've recently been investigating CLAs, the options available to automate their signing and Probot over the past few days, and was about to open an issue to chat about Probot and its relation to cla-bot.

For a bit of context: I'm looking at a CLA solution for my company and I've was very impressed by cla-bot and its configurability, I do however have some concerns about hosting - I'd like to self-host the app so that we can support it in the event of any availability problems. In addition to that, integration with our existing probot deployment would be really useful to reduce operational overhead.

With those selfish motivations out of the way, I think moving cla-bot to be probot-based would be a useful move anyway as it seems like a lot of the existing thought process that has gone into cla-bot mirrors what I've saw in probot, probot offers a chance to remove some boilerplate from cla-bot and I think your experience could help the general probot team:

• All the initialization and authentication managed is by the probot framework
• All the github API calls can be made through octokit which has also been setup by the framework
• Probot offers conventions and helpers for reading configuration out of the local repo and a per-organisation repository (though the per-org repo is named .github rather than clabot-config) - This lookup is not yet done automatically, perhaps you have some thoughts on the ticket: https://github.com/probot/probot-config/issues/1
• Probot offers conventions and helpers for /doathing commands in issue comments https://github.com/probot/commands
• The Probot team are investigating how to use serverless and lambda to deploy apps (see https://github.com/probot/probot/issues/149, https://github.com/probot/serverless-lambda and https://github.com/tcbyrd/probot-lambda). Your experience with using serverless might be of relevance to them.
• Probot offers an endpoint that exposes usage stats so #63 can be closed (see https://github.com/probot/probot/pull/181)
• Octokit always follows AP redirects so #1 can be closed (see https://github.com/octokit/rest.js/pull/659)
• Probot and octokit examples all use async/await syntax so #71 can be closed

---

I have been working on a probot-based CLA helper with similar functionality to cla-bot over the past few days. If moving to be probot-based is something you're interested in for cla-hub I would be interested in helping rather than creating a similar implementation in isolation.

If I were to show you my work in progress would you be interested in working together and using that as a base?

[ColinEberhardt]

Hi @BPScott thanks for getting in touch!

I do wish I'd seen Probot earlier, it does look like it makes a number of things I've implemented manually a lot easier 🙄

I'm looking at a CLA solution for my company and I've was very impressed by cla-bot and its configurability, I do however have some concerns about hosting - I'd like to self-host the app so that we can support it in the event of any availability problems.

Just FYI, I've recently updated the project to use the serverless framework. You can now deploy your own version to AWS by simply running serverless deploy.

Thanks for pointing our the various probot features and conversations that are relevant. There is one feature that probot doesn't currently support, which you referenced https://github.com/probot/probot-config/issues/1, that is critical to cla-bot. This allows people to hide their contributor list in a private organisation-wide repo.

I'm definitely interested in moving over to probot, although I think I need to familiarise myself with that framework first - I'll give that a go in a few days time.

Thank you!

[BPScott]

Thanks for pointing out the serverless approach, I spotted the serverless newness - however unfortunately serverless doesn't fit into our existing automation and deployment pipelines, notably we've recently moved away from AWS towards Google Cloud. From a selfish my-work perspective, me reimplementing the the functionality of cla-bot and hosting it in our already-existing probot deploy is less effort than teaching people about a new mechanism of code deployment and how to maintain it :)

Regarding the support of a contributor list in a private org-wide repo, it sounds like this list is would be separate from the probot configuration files and thus using probot-config to gain access to it isn't the right approach. Octokit (the GitHub API library) provides functionality to get a given file in a repository. As Probot already provides an authenticated octokit instance it should be a case of:

module.exports = app => {
  app.on(['pull_request.opened', 'pull_request.reopened', 'pull_request.synchronize'], onPr);

  async function onPr(context) {
    /* 
      A bunch of stuff to read config, that ends up with you needing
      to get a list of contributors from a private repo
    */

    // Read data from the JSON array stored in https://api.github.com/repos/foo/bar/contents/.contributors
    const response = await context.github.repos.getContent({
        owner: 'foo',
        repo: 'bar',
        path: '.contributors',
    });

    const contributors = response.data.content;
  }
}

---

I'll try and throw up what I've done so far somewhere so you can see the general layout for a probot app.

[BPScott]

I've got a branch up and running with some initial work: https://github.com/BPScott/cla-bot/tree/v2-probot/probot-cla

That folder contains an install of probot that will listen to PR changes, and set status and comments on a PR.

It's still very rough around the edges and all the config messaging is hardcoded, but hopefully it can show you a starting point for how cla-bot could do its thing using the probot framework. I'll be adding extra functionality like config over the next few days.

https://probot.github.io/docs/development/#configuring-a-github-app contains info on how to configure the .env file with the data needed to receive hooks from a live GitHub App.