Closed Bullrich closed 10 months ago
Just one thing I spotted without commenting on anything else:
Lock reviews 🔒 Requests that a team reviews a PR if a particular file/files are modified. This is literally the same functionality that
CODEOWNERS
provide.
I believe that's incorrect, the 🔒 locks in PRCR refer to lines, not files.
So this functionality is not provided by CODEOWNERS
.
I remember searching for usages and remember that it was not used, however this functionality is specifically mentioned in https://github.com/paritytech/pr-custom-review/issues/104 so we should double check that.
I believe that's incorrect, the 🔒 locks in PRCR refer to lines, not files. So this functionality is not provided by
CODEOWNERS
.
Regarding this, you are right, but also the whole file after the line:
Locks touched: Lines which have a lock emoji (🔒) or any line directly below a lock emoji require
- 1 approval from locks-review-team
- 1 approval from team-leads-team
Though, this is only being used at the beginning of a the configuration files:
I remember searching for usages and remember that it was not used, however this functionality is specifically mentioned in paritytech/pr-custom-review#104 so we should double check that.
Good catch with that. I didn't notice that part.
I'm not very fond of that particular functionality because reading the whole files for the locks adds a lot of complexity, and this could be replaced with an AND
rule:
- name: Locked files
condition:
# you add the file you want here instead of adding the lock functionality
include:
- runtime/polkadot/src/**/*.rs
- runtime/kusama/src/**/*.rs
all_distinct:
- min_approvals: 1
teams:
- locks-review-team
- min_approvals: 1
teams:
- team-leads-team
Another reason for which I would comment against the lock functionality is that it could be that someone adds a comment and that would break lock the file, as the whole lock functionality is not really known.
// This functions locks the user key from third party providers 🔑➡🔒
println!("Transaction locked 🔒");
Also, you can think that a 🔓 is a 🔒 and confuse people.
Closed this phase as done
Rewrite of PR-Custom-Review
Let’s rewrite PR-Custom-Review 📝.
Why?
The code itself is very hard to maintain.
Flow of the current state of the app
This are my notes of the method [run checks](https://github.com/paritytech/pr-custom-review/blob/master/src/core.ts#L109) located in the core file. I tried to visualize the flow of the application to understand it better. ![PR-Custom-Review-1](https://github.com/paritytech/pr-custom-review/assets/8524599/0abd1455-9d4a-452f-8c3d-d35b09fb63ee)I can go in detail if you anyone wants me to (there is a flow diagram showing how it works internally) but, to summarize it:
pull_request_target
pull_request_target
runs a GitHub action in a Pull Request using the action file from the root to stop it from being affected if a malicious user modified the action file.CODEOWNERS
instead as it wouldn’t collide, have this security issue.The how:
First of all, let’s write down all the necessary uses that this app has. For this, I will use the configuration files of:
By necessary, I refer to features that are actually being used. If there is a feature it is not currently in use, I prefer to remove it and only add it if requested. I will also remove the action review file rule, as the security of this file shouldn’t be managed by the file itself.
App features
The features that are currently in use are the following:
Rules
The action allows passing a set of rules. These rules have the following fields:
BASIC
,AND
&AND DISTINCT
rules.OR
rule is not in use.Features not used
These are all features that are available but are not being used by any of the projects. For complexity’s sake, I recommend removing all that is not being used currently and only adding it if it is necessary/requested.
CODEOWNERS
provide.action-review-team
CODEOWNERS
(as it does the same thing).diff
comparison.The changes
These are the things I propose that should change and/or be improved based on the current usage, on developer experience, or that have been requested.
Verbosity
The current implementation logs aren’t straightforward to read. We will use GitHub Action’s Summaries to provide a clear text of what is missing.
Code structure
The code will be divided into different areas:
The idea is to be able to properly test only the validator or the GitHub api without needing to constantly run integration tests. With a properly defined structure and abstraction, extending the code and maintaining it will be easier.
Replace RegEx for Glob Pattern
I recommend that, for the include/exclude section, instead of having regular expressions we use instead an array glob pattern to be used. Example:
It makes the code more readable, and a glob pattern is easier to recognize than a regex.
Produce an output of users to be requested
If we decide to implement paritytech/review-bot#92 as a standalone action, we can produce an output for the job and use that job in a different step.
Obtain teams from paritytech/list-team-members
We have an action that can fetch the required team members. This could simplify the logic of the action by combining it with that other action, the same way that Stale Issues Finder uses that output.
This will allow us to easily switch the “teams” for users obtained from the chain data As requested by Gavin:
Remove the server
We can use
pull_request_target
to automatically run the action with secrets without the risk of having users trying to get out secrets.npm install && npm run build
in a PR with an action using this event.Convert action into Dockerfile
This will greatly improve the execution time. This has been done for our other GitHub actions.