fix(opencode:pin): resolve ref from the tag instead of leaving it stale - #222
Merged
Conversation
pinFromRelease only wrote `ref` when --ref was passed, so the ordinary `pnpm opencode:pin <tag>` produced a lock claiming the new tag while `ref` still pointed at the PREVIOUS release's commit. Release mode ignores ref (tag drives the download, sha256 verifies it), so this never shipped a wrong binary. But `source: "local"` validates ref against the clone HEAD, so a stale ref tells a fork developer to check out the wrong commit — and the lock misreports its own provenance either way. Resolve the tag to its commit via gh, dereferencing annotated tags (what amicode-release cuts). Explicit --ref still wins. Fails with a pointed error rather than silently writing a stale value. Caught bumping to v1.17.3-amicode.10: the lock read tag=.10 with ref=bbe47b60 (.9's commit).
This was referenced Jul 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pnpm opencode:pin <tag>writes a lock that misreports its own provenance.pinFromReleaseonly setrefwhen--refwas passed explicitly:So the ordinary invocation updates
tagand bothsha256s but leavesrefpointing at the previous release's commit.Caught while bumping to
v1.17.3-amicode.10(#221) — the lock came out as:Does it matter?
Not for the shipped artifact. In
source: "release"— the committed default —refis never read:fetchFromReleasedownloads bytagand verifies bysha256. A wrong ref cannot produce a wrong binary.It matters in two other ways:
source: "local"validates it.fetchFromLocalcompares the clone HEAD againstmanifest.refand throws:clone … is at <head> but the lock pins <ref> — checkout the pinned ref, update opencode.lock.json, or pass --any-refWith a stale ref that message names the wrong commit, so a fork developer following it checks out the previous release.
Fix
Resolve the tag to its commit when
--refis omitted.amicode-releasecuts annotated tags, sogit/ref/tags/<tag>yields a tag object that needs dereferencing; lightweight tags point straight at the commit. Both handled.Explicit
--refstill wins. Resolution failure raises a pointed error instead of silently writing a stale value:Verification
End-to-end, real tag, no
--ref:e0105cd4d…is the commitv1.17.3-amicode.10points at, confirmed by dereferencing the annotated tag.Unit-level, against an injected resolver (
resolveTagCommitis a seam onpinFromRelease, matching the existingdownloadseam):--refis omitted--refstill winsStacked on nothing — independent of #221, which already carries the correctly-resolved ref because I passed
--refby hand there.