ci: make sample-test Pester install resilient to PSGallery flake - #701
Merged
Nikola Metulev (nmetulev) merged 1 commit intoJul 30, 2026
Merged
Conversation
Skip the PSGallery registration entirely when Pester 5.x is already on the runner image, and retry acquisition up to 3 times with backoff when it is not. A genuinely missing Pester still fails the job. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5b5228f5-d804-4288-bf04-a00cdfd27560
Contributor
There was a problem hiding this comment.
🟢 Ready to approve
The focused workflow change correctly addresses the verified CI flake without masking persistent failures.
This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.
Pull request overview
Makes sample-test CI resilient to transient PSGallery failures.
Changes:
- Reuses an available Pester 5.x installation.
- Retries installation three times with backoff and preserves failure reporting.
File summaries
| File | Description |
|---|---|
.github/workflows/test-samples.yml |
Adds Pester detection and resilient installation retries. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Medium
We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.
Contributor
Build Metrics ReportBinary Sizes
Test Results✅ 3719 passed, 4 skipped out of 3723 tests in 625.3s (+15.5s vs. baseline) Test Coverage✅ 94.5% line coverage, 88.6% branch coverage · ✅ no change vs. baseline CLI Startup Time42ms median (x64, Try This BuildInstalls the MSIX for your architecture, replacing any previously installed build. Needs the GitHub CLI — the command offers to install it and sign you in if it is missing. & ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) 701Switching between builds often?Put the tool on your PATH once: & ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) -AddToPathThen this build is just: winapp-pr 701Run Updated 2026-07-30 19:24:37 UTC · commit |
Nikola Metulev (nmetulev)
added a commit
that referenced
this pull request
Jul 30, 2026
Based directly on `main`. Single commit, one file. Picking up newer commits on the build you are already running was more work than it should be. You had to remember which PR or branch it came from — `-Status` would tell you, but that is an extra step — and name it again. Worse, re-resolving the same target silently uninstalled and reinstalled an identical package with no indication you were already current. ## Changes **`-Update`** installs the newest build for whatever is installed: ```powershell winapp-pr -Update ``` It resolves by the PR the build came from where there was one. Fork PRs run in the *base* repo, so a branch name alone can match another fork's runs — `main` being the obvious case — and picking "the newest run on that branch" could hand you an unrelated contributor's build. Where only a branch is known, resolution is pinned to that build's head repository instead. Only an explicit `-Repo` overrides the recorded source. `WINAPP_PR_REPO` is a default for *new* installs, not a redirect for an existing one; otherwise having it point at the public repo while running a private-fork build would send `-Update` looking for that branch in the wrong place. Updating the tool itself moves from `-Update` to **`-UpdateTool`**. Updating the *build* is by far the more common intent, so it should own the obvious name. **Already-installed builds are no longer reinstalled.** Any resolution that lands on the run you are already on stops early: ``` [OK] Run 30544907744 [success] de22c73 [OK] Already on this build -- nothing to do. Use -Force to reinstall it anyway. ``` This applies to naming a target explicitly too, so `winapp-pr 681` when you are on 681's newest build is a no-op instead of a ~10 second uninstall/reinstall cycle. **The install record is only trusted while it still describes the installed package.** A package installed by other means — double-clicking an MSIX, `setup-winapprun.ps1` — used to leave the record describing a build that was no longer there, which would have let the no-op above skip a genuinely needed install. The record is now validated against the live package first: ``` >> Installed winapp package winapp-dev 0.5.1.40 [CN=runneradmin] [WARN] This package was not installed by winapp-pr; its source is unknown. ``` `-Update` refuses rather than guessing, and points at a concrete alternative: ``` [ERROR] The installed package (winapp-dev 0.5.1.40) was not installed by winapp-pr, so there is no way to tell which build it came from. Name what you want instead, for example: winapp-pr jay/find-ui-port ``` The record now tracks architecture as well, so requesting a different `-Arch` for a run you already have is not mistaken for a no-op. Records written before this change lack the newer fields and fall back to the old behaviour, so nobody has to reinstall to get a working record. **The picker shows build freshness**, distinguishing "you have this" from "there is something newer": ``` * installed ^ newer build available . current branch 1. . #702 Add winapp-pr -Update and show build freshness in the picker nmetulev - 2m 2. ^ #681 feat: add winapp find-ui — WinUI control & sample search Jaylyn-Barbee - 4m 3. #701 ci: make sample-test Pester install resilient to PSGallery nmetulev - 2h ``` Freshness is resolved the same way an install would resolve it — the newest run that actually has an artifact, pinned to the same head repository — so neither an in-progress build nor another fork's run produces a phantom `^`. It costs two extra API calls, only for the one installed branch. **`-Help`** lists everything. PowerShell's built-in `-?` already covers the on-disk case, but it throws when the script is run from the web as a scriptblock: ``` InvalidArgument: Cannot process argument because the value of argument "helpTarget" is null. ``` That is exactly how the documented installer runs it, so `-Help` uses `Get-Help` when there is a file and falls back to the script's own comment-based help block otherwise. ## Also carries the #700 review fixes Those review comments were written after #700 had already merged, so they never landed. They are folded in here rather than left on a dead branch: - The gh readiness check is scoped with `--active --hostname github.com`. A bare `gh auth status` fails when *any* configured account on *any* host is stale, so anyone with a second account would have been pushed into a pointless sign-in. - When an invalid `GH_TOKEN` or `GITHUB_TOKEN` is the cause, say so instead of offering to sign in. `gh auth login` refuses to store credentials while an env token is set, so that prompt could only ever dead-end. ## Validation The fork-collision fix was reproduced directly: two `Build and Package` runs on a branch named `feature` from different head repositories, the unrelated one newer. Unfiltered resolution selects the stranger's run; pinned to the head repository it selects the right one. `-Update` was checked with `WINAPP_PR_REPO` pointing at a different repo, confirming it stays on the recorded source; with a record carrying a PR number, confirming it resolves by PR; and with a legacy record lacking the new fields, confirming the branch path still works. A real install was run end to end to confirm `Pr`, `HeadRepo`, and `Arch` are persisted. Also exercised against real branch builds: `-Update` when current reports it and exits 0; `-Update -Force` performs a full reinstall; `-Update` with no record fails cleanly; `-UpdateTool` still targets the tool. Record validation was covered as a table — matching version and architecture, mismatched architecture, legacy record, and a version mismatch standing in for a manual install — and end to end by pointing the record at a version that is not installed. Picker markers were checked in all three states, and `-Help` both from a file and through a scriptblock. --------- Co-authored-by: Nikola Metulev <711864+nmetulev@users.noreply.github.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: db5ddd3d-7017-4d4a-9b45-d7f8dc70deaf
This was referenced Aug 14, 2026
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.
The flake
The
Install Pesterstep in.github/workflows/test-samples.ymlfails intermittently on GitHub-hosted Windows runners:Register-PSRepository -Defaulthits a transient error inside the bundled NuGet provider, so PSGallery never gets registered. The next line then fails because the repository doesn't exist and the step exits 1 — the sample test never runs.Evidence it's a flake, not a real break
30570937690, jobwinui-app. All 11 other sample matrix jobs passed on the same commit, same runner image, same step.Approach
Two changes to the one step (it appears once in the YAML — the matrix duplicates it at runtime, so no composite action is needed):
scripts/test-samples.ps1andscripts/build-cli.ps1.::warning::so the flake stays visible rather than being silently swallowed.The failure signal is preserved: if Pester 5.x still isn't available after all attempts, the step
Write-Errors and exits 1.Verification
Using Pester 5.7.1, exit 0Write-Error, exit 1