hanzoai/vitest
2
0
Fork 0
mirror of https://github.com/hanzoai/vitest.git synced 2026-09-24 17:04:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: document release protections in CONTRIBUTING (#10689)

Browse Source 
Co-authored-by: Hiroshi Ogawa <[email protected]>
Co-authored-by: OpenCode (claude-opus-4-8) <[email protected]>
This commit is contained in:
Hiroshi Ogawa
2026-07-01 08:22:48 +02:00
committed by GitHub
co-authored by Hiroshi Ogawa OpenCode
parent 6f8a64d97b
commit 39fae07caa
1 changed files with 20 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONTRIBUTING.md
+20
View File
@@ -178,6 +178,26 @@ Releases — publishing the npm packages, creating the git release tag, and gene
4. **Approve the npm staged publish.** Review the staged packages on npm, then approve them with 2FA so the release becomes installable. Afterwards, confirm npm, the tag, and the GitHub release all look right.
### Release Protections
A few settings outside this repository guard the release process above: GitHub rulesets that keep release branches and tags from being changed by hand, a `Release` environment that requires a maintainer to approve each publish, and npm settings that decide how packages are published.
- **Protect releases** — branch ruleset on `main` and the `v*` lines, so release branches only change through reviewed pull requests.
- required pull request with at least one approval, stale approvals dismissed on push; the reviewed PR merge is the single auditable entry point for changes to a release line.
- squash-only merges; keeps release-branch history to one commit per PR, so `chore: release v*` lands as a clean, identifiable trigger commit.
- force-push and branch deletion blocked; release history cannot be silently rewritten or dropped.
- code scanning must pass; workflow-security findings block the merge before they can reach a release branch.
- **Protect tags** — tag ruleset on the `v*` release tags, so a tag always maps to a real publish run.
- manual creation, update, and deletion blocked; nobody can hand-craft or move a release tag.
- only the [`vitest-release-bot`](https://github.com/organizations/vitest-dev/settings/apps/vitest-release-bot) GitHub App may bypass; the publish workflow is the sole way a `v*` tag gets pushed.
- **Release environment** — deployment gate on the [`Publish Package`](./.github/workflows/publish.yml) workflow, so a human approves each publish.
- required reviewer; publishing pauses until a maintainer approves the `Release` environment deployment.
- self-review disabled; the maintainer who triggered the release cannot approve their own publish.
- deployment restricted to `main` and the `v*` branches; a publish can only run from a real release branch, never from an arbitrary or feature branch.
- **npm publishing** — npm settings control how packages are authenticated and released.
- trusted publishing (OIDC); each package's trusted publisher on npm pins the source repository (`vitest-dev/vitest`), workflow file (`publish.yml`), and environment (`Release`), so publishes use short-lived tokens from that workflow alone with no long-lived npm token to leak, and they carry provenance attestation automatically so users can trace a package back to the exact workflow run that produced it.
- staged publishing; a publish run only stages the packages, and they go live only after a maintainer reviews and approves them on npm with 2FA, so a bad or accidental publish can be discarded before it becomes installable.
### Issue Triaging Workflow
```mermaid