Pushing stagehand-server to github releases with changesets, instead of using github artifacts

[monadoid]

why

With my previous artifacts approach, our client sdk repos like stagehand-python just pulled the most recent artifact, which could be error prone - by having it pull a versioned release, we avoid a swath of potential issues.

what changed

Added logic for pushing releases.

test plan

We should see a release show up for stagehand-server when this merges, since I added a minor version bump changeset.

---

Summary by cubic

Publish stagehand-server via versioned GitHub Releases driven by Changesets, replacing the previous GitHub Artifacts flow. SDKs can now fetch stable, versioned assets (OpenAPI spec) from releases.

• New Features

  • Auto-tag stagehand-server/v{version} when packages/server version changes; skips if unchanged or tag exists.
  • New release workflow verifies the tag matches package.json, packages openapi.v3.yaml, and publishes a GitHub Release with notes.
  • Added a minor Changeset for @browserbasehq/stagehand-server to trigger the first release.

• Migration

  • Update SDKs (e.g., stagehand-python) to download openapi.v3.stagehand-server-{version}.yaml from the matching GitHub Release tag.
  • Stop relying on the “latest” GitHub Artifacts.

^{Written for commit e47c56e. Summary will update automatically on new commits.}

[changeset-bot]

🦋 Changeset detected

Latest commit: e47c56e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@browserbasehq/stagehand-server	Minor

Not sure what this means? Click here to learn what changesets are.

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

[cubic-dev-ai]

No issues found across 4 files

[greptile-apps]

Greptile Summary

This PR transitions from using GitHub artifacts to versioned releases for stagehand-server, improving reliability for downstream SDK repositories. The implementation adds automated tagging when the server version changes and creates GitHub releases with the OpenAPI spec.

Changes:

• Added changeset for @browserbasehq/stagehand-server to trigger initial minor version bump
• Updated release.yml to automatically create git tags when server version changes (comparing current version with previous commit)
• Added new stagehand-server-release.yml workflow triggered by tags to publish GitHub releases with OpenAPI spec
• Fixed stainless.yml to only run merge builds when merging to main branch

The tagging logic correctly handles edge cases including missing previous versions, existing tags, and initial commits. The workflow integrates cleanly with the existing changesets release process.

Confidence Score: 4/5

• This PR is safe to merge with low risk
• The implementation is well thought out with proper error handling and edge case management. The tagging logic correctly compares versions and handles scenarios like missing previous versions and existing tags. The new workflow is simple and focused. Minor deduction because this introduces a new release mechanism that should be monitored on first run to ensure the tag-to-release flow works as expected.
• Monitor .github/workflows/release.yml on first run to verify the tagging step executes correctly when versions change

Important Files Changed

Filename	Overview
.github/workflows/release.yml	Updated checkout action to v4, added fetch-depth: 0, and added tagging logic for stagehand-server versions
.github/workflows/stagehand-server-release.yml	New workflow that creates GitHub releases with OpenAPI spec when stagehand-server tags are pushed

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant PR as Pull Request
    participant Release as release.yml
    participant Changesets as changesets/action
    participant Main as main branch
    participant Tag as Git Tag
    participant ServerRelease as stagehand-server-release.yml
    participant GH as GitHub Releases

    Dev->>PR: Add changeset file (lucky-dolls-joke.md)
    PR->>Main: Merge to main
    Main->>Release: Trigger workflow (push to main)
    Release->>Changesets: Run changesets/action
    Changesets->>Changesets: Detect changesets
    Changesets->>PR: Create "Version Packages" PR
    Note over Changesets,PR: Updates package.json versions
    PR->>Main: Merge Version Packages PR
    Main->>Release: Trigger workflow again
    Release->>Changesets: Run changesets/action
    Changesets->>Changesets: Detect version bump commit
    Changesets->>Changesets: Publish to npm
    Release->>Release: Read current server version
    Release->>Release: Compare with previous commit version
    alt Version changed
        Release->>Tag: Create stagehand-server/vX.Y.Z tag
        Tag->>ServerRelease: Trigger workflow (tag push)
        ServerRelease->>ServerRelease: Verify tag matches package.json
        ServerRelease->>ServerRelease: Copy OpenAPI spec to release assets
        ServerRelease->>GH: Create GitHub release with assets
        GH->>Dev: Release published
    else Version unchanged
        Release->>Release: Skip tagging
    end

Loading

[greptile-apps]

Greptile's behavior is changing!

From now on, if a review finishes with no comments, we will not post an additional "statistics" comment to confirm that our review found nothing to comment on. However, you can confirm that we reviewed your changes in the status check section.

_{This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR".}