C1 + C4: cross-platform release workflow + bcode.sh install script

Merged
AL
7mo ago
+588-9

Summary

Two of the three pieces needed for curl -fsSL https://bcode.sh/install | bash. The third (the release-build workflow file) needs the user to add it directly because the BROWSERCODE_DEV_PAT lacks workflow scope — full content is staged at memory/browsercode/release_workflow.yml in the agent home, and the PR description below quotes it inline.

What's in this PR

1. packages/opencode/script/build.ts — split asset name from package name (Yellow zone)

The npm package id remains @browser-use/browsercode-core-<target> (drives the dist/<scope>/<pkg>/ subdir + target: name.replace(pkg.name, "bun") cross-compile target). The release-archive basename is now a separate bcode-<target> value, used only for the tar/zip output filename and the gh release upload glob.

Before: archives landed at dist/@browser-use/browsercode-core-<target>.{tar.gz,zip}. The gh release upload shell glob ./dist/*.tar.gz expanded via the slash to upload them under their basename, working but messy and producing asset URLs with awkward path components for the install script to construct.

After: archives at dist/bcode-<target>.{tar.gz,zip}, uploaded via ./dist/bcode-*.tar.gz ./dist/bcode-*.zip. The install script can now construct stable URLs like https://github.com/browser-use/browsercode/releases/download/v0.0.3/bcode-darwin-arm64.zip.

Documented in memory/browsercode/EXCEPTIONS.md (Phase C1 row, "Maybe" upstream-able).

2. install.sh at repo root — one-line installer (port of opencode.ai/install)

To be served at https://bcode.sh/install. Diffs vs upstream:

  • APP=bcode, INSTALL_DIR=$HOME/.bcode/bin.
  • Pulls assets from browser-use/browsercode GitHub Releases.
  • Shell-rc marker # bcode (matches the uninstall grep already shipped in PR #12).
  • BrowserCode wordmark + footer text (no opencode.ai docs link).
  • uv on-PATH detection: prints a one-line install hint if missing (the harness needs uv at runtime for browser_execute). Does not auto-install — chained installers are bad form.

Same arch/musl/baseline/rosetta detection as upstream. Same per-shell config-file walking + # bcode markered append. Same --version, --binary, --no-modify-path flag set.

What needs to be added separately (workflow file)

.github/workflows/release.yml was rejected by the push because the PAT lacks workflow scope. Two options:

Option A (preferred): the admin commits the file directly via the GitHub web UI or with a personal token that has workflow scope. The full file is in memory/browsercode/release_workflow.yml on the agent's home repo. The shape:

  • Triggers on v* tag push (or workflow_dispatch with a tag input).
  • Single Ubuntu runner; Bun cross-compiles every target. (Bun supports cross-compile for darwin and windows from a Linux host; the script/build.ts matrix already enumerates all 12 targets.)
  • Creates the GitHub Release as a prerelease if it doesn't exist; passes OPENCODE_VERSION + OPENCODE_RELEASE=1 to build.ts so it auto-archives and uploads.
  • Gated to github.repository == 'browser-use/browsercode' so it's a no-op on forks.

Option B: rotate the PAT scope on the secret used by this agent (BROWSERCODE_DEV_PAT in the Sprite .env) to include workflow, and ask the agent to submit a follow-up PR with just the workflow file.

Pre-conditions for the install one-liner to actually work post-merge

  1. Repo public. bcode-cli/install.sh calls https://api.github.com/repos/browser-use/browsercode/releases/latest to discover the latest tag. Returns 401 against a private repo. Until then, users can --version pin to a known release as a workaround (the version asset URL itself does not require auth).
  2. Static hosting for install.sh at bcode.sh. Cloudflare Pages or GitHub Pages serving install.sh as text/plain at the apex /install path. DNS: bcode.sh → CNAME (or A records) to the Pages host. HTTPS via the platform's free TLS.
  3. A real release with the new asset names. Cut v0.0.3 (or any new tag) on main after this PR + the workflow file are both merged, so the matrix builds fire. v0.0.1 and v0.0.2 only have bcode-linux-x64* assets — the install script's darwin/windows paths won't find anything against those tags.

Verification

  • bun typecheck (filtered) clean.
  • bash -n install.sh clean. bash install.sh --help prints the expected usage.
  • OPENCODE_VERSION=0.0.3-dryrun ./packages/opencode/script/build.ts --single ran end-to-end on the Sprite. Compiled bcode --version → 0.0.3-dryrun. tar -czf ../../../bcode-linux-x64-test.tar.gz * from inside dist/@browser-use/browsercode-core-linux-x64/bin/ produced dist/bcode-linux-x64-test.tar.gz as expected — confirming the cwd math (../../../) is correct.

Out of scope

  • Homebrew tap, npm publish, Scoop / Chocolatey manifests (ROADMAP C2/C3). The single curl-bash one-liner covers >95% of the install surface.
  • Windows PowerShell installer (separate install.ps1 orthogonal channel). Skip until BrowserCode has Windows-without-bash users.
  • Re-enabling the disabled bcode upgrade codepath. Currently short-circuits to a friendly "download from releases" message (PR #12). Once we have a real release feed, can be flipped back on with the install script as the upgrade target.