Consider managing repo settings via GitHub's probot app

[patcon]

GitHub has an app that we can auth on the repo and use to manage/sync repo settings through the PR process, just like we would with any code change. Can be nice way to change things using the same process everyone already understands: labels, branch protection, repo description, topics, collaborators, etc

App: https://github.com/apps/settings
Code: https://github.com/probot/settings

This just imports current settings into a config file, and doesn't change anything.

I'm mainly intending this as a check-in on whether this app would suit upstream pol-is org. I'm not intending this yet as a place to change settings, though that's certainly something to do later.

cc: @colinmegill @metasoarous

To Do

• decide if this app is ok for upstream
• auth app against this repo https://github.com/apps/settings
• document (CONTRIBUTING.md?)
• merge PR

[patcon]

Also, no urgency on this

[crkrenn]

+1 on consideration. neutral on implementation now.

This seems reasonable. And because of the warning below, there is a tension between making management easier using probot with a core set of fully trusted maintainers and making management easier by giving a larger group of maintainers limited push access. That's not my call.

Best of both worlds would be to follow the repo and implement when the team limitations are implemented.

WARNING: Note that this integration inherently escalates anyone with push permissions to the admin role, since they can push config settings to the master branch, which will be synced. In the future, we may add restrictions to allow changes to the config file to be merged only by specific people/teams, or those with admin access (via a combination of protected branches, required statuses, and branch restrictions). Until then, use caution when merging PRs and adding collaborators.

[patcon]

Thanks chris!

WARNING: Note that this integration inherently escalates anyone with push permissions to

Note that turning on "branch protection" addresses this vulnerability -- can set repo so pushers can't change master without going through PR with review& approval from others. Without that precaution, the escalation of push to admin does happen.

I'll give upstream maintainers a chance to weigh in.

EDIT: What we could add for branch protection:

branches:
  - name: monorepo
    protection:
      required_pull_request_reviews:
        required_approving_review_count: 1
        dismiss_stale_reviews: false
        dismissal_restrictions: {}
      required_status_checks: null
      enforce_admins: true
      restrictions: null