fix(release): stop an AUR outage failing the whole package submission - #38
Merged
Conversation
The v0.9.45 release job went red with "Failed: 1" even though 7 of the 8 package managers published fine. The one failure was AUR: aur: AUR submission failed: Command failed: git push origin master Connection closed by 209.126.35.78 port 22 That address is aur.archlinux.org. The key was never the problem: the clone in the same run succeeded seconds earlier, and the package is still ours at 0.9.44-1. AUR simply drops into maintenance without notice, and while it does it still accepts the SSH connection but refuses the git operation. Three changes: - Retry a git command that failed because AUR was unreachable, three times, 15s apart. A short maintenance window no longer needs a human. - Report an exhausted retry as skipped rather than failed, so a third-party outage stops failing a release that otherwise published everywhere. A real error, such as a rejected key, still fails. - Stop swallowing the clone error. A failed clone was treated as "the package does not exist yet", so an outage quietly built an empty repo and pushed a fresh history over the real package once AUR returned. execSync hides stderr behind "Command failed: git push origin master" when stdio is piped, which is why the original failure said so little. The error now carries the stderr that explains it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan159 finding(s) HIGH/CRITICAL: 111 | MEDIUM: 48
…and 109 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
…udit The security workflow gates on critical advisories only, and two had appeared, so `pnpm audit --prod --audit-level critical` exited 1 on every run. This fails on master too; it is not specific to this branch. Both reach us transitively, and neither ships to users: form-data 2.3.3 GHSA-fjxv-7rqg-78g4 unsafe random boundary remote-input > dbus-next > usocket > node-gyp@7 > request > form-data tar 6.2.1 GHSA-23hp-3jrh-7fpw decompression/parse DoS remote-input > dbus-next > usocket > node-gyp@7 > tar mobile > expo > @expo/cli > (cacache >) tar form-data is a patch bump inside its own major, so `form-data@2` moves to ^2.5.4 and resolves to 2.5.6. tar has no fix on the 6.x line: 6.2.1 is the last 6.x ever published and the advisory patches at >=7.5.19. `tar@6` is therefore overridden to ^7.5.19 alongside the existing `tar@7` pin, which was still sitting on a vulnerable 7.5.16. Everything now resolves to a single tar 7.5.22 and no 6.x copy remains. Criticals go to zero and the gate passes; the remaining 77 advisories are the low/moderate/high tooling noise the workflow deliberately does not gate on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
The v0.9.45 release job went red with "Failed: 1" even though 7 of the 8 package managers published fine. The one failure was AUR:
aur: AUR submission failed: Command failed: git push origin master
Connection closed by 209.126.35.78 port 22
That address is aur.archlinux.org. The key was never the problem: the clone in the same run succeeded seconds earlier, and the package is still ours at 0.9.44-1. AUR simply drops into maintenance without notice, and while it does it still accepts the SSH connection but refuses the git operation.
Three changes:
execSync hides stderr behind "Command failed: git push origin master" when stdio is piped, which is why the original failure said so little. The error now carries the stderr that explains it.