Conversation
| "Frontend / Lint", | ||
| "Frontend / Test", | ||
| ] | ||
| required-approvals = 0 |
There was a problem hiding this comment.
It was already present in the branch protection. See #2046
docs/toml-schema.md
Outdated
| # GitHub App IDs that are allowed to bypass the branch protection rules. | ||
| # The app ID can be found via the GitHub API (GET /orgs/{org}/installations). | ||
| # (optional) | ||
| bypass-app-ids = [2201425] # workflows-crates-io |
There was a problem hiding this comment.
for simplicity, I put directly the ID, to avoid having another rest API to call GitHub to query for the ID.
Also, this app is only used in crates-io, so I thought adding an enum between app name and ID was overengineering. We can refine this later if needed.
You can see from the screenshot of the issue linked in the PR body that this app is in the bypass list.
There was a problem hiding this comment.
Tbh I would rather add the enum variant to document what are all the integrations that we care about (and hardcode the app ID in code, same as we do for bors and Renovatebot).
fa95128 to
c6e6481
Compare
Dry-run check results |
| OrganizationAdmin, | ||
| RepositoryRole, | ||
| Team, | ||
| DeployKey, |
There was a problem hiding this comment.
39525b0 to
5bedc6d
Compare
| crates-io = "write" | ||
|
|
||
| [[branch-protections]] | ||
| name = "main" |
There was a problem hiding this comment.
adding this to minimize the sync team dry run diff
44eeeb4 to
c7b6732
Compare
docs/toml-schema.md
Outdated
| @@ -429,6 +433,19 @@ allowed-merge-teams = ["awesome-team"] | |||
| # When "homu" is used, "bors" has to be in the `bots` array. | |||
| # (optional) | |||
| merge-bots = ["homu"] | |||
There was a problem hiding this comment.
@Kobzol one doubt I have: does it makes sense to have merge-bots and bypass-app-ids separated?
There was a problem hiding this comment.
No, I don't think so. I would suggest merging (:laughing:) merge-bots and bypass-app-ids into allowed-merge-apps, to mirror the already existing allowed-merge-teams.
There was a problem hiding this comment.
If I delete merge-bots than retrocompatibility becomes a mess. I.e. I need to change all repos files 🤔
Should we do it in another PR?
Should I momentarely add this github app in "merge-bots"? and then rename it in a separate PR?
There was a problem hiding this comment.
merge-bots is currently used only on rust-lang/rust and nowhere else, so I don't see why we would need to change all repo files 🤔
|
Here is the dry run diff: updating the branch to a fixed one from the default is fine. |
| } | ||
|
|
||
| // Add non-fast-forward protection if requested | ||
| if branch_protection.prevent_force_push { |
There was a problem hiding this comment.
This is not for this PR, but I think that those two (along with forbid creation) should be the default.
| #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)] | ||
| #[serde(rename_all = "snake_case")] | ||
| pub enum MergeBot { | ||
| Homu, |
There was a problem hiding this comment.
I removed homu because it was unused.
Also I kept the "MergeBot" name here to minimize LoC changed for this PR
|
Not sure why after my latest changes the dry run diff increased: |
| [[branch-protections]] | ||
| pattern = "main" | ||
| merge-bots = ["bors"] | ||
| pr-required = false |
There was a problem hiding this comment.
I decided to setup this field explicitly instead of inferring it via code (in case the app is bors).
But let's see the dry run.
sync-team/src/github/mod.rs
Outdated
| use api::*; | ||
|
|
||
| let uses_merge_bot = !branch_protection.merge_bots.is_empty(); | ||
| let uses_merge_bot = !branch_protection.allowed_merge_apps.is_empty(); |
There was a problem hiding this comment.
This should be changed to check if allowed_merge_apps contains Bors (not just that it is empty). That should fix the diff.
There was a problem hiding this comment.
yes, but I thought that having the config more explicit was better instead of this custom logic. Wdyt? 🤔
There was a problem hiding this comment.
I think that this logic is fine. The high-level config should be "bors managed this branch", and then team should do whatever is necessary to make that happen. Setting pr-required = false just exposes (just one) implementation detail of that. So I'd rather just say that bors can push to this branch, and interpret that is it being bors managed, and set the various protection options accordingly.
eea0ed8 to
9475511
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
9475511 to
7b29da4
Compare
|
The dry run looks good now: |



Close #2198