Repository navigation
fix(ci): ensure NSIS via a preinstalled/choco-retry/verified-download ladder - #23
Merged
Merged
Conversation
… ladder The Windows leg installed NSIS with a bare, single-attempt `choco install nsis -y --no-progress`. That is a hard dependency on the Chocolatey CDN with no retry: when the CDN started answering 503 it took `DisplayXR/displayxr-shell-pvt`'s Windows build red for days (displayxr-shell-pvt#104, fixed there in PR #106). The same line was here, and because this workflow also builds and attaches `DisplayXRMCPSetup-*.exe` on `v*` tags, a CDN blip would take an MCP release with it. Ported from the shell's proven `Ensure NSIS` step: 1. preinstalled makensis (PATH, both Program Files roots, choco shim). The step comment this replaces claimed "NSIS is not preinstalled on windows-latest" -- that is no longer true: the GitHub `windows-*` images ship it at `C:\Program Files (x86)\NSIS\makensis.exe`, which is why displayxr-runtime's build-windows.yml has no install step at all and still builds its NSIS installer green. The happy path now has no network dependency; 2. `choco install nsis` -- pinned to 3.10, `--no-progress`, 3 attempts with 15/30 s backoff (last attempt unpinned, so a bad pin can't be the thing that fails the build); 3. direct download of nsis-3.10-setup.exe from SourceForge, SHA-256 verified (4313d352...f24f7bdd) before it is executed, then a silent `/S /D=C:\NSIS` install. Download uses in-box `curl.exe`, not `Invoke-WebRequest`: IWR `-UseBasicParsing` stops at SourceForge's interstitial and saves ~147 KB of HTML instead of the 1.5 MB installer. The checksum is the success criterion, so a mirror that serves markup rolls over to the next mirror rather than being run -- and since NSIS releases are not Authenticode-signed, that checksum is the only integrity control there is. `CMakeLists.txt` locates makensis via `find_program(MAKENSIS makensis REQUIRED)`, so the step publishes the *resolved* directory on `GITHUB_PATH` -- same contract as the old step, which appended a hardcoded path, but now correct whichever rung supplied makensis. The step body is kept ASCII: PowerShell treats a U+201D as a string delimiter, so an em dash that gets mis-decoded turns the whole step into a parse error. Origin: DisplayXR/displayxr-shell-pvt#104 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DKfVYJBmuWSLApa7a2yQPa
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.
The Windows leg installed NSIS with a bare, single-attempt
choco install nsis -y --no-progress. That is a hard dependency on the Chocolatey CDN with no retry: when the CDN started answering 503 it tookDisplayXR/displayxr-shell-pvt's Windows build red for days (DisplayXR/displayxr-shell-pvt#104, fixed there in PR #106). The same line was here — and because this workflow also builds and attachesDisplayXRMCPSetup-*.exeonv*tags, a CDN blip would take an MCP release with it.This ports the shell's proven
Ensure NSISstep.The ladder
windows-*images ship it atC:\Program Files (x86)\NSIS\makensis.exe, which is whydisplayxr-runtime'sbuild-windows.ymlhas no install step at all and still builds its NSIS installer green. The happy path now has no network dependency.choco install nsis— pinned to 3.10,--no-progress, 3 attempts with 15 s / 30 s backoff. The last attempt is unpinned, so a bad pin can't be the thing that fails the build.nsis-3.10-setup.exefrom SourceForge, SHA-256 verified (4313d352…f24f7bdd) before it is executed, then a silent/S /D=C:\NSISinstall.Download uses in-box
curl.exe, notInvoke-WebRequest: IWR-UseBasicParsingstops at SourceForge's interstitial and saves ~147 KB of HTML instead of the 1.5 MB installer. The checksum is the success criterion, so a mirror that serves markup rolls over to the next mirror rather than being run — and since NSIS releases are not Authenticode-signed, that checksum is the only integrity control there is.Contract unchanged
CMakeLists.txtlocates makensis viafind_program(MAKENSIS makensis REQUIRED), so the step publishes the resolved directory onGITHUB_PATH— same contract as the old step, which appended a hardcoded path, but now correct whichever rung supplied makensis.The step body is kept ASCII: PowerShell treats a U+201D as a string delimiter, so an em dash that gets mis-decoded turns the whole step into a parse error.
Origin: DisplayXR/displayxr-shell-pvt#104
🤖 Generated with Claude Code