aevgarik/paperclip
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: require frozen lockfile for releases

Browse Source
This commit is contained in:
Dotta
2026-03-09 10:43:04 -05:00
parent 7d8d6a5caf
commit 632079ae3b
3 changed files with 28 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.github/workflows/release.yml vendored
View File

@@ -56,7 +56,7 @@ jobs:
cache: pnpm
- name: Install dependencies
run: pnpm install --no-frozen-lockfile
run: pnpm install --frozen-lockfile
- name: Typecheck
run: pnpm -r typecheck
@@ -95,7 +95,7 @@ jobs:
cache: pnpm
- name: Install dependencies
run: pnpm install --no-frozen-lockfile
run: pnpm install --frozen-lockfile
- name: Configure git author
run: |

33
doc/RELEASING.md
View File

@@ -26,20 +26,23 @@ Treat those as related but separate. npm can succeed while the GitHub Release is
Use this when you want an installable prerelease without changing `latest`.
```bash
# 0. Preflight the canary candidate
# 0. Confirm master already has the CI-owned lockfile refresh merged
# If package manifests changed recently, wait for the refresh-lockfile PR first.
# 1. Preflight the canary candidate
./scripts/release-preflight.sh canary patch
# 1. Draft or update the stable changelog for the intended stable version
# 2. Draft or update the stable changelog for the intended stable version
VERSION=0.2.8
claude --print --output-format stream-json --verbose --dangerously-skip-permissions --model claude-opus-4-6 "Use the release-changelog skill to draft or update releases/v${VERSION}.md for Paperclip. Read doc/RELEASING.md and skills/release-changelog/SKILL.md, then generate the stable changelog for v${VERSION} from commits since the last stable tag. Do not create a canary changelog."
# 2. Preview the canary release
# 3. Preview the canary release
./scripts/release.sh patch --canary --dry-run
# 3. Publish the canary
# 4. Publish the canary
./scripts/release.sh patch --canary
# 4. Smoke test what users will actually install
# 5. Smoke test what users will actually install
PAPERCLIPAI_VERSION=canary ./scripts/docker-onboard-smoke.sh
# Users install with:
@@ -60,27 +63,30 @@ Result:
Use this only after the canary SHA is good enough to become the public default.
```bash
# 0. Start from the vetted commit
# 0. Confirm master already has the CI-owned lockfile refresh merged
# If package manifests changed recently, wait for the refresh-lockfile PR first.
# 1. Start from the vetted commit
git checkout master
git pull
# 1. Preflight the stable candidate
# 2. Preflight the stable candidate
./scripts/release-preflight.sh stable patch
# 2. Confirm the stable changelog exists
# 3. Confirm the stable changelog exists
VERSION=0.2.8
ls "releases/v${VERSION}.md"
# 3. Preview the stable publish
# 4. Preview the stable publish
./scripts/release.sh patch --dry-run
# 4. Publish the stable release to npm and create the local release commit + tag
# 5. Publish the stable release to npm and create the local release commit + tag
./scripts/release.sh patch
# 5. Push the release commit and tag
# 6. Push the release commit and tag
git push public-gh HEAD:master --follow-tags
# 6. Create or update the GitHub Release from the pushed tag
# 7. Create or update the GitHub Release from the pushed tag
./scripts/create-github-release.sh X.Y.Z
```
@@ -163,6 +169,7 @@ The workflow:
- [ ] The working tree is clean, including untracked files
- [ ] The target branch and SHA are the ones you actually want to release
- [ ] If package manifests changed, the CI-owned `pnpm-lock.yaml` refresh is already merged on `master`
- [ ] The required verification gate passed on that exact SHA
- [ ] The bump type is correct for the user-visible impact
- [ ] The stable changelog file exists or is ready to be written at `releases/vX.Y.Z.md`
@@ -202,6 +209,8 @@ pnpm build
This matches [`.github/workflows/pr-verify.yml`](../.github/workflows/pr-verify.yml). Run it before claiming a release candidate is ready.
The release workflow at [`.github/workflows/release.yml`](../.github/workflows/release.yml) installs with `pnpm install --frozen-lockfile`. That is intentional. Releases must use the exact dependency graph already committed on `master`; if manifests changed and the CI-owned lockfile refresh has not landed yet, the release should fail until that prerequisite is merged.
For release work, prefer:
```bash

7
skills/release/SKILL.md
View File

@@ -36,8 +36,9 @@ Before proceeding, verify all of the following:
2. The repo working tree is clean, including untracked files.
3. There are commits since the last stable tag.
4. The release SHA has passed the verification gate or is about to.
5. npm publish rights are available locally, or the GitHub release workflow is being used with trusted publishing.
6. If running through Paperclip, you have issue context for status updates and follow-up task creation.
5. If package manifests changed, the CI-owned `pnpm-lock.yaml` refresh is already merged on `master`.
6. npm publish rights are available locally, or the GitHub release workflow is being used with trusted publishing.
7. If running through Paperclip, you have issue context for status updates and follow-up task creation.
If any precondition fails, stop and report the blocker.
@@ -120,6 +121,8 @@ pnpm build
If the release will be run through GitHub Actions, the workflow can rerun this gate. Still report whether the local tree currently passes.
The GitHub Actions release workflow installs with `pnpm install --frozen-lockfile`. Treat that as a release invariant, not a nuisance: if manifests changed and the lockfile refresh PR has not landed yet, stop and wait for `master` to contain the committed lockfile before shipping.
## Step 4 — Publish a Canary
Run: