Dispatched desktop releases were tagged on main (the CLI lineage) - #67
Merged
Merged
Conversation
…lineage Found while verifying desktop-v1.18.66, which I released: the tag did not point at the commit I had verified and built. tag triggered by tagged on built from desktop-v1.18.64 tag push 1.18.23 1.18.23 desktop-v1.18.65 dispatch MAIN 1.18.23 (30cbeae) desktop-v1.18.66 dispatch MAIN 1.18.23 (3ff9086) `gh release create "$TAG"` had no --target. A tag push creates the tag at the pushed commit before the workflow runs, so create never makes one and it was always right. A workflow_dispatch has no tag yet, so create makes it — at the head of the DEFAULT branch, which is `main`. Both dispatched releases shipped correct binaries under a tag naming the other product's source. Checking one out to debug a desktop build hands you the CLI, and RELEASE_AND_REPO_MAP.md's own merge-base test would report the release as CLI. I documented dispatch as the release path yesterday, so this was mine. Fix: --target "$GITHUB_SHA", the commit the run built. Plus a guard that reads the tag back and fails the run if it names different source — a tag on the wrong commit publishes perfectly and is otherwise found only by someone checking it out. NOT DONE, deliberately: moving the two existing tags. Updating a desktop-v* ref is a push, and this workflow triggers on those — it would rebuild, re-upload and auto-promote a stale version to every user. Their true source is recorded in each release's notes instead, which changes nothing that runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JwiqN8M84qimu1TjZGSsdQ
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.
gh release create "$TAG"had no--target. A tag push already has its tag at the pushed commit, so that path was always right. A workflow_dispatch has no tag yet, so GitHub created it at the default branch head,main, which is the CLI lineage.30cbeae643ff908662The binaries were correct; the tags named the wrong product's source.
Fix:
--target "$GITHUB_SHA", plus a guard that reads the tag back and fails the run if it doesn't match the built commit.Deliberately not done: retagging the two existing releases. Moving a
desktop-v*ref is a push, which re-triggers this workflow and would auto-promote a stale build. Their real source commits are recorded in their release notes instead.Workflow-only change; YAML validated.
🤖 Generated with Claude Code
https://claude.ai/code/session_01JwiqN8M84qimu1TjZGSsdQ