fix(release): re-register PSGallery before Windows Artifact Signing#264
Conversation
azure/artifact-signing-action installs its ArtifactSigning module from PSGallery at runtime. PSGallery is intermittently absent on hosted windows runners (actions/runner-images#13758), so the action fails with "Unable to find repository 'PSGallery'". This dropped the Windows arm64 exe and msi from the v0.6.14 release while x86_64 (a different runner) shipped fine. Register-PSRepository -Default in both Windows signing jobs when the repository is missing, so a mis-provisioned runner can no longer lose a release artifact.
Greptile SummaryThis PR adds a defensive PowerShell step to re-register PSGallery before each
Confidence Score: 5/5YAML-only change; no Rust or application logic touched. The new step is a well-known workaround for a documented runner provisioning flake and is correctly placed and idempotent. The two added steps exactly match the workaround recommended for actions/runner-images#13758. The conditional guard prevents double-registration on healthy runners, and the step is placed correctly in both jobs — after the Azure login that the signing action depends on, and before the signing action itself. No logic paths are altered for the happy case. No files require special attention. Important Files Changed
Sequence DiagramsequenceDiagram
participant Runner as Windows Runner
participant Guard as Ensure PSGallery step (NEW)
participant PSGallery as PSGallery
participant SignAction as azure/artifact-signing-action@v2
participant AzureSign as Azure Artifact Signing
Runner->>Guard: Execute pwsh guard
Guard->>PSGallery: Get-PSRepository -Name PSGallery
alt PSGallery not registered (flaky runner)
PSGallery-->>Guard: $null
Guard->>PSGallery: Register-PSRepository -Default
PSGallery-->>Guard: Registered ✓
else PSGallery already registered (healthy runner)
PSGallery-->>Guard: Repository info
Guard-->>Guard: Skip (no-op)
end
Guard-->>Runner: Step succeeds
Runner->>SignAction: Run signing action
SignAction->>PSGallery: Install-Module ArtifactSigning
PSGallery-->>SignAction: Module installed ✓
SignAction->>AzureSign: Submit file for signing
AzureSign-->>SignAction: Signed artifact ✓
Reviews (1): Last reviewed commit: "fix(release): re-register PSGallery befo..." | Re-trigger Greptile |
Problem
The
v0.6.14Release run failed two jobs — Windows EXE (arm64) and Windows MSI (arm64) — so those two assets are missing from the published release. Everything else (macOS, Linux, Windows x86_64) shipped, and the GitHub Release published (the publish job is best-effort over Windows artifacts).The arm64 EXE build succeeded; the signing step failed:
azure/artifact-signing-action@v2installs itsArtifactSigningmodule from PSGallery at runtime. PSGallery is intermittently not registered on hostedwindowsrunners (actions/runner-images#13758), so the action dies on a mis-provisioned VM. x86_64 landed on a healthy runner and signed fine — this is a transient infra flake, not a config bug.The MSI (arm64) failure is a downstream cascade: it couldn't download the missing arm64 EXE artifact.
Fix
Re-register the default PSGallery before each
azure/artifact-signing-action@v2call (both the EXE and MSI Windows jobs):This is the workaround recommended in the runner-images issue. A mis-provisioned runner can no longer silently drop a release artifact.
Scope