Closed dylan-smith closed 1 year ago
Our fix for the time-being is we're rolling back to setup-dotnet@v2
. This obviously isn't a long-term solution.
Hi, @dylan-smith 👋 As we discussed, you need to add global.json
file to your repository and set up the required version of .NET there. To make it more comfortable to work with the action, instead of setting dotnet-version
input, you can set global-json-file
input, and the action will read and install the .NET version from the global.json
you specify in the input. I'm going to close this issue now, if you have any additional questions feel free to ask them.
Thanks for the help @IvanZosimov . To make sure I understand what's going on here (and for the benefit of any future travelers that land on this issue), I'll try and sum up my understanding.
When building with dotnet
there is the .Net version that you are targeting - which is specified in the csproj. There is the .Net SDK version that you are using to build it (not necessarily the same as the target), and this is specified in a global.json
file, and if not present it will use the latest SDK version available on the machine.
setup-dotnet
doesn't set/pin either of these versions for you, instead it simply installs a specific version of .Net onto the build runner machine.
It seems the slowdown I was seeing was due to a difference in perf between using .Net SDK v6 vs v7. I was able to confirm this by adding a global.json forcing SDK v6 and the times became similar (setup-dotnet@v3
became faster to match the perf of v2).
What I don't understand is what was going on with setup-dotnet@v2
, it seemed that it was using .Net SDK v6 (the same version I specified in the dotnet-version
arg) despite .Net SDK v7 being present on the machine, and no global.json present.
It would be nice if there was a way to make setup-dotnet@v3
behave in a similar way to v2. Through some combination of args be able to say "install this version of .Net and make sure that it is used for all subsequent dotnet
commands (e.g. generate a global.json file for me)".
Thanks for the feedback, @dylan-smith 👋 We've started the internal investigation on this topic. We will keep you in the loop.
Description: We just recently upgraded to v3 of this action and it resulted in significantly slower dotnet builds. NOTE: It's not the setup-dotnet action that is slow, but the subsequent build step.
Task version: v2 is fast, v3.0.0 is slow
Platform:
Runner type:
Repro steps:
I created a small workflow that demonstrates the problem: https://github.com/dylan-smith/setup-dotnet-repro/blob/main/.github/workflows/blank.yml
It has a
build-v2
job and abuild-v3
job, the only difference is the version of thesetup-dotnet
task in them. All they do is checkout a dotnet repo,setup-dotnet
, then run adotnet publish
command. The dotnet publish command is significantly slower whensetup-dotnet@v3
is used.Windows/Ubuntu runners are more than 2x as slow when using
setup-dotnet@v3
. Mac runners don't seem to be affected.Ubuntu: 47s -> 97s Windows: 96s -> 256s Mac: 135s -> 139s
The workflow run/logs can be seen here: https://github.com/dylan-smith/setup-dotnet-repro/actions/runs/4609178383
Expected behavior: I wouldn't expect the version of
setup-dotnet
to affect dotnet build times, or if it did I would expect newer versions to improve build perf not decrease it.