ci(winget): self-heal fork drift and probe the real publish path - #590
Merged
Conversation
v0.6.31's WinGet submission failed while the weekly token check reported
healthy every single week. Both halves of that are fixed here.
1. winget-publish.yml fast-forwards the fork before komac runs.
The fork sat three weeks behind microsoft/winget-pkgs (7fb04c98 vs
50db148f) and komac aborted with
githubrobbi does not have the correct permissions to execute `CreateRef`
failed to create branch SkyLLC.UFFS-0.6.31-<hash>
which reads as a credentials problem and is not one: the token was a
classic PAT with `public_repo`, valid to 2027, and GitHub resolved it
to the right user. The branch simply could not be cut from a stale
base. Syncing the fork fixed it on the next attempt with no
credential change at all.
This recurs by construction — winget-pkgs moves constantly, nothing
else ever pushes to the fork, so every release landing more than a
few weeks after the last one re-opens the gap. The sync step is
continue-on-error: a hiccup there must never block a submission that
would otherwise succeed.
2. winget-token-expiry-check.yml now probes publish READINESS, not just
token liveness.
Probing `/rate_limit` proves the token is alive. It cannot prove a
release would publish, which is why this workflow stayed green
through the entire outage. It now fast-forwards the fork and then
genuinely creates — and deletes — a ref off upstream HEAD, the exact
operation komac performs, so token write-capability and fork state
are both exercised.
Deliberately NOT a drift check: the fork is expected to fall behind
between releases, so alarming on drift would fire weekly and train
everyone to ignore it. Publishing self-heals drift now, so the only
thing worth waking someone for is a broken sync-then-branch path.
A failed probe raises the alarm even when the token is healthy, and
the issue body leads with fork checks before blaming credentials —
plus a note that the action requires a classic PAT, since
fine-grained PATs cannot open the cross-fork PR at all.
Verified: PR microsoft/winget-pkgs#416270 (v0.6.31) merged with
Validation-Completed and Publish-Pipeline-Succeeded after the fork sync.
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
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.
v0.6.31's WinGet submission failed while the weekly token check reported
healthy every single week. Both halves of that are fixed here.
winget-publish.yml fast-forwards the fork before komac runs.
The fork sat three weeks behind microsoft/winget-pkgs (7fb04c98 vs
50db148f) and komac aborted with
which reads as a credentials problem and is not one: the token was a
classic PAT with
public_repo, valid to 2027, and GitHub resolved itto the right user. The branch simply could not be cut from a stale
base. Syncing the fork fixed it on the next attempt with no
credential change at all.
This recurs by construction — winget-pkgs moves constantly, nothing
else ever pushes to the fork, so every release landing more than a
few weeks after the last one re-opens the gap. The sync step is
continue-on-error: a hiccup there must never block a submission that
would otherwise succeed.
winget-token-expiry-check.yml now probes publish READINESS, not just
token liveness.
Probing
/rate_limitproves the token is alive. It cannot prove arelease would publish, which is why this workflow stayed green
through the entire outage. It now fast-forwards the fork and then
genuinely creates — and deletes — a ref off upstream HEAD, the exact
operation komac performs, so token write-capability and fork state
are both exercised.
Deliberately NOT a drift check: the fork is expected to fall behind
between releases, so alarming on drift would fire weekly and train
everyone to ignore it. Publishing self-heals drift now, so the only
thing worth waking someone for is a broken sync-then-branch path.
A failed probe raises the alarm even when the token is healthy, and
the issue body leads with fork checks before blaming credentials —
plus a note that the action requires a classic PAT, since
fine-grained PATs cannot open the cross-fork PR at all.
Verified: PR microsoft/winget-pkgs#416270 (v0.6.31) merged with
Validation-Completed and Publish-Pipeline-Succeeded after the fork sync.
Verified live: PR microsoft/winget-pkgs#416270 (v0.6.31) merged with
Validation-CompletedandPublish-Pipeline-Succeededafter the fork sync that this change now automates.