chore(release): cherry-pick release system stack from staging - #44
Merged
Conversation
Blocks PRs to staging that do not include a .changeset/*.md file. Part of the release system plan (Phase 4). This is the first layer of the implementation stack: lint CI first, workflow rewrite second, documentation third.
The previous version failed because actions/checkout@v4 only fetches the PR branch by default. The git diff against origin/staging returned an ambiguous argument error, which the bash 'if !' then interpreted as 'test failed', triggering the changeset error message incorrectly. Fix: fetch-depth 0, explicit 'git fetch origin staging', and capture the diff output before grepping.
The ci.yml addition requires a changeset to pass the new lint itself. This is a minor bump for @deessejs/errors because the workaround is shipped as part of the package release.
Replaces the existing release.yml with the version described in docs/internal/engineering/plans/release-system.md (Section 3): - Explicit 'has_changesets' detection step. All publish steps are gated on this. A 'version bump' PR with no changesets is a no-op. - Tag is pushed at the version bump commit, not at the merge commit. Fixes the @deessejs/errors@1.1.1 tag drift. - pnpm install --frozen-lockfile (was pnpm install) for reproducibility. - Adds dry_run and packages inputs to workflow_dispatch for tabletop exercises and selective re-publishes. - Keeps the existing 'version bump' label gate on PRs to main. - Adds a changeset to pass the new ci.yml lint. This is the second layer of the release system plan implementation stack: lint CI (PR #1) first, workflow rewrite (this commit) second, documentation update (next) third.
CLAUDE.md and CONTRIBUTING.md both described a 'main <- staging <- dev' flow that the project does not actually follow. The real flow is staging-first: devs land PRs on staging, the release engineer cherry-picks to main with a 'version bump' label, and the release workflow runs on the merge. Also documents: - The CI lint that requires a .changeset/*.md on every PR to staging - The hotfix path (release/hotfix-* branch from main) - The single release engineer convention (no rotation) - The release cadence (one release per package per version bump PR) This is the third layer of the release system plan implementation stack: lint CI (first), workflow rewrite (second), documentation update (this commit). Adds a changeset to pass the new ci.yml lint.
Proposes a documented release system plan for @deessejs/errors. The plan is grounded in a Phase 0 inventory of the current pipeline (Changesets + 'version bump' label + cherry-pick PRs from staging to main) and lists six implementation phases to harden the workflow. No code, no workflow changes, no tag changes in this commit.
… main Simplifies the release flow. Any PR merged to main now produces a release if it contains .changeset/*.md in its diff. The 'version bump' label is no longer required. Changes: - release.yml: drop the 'contains(..., labels.*.name, "version bump")' condition from the job 'if'. PR-closed-on-main is the only condition. - CLAUDE.md: update Branching Strategy to drop the label requirement. - CONTRIBUTING.md: same. - release-system.md (plan): update Section 3, Decision log, and YAML example to match the simplified flow. The 'has_changesets' detection step is the only safety net: a merge to main without changesets is a no-op (the publish steps are gated on it). Adds a changeset to pass the new ci.yml lint.
Drops the NODE_AUTH_TOKEN env var from the publish step. The job's existing 'id-token: write' permission is what GitHub needs to mint the OIDC token, which npm exchanges for a short-lived publish credential. Required (by the user, before or after merge): 1. Add a trusted publisher on npmjs.com for @deessejs/errors, pointing at deessejs/errors with workflow 'release.yml'. 2. Cut one release via the modified workflow to validate end-to-end. 3. On npmjs.com: Settings -> Publishing access -> 'Require 2FA and disallow tokens' (recommended maximum-security posture). 4. Revoke the NPM_TOKEN GitHub secret once the OIDC publish succeeds. Adds a changeset to pass the new ci.yml lint.
GitHub Environment gives us a deployment record per run, visible in the Deployments API and the GitHub UI. No protection rules are attached yet, so the trigger stays label-less / fire-on-every-merge. Future hardening (required reviewers, branch restrictions, wait timer, env secrets) can attach to the same environment without changing this workflow further. The environment on the npmjs.com trusted publisher config is intentionally left blank for now; we only point at the workflow file. Adding environment name on the trusted publisher side would require the env on the workflow to exist first, which it now does. Adds a changeset to pass the new ci.yml lint.
…ronment) Adds Section 7 (Trusted publishing & environment) to the plan and a matching Appendix C (Post-plan decision log). Two items are added to the Definition of done: - At least one release has been published via npm trusted publishing (OIDC), per Section 7.1. - The GitHub 'release' environment exists with at least one deployment record, per Section 7.2. Plan Status also moves from 'Proposed' to 'Approved and partially implemented on staging' because Phases 3, 4, 5 plus Section 7 are now merged on the staging branch (PRs #40, #41, #42).
This was referenced Aug 3, 2026
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
2 participants
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.
Summary
Cherry-picks the release system stack from
stagingtomain. The stack is the implementation ofdocs/internal/engineering/plans/release-system.md:.changeset/*.mdon every PR tostagingCLAUDE.mdandCONTRIBUTING.mdversion bumplabel gate removed (fire on every merge to main)NPM_TOKENto npm trusted publishing (OIDC)environment: releaseWhat this PR triggers
Once merged, the release workflow runs because there are 7 pending changesets in this PR's diff:
add-staging-changeset-lint.md(minor)release-workflow-rewrite.md(patch)docs-update-branching-model.md(patch)remove-version-bump-label.md(patch)switch-to-trusted-publishing.md(patch)add-release-environment.md(patch)docs-plan-trusted-publishing.md(patch)Changesets will default to
**1.2.0**(highest single bump is minor).Verified before push
@deessejs/errorsis at1.1.1onmain(commit569c96d)main, all cherry-picked fromstagingci.ymlby keeping the post-fix version)🤖 Generated with Claude Code