-
Notifications
You must be signed in to change notification settings - Fork 555
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
Creating a branch rule for non LTS staging branches #1004
Comments
This is not true. Only releasers and backporters can push to LTS staging branches. |
|
Moderation team members are org Owner, and therefore have technically Write permission on the repo. |
Updated the description to mention non LTS |
Yes, but it doesn't matter. We have setup branch protection rules that don't allow owners, admins, etc to bypass them. |
We currently don't have a branch protection rule for |
Note that if we restrict it to Releasers, it will make onboarding harder. Maybe a better workflow would be to have some automation that sends a Slack notification everytime someone pushes to a staging branch, so if there are some suspicious activity, it can more easily be noticed (I assume pushing to staging branch is not something that happens often, is it?) |
When I had time to take care of staging branches, I used to push a few times per week. |
It's also common to rebase the staging branches frequently when triaging test results on the proposal (to remove problematic commits), or push additional commits on request. |
@targos do you mean LTS-staging branches, or also non-LTS ones? |
I mean the staging branch for Current. I found it easier to continuously cherry-pick from main rather than doing everything just before the release proposal. |
I think the staging branch (LTS and non LTS) should be treated equally as we are releasing them either way, that also makes it easier to write a rule that protects all branches ending with |
Regarding that, I'm afraid that's not true:
TSC voting members and Moderation team members, because they are org owners, can technically push to LTS staging branches, no matter they are protected branch. To see what it would look like to push to a protected branch as an org owner, I activated that branch protection to node-auto-test, and try to push: I wasn't given a warning that I was doing an admin-only action. |
If rulesets are not affected by this limitation, we should migrate asap |
What about that: |
In today Release WG meeting #1011 we discussed a bit about this, and the idea of having just one rule to protect all staging branch sounds reasonable. This means only release will be able to push to staging branches. I'll open a PR to update the documentation and after that we can update the rule |
To repeat what I said #1004 (comment), I'm not sure adding a rule won't add frictions to onboarding new releasers. My recommendation would be to instead enforce commit signatures, because it:
When we discussed this on the call, @richardlau pointed out that it's also possible to add folks to |
why not both, I would be +1 on both
|
Right now, everyone with push permission (collaborators) can push on non LTS staging branches.
I believe we might want to change that to releasers only.
Adding it to the agenda to seek consensus
The text was updated successfully, but these errors were encountered: