ci: install cargo-nextest from one pinned composite action - #7266
Merged
Conversation
The Windows cells fetched cargo-nextest with a single Invoke-WebRequest against get.nexte.st/latest, under ErrorActionPreference=Stop. One transient failure skipped the whole cell - PRs #7234 and #7265 both died there with Build and Test never running. The block was copy-pasted 15 times across 10 workflow files and had already drifted into three comment variants. It is now one composite action. Pinned to an exact version instead of latest, so re-running an old commit installs what it was tested against. rust-cache already restores ~/.cargo/bin before this step, so when the pinned binary is present the download is skipped and no network I/O happens at all. No retry and no backoff: the fetch is attempted once when needed and fails loudly.
cargo-nextest --version prints a multi-line block on Windows (cargo-nextest X.Y.Z, then release:, commit-hash:, commit-date:, host:), so the native call yields an ARRAY. -replace over an array returns an array - only the first element matches - and -ne against an array FILTERS rather than compares, so the non-empty result was truthy and the version guard threw on a correct install, taking down every Windows cell. Index the first line explicitly. @() forces an array so [0] is always safe, and indexing avoids terminating the native command pipeline the way Select-Object -First 1 would.
oferchen
marked this pull request as draft
August 12, 2026 18:10
Owner
Author
|
Marking draft: every Windows cell fails at the new install step (exit code 1, no further detail in the annotation yet, run still queued so logs are not retrievable). Not pushing a speculative second patch - the log will name the failing line. Master is unaffected; this PR is unmerged. |
oferchen
marked this pull request as ready for review
August 12, 2026 18:18
oferchen
added a commit
that referenced
this pull request
Aug 12, 2026
The `paths:` filter on both the push and pull_request triggers enumerated individual workflow files but never `.github/actions/**`. A change touching only a composite action therefore started no CI run at all. That made the Windows nextest fix unverifiable by the cells it fixes. PR #7268 edits only `.github/actions/install-cargo-nextest-windows/action.yml`, and registered exactly three checks - Label PRs, Bin build coverage, Check --locked flags - with no CI workflow and no Windows cell. #7266 escaped the gap only because it also edited ci.yml itself, so that path matched. The action is used by 15 Windows call sites (5 in ci.yml, 2 matrix-expanded in _test-features.yml, 8 in windows-nightly-*.yml), so any future edit to it would likewise have shipped unvalidated. ci.yml is the only workflow carrying a paths filter; the windows-nightly-* workflows are schedule/dispatch-triggered and _test-features.yml is a reusable callee, so neither needs the same entry.
oferchen
added a commit
that referenced
this pull request
Aug 13, 2026
#7266 pinned the version and added a skip-if-present guard, documenting that guard as resting on Swatinem/rust-cache restoring ~/.cargo/bin. That premise is false. rust-cache restores the registry, git DB and target dir but deliberately does not preserve installed binaries, so ~/.cargo/bin is empty on a fresh runner even on a full-match hit. The guard therefore never fired and every Windows cell still fetched on every run, one of which died: Invoke-WebRequest -Uri "https://get.nexte.st/0.9.114/windows" | The response ended prematurely. (ResponseEnded) Cache the exact pinned executable here instead, keyed on version plus runner, so a hit does no network at all. The download runs only on a miss, exactly once, with no retry and no backoff - a fetch failure still fails the job immediately and loudly. The version check moves into its own always-run step so it covers both paths: on a miss it catches get.nexte.st serving a different release, and on a hit it catches a cache entry whose key claims one version while the executable is another.
oferchen
added a commit
that referenced
this pull request
Aug 13, 2026
The `paths:` filter on both the push and pull_request triggers enumerated individual workflow files but never `.github/actions/**`. A change touching only a composite action therefore started no CI run at all. That made the Windows nextest fix unverifiable by the cells it fixes. PR #7268 edits only `.github/actions/install-cargo-nextest-windows/action.yml`, and registered exactly three checks - Label PRs, Bin build coverage, Check --locked flags - with no CI workflow and no Windows cell. #7266 escaped the gap only because it also edited ci.yml itself, so that path matched. The action is used by 15 Windows call sites (5 in ci.yml, 2 matrix-expanded in _test-features.yml, 8 in windows-nightly-*.yml), so any future edit to it would likewise have shipped unvalidated. ci.yml is the only workflow carrying a paths filter; the windows-nightly-* workflows are schedule/dispatch-triggered and _test-features.yml is a reusable callee, so neither needs the same entry.
oferchen
added a commit
that referenced
this pull request
Aug 13, 2026
…7268) * ci: cache the pinned cargo-nextest binary instead of refetching it #7266 pinned the version and added a skip-if-present guard, documenting that guard as resting on Swatinem/rust-cache restoring ~/.cargo/bin. That premise is false. rust-cache restores the registry, git DB and target dir but deliberately does not preserve installed binaries, so ~/.cargo/bin is empty on a fresh runner even on a full-match hit. The guard therefore never fired and every Windows cell still fetched on every run, one of which died: Invoke-WebRequest -Uri "https://get.nexte.st/0.9.114/windows" | The response ended prematurely. (ResponseEnded) Cache the exact pinned executable here instead, keyed on version plus runner, so a hit does no network at all. The download runs only on a miss, exactly once, with no retry and no backoff - a fetch failure still fails the job immediately and loudly. The version check moves into its own always-run step so it covers both paths: on a miss it catches get.nexte.st serving a different release, and on a hit it catches a cache entry whose key claims one version while the executable is another. * ci: trigger CI on .github/actions changes The `paths:` filter on both the push and pull_request triggers enumerated individual workflow files but never `.github/actions/**`. A change touching only a composite action therefore started no CI run at all. That made the Windows nextest fix unverifiable by the cells it fixes. PR #7268 edits only `.github/actions/install-cargo-nextest-windows/action.yml`, and registered exactly three checks - Label PRs, Bin build coverage, Check --locked flags - with no CI workflow and no Windows cell. #7266 escaped the gap only because it also edited ci.yml itself, so that path matched. The action is used by 15 Windows call sites (5 in ci.yml, 2 matrix-expanded in _test-features.yml, 8 in windows-nightly-*.yml), so any future edit to it would likewise have shipped unvalidated. ci.yml is the only workflow carrying a paths filter; the windows-nightly-* workflows are schedule/dispatch-triggered and _test-features.yml is a reusable callee, so neither needs the same entry.
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.
Problem
PRs #7234 and #7265 both failed the
Windows (nightly)cell at step 5,Install cargo-nextest (Windows direct download), roughly 76 s in. Build andTest were skipped, so neither PR's code was compiled, let alone tested.
Two unrelated PRs, same step, same cell - the failure was the install step, not
the changes.
That step was a single
Invoke-WebRequestagainsthttps://get.nexte.st/latest/windowsunder
$ErrorActionPreference = 'Stop'. One transient fetch failure takes theentire Windows test cell with it.
It was also copy-pasted 15 times across 10 workflow files, so any change to
it had to be made fifteen times, and the copies had already drifted (three
different comment bodies for the same eight lines).
Change
One composite action,
.github/actions/install-cargo-nextest-windows, replacesall 15 copies. Two properties, in order:
Reproducible. The version is pinned (
0.9.114) instead of trackinglatest, so re-running an old commit installs what that commit was testedagainst.
latestalso meant the fetched artifact was unpinnedsupply-chain-wise. The pin lives in the action's input default - one source
of truth, no
envthreaded through ten files.No network on the common path.
Swatinem/rust-cachealready runs beforethis step in every one of these jobs and restores
~/.cargo/bin, but theold step downloaded unconditionally anyway. The action now skips the fetch
when the pinned binary is already present, so a cache hit performs no
network I/O and cannot be taken down by a transient failure.
The installed version is verified after extraction: a silently wrong version
would make the matrix test something other than what the pin claims.
This deliberately contains no retry and no backoff. The download is still
attempted exactly once when genuinely needed, and a failure there fails the job
immediately and loudly. The fix removes the reason to re-attempt rather than
re-attempting.
Upstream
rsync 3.4.4 has no GitHub Actions Windows CI, so there is no upstream behaviour
to mirror here. This is oc-only infrastructure and the oracle is
reproducibility, not fidelity.
Verification
grep -rc get.nexte.st .github/workflows/returns nothingactions/checkoutbefore it (required for a localuses: ./...)if: runner.os == 'Windows'