-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add review-bot to require fellows as reviewers #31
add review-bot to require fellows as reviewers #31
Conversation
Created a Github Action that uses the [Review-Bot app](https://github.com/paritytech/review-bot) to require fellows to review pull requests before allowing the PR to be merged. The user's information is fetched always from the chain after every event. It looks in the fellows data for a field named GitHub and it extracts the handle from there. This resolves polkadot-fellows#7 (you can find more information about the request there) This uses [`pull_request_target`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) for the event, not `pull_request`. This is a security measure so that an attacker doesn’t have access to the secrets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the future it would be nice to have some kind of "calculations" based on the rank. So that for example 4 rank two people get the same voting power as one rank 3 or whatever (this is just for illustration, not really put any thought into this).
Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Created a new type of rule named `fellows`. This rule has its own evaluation (currently, it is mostly a copy of the `basic` evaluation). This is done so we can add special cases for rule, as _suggested by @bkchr in polkadot-fellows/runtimes#31 (review). Removed all the ability to request a `rank` in normal rules. I believe that this is better as we now separate the concerns and simplify logic. The `or`, `and` and `and-distinct` rule didn't really apply on fellows because a higher ranking one belongs also to the lower echelons. This resolves #84 and allows us to experiment better. Also, this is technically a breaking change, but it has never been applied on any system, so it wouldn't be breaking an existing system.
Version 2.0.0 requires new types and fields. This will help us so we can develop custom rules in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. I thought for the release process we want to push a commit to ./CHANGELOG
? That should perhaps be a case and require approval from Fellows and above?
The last rule |
TBH, I feel like this idea is a wrong turn, that would make the bot more complex than it needs to be. Can we actually put some thought into it and provide usecases? |
IMO it should be a stronger hurdle than a single rank 2. Would recommend just putting it under the "Relay and system chains" requirements. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For a first version I would say it is good enough. We can improve in the future.
Created a Github Action that uses the [Review-Bot app](https://github.com/paritytech/review-bot) to require more fine tuned requirements to review pull requests before allowing the PR to be merged. This uses [`pull_request_target`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) for the event, not `pull_request`. This is a security measure so that an attacker doesn’t have access to the secrets. All the rules have been copied from the original `.github/pr-custom-review.yml` file. I want to clarify, this particular commit is **not intended to replace PRCR yet**. # Advantages it brings over `PRCR` Most of the features available in `PRCR` have been duplicated and enhanced. For a complete detailed write up, please see: - paritytech/pr-custom-review#114 -> Proposal for the rewrite - [Review Bot Documentation](https://github.com/paritytech/review-bot/blob/main/README.md) The most important features are: - `include` and `exclude` fields now accept an array, making it easier to read the regular expressions. - Ability to skip a rule - We can set that PRs coming from a particular user or team will cause the rule to be skipped. - This is used in the `Audit rule`, which was requested by @the-right-joyce. - This resolves paritytech/pr-custom-review#136 - Ability to request fellows instead of teams - As requested in polkadot-fellows/runtimes#7, this bot has the ability to request fellows by rank instead of users. - We currently have polkadot-fellows/runtimes#31 which is using that feature. Aside from all the rules available in `PRCR` I have added a particular rule to lock the review-bot files and require a review from the `locks-review` team, the @paritytech/ci team and the @paritytech/opstooling team to ensure that the file has been written correctly. ## Next steps The next steps will consist on paritytech/review-bot#53, once this issue has been resolved, and `review-bot` has worked without any issues on this repository for a while, we will upgrade it to be able to fully replace `PRCR`.
Created a Github Action that uses the Review-Bot app to require fellows to review pull requests before allowing the PR to be merged.
The user's information is fetched always from the chain after every event.
It looks in the fellows data for a field named GitHub and it extracts the handle from there. This resolves #7 (you can find more information about the request there)
This uses
pull_request_target
for the event, notpull_request
. This is a security measure so that an attacker can't steal secrets by changing the workflow fileI added an example configuration for this repository so that we can tweak each individual requirements for the files. Feel free to suggest edits to fulfill your requirements.
.github/
files.relay/kusama
orrelay/polkadot
folder with the exception of the files that end in.adoc
.system/parachains
folder.All these rules are of type
basic
. There are more types of rules available but it is intended for teams with different users, and because higher ranks also fulfill requirements for lower ranks, I thought it would be redundant to use those particular type of rules.Side notes:
.github/review-bot.yml
to a different file, there is an option to move the location.