-
Notifications
You must be signed in to change notification settings - Fork 335
feat: implement rulesets for branch protections #2168
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
base: main
Are you sure you want to change the base?
feat: implement rulesets for branch protections #2168
Conversation
Dry-run check results |
|
unfortunately there are merge conflicts 😭 |
effc88e to
a9f0337
Compare
b667d31 to
2b33998
Compare
| _org: &str, | ||
| _repo: &str, | ||
| ) -> anyhow::Result<Vec<crate::github::api::Ruleset>> { | ||
| // Return empty list for tests - rulesets not used in mock tests yet |
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.
do you want to do this in another PR?
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.
My initial idea was to submit a PR with minimum changes and improve it further based on the feedback, and write test cases. This was simple enough, so I pushed the actual test case.
Thanks for highlighting it.
|
This feature is missing:
Do you want to do these changes in another PR? |
I was thinking that when we're sure the feature is stable, we can update the docs and extend the feature to have its own standalone config. Right now, it just copies the branch protection rules without an explicit config. Sure, we can accommodate both changes in a single PR. WDYT? |
|
|
||
| /// Convert a branch protection to a ruleset with merge queue enabled | ||
| pub fn construct_ruleset( | ||
| _expected_repo: &rust_team_data::v1::Repo, |
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.
why this parameter is unused? Should we remove it?
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 variable will be used during the implementation of the bypass actor sub-property.
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.
I’m fine keeping this unused variable, since I’ll be addressing the next bypass actor–related issue right after this PR, and then the final configuration and documentation PR.
| let uses_merge_bot = !branch_protection.merge_bots.is_empty(); | ||
| let branch_protection_mode = if uses_merge_bot { | ||
| BranchProtectionMode::PrNotRequired | ||
| } else { | ||
| branch_protection.mode.clone() | ||
| }; |
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.
no repository uses merge_bot as far as I can see.
This option is not even documented. Why using it?
Maybe I'm missing something.
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.
It's used by rust-lang/rust.
| min_entries_to_merge: 0, | ||
| min_entries_to_merge_wait_minutes: 0, | ||
| }, | ||
| }); |
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.
no all repos use merge queues.
Probably merge queues should be configured from the repository toml file.
But it can be done in another pr
|
The dry run seems to work: However it would be nice if the dry run would print the ruleset itself (ie its rules etc). As an example, you can have a look at the following dry run: |
|
New dry run: |
This looks good to me. I know most of the values are default/fixed. These will be changed to a full-fledged configuration in the next PR. Thoughts @marcoieni? |
| } | ||
| } | ||
| }; | ||
| } |
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.
why this needs to be a macro vs a function taking generics for example? Maybe something we can improve in another pr
a830b7e to
de5a87c
Compare
|
There was an error while applying: Now bors is without branch protections momentarely. |
| pub(crate) id: Option<i64>, | ||
| pub(crate) name: String, | ||
| pub(crate) target: RulesetTarget, | ||
| pub(crate) source_type: RulesetSourceType, |
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 field is not present in the request, only in the response, right?
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.
The issue was enum RulesetSourceType was not using PascalCase to match GitHub's API format.
Along with this,
- I also handled the optional fields.
- Fixed some deserialization issues.
|
I triggered the workflow manually from the main branch to restore branch protections in bors |
de5a87c to
7189083
Compare
|
I have made all the fixes and run it locally; it is working. Here is the recording for reference. Screen.Recording.2025-12-19.at.10.56.21.PM.mov |
|
Thanks! I don't want to merge this on friday evening because if there are issues I can't fix them, so I will take a look on Monday morning. I hope you don't mind! Since I re-run the workflow from the main branch, the bors repo has branch protection again 👍 |

Related to #1735