fix: use one workflow for npm trusted publishing
This commit is contained in:
Dotta
@@ -9,8 +9,7 @@ This document covers the GitHub and npm setup required for the current Paperclip
|
||||
|
||||
Repo-side files that depend on this setup:
|
||||
|
||||
- `.github/workflows/release-canary.yml`
|
||||
- `.github/workflows/release-stable.yml`
|
||||
- `.github/workflows/release.yml`
|
||||
- `.github/CODEOWNERS`
|
||||
|
||||
Note:
|
||||
@@ -24,8 +23,7 @@ Before touching GitHub or npm settings, merge the release automation code so the
|
||||
|
||||
Required files:
|
||||
|
||||
- `.github/workflows/release-canary.yml`
|
||||
- `.github/workflows/release-stable.yml`
|
||||
- `.github/workflows/release.yml`
|
||||
- `.github/CODEOWNERS`
|
||||
|
||||
## 2. Configure npm Trusted Publishing
|
||||
@@ -46,21 +44,26 @@ For each package:
|
||||
2. go to the package settings / publishing access area
|
||||
3. add a trusted publisher for the GitHub repository `paperclipai/paperclip`
|
||||
|
||||
### 2.2. Add two trusted publisher entries per package
|
||||
### 2.2. Add one trusted publisher entry per package
|
||||
|
||||
Because npm trusted publishing is tied to the workflow filename, configure both:
|
||||
npm currently allows one trusted publisher configuration per package.
|
||||
|
||||
- workflow: `.github/workflows/release-canary.yml`
|
||||
- workflow: `.github/workflows/release-stable.yml`
|
||||
Configure:
|
||||
|
||||
- workflow: `.github/workflows/release.yml`
|
||||
|
||||
Repository:
|
||||
|
||||
- `paperclipai/paperclip`
|
||||
|
||||
Branch expectations:
|
||||
Environment name:
|
||||
|
||||
- canary workflow should only ever run from `master`
|
||||
- stable workflow is manual but should also be restricted to `master` by GitHub environment policy
|
||||
- leave the npm trusted-publisher environment field blank
|
||||
|
||||
Why:
|
||||
|
||||
- the single `release.yml` workflow handles both canary and stable publishing
|
||||
- GitHub environments `npm-canary` and `npm-stable` still enforce different approval rules on the GitHub side
|
||||
|
||||
### 2.3. Verify trusted publishing before removing old auth
|
||||
|
||||
@@ -167,8 +170,7 @@ If `@dotta` is not the right reviewer identity in the public repo, change it bef
|
||||
|
||||
These files should always trigger code owner review:
|
||||
|
||||
- `.github/workflows/release-canary.yml`
|
||||
- `.github/workflows/release-stable.yml`
|
||||
- `.github/workflows/release.yml`
|
||||
- `scripts/release.sh`
|
||||
- `scripts/release-lib.sh`
|
||||
- `scripts/release-package-map.mjs`
|
||||
@@ -198,7 +200,7 @@ This keeps LLM spending intentional and avoids a high-value token sitting in Act
|
||||
After setup:
|
||||
|
||||
1. merge a harmless commit to `master`
|
||||
2. open the `Release Canary` workflow run
|
||||
2. open the `Release` workflow run triggered by that push
|
||||
3. confirm it passes verification
|
||||
4. confirm publish succeeds under the `npm-canary` environment
|
||||
5. confirm npm now shows a new `canary` release
|
||||
@@ -215,7 +217,7 @@ npx paperclipai@canary onboard
|
||||
After at least one good canary exists:
|
||||
|
||||
1. prepare `releases/vYYYY.M.D.md` on the source commit you want to promote
|
||||
2. open `Actions` -> `Release Stable`
|
||||
2. open `Actions` -> `Release`
|
||||
3. run it with:
|
||||
- `source_ref`: the tested commit SHA or canary tag source commit
|
||||
- `stable_date`: leave blank or set the intended UTC date
|
||||
|
||||
@@ -53,7 +53,7 @@ Canaries only cover the first two surfaces plus an internal traceability tag.
|
||||
|
||||
### Canary
|
||||
|
||||
Every push to `master` runs [`.github/workflows/release-canary.yml`](../.github/workflows/release-canary.yml).
|
||||
Every push to `master` runs the canary path inside [`.github/workflows/release.yml`](../.github/workflows/release.yml).
|
||||
|
||||
It:
|
||||
|
||||
@@ -70,7 +70,7 @@ npx paperclipai@canary onboard
|
||||
|
||||
### Stable
|
||||
|
||||
Use [`.github/workflows/release-stable.yml`](../.github/workflows/release-stable.yml) from the Actions tab.
|
||||
Use [`.github/workflows/release.yml`](../.github/workflows/release.yml) from the Actions tab with the manual `workflow_dispatch` inputs.
|
||||
|
||||
Inputs:
|
||||
|
||||
|
||||
@@ -158,20 +158,17 @@ This is the cleanest answer to the open-repo security concern.
|
||||
|
||||
### Concrete controls
|
||||
|
||||
#### 1. Split canary and stable into separate workflow files
|
||||
#### 1. Use one release workflow file
|
||||
|
||||
Do not use one workflow file for both.
|
||||
Use one workflow filename for both canary and stable publishing:
|
||||
|
||||
Recommended:
|
||||
|
||||
- `.github/workflows/release-canary.yml`
|
||||
- `.github/workflows/release-stable.yml`
|
||||
- `.github/workflows/release.yml`
|
||||
|
||||
Why:
|
||||
|
||||
- npm trusted publishing is configured per workflow filename
|
||||
- canary and stable need different blast radii
|
||||
- stable should have stronger GitHub environment rules than canary
|
||||
- npm currently allows one trusted publisher configuration per package
|
||||
- GitHub environments can still provide separate canary/stable approval rules inside the same workflow
|
||||
|
||||
#### 2. Use separate GitHub environments
|
||||
|
||||
@@ -438,7 +435,7 @@ That is acceptable if canaries stay clearly separate:
|
||||
|
||||
### Phase 1: Security foundation
|
||||
|
||||
1. Create `release-canary.yml` and `release-stable.yml`
|
||||
1. Create `release.yml`
|
||||
2. Configure npm trusted publishers for all public packages
|
||||
3. Create `npm-canary` and `npm-stable` environments
|
||||
4. Add `CODEOWNERS` protection for release files
|
||||
|
||||
Reference in New Issue
Block a user