Creating a branch rule for non LTS staging branches

[marco-ippolito]

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

[targos]

This is not true. Only releasers and backporters can push to LTS staging branches.
Additionally, collaborators can push to non-LTS staging branches (not sure why you mention moderation team, they don't have permission).

[richardlau]

For reference https://github.com/nodejs/node/blob/f7e73cd1f2081d8b4a7e67b28ba90760a36ee8b3/doc/contributing/collaborator-guide.md?plain=1#L801-L802:

Only members of @nodejs/backporters should land commits onto LTS staging branches.

[aduh95]

not sure why you mention moderation team, they don't have permission

Moderation team members are org Owner, and therefore have technically Write permission on the repo.

[marco-ippolito]

Updated the description to mention non LTS

[targos]

not sure why you mention moderation team, they don't have permission

Moderation team members are org Owner, and therefore have technically Write permission on the repo.

Yes, but it doesn't matter. We have setup branch protection rules that don't allow owners, admins, etc to bypass them.

[richardlau]

We currently don't have a branch protection rule for v22.x-staging (or any other newly created branch that isn't caught by the existing rules).

[aduh95]

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?)

[targos]

When I had time to take care of staging branches, I used to push a few times per week.

[BethGriggs]

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.

[aduh95]

@targos do you mean LTS-staging branches, or also non-LTS ones?

[targos]

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.
For LTS, I also did it but in bigger batches (like dedicating one hour from time to time to cherry-picks / backport requests)

[marco-ippolito]

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 -staging

[aduh95]

not sure why you mention moderation team, they don't have permission

Moderation team members are org Owner, and therefore have technically Write permission on the repo.

Yes, but it doesn't matter. We have setup branch protection rules that don't allow owners, admins, etc to bypass them.

not sure why you mention moderation team, they don't have permission

Moderation team members are org Owner, and therefore have technically Write permission on the repo.

Yes, but it doesn't matter. We have setup branch protection rules that don't allow owners, admins, etc to bypass them.

Regarding that, I'm afraid that's not true:

People and apps with admin permissions to a repository are always able to push to a protected branch or create a matching branch.
Source: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#restrict-who-can-push-to-matching-branches

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.