Add support for configuring protected branches

[bkeepers]

Protected branches have a lot of different toggles:

• required status checks
• pull request review enforcement
• team restrictions
• user restrictions

I think all of these could be configured via something like this:

protected_branches:
  master:
    required_status_checks:
      include_admins: true  # Enforce required status checks for repository administrators.
      strict: true # Require branches to be up to date before merging.
      contexts: [continuous-integration/jenkins]
    required_pull_request_reviews: true # boolean or 'non-admin'
    teams: [team1, team2]
    users: [person1, person2]

[bkeepers]

   required_pull_request_reviews: true # boolean or 'non-admin'

I'm not crazy about this syntax. This feature basically has an on/off toggle, and then on/off for also requiring admins (see api).

Here's an alternate option:

  required_pull_request_reviews: true # on for everyone
  required_pull_request_reviews: false # off for everyone

  required_pull_request_reviews:
    include_admins: false # on for all non-admins

[patcon]

The alternative strikes me as a little nicer, fwiw :)

[jwsloan]

If we could setup protected branches this way, I think this app would be fantastic. Any idea when this enhancement might occur? Or maybe some guidance as to how someone else might make the change and get an accepted PR?

[patcon]

@jwsloan you can take a stab at it yourself, and even host your own app for testing.

Basically, each top-level key in this plugins config (repository, labels, contributors, team`) corresponds to a plugin file here: https://github.com/probot/settings/tree/master/lib/plugins

I believe that the github apps code just takes values corresponding to api endpoints in a really lightweight way, although you'll have to do your own research there. As I understand, anything in the API is scriptable via github apps framework.

So tl;dr, you'll want to create a new key for branches and wire it up according to the endpoint where protected branches happen: https://developer.github.com/v3/repos/branches/

Good luck! Someone who's written more apps can prob tell you more :)

EDIT: keep us posted here if you take a run at it!

[nnordrum]

We have a similar thing to probot/settings that support protected branches and the first enhancement was "branch protection templates". i.e. (I'm just taking OP's yaml for consistency)

protected_branches:
  templates:
  - pattern: release/*
    required_status_checks:
      include_admins: true  # Enforce required status checks for repository administrators.
      strict: true # Require branches to be up to date before merging.
      contexts: [continuous-integration/jenkins]
    required_pull_request_reviews: true # boolean or 'non-admin'
    teams: [team1, team2]
    users: [person1, person2]

You could then apply it to existing branches, or just respond to CreateEvent/branch going forward.

[jwsloan]

@nnordrum that looks great, but I feel like I'm missing something. Is that something I can make use of? If so, how?

[jwsloan]

@patcon

Would it be awful to mirror the Update Branch Protection API docs?

It seems like I could just write a class with a sync() function that turns this yaml into JSON, and passes it directly to the API call. Am I missing something?

branches:
  master:
    protection:
      required_status_checks: 
        strict: true
        contexts: []
      enforce_admins: true
      required_pull_request_reviews:
        dismissal_restrictions:
          users: []
          teams: []
        dismiss_stale_reviews: true
        require_code_owner_reviews: true
      restrictions:
        users: []
        teams: []

[nnordrum]

@jwsloan that's what I did 👍 #superlazy

[bkeepers]

Would it be awful to mirror the Update Branch Protection API docs?

That would be ideal, IMHO.

[stale]

Is this still relevant? If so, please comment with any updates or addition details.

[travi]

i see a number of the more complex options for protected branches detailed out above, but my most common use case for simple repos is to simply mark it as protected so no one can accidentally force push. what might that simple configuration look like?