Skip to content

ci(release): refuse a skein release version below the provider floor - #96

Merged
androidand merged 1 commit into
devfrom
ci-skein-release-version-floor
Oct 3, 2026
Merged

androidand merged 1 commit into
devfrom
ci-skein-release-version-floor

Conversation

@androidand

Copy link
Copy Markdown
Owner

Problem

skein-release.yml takes the version from a workflow_dispatch input or a skein-v* tag and hands it straight to build.ts as OPENCODE_VERSION. That value is compiled in and goes out as the opencode/<version> User-Agent (packages/opencode/src/provider/provider.ts). Providers on the free tier refuse anything below 1.17.0.

So a release cut as 0.1.0-skein.1 — a perfectly natural "first release of the fork" number — would build, upload, and publish cleanly, and every free provider would reject the resulting binary. Nothing in the pipeline would have objected.

Fix

One new step after "Resolve version", gating on the scheme that keeps the version honest: <upstream version>-skein.<n>, where the base must equal the version in packages/opencode/package.json (the upstream we last synced to). Pinning the base to the sync makes the 1.17.0 floor follow for free, and it means the release name always says which upstream it carries.

A mismatch now names the remedy rather than shipping quietly:

'1.17.8-skein.1' has base 1.17.8 but packages/opencode/package.json says we are
synced to 1.18.18. Release 1.18.18-skein.<n>, or sync first.

Also refreshed the two stale 1.17.8-skein.1 examples in the comments and the workflow_dispatch input description, which pointed at a base the guard would now reject.

Testing

  • Guard logic exercised against 8 inputs — accepts 1.18.18-skein.1 / -skein.12; rejects 0.1.0-skein.1 and 1.16.9-skein.1 (floor), 1.18.17-skein.1 (base != sync), and 1.18.18 / v1.18.18-skein.1 / 1.18.18-skein (shape).
  • Workflow YAML parses.
  • bun run fork:verify — 223/223 owned, 112/112 patched, 0 unregistered divergence.

🤖 Generated with Claude Code

The release version is not cosmetic: skein-release.yml passes it as
OPENCODE_VERSION, which build.ts compiles in and provider.ts sends as the
`opencode/<version>` User-Agent. Providers on the free tier reject anything
below 1.17.0, so a release named with a fork-local number (0.1.0-skein.1)
would ship a binary whose free providers all refuse it — and nothing in the
pipeline would have said so.

Gate the resolved version on the scheme that keeps the name honest:
<upstream version>-skein.<n>, where the base must equal the version in
packages/opencode/package.json (what we last synced to). Pinning the base to
the sync makes the floor follow for free, and a mismatch now names the fix
("release 1.18.18-skein.<n>, or sync first") instead of silently shipping.
@github-actions

Copy link
Copy Markdown

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

  • PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

@github-actions

Copy link
Copy Markdown

Hey! Your PR title ci(release): refuse a skein release version below the provider floor doesn't follow conventional commit format.

Please update it to start with one of:

  • feat: or feat(scope): new feature
  • fix: or fix(scope): bug fix
  • docs: or docs(scope): documentation changes
  • chore: or chore(scope): maintenance tasks
  • refactor: or refactor(scope): code refactoring
  • test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

@androidand
androidand merged commit 51343b5 into dev Oct 3, 2026
3 of 9 checks passed
@androidand
androidand deleted the ci-skein-release-version-floor branch October 3, 2026 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant