Repository navigation
Fix targeting and the re-run push, found by the first real submit - #118
Merged
Merged
Conversation
Publishing chocolatey for real turned up three things the earlier runs could not have shown, because no run had ever reached the submit path. Asking for one channel ran all of them. The Linux job stripped chocolatey out of the list with sed, so `-p chocolatey` left the list empty, no `-p` flags were passed, and submit-packages.mjs falls back to ALL on an empty target list. A dispatch for chocolatey alone therefore also pushed homebrew and scoop. They were idempotent and reported "already current", so nothing was damaged, but the next such dispatch would not be so lucky. That sed was also why distribution/chocolatey/* was the one pair of manifests never refreshed in git: only the Windows job templated them, and the Windows job has no commit step. The Linux job now templates every channel, chocolatey included, and the chocolatey submitter skips itself when choco is not on PATH -- Windows still does the packing and pushing. It probes by running the command rather than which/where, which differ between the Linux runner and the Windows one's git-bash. And --force-with-lease was rejected with "stale info" on the re-run. The release checkout is a shallow clone of a single ref, so refs/remotes/origin/<branch> does not exist and there is nothing for the lease to form against. Fetch the branch first and pass the expected commit explicitly, and it does what it was meant to: overwrite our own earlier attempt, refuse if someone else moved it. Verified: `-p chocolatey` on Linux now templates the manifest and prints that Windows will push it, instead of exploding on a missing binary. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
ThreatCrush Security Scan52 finding(s) HIGH/CRITICAL: 3 | MEDIUM: 28 | LOW: 21
…and 2 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
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.
Publishing Chocolatey for real turned up three things earlier runs could not have shown, because no run had ever reached the submit path.
Asking for one channel ran all of them. The Linux job stripped
chocolateyout of the list withsed, so-p chocolateyleft the list empty, no-pflags were passed, andsubmit-packages.mjsfalls back to ALL on an empty target list. A dispatch for chocolatey alone therefore also pushed homebrew and scoop. They were idempotent and reported "already current", so nothing was damaged — but the next such dispatch would not be so lucky.That same
sedis whydistribution/chocolatey/*was never refreshed in git. Only the Windows job templated those two files, and the Windows job has no commit step. The Linux job now templates every channel, chocolatey included, and the chocolatey submitter skips itself whenchocois not on PATH — Windows still packs and pushes. It probes by running the command rather thanwhich/where, which differ between the Linux runner and the Windows one's git-bash.--force-with-leasewas rejected with "stale info". The release checkout is a shallow clone of a single ref, sorefs/remotes/origin/<branch>does not exist and the lease has nothing to form against. Fetch the branch first and pass the expected commit explicitly, and it does what it was meant to: overwrite our own earlier attempt, refuse if someone else moved it.Verified locally:
-p chocolateyon Linux templates the manifest and reports that Windows will push it, instead of dying on a missing binary.🤖 Generated with Claude Code