Refactor RNW release pipelines to prepare via PRs instead of main-branch commits
Background
Today our release flow is split between two ADO pipelines:
-
publish.ymlruns on a schedule, uses Beachball to bump versions, generates.tgzpackages, publishes them directly to npmjs.com, and creates NuGet packages. - After that completes,
release.ymlpushes the NuGet packages to nuget.org.
Because publish.yml commits the version bumps straight to main, we have to keep rotating a PAT with force-push rights. This bypasses branch protection and is increasingly out of line with SDL expectations.
Proposal
Move the version bump and release prep into a scheduled pipeline that raises a release PR, and only build/publish artifacts once the PR merges:
-
Add
prepare-release.yml(same cadence as today’spublish.yml):- Run
beachball bumpto update package versions/changelogs and commit them to arelease_request/<date>branch. - Generate the release manifest and open/update a PR targeting
mainor the corresponding release branch.
- Run
-
When the PR merges, run the existing
publish.yml:- Build the repo and create npm
.tgzplus NuGet artifacts, but do not push to registries yet.
- Build the repo and create npm
-
Finally, let
release.ymlpublish those artifacts to npmjs.com and nuget.org.
This keeps all commits to main and other release branches going through protected PRs, removes our dependency on elevated PATs, and aligns the release flow with SDL guidance.
This proposal is based on the separate discussions with @jonthysell and @dannyvv that we had last week.
- @jonthysell outlined the whole new process. He proposed to create artifacts before the PR with package version bumps is created.
- @dannyvv expressed concerns about having the version bump PR to match the previously created artifacts. Also, we must have a way to manually fix/override any steps if need to get the repo and releases in a good state.
- This proposal augments the original process suggested by @jonthysell to generate released artifacts after the PR with version bumps (release PR) is merged. Hopefully it should address @dannyvv concerns.
- @dannyvv also proposed to create a process for the end-to-end testing between RNW released and its key consumers. We should consider to implement it in future.
- A quick experiment had shown that our current ADO pipeline can create branches and PRs using the standard permissions.