Assert the Windows desktop strip actually took effect

The desktop job's Windows masking renamed the toolcache Python, scrubbed the
Machine and User registry PATH, and probed `py`, but nothing checked that
`python`, `git`, `cmake` or `cl` were gone. The drop list is heuristic path
fragment matching, so a runner image that moves any of those outside those
fragments leaves the bundled install.ps1 reusing hosted developer tooling while
the job still reports a clean machine. PATH written to $GITHUB_ENV only applies
to later steps, so the check has to live in a step of its own; it carries the
same event gate as the strip, exempts `py` (it lives in C:\Windows and stays,
which is why the start probe is the real evidence), and resets $LASTEXITCODE
before exiting 0 so an intentionally failing probe cannot fail a clean machine.

Also correct the no-winget matrix note: that leg is not failing for an unfixed
product reason. It stops at the unconditional git gate in setup.ps1 only on this
ref, and with that gate relaxed it passes along with every other leg, so the row
is a merge order dependency and stays required.
This commit is contained in:
danielhanchen 2026-07-29 00:22:54 +00:00
commit d5f747ef5e
2 changed files with 35 additions and 14 deletions

View file

@ -697,14 +697,13 @@ jobs:
# Ensure-VCRedist silently does not run, leaving torch unable to load, hence
# the explicit `import torch` assert below.
#
# It fails at studio/setup.ps1:1652-1670, the unconditional "Git is required
# but could not be installed automatically" gate: no winget means no way to
# fetch git. Before the overlay that failure came out of the RELEASED setup.ps1
# and said nothing about this ref; it now comes out of this ref's own copy,
# which carries the same gate, so the leg is red for a real and currently
# unfixed reason rather than an untestable one. Relaxing that gate to --local
# and llama.cpp source builds turns it green, and the overlay is what lets this
# workflow see that happen.
# On this ref alone it stops at studio/setup.ps1:1655-1669, the unconditional
# "Git is required but could not be installed automatically" gate: no winget
# means no way to fetch git. That gate is what #7549 relaxes to the --local and
# llama.cpp source paths that actually use git; with it applied the leg is
# green (staging run 30407859691, all 16 legs). So this row stays required: it
# is a merge-order dependency, not a product gap, and the overlay is what lets
# this workflow see the fix land.
- os: windows-latest
winget: 'masked'
experimental: false

View file

@ -473,22 +473,44 @@ jobs:
foreach ($v in 'VSINSTALLDIR','VCINSTALLDIR','WindowsSdkDir','INCLUDE','LIB','LIBPATH') {
"$v=" | Out-File -FilePath $env:GITHUB_ENV -Append -Encoding utf8
}
# Prove it: the launcher binary stays, but an interpreter it can still START
# is a leak, because Find-CompatiblePython (install.ps1:1130-1153) probes `py`
# first. `py -0p` is only the launcher's REGISTRY view, which still names the
# paths the rename removed, so a start attempt is the only real evidence.
exit 0
- name: Verify the strip took effect
# PATH written to $GITHUB_ENV only applies to LATER steps, so the scrub can
# only be checked from here. The drop list above is heuristic path-fragment
# matching: if a runner image moves any of these tools outside those fragments,
# the bundled install.ps1 reuses the survivor and this job still calls itself
# clean. Same assertion the installer workflow runs, same reason.
if: ${{ github.event_name != 'workflow_dispatch' || inputs.strip_toolchain }}
shell: pwsh
run: |
$leaked = @()
foreach ($t in 'python','py','git','cmake','cl') {
$f = Get-Command $t -ErrorAction SilentlyContinue
Write-Host ("{0,-8} {1}" -f $t, $(if ($f) { $f.Source } else { 'ABSENT' }))
if ($f -and $t -ne 'py') { $leaked += "$t -> $($f.Source)" }
}
# `py` itself lives in C:\Windows and stays. Only an interpreter it can still
# START is a leak, because Find-CompatiblePython (install.ps1:1130-1153) probes
# `py` first. `py -0p` is just the launcher's REGISTRY view, which still names
# the paths the rename removed, so a start attempt is the only real evidence.
if (Get-Command py -ErrorAction SilentlyContinue) {
foreach ($v in '-3.11', '-3.12', '-3.13') {
$out = & py $v -c "import sys; print(sys.executable)" 2>&1
$rc = $LASTEXITCODE
Write-Host ("py {0} -> exit {1}: {2}" -f $v, $rc, (($out | Out-String).Trim() -replace '\r?\n', ' / '))
if ($rc -eq 0) { Write-Host "::error::toolcache python survived the mask: $out"; exit 1 }
if ($rc -eq 0) { $leaked += "py $v -> $out" }
}
# A failing probe is the outcome we want, but it leaves $LASTEXITCODE
# non-zero and the runner appends `exit $LASTEXITCODE` to every pwsh step
# (actions/runner#351), so the step would fail on a machine that is clean.
# (actions/runner#351), so the step would exit 1 with nothing printed on a
# machine that is in fact clean.
$global:LASTEXITCODE = 0
}
if ($leaked) {
Write-Host "::error::developer tooling survived the strip: $($leaked -join '; ')"
exit 1
}
exit 0
- name: Silent install