Unified release process#36456
Open
eps1lon wants to merge 2 commits into
Open
Conversation
|
Comparing: d5736f0...56763b5 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
c87c22f to
95409bb
Compare
95409bb to
56763b5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This unifies the release process for Nightlies and stable releases within a single workflow. The publish job now runs in a protected GitHub environment that matches our protected branches. This ensures release are only published from source that is reviewed by at least two people (commit author and reviewer). No self-review is allowed.
Any release going forward will be done from CI.
Discord notifications and automatic Nightlies should work like before.
Authentication is based on NPM's Trusted Publishing which allows us to drop usage of static automation tokens. However, this means
canary(no morenexttag)backporttag insteadThese downsides are unavoidable with NPM's Trusted Publishing. OIDC tokens from GitHub are only allowed to use
npm publish(which only allows a single tag). Nonpm dist-tagornpm deprecateoperations are allowed.Backport releases are blocked until we implement a custom Ruleset bypass to allow ref creation. If we'd allow ref creation for
releases/**/*, a single compromised account with write access could just create the ref from an unreviewed commit.For a stable release, manually bumping versions is still required.
I removed the "release from npm" workflow since that's largely defunct. Especially for backport releases we wouldn't validate a Canary before so all that adds is time between vulnerability discovery and fix being published. Still an interesting idea to implement but since we nowadays publish canaries from CI and use the same artifacts for stable, I don't see much added confidence we'd gain by using NPM artifacts.
Test plan
mainreleases -canary-mainreleases ReactVersions.jsmainreleases ReactVersions with allow-listed packages