timescale.info#226 · Install NSIS for the Windows server build without depending on Chocolatey
- timeline-app
- pull request
- packages
Closes #225. On 2026-10-19 the Chocolatey community feed answered 503 for hours, and every Windows server job failed installing NSIS (for example on #219, re-runs included). NSIS now comes from `deploy/windows-server/nsis.ps1`, which tries, in order: 1. **An NSIS already on the runner.** Same check as before. 2. **CI's cache.** The new **Cache NSIS** step restores `${{ runner.temp }}/nsis` from earlier runs, keyed on the script, so most runs need no network. 3. **The pinned portable release, NSIS 3.13** (the version Chocolatey was installing), from SourceForge. - **Checked:** against a pinned SHA-256, so a changed or substituted file is refused. - **Retried:** three times, with backoff. - **Downloaded as a command-line client:** SourceForge gives browsers a "your download will start" page instead of the file. 4. **Chocolatey, as before.** Last resort, three tries. The folder used goes on later steps' `PATH`, where `build.ps1` already looks for `makensis`. ### Checking - **The pinned hash:** two separate downloads of `nsis-3.13.zip` gave the same SHA-256. SourceForge's page doesn't expose its checksums to a script, so I couldn't compare against a published one. - **The script** ran in a PowerShell 7.5 container: - a fresh download, three times, unpacked a complete NSIS (`makensis.exe`, `Stubs`) and wrote the folder to `GITHUB_PATH`; - a cached copy was used without downloading; - with a wrong pin, all three downloads were refused and it fell through to Chocolatey, ending with a clear error since the container has none. - **On Windows:** that runner has no NSIS, so this PR's Windows server job exercises the download path for real.