[chore]: only release alpha when changeset present#1826
[chore]: only release alpha when changeset present#1826seanmcguire12 wants to merge 3 commits intomainfrom
Conversation
|
Greptile SummaryThis PR adds a guard to the Key changes:
Confidence Score: 4/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Push to main] --> B[Checkout and Setup]
B --> C[Lint and Build]
C --> D[changesets/action - Create Version PR or Publish Stable]
D --> E[check_changesets - pnpm changeset status output JSON]
E --> F{changeset-status.json exists?}
F -- No or empty --> G[has_changesets=false]
F -- Yes --> H{releases contains @browserbasehq/stagehand?}
H -- No --> G
H -- Yes --> I[has_changesets=true]
G --> J[Publish Canary - SKIPPED]
I --> K[Publish Canary - git checkout main then pnpm run release-canary]
K --> L[changeset version --snapshot creates alpha versions]
L --> M[changeset publish --tag alpha to npm]
Last reviewed commit: 2da4412 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
.github/workflows/release.yml
Outdated
| run: | | ||
| set -euo pipefail | ||
| rm -f changeset-status.json | ||
| pnpm changeset status --output changeset-status.json || true |
There was a problem hiding this comment.
Silent suppression of all changeset status errors
|| true suppresses every non-zero exit from pnpm changeset status, including unexpected infrastructure failures (e.g., a corrupted node_modules, a pnpm resolution error, etc.). In those cases the output file won't be created, the node script falls into the !fs.existsSync branch, sets has_changesets=false, and the alpha publish is silently skipped with no indication that something went wrong.
Consider adding a brief comment so future maintainers know the intent — changeset status exits 1 when there are no pending changesets, which is why || true is needed rather than to swallow real errors:
| pnpm changeset status --output changeset-status.json || true | |
| pnpm changeset status --output changeset-status.json || true # exits 1 when no changesets exist |
.github/workflows/release.yml
Outdated
| const hasStagehand = changesets.some((cs) => | ||
| (cs.releases || []).some((r) => r?.name === '@browserbasehq/stagehand') | ||
| ); |
There was a problem hiding this comment.
Alpha gated only on @browserbasehq/stagehand, not sibling packages
The release-canary script (changeset version --snapshot && changeset publish --tag alpha) publishes all packages that have pending changesets — including @browserbasehq/browse-cli. However, the gate here only checks for a @browserbasehq/stagehand changeset.
This means if @browserbasehq/browse-cli (or any other workspace package) accumulates changesets without a corresponding stagehand changeset, those packages will never get an alpha release through this workflow until a stagehand changeset also lands.
If the intent is truly "only alpha when stagehand itself changes" this is fine — but it's worth a comment documenting the choice so it's not accidentally widened later.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 1 file
Confidence score: 3/5
- There is a concrete medium-risk release-process issue in
.github/workflows/release.yml: the changeset check is not scoped to the current push range, so alpha can publish on merges that did not add a changeset. - Because this behavior is tied to STG-1583 and can violate the stated alpha publishing requirement, the risk is user-impacting for release correctness even though the change scope is small.
- Pay close attention to
.github/workflows/release.yml- ensure the changeset validation only evaluates the current push range to prevent unintended alpha releases.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".github/workflows/release.yml">
<violation number="1" location=".github/workflows/release.yml:54">
P2: Scope the changeset check to the current push range; otherwise alpha can still publish on merges that didn’t add a changeset.
According to linked Linear issue STG-1583, this can violate the requirement to avoid alpha releases for merges to `main` without a changeset.</violation>
</file>
Architecture diagram
sequenceDiagram
participant Runner as GitHub Actions Runner
participant CLI as Changeset CLI
participant FS as File System
participant Node as Validation Script
participant Release as Release Process (pnpm)
participant Registry as NPM Registry
Note over Runner, Registry: CI/CD Release Flow (Branch: main)
Runner->>CLI: pnpm changeset status --output changeset-status.json
CLI->>FS: Write status to changeset-status.json
Runner->>Node: NEW: Parse status and check package
FS-->>Node: Read JSON data
Note over Node: NEW: Logic looks for package<br/>'@browserbasehq/stagehand'
alt Changeset exists for stagehand
Node-->>Runner: NEW: set GITHUB_OUTPUT has_changesets=true
Runner->>Release: pnpm run release-canary
Release->>Registry: Publish alpha version
else No changeset or different package
Node-->>Runner: NEW: set GITHUB_OUTPUT has_changesets=false
Note over Runner: NEW: Publish step skipped via 'if' condition
end
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".github/workflows/release.yml">
<violation number="1" location=".github/workflows/release.yml:67">
P2: This check can produce false positives because it scans the whole changeset markdown file instead of only frontmatter package entries. According to linked Linear issue STG-1583, alpha publishing should only happen when a relevant changeset is actually present; this logic can still publish alpha when package names appear only in the note body.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| # Private packages (server-v3, server-v4) have their own release workflows. | ||
| has_publishable=false | ||
| for file in $new_changesets; do | ||
| if grep -qE '"@browserbasehq/stagehand"|"@browserbasehq/browse-cli"' "$file"; then |
There was a problem hiding this comment.
P2: This check can produce false positives because it scans the whole changeset markdown file instead of only frontmatter package entries. According to linked Linear issue STG-1583, alpha publishing should only happen when a relevant changeset is actually present; this logic can still publish alpha when package names appear only in the note body.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/release.yml, line 67:
<comment>This check can produce false positives because it scans the whole changeset markdown file instead of only frontmatter package entries. According to linked Linear issue STG-1583, alpha publishing should only happen when a relevant changeset is actually present; this logic can still publish alpha when package names appear only in the note body.</comment>
<file context>
@@ -46,25 +46,30 @@ jobs:
+ # Private packages (server-v3, server-v4) have their own release workflows.
+ has_publishable=false
+ for file in $new_changesets; do
+ if grep -qE '"@browserbasehq/stagehand"|"@browserbasehq/browse-cli"' "$file"; then
+ has_publishable=true
+ break
</file context>
| if grep -qE '"@browserbasehq/stagehand"|"@browserbasehq/browse-cli"' "$file"; then | |
| if sed -n '/^---$/,/^---$/p' "$file" | grep -qE "^[[:space:]]*['\"](@browserbasehq/stagehand|@browserbasehq/browse-cli)['\"]:[[:space:]]"; then |
1 participant
why
what changed
release.ymlto check for a changeset in the stagehand package. if one exists, it will publish an alpha version. otherwise, it wont publishSummary by cubic
Only publish canary (alpha) on main when this push adds a changeset for
@browserbasehq/stagehandor@browserbasehq/browse-cli. Adds a step in.github/workflows/release.ymlto scan new.changeset/*.mdfiles in the push and gate the publish step, aligning with STG-1583.Written for commit 242e266. Summary will update on new commits. Review in cubic