Run gzip directly in BuildDockerImages instead of through pwsh - #2154
Merged
Conversation
BuildDockerImages launched PowerShell for exactly one thing: running
`gzip -k -9 -f` on the OCI tar. That made the step depend on whichever .NET
runtime the agent's `pwsh` global tool was built against, and on main's build
agent those no longer line up:
App: /root/.dotnet/tools/pwsh
Framework: 'Microsoft.NETCore.App', version '10.0.0'
.NET location: .../.nuke/temp/dotnet-unix
The following frameworks were found:
8.0.30
The agent's `pwsh` needs .NET 10, and the only runtime on offer is the .NET 8
SDK that build.sh bootstraps into .nuke/temp and puts on PATH. Calling gzip
directly removes pwsh from the equation. This was the build's only use of
PowerShellTasks, so nothing else in the build cares about the agent's pwsh now.
Failures also surface properly. `pwsh -Command` exits 0 regardless of the
native exit code, so a failed gzip used to show up later as a confusing
missing-artifact error from PublishArtifacts. A Nuke Tool asserts a zero exit
code, so it now fails at the gzip call with gzip's stderr attached.
Verified with a throwaway target: resolves /usr/bin/gzip from PATH, arguments
pass through intact, -k keeps the .tar alongside the .gz, and a deliberate
failure raises `ProcessException: Process 'gzip' exited with code 1`.
Not addressed here: reaching the SDK bootstrap at all means `dotnet --version`
failed, so the agent no longer satisfies global.json's 8.0.419 pin. That costs
every build a full SDK download and belongs with the .NET 10 work.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
APErebus
approved these changes
Sep 8, 2026
APErebus
left a comment
APErebus
left a comment
Contributor
There was a problem hiding this comment.
That is a much better way of invoking it. I didn't have enough Nuke knowledge to know how to invoke tools directly
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
2 participants
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.
Build: Docker images failing... but why now...
BuildDockerImageslaunchedpwshfor one thing — runninggzipon the OCI tar. The agent'spwshis a dotnet global tool needing .NET 10, whilebuild.shbootstraps a .NET 8-only SDK into.nuke/temp/dotnet-unixand puts it onPATH:Why it started failing on 2026-09-07: the
nautilus-linuxagent image changed between the last green build (24081109, Sep 3) and the first red one (24122436, Sep 7) — bash 5.1.4 -> 5.2.21, and the system SDK it reports went 6.0.428 -> 10.0.400. Both logs show the same./build.sh BuildDockerImagesand the same net8 SDK bootstrap,BuildDockerImages.xmlis untouched in the settings diff between the two builds, and no Calamari commit landed in that window. The agent'spwshis the only variable that moved.So: call
gzipdirectly. This was the build's only use ofPowerShellTasks.Also stops a silent failure —
pwsh -Commandexits 0 regardless of the native exit code, so a failed gzip used to surface later as a missing artifact inPublishArtifacts. A NukeToolasserts a zero exit code.Verified locally
/usr/bin/gzipfromPATH,-kstill keeps the.tarnext to the.gz, and a forced failure throwsProcessException: Process 'gzip' exited with code 1.🤖 Generated with Claude Code