ci: simplify CLI binary release workflow#3121
Conversation
Two paths: - Push to next: auto-beta (or stable if commit is "Release: update version") - workflow_dispatch: build-beta from any branch, or promote-stable from existing beta tag Removes the old PR-title-gated flow. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
More reliable than matching commit messages — if the CLI version in package.json changed in the commit, it's a stable release. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Describes the two-channel system: auto-beta on push to next, stable via changeset + version bump detection. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2e45406 to
4e86c0e
Compare
|
The Please review and fix the vulnerabilities. You can try running: pnpm audit --fix --prodAudit output |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 4 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 4e86c0e. Configure here.
| uses: actions/checkout@v6 | ||
| with: | ||
| ref: ${{ github.event.pull_request.head.sha }} | ||
| ref: ${{ github.sha }} |
There was a problem hiding this comment.
Shallow checkout prevents stable release version detection
High Severity
The checkout step uses actions/checkout@v6 without specifying fetch-depth, which defaults to 1 (shallow clone). The stable release detection on line 59 runs git show HEAD^:ts/packages/cli/package.json to compare versions, but HEAD^ doesn't exist in a depth-1 clone. This silently fails (caught by || echo ""), leaving previous_version empty, so the version-changed check on line 61 is always false. Every push to next — including "Release: update version" merges — will create a beta instead of a stable release. Adding fetch-depth: 2 to the checkout step would fix this.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 4e86c0e. Configure here.
| latest_stable_tag=$(gh release list \ | ||
| --repo "$REPOSITORY" \ | ||
| --json tagName,isPrerelease \ | ||
| --jq '[.[] | select(.tagName | startswith("@composio/cli@")) | select(.isPrerelease == false)] | sort_by(.tagName) | last | .tagName // empty') |
There was a problem hiding this comment.
Lexicographic sort breaks semver tag ordering
High Severity
The jq expression sort_by(.tagName) | last sorts release tags lexicographically, not by semantic version. For example, @composio/cli@0.2.9 sorts after @composio/cli@0.2.19 lexicographically (since '9' > '1'), so the query would return 0.2.9 as the "latest" stable release instead of the actual latest 0.2.19. Given the current CLI version is 0.2.19, this bug is likely active now, causing beta versions to be computed from the wrong base.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 4e86c0e. Configure here.
| latest_stable_tag=$(gh release list \ | ||
| --repo "$REPOSITORY" \ | ||
| --json tagName,isPrerelease \ | ||
| --jq '[.[] | select(.tagName | startswith("@composio/cli@")) | select(.isPrerelease == false)] | sort_by(.tagName) | last | .tagName // empty') |
There was a problem hiding this comment.
Default 30-result limit may miss stable releases
Medium Severity
gh release list defaults to returning only 30 results. Since every push to next touching CLI files creates a new beta prerelease, it's plausible for 30+ betas to accumulate between stable releases. When that happens, the jq filter finds no stable releases in the returned set, and the fallback to package.json kicks in — which may produce an incorrect base version, especially for workflow_dispatch builds on non-next branches. Adding --limit 200 (or similar) would help.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 4e86c0e. Configure here.
| echo "make_latest=false" | ||
| } >> "$GITHUB_OUTPUT" | ||
| exit 0 | ||
| fi |
There was a problem hiding this comment.
Duplicated beta version logic risks inconsistent bug fixes
Low Severity
The beta version computation logic (query gh release list, fallback to package.json, parse/bump semver, emit outputs) is copy-pasted identically between the push path and the workflow_dispatch build-beta path. Both copies share the same sort_by(.tagName) and missing --limit issues — when one is fixed, the other can easily be missed. Extracting this into a shell function within the run: block would eliminate the duplication.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 4e86c0e. Configure here.


Summary
next: any merge touchingts/packages/cli/**automatically builds binaries and creates a@composio/cli@X.Y.Z-beta.<run_number>prerelease. Version = latest stable + patch bump.ts/packages/cli/package.jsonversion changed in the push commit (i.e. changeset "Release: update version" merge), creates a stable release instead.workflow_dispatchbuild-beta: build a beta from any branch on demand.workflow_dispatchpromote-stable: promote an existing beta tag to stable (unchanged).pull_requesttrigger with title check).Test plan
nextwith a CLI change → verify beta release is createdworkflow_dispatchwithbuild-betaon a feature branch → verify beta releaseworkflow_dispatchwithpromote-stable+ existing beta tag → verify stable release🤖 Generated with Claude Code