Conversation
Dry-run check results |
11472fe to
ccd8f31
Compare
|
Backup (taken automatically with https://github.com/marcoieni/multicheese in case you are curious!)
|
a4540e6 to
83f09a2
Compare
| protection.pattern, | ||
| ); | ||
| } | ||
|
|
There was a problem hiding this comment.
Unlike protection rules, multiple rulesets can apply at the same time, so you can be confident that every rule targeting a branch in your repository will be evaluated when someone interacts with that branch
I removed this because we need multiple rules to interact with the same branch (different bypass list for normal push and force push).
There was a problem hiding this comment.
In that case we should make the name required when there are multiple identical patterns, because we used the pattern as an identifier.
6f35480 to
c3d0cbd
Compare
|
Here's how I tested the "stable" and "stable - force-pushes" rules.
The user in the |
6e4c63c to
c67ec1b
Compare
|
There's one issue: |
0dee3f1 to
f614447
Compare
|
We are relatively close to making the unrolled PRs by bors, instead of rustc-perf. If this can wait a few weeks, rust-timer will no longer need that access. |
f614447 to
dbe30bf
Compare
#2343 is a small change that can be reverted easily. Since this is the only blocker to have rulesets in the rust I'm in favor of creating the team. What do you think? 🤔 |
|
Sure, go ahead, it's a small change 👍 |
1b14c6d to
c62adff
Compare
| let bypass_actors = self.bypass_actors(expected_repo, branch_protection).await?; | ||
|
|
||
| Ok(construct_ruleset(branch_protection, bypass_actors)) | ||
| } |
There was a problem hiding this comment.
this function is only two lines but I left it like this to minimize the git diff of the PR.
We could inline the construct_ruleset free function later
| bypass_mode: RulesetBypassMode::Always, | ||
| }) | ||
| }) | ||
| .collect(); |
There was a problem hiding this comment.
this piece of code was moved up
c62adff to
8c81777
Compare
| rust-timer = "write" | ||
|
|
||
| # Only `bors` can push to `main` | ||
| [[branch-protections]] |
There was a problem hiding this comment.
I don't understand why we need two separate branch protections to prevent force pushes. Force pushes should be disabled for everyone, even for bors.
There was a problem hiding this comment.
Force pushes should be disabled for everyone, even for bors.
That's what the main - force-push rule does. It prevents everyone (including bors) to force push.
Bors is in the main rule, so that rule doesn't apply to bors. To restrict bors, we need another rule where bors isn't in the bypass list.
There was a problem hiding this comment.
Ah, I see, I forgot about the other branch protection. That's quite stupid that rulesets work like this, tbh 😆 It would be better if we could bypass only specific properties.. but I understand that would make the options more complicated.
It's quite non-obvious though, and it seems hard to ensure that the other branch protection don't enable something that we don't want, hmm.
There was a problem hiding this comment.
It's quite non-obvious though, and it seems hard to ensure that the other branch protection don't enable something that we don't want, hmm.
Yeah, it requires a different mindset than before a bit.
There was a problem hiding this comment.
Wait, but if the force push ruleset requires a PR by default, doesn't that mean that it will require a PR also for bors?
There was a problem hiding this comment.
yes, you are right, in my test I didn't have "requires a PR" in the settings.
Probably we should add a third rule related to main 😅
There was a problem hiding this comment.
Not a third rule, just disable requiring PRs here.
There was a problem hiding this comment.
With "here" you mean in the "main - force push"?
I think you are right!
Because "main" already prevent everyone from opening PRs.
I'll do it.
There was a problem hiding this comment.
I did the same for stable and beta as well.
| pattern = "perf-tmp" | ||
| allowed-merge-apps = ["rust-timer"] | ||
| allowed-merge-teams = ["rust-timer"] | ||
| prevent-update = true |
There was a problem hiding this comment.
What does prevent-update actually do? Any why isn't it the default?
There was a problem hiding this comment.
If selected, only users with bypass permissions can push to branches or tags whose name matches the pattern you specify.
At the moment it's not enabled by default. I will raise a PR to make it the default.
There was a problem hiding this comment.
Hmm, it seems that the mental model of branch protections and rulesets quite diverges here. I guess that prevent-update = true should be automatically set by pr-required = true?
There was a problem hiding this comment.
Yeah the fact that you both have "restrict updates" and "require a pull request before merging" as possible rules is weird. I think it makes sense for tags, but still..
I will raise a PR
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
761602e to
a6907b3
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
04c04e1 to
846355b
Compare
|
We added "allow force push" to the |
846355b to
6e05527
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
eafb1f6 to
2146114
Compare
ubiratansoares
left a comment
There was a problem hiding this comment.
I've checked all screenshots and compared side-by-side with the new config. Looks Ok to me. Perhaps @Kobzol wants to confirm whether we are good to go from his side as well.
I think it'd be nice spreading the word about this PR on T-infra/annoucements.
| name = "main" | ||
| pattern = "main" | ||
| allowed-merge-apps = ["bors"] | ||
| prevent-update = true |
There was a problem hiding this comment.
I realized that to mirror the previous behavior of branch protections, having a non-empty list of allowed-merge-apps should probably imply prevent-update = true. But that's non-blocking, we can do that later.
| pattern = "stable" | ||
| allowed-merge-apps = ["promote-release"] | ||
| # `stable` already requires users to open PRs. | ||
| # This allows bors to push without opening a PR. |
There was a problem hiding this comment.
| # This allows bors to push without opening a PR. | |
| # This allows promote-release to push without opening a PR. |
There was a problem hiding this comment.
no, I meant bors!
The stable - force-push branch protection is there to restrict the behavior of bors.
promote-release doesn't have any restrictions because it is in all the allowed lists, so it could even delete the branch.
2146114 to
90ef019
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. |
|
☔ The latest upstream changes (possibly #2355) made this pull request unmergeable. Please resolve the merge conflicts. |















Is there a preferred moment when we want to merge this?