Skip to content

ci: add manual snapshot release workflow - #305

Merged
alexmarqs merged 1 commit into
mainfrom
feat/snapshot-releases
Nov 7, 2026
Merged

alexmarqs merged 1 commit into
mainfrom
feat/snapshot-releases

Conversation

@alexmarqs

Copy link
Copy Markdown
Member

What

Adds a Release Snapshot workflow that publishes any branch to npm, so it can be installed in other projects before it's merged.

  • Trigger: Actions → Release Snapshot → Run workflow, pick the branch. Or: gh workflow run release-snapshot.yml --ref <branch>
  • Version: 0.0.0-<branch>-<timestamp>, e.g. 0.0.0-feat-tiered-fix-20261106143000
  • Published under the snapshot dist-tag, so latest is never touched
  • The install command (pnpm add @epilot/pricing@<version>) is shown in the run summary

How

Same approach as vercel-labs/mcp-handler's release-snapshot.yml: changeset version --snapshot followed by changeset publish --tag snapshot --no-git-tag, via the existing release and release:publish scripts.

  • No changeset needed on the branch. A temporary one is written inside the run and never committed.
  • Version guard. The run fails unless the result is a 0.0.0-* version, so it can never republish a real release.
  • No dependency cache. The job runs branch code in main's cache scope, and a poisoned cache could later be restored by the Release job.
  • ci-cd.yml is unchanged. npm now supports multiple trusted publishers per package, so this lives in its own file.

Setup after merge

  1. On npmjs.com, go to @epilot/pricing → Settings → Trusted publishing and add a GitHub Actions publisher:
    • Repository epilot-dev/pricing
    • Workflow file release-snapshot.yml
    • No environment
    • Direct publishing allowed. New configs default to stage-only, which would need manual approval on every snapshot.
    • Dist-tag permission off. If the first run fails on the snapshot tag, turn it on.
  2. Run the first snapshot within 2 days of creating that config, otherwise npm expires it.
  3. Branches created before this merge need main merged in before they show the Run workflow option.

Testing

  • The YAML parses, and the step scripts pass bash -n.
  • I ran the versioning and summary steps locally on a scratch copy with no changesets. For branch feat/Tiered_Fix they produced 0.0.0-feat-tiered-fix-<timestamp> and the expected summary.
  • The publish step can only be verified on GitHub, after the npm setup above.

🤖 Generated with Claude Code

Adds a "Release Snapshot" workflow that publishes any branch to npm as
0.0.0-<branch>-<timestamp> under the `snapshot` dist-tag, so it can be
installed in other projects before merging. Triggered manually from the
Actions tab or with `gh workflow run release-snapshot.yml --ref <branch>`.

The branch doesn't need a changeset: a temporary one is added inside the
run. The dependency cache is disabled because the job runs branch code
in main's cache scope.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@changeset-bot

changeset-bot Bot commented Nov 6, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 290ec65

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@alexmarqs
alexmarqs merged commit 1ff66e3 into main Nov 7, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant