Skip to content
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

Added review-bot to fine tune review requirements #1673

Merged
merged 7 commits into from
Sep 28, 2023
Merged

Conversation

Bullrich
Copy link
Contributor

Created a Github Action that uses the Review-Bot app to require more fine tuned requirements to review pull requests before allowing the PR to be merged.

This uses 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:

The most important features are:

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](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.
Added rule which allows the audit team to lock particular important changes when they were created by someone who does not belong to the core-devs team

This resolves paritytech/pr-custom-review#136
Added protection to review bot file which would keep this file from being modified by unknown parties. Added `opstooling` as a required team to ensure that this file does not break
@Bullrich Bullrich requested a review from a team as a code owner September 22, 2023 09:38
@Bullrich Bullrich self-assigned this Sep 22, 2023
@Bullrich Bullrich requested a review from a team as a code owner September 22, 2023 09:38
@Bullrich Bullrich added the R0-silent Changes should not be mentioned in any release notes label Sep 22, 2023
@paritytech-ci paritytech-ci requested a review from a team September 22, 2023 10:12
@Bullrich
Copy link
Contributor Author

Question for the reviewers:
I set the label to R0-silent and didn't write a .prdoc.

Was this the correct course of action? I supposed that a PR that modifies the CI system is not part of the exposed changelog.

Co-authored-by: Joyce Siqueira <98593770+the-right-joyce@users.noreply.github.com>
@Bullrich Bullrich enabled auto-merge (squash) September 28, 2023 10:10
@Bullrich Bullrich merged commit 4384c61 into master Sep 28, 2023
81 of 104 checks passed
@Bullrich Bullrich deleted the bullrich/review-bot branch September 28, 2023 10:59
@kianenigma
Copy link
Contributor

re. both this and paritytech/pr-custom-review#136, I don't get why there is no way to circumvent a change that is purely aesthetic and should not be audited?

@kianenigma
Copy link
Contributor

Okay, I found that all core-devs is capable of skipping the rule.

two comments:

  1. allowing all core devs to skip the check is basically equal to removing the check. All developers in engineering are in the core devs team. If everyone has the key to something, then no one has the key to that. If everyone can skip this, what is the point of having it?
  2. tbh I kinda liked the label based approach a bit better in the sense that when I was reviewing a PR I could see at a glance if the author is gonna wait for an audit or not. How can I do that now?

@Bullrich
Copy link
Contributor Author

Bullrich commented Oct 2, 2023

  1. allowing all core devs to skip the check is basically equal to removing the check. All developers in engineering are in the core devs team. If everyone has the key to something, then no one has the key to that. If everyone can skip this, what is the point of having it?

I believe that this was intentional. If I am not misinterpreting @the-right-joyce, she wants to audit only PRs made by external people, and ignore ones from internals.

  1. We can still provide such request. I'm currently working on a side project for the security team, and adding a label would be a minor task.

@kianenigma
Copy link
Contributor

kianenigma commented Oct 2, 2023

I believe that this was intentional. If I am not misinterpreting @the-right-joyce, she wants to audit only PRs made by external people, and ignore ones from internals.

This is too lenient, IMO. All PRs done internal or external, if they will insignificantly alter the Polkadot runtime down the road, must be audited.

@mordamax
Copy link
Contributor

mordamax commented Oct 2, 2023

@kianenigma isn't Polkadot runtime going to be removed quite soon?

@kianenigma
Copy link
Contributor

It is already technically removed, but it doesn't change anything about the rule. Some pallets and codes and configs are used in the Polkadot runtime in the fellowship, some or not.

@0xJayPi
Copy link

0xJayPi commented Dec 19, 2023

It looks like this bot introduced SRLabs as a required reviewer, which is blocking merging of some PRs atm. I understand this was an unexpected behaviour. Could you confirm?

@mordamax
Copy link
Contributor

@0xJayPi it was intended behavior at some level, please refer to paritytech/pr-custom-review#136

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R0-silent Changes should not be mentioned in any release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a rule for SRLabs audits
7 participants