Protect the release branch with trunk's settings during code freeze

[AliSoftware]

Related Issues

• Fixes AINFRA-2697

Note

The last part of that issue — about reviewing the wording of the MC pre-release task for release notes — is handled by 230972-ghe-Automattic/wpcom in ReleasesV2.

How AI was used in this PR

Claude Code drafted the changes and the docs, from the Linear issue plus the copy_branch_protection calls we already make in the Fastfile of our other mobile repos. It also surfaced the Performance Metrics gotcha described below by cross-checking trunk's live protection settings against the if: guards in pipeline.yml. I reviewed the diff, adjusted the code comments, and made the calls on what to include (see "Not included" below).

Why this is needed / What triggered this change

During the 1.15.0 release, the release/1.15.0 branch was deleted prematurely — GitHub auto-deletes the head branch of a merged PR, and a backmerge PR ended up with the release branch as its head — which broke the Build Release step until the branch was recreated by hand. Unlike our other repos, Studio never protected its release branches, most likely a leftover from the migration to Buildkite and ReleasesV2, before the code-freeze-driven release process was in place.

See p1783940368685129/1783940368.685129-slack-CC7L49W13 for more context.

Proposed Changes

• code_freeze now copies trunk's branch protection onto the release/* branch it creates, so for the whole life of the release that branch can't be force-pushed or deleted, and PRs into it require the same CI checks and reviews as trunk.
• publish_release removes that protection again when it deletes the branch at the end of the release.

This mirrors what WPiOS, WPAndroid, WooCommerce, Simplenote, Tumblr, Day One and Pocket Casts have been doing for years.

Two details worth knowing for the review:

• The bot can still push directly. trunk's protection has "Do not allow bypassing the above settings" off in this repo's GitHub Settings, and wpmobilebot is an admin on this repo; so the version bumps that new_beta_release and finalize_release push straight to the release branch keep working. Everyone else goes through PRs, which is already the case on trunk. If we ever enable admin enforcement on trunk, the release automation would start failing on those direct pushes, and we'd need to add the set_branch_protection(…, enforce_admins: false) extra call like we do on some other repos in that case to solve it.
• The Performance Metrics job needed a CI change. It's one of trunk's five required checks, but its step only ran for trunk builds and PRs based on trunk. Copied verbatim onto a release branch, any PR targeting that branch (e.g. a fix for a bug caught during the beta period) would sit forever waiting on a check that never reports. So the step now also runs for PRs based on release/*. The alternative — requiring a smaller set of checks on release branches — would have meant keeping that exclusion list in sync with trunk's settings by hand.

Hotfix branches, which new_hotfix_release also creates as release/*, are deliberately left unprotected: that matches the other repos, where only code freeze protects. Happy to follow up separately if we'd rather cover them too.

Testing Instructions

There's no way to fully exercise this before the next code freeze, but the pieces can be checked independently.

The protection call itself, on a throwaway branch (needs a GITHUB_TOKEN with admin rights on the repo):

git push origin trunk:refs/heads/release/0.0.0-test
bundle exec fastlane run copy_branch_protection repository:Automattic/studio from_branch:trunk to_branch:release/0.0.0-test
gh api repos/Automattic/studio/branches/release/0.0.0-test/protection    # expect trunk's checks + reviews, allow_deletions false, enforce_admins false
bundle exec fastlane run remove_branch_protection repository:Automattic/studio branch:release/0.0.0-test
git push origin --delete release/0.0.0-test

The CI change is visible on this very PR: it targets trunk, so Performance Metrics must still run and report as before. To confirm the release-branch case, open a throwaway non-draft PR against a release/* branch and check that the job is created.

Then, at the next code freeze, verify that release/<version> shows up as protected with trunk's required checks, that the beta version bumps still push to it, and that publish_release deletes it cleanly at the end.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors? — no app code touched; ruby -c on the Fastfile, a YAML parse of pipeline.yml, and the fastlane/test/*_test.rb suites all pass.

[mokagio]

Only a couple of nitpicks on the comments wording.

[wojtekn]

Looks like a good improvement.