Use the binary dotnet SDK in Darwin dev shells#1723
Conversation
The csharp dev shell takes dotnetCorePackages.sdk_10_0, which resolves to the source-built VMR SDK. The public nix cache has no Darwin binaries for the VMR, so every uncached realization compiles the entire .NET SDK from source. On CI this dominates the macOS csharp job: of a 2h29m run, nix develop spent 2h24m building dotnet-vmr derivations while the actual work took under five minutes (cargo build 4m09s, bindings generation 2s, dotnet test 8s). macOS contributors pay the same cost on their first nix develop .#csharp. Use the Microsoft-binary SDK on Darwin instead; it satisfies the same global.json band (10.0.1xx) and keeps the share/dotnet layout DOTNET_ROOT expects. Linux keeps the source-built SDK, which hydra serves from cache.
The unix csharp jobs run inside the flake's csharp dev shell, so a flake change alters this workflow's environment without running it. Include the flake in the path filter; it also lets this branch's dev shell change demonstrate its effect on the macOS job time.
|
Pushed a second commit adding |
The dart, javascript and python jobs run inside flake dev shells, same as csharp: a flake change alters their environment without running them. Give them the same flake path filter.
|
Extended the path-filter fix to the dart, javascript and python workflows in the last commit, they run inside flake dev shells the same way, so they had the same blind spot. Their runs on this PR also serve as confirmation that the Darwin SDK change doesn't disturb the other shells. |
Coverage Report for CI Build 29044042286Coverage remained the same at 86.003%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
|
Measurement is in: Build and test csharp (macos-latest) now passes in 12m12s on this PR, versus ~150–170 min on every prior run of the workflow, with no dotnet-vmr derivations built. Ubuntu is unchanged at 31m20s, as expected since the Linux shell keeps the source-built SDK. dart/javascript/python runs on this PR confirm the flake change is inert for the other shells. |
Mshehu5
left a comment
Mshehu5
left a comment
There was a problem hiding this comment.
ACK
From https://github.com/payjoin/rust-payjoin/actions/runs/29044042346/job/86208148899 time Has improved.
Nice !
4 participants
The "Build and test csharp (macos-latest)" job takes 2.5–3 hours on every run (2h51m, 2h53m, 2h29m on the three most recent PRs, and the same ~150–170 min on every earlier
csharp.ymlrun sampled back through July 4). The job log shows where the time goes: of a 2h29m run, the script itself, cargo build, bindings generation,dotnet test, finishes in under five minutes (4m09s + 2s + 8s); the remaining ~2h24m isnix develop .#csharpbuildingdotnet-vmrderivations before the command even starts.dotnetCorePackages.sdk_10_0resolves to the source-built VMR SDK, and the public nix cache has no Darwin binaries for it, so every macOS CI run, and every macOS contributor's firstnix develop .#csharp, compiles the entire .NET SDK from source.This switches the Darwin dev shells to the Microsoft-binary SDK,
sdk_10_0_1xx-bin: the same10.0.1xxfeature band thatglobal.jsonrequires (10.0.100,rollForward: latestFeature), and the sameshare/dotnetlayout thatDOTNET_ROOTexpects. Linux keeps the source-built SDK, which hydra serves from cache. After the change, the Darwin csharp shell's closure contains thedotnet-sdk-10.0.109-osx-arm64binary tarball and no VMR derivations.Disclosure: co-authored by Claude Code
Pull Request Checklist
Please confirm the following before requesting review:
AI
in the body of this PR.