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:
parent
b8a052080e
commit
d5f747ef5e
2 changed files with 35 additions and 14 deletions
15
.github/workflows/clean-machine-install-ci.yml
vendored
15
.github/workflows/clean-machine-install-ci.yml
vendored
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue