docs(release): winget fails differently now — record the v0.9.0 evidence - #146
Merged
Merged
Conversation
The winget section described one failure shape and two causes, both of which are now fixed. v0.9.0 failed a third way and the old text would have sent the next person after a stale fork that wasn't stale, or a token scope that was already correct. What actually happened (2026-09-30): the workflow's sync step SUCCEEDED, and submit then failed with "Ref cannot be created." — no user named, no mention of permissions, which is a different string from the documented one. The fork was behind upstream by exactly the 5 commits winget-pkgs landed in the 34 seconds between the sync (18:51:46) and the submit error (18:52:23). komac resolves upstream HEAD at submit time and branches from it, so a commit that arrives inside that gap is one the fork does not have yet. A hand merge-upstream (clean fast-forward to 0/0) plus an immediate re-dispatch succeeded with no other change. Recorded: - The new error text, next to the old one, and a table keyed on BOTH the error string and whether the sync step passed — that pair separates all three causes in one glance, which is the thing that was missing. - That the sync step not being continue-on-error is what made this diagnosable: its passing is what ruled out the two historical causes. - The compare-direction gotcha. `compare/master...microsoft:winget-pkgs:master` puts the fork in base position, so `ahead_by` is upstream's lead over the fork. Read the natural way round it reports "5 ahead" for a fork that is 5 behind, and sends you looking for a divergence that does not exist. I misread it once before catching it. - The personal-fork question, re-tested rather than re-asserted: it was 19,108 commits behind and untouched since 2026-08-19, yet v0.7.0 and v0.8.0 both published fine in that window, so komac is not using it. Marked settled. - A note on the post-tag checklist that winget has now needed manual help on three consecutive releases, each for a different reason, while Chocolatey has been reliable throughout. The underlying fix for all of it is unchanged and still not done: have CI create the Release with a PAT instead of GITHUB_TOKEN. That removes the manual dispatch and the sync-to-submit gap together. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NDsEfog5kVkT5NmX1Ya5be
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.
Why
The winget section documented one error shape and two causes. Both are now fixed, and v0.9.0 failed a third way — so the existing text would have sent the next person chasing a stale fork that wasn't stale, or a token scope that was already correct.
What happened on v0.9.0 (2026-09-30)
The workflow's sync step succeeded. Submit then failed with:
No user named, no mention of permissions — a different string from the documented
AThraen does not have the correct permissions to execute CreateRef.At the moment of failure the fork was behind upstream by exactly 5 commits: everything winget-pkgs landed in the 34 seconds between the sync (18:51:46) and the submit error (18:52:23). komac resolves upstream HEAD at submit time and branches from it, so a commit arriving inside that gap is one the fork does not have yet, and the ref cannot be created.
A hand
merge-upstream(clean fast-forward to 0/0) plus an immediate re-dispatch succeeded with no other change — which is the evidence for the race rather than a guess.What this records
continue-on-erroris what made this diagnosable at all — its passing is what ruled out the two historical causes immediately.compare/master...microsoft:winget-pkgs:masterputs the fork in base position, soahead_byis upstream's lead over the fork. Read the natural way round it reports "5 ahead" for a fork that is 5 behind, and sends you hunting a divergence that doesn't exist. I misread it once before catching it, which is why it's written down.AThraen/winget-pkgswas 19,108 commits behind and untouched since 2026-08-19, yet v0.7.0 and v0.8.0 both published fine in that window — so komac isn't using it. Marked settled so it stops being re-opened.Not done
The underlying fix is unchanged and still open: have CI create the Release with a PAT instead of
GITHUB_TOKEN. That removes the manual dispatch and the sync→submit gap together. Flagged in the doc as worth doing before v1.0.Docs only — no code, no build impact.
🤖 Generated with Claude Code
https://claude.ai/code/session_01NDsEfog5kVkT5NmX1Ya5be