This might be a smidge out of scope, but I noticed for GitHub-implemented branch protection rules (like # of approvers or CODEOWNERS) have been re-implemented in bors
so users can still have them. This has the drawbacks of A) Making more code for bors
to maintain and B) requiring the feature have a similar UX to the original feature.
What if instead of implementing these things inside of bors
(which should ideally only be responsible for checking checks and merge-queueing and the like) bors
authored and advocated for the usage of a GitHub Action implementation which then could be listed in pr-status
in bors.toml
Example:
If I wanted CODEOWNERS
checks, I would set up a little GitHub Action (provided by bors
, since I don't see one in the community today) like so:
# .github/workflows/owners_check.yml
on:
pull_request:
branches: [master
name: CODEOWNERS Check
jobs:
check:
name: CODEOWNERS Check
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: bors-ng/codeowners-check@v1
and my bors.toml
would list CODEOWNERS Check
as a pr-status
.
(The same goes for # of approvers or any other GitHub-implemented branch protection check that bors
users might want)
Pros:
- Less code inside of
bors
to run - Open source action that others outside of
bors
can use and contribute to - Less configuration == less confusing for clients
- Easier to push out new features (just use a later version)
- E.g. There's a feature to see who is missing, that's easy enough to do in the action. And upgrading the action is easier than upgrading
bors
.
- E.g. There's a feature to see who is missing, that's easy enough to do in the action. And upgrading the action is easier than upgrading
- Can implement in any language
- Less permissions required by
bors
Cons:
- Something else to maintain
- Migration cost of existing users (if so desired)