feat: tag-triggered releases — installable ct tarball on the GitHub Releases page (#9) - #44
Merged
Merged
Conversation
Baseline for tag-driven releases (#9). package stays private: true — install is via GitHub Releases tarball + npm pack, not npm publish.
Pushing a v* tag runs the same lint/typecheck/test/build gate as CI, packages the built CLI with `npm pack`, and publishes a GitHub Release with the tarball + an INSTALL.md, using GitHub's auto-generated release notes (#9). Deviates from the issue's semantic-release + standalone-binary proposal: no pkg/bun/SEA toolchain exists in the repo today, so this ships the minimal robust path (tag push -> release) rather than adding a new packaging toolchain and merge-to-main automation. Standalone macOS binaries and auto-versioning-on-merge remain open follow-ups.
Add an Install section pointing at the GitHub Releases tarball + npm install -g, ahead of the existing dev/from-source setup docs (#9).
1 of 6 tasks
2000game
added a commit
that referenced
this pull request
Jul 9, 2026
…trix (#9) Replace the tag-triggered release flow (#44) with per-merge releases: every push to main runs the CI gate, cross-compiles ct as standalone bun binaries (darwin-arm64, darwin-x64, linux-x64), smoke-tests each one on its native OS/arch (--help plus a real ct plan against a fixture .config.ts, so jiti's runtime TS transpilation inside the compiled binary is actually exercised — not just --help), and only then runs semantic-release (pinned via npx, no new devDependencies) to compute the version, generate the changelog as GitHub Release notes, create the tag, and publish the release with the tarball + binaries attached. No manual tag push. Release stays private/GitHub-only: no npm publish plugin. Comment/label side effects on @semantic-release/github are disabled to keep the GITHUB_TOKEN permission footprint at contents:write only.
3 tasks
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
1 participant
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.
Minimal robust release automation, first slice of #9:
.github/workflows/release.yml: pushing av*tag runs the identical CI gate (Node 22: lint → typecheck → test → build), thennpm packs the built CLI and publishes a GitHub Release (auto-generated notes) with the tarball + anINSTALL.md.npm install -g <release-asset-url>→ct --help. Verified end-to-end in an isolated prefix: packed tarball installs and runs.package.jsonversion 0.0.0 → 0.1.0; staysprivate: true(blocks onlynpm publish, which is not the install story).Deliberately not in this slice (issue #9 stays open, scope narrowed): standalone no-Node binaries (SEA/pkg/bun), auto-versioning on merge (semantic-release/release-please), Homebrew tap. None of that tooling exists in the repo today and the tarball path unblocks installs now.
Addresses #9.