SDK versions already on the VM are installed a second time and pre-installed SDKs become unavailable

[xt0rted]

Description:

Calling this action with an SDK version pre-installed on the VM causes it to be installed a second time and the pre-installed SDKs become unavailable.

Task version: v2

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:

Call actions/setup-dotnet with a list of sdks that are pre-installed:

- name: Set up .NET
  uses: actions/setup-dotnet@v2.0.0
  with:
    dotnet-version: |
      3.1.417
      5.0.406
      6.0.201

Expected behavior:

1. For any SDK version installed by this action to be skipped if it's already installed on the VM.
2. All pre-installed SDKs to be available after calling this action.

Actual behavior:

On macos-latest the v3 and v5 SDKs are skipped because they're already installed while v6 is downloaded and installed. Calling this a second time shows all 3 SDKs being skipped. After calling this action the pre-installed and newly installed SDKs are shown with dotnet --info.

On ubuntu-latest and windows-latest all 3 SDKs are downloaded and installed even though they're pre-installed. Calling this a second time shows all 3 SDKs being skipped. After calling this action only the newly installed SDKs are shown with dotnet --info, any pre-installed SDK becomes unavailable.

This is being caused by the installation location of the SDKs on Ubuntu and Windows differing from the pre-installed location, while on macOS it's the same location.

Two test runs can be seen here:

• Latest patch versions
• Explicit versions

Calling dotnet --info gives the following results (see the above build logs for more info):

macOS out of the box

.NET SDKs installed:
  3.1.101 [/Users/runner/.dotnet/sdk]
  3.1.201 [/Users/runner/.dotnet/sdk]
  3.1.302 [/Users/runner/.dotnet/sdk]
  3.1.417 [/Users/runner/.dotnet/sdk]
  5.0.102 [/Users/runner/.dotnet/sdk]
  5.0.202 [/Users/runner/.dotnet/sdk]
  5.0.302 [/Users/runner/.dotnet/sdk]
  5.0.406 [/Users/runner/.dotnet/sdk]

macOS after calling actions/setup-dotnet

.NET SDKs installed:
  3.1.101 [/Users/runner/.dotnet/sdk]
  3.1.201 [/Users/runner/.dotnet/sdk]
  3.1.302 [/Users/runner/.dotnet/sdk]
  3.1.417 [/Users/runner/.dotnet/sdk] <- skipped
  5.0.102 [/Users/runner/.dotnet/sdk]
  5.0.202 [/Users/runner/.dotnet/sdk]
  5.0.302 [/Users/runner/.dotnet/sdk]
  5.0.406 [/Users/runner/.dotnet/sdk] <- skipped
  6.0.201 [/Users/runner/.dotnet/sdk] <- installed

Windows out of the box (similar for Ubuntu)

.NET SDKs installed:
  3.1.120 [C:\Program Files\dotnet\sdk]
  3.1.202 [C:\Program Files\dotnet\sdk]
  3.1.302 [C:\Program Files\dotnet\sdk]
  3.1.417 [C:\Program Files\dotnet\sdk]
  5.0.104 [C:\Program Files\dotnet\sdk]
  5.0.212 [C:\Program Files\dotnet\sdk]
  5.0.303 [C:\Program Files\dotnet\sdk]
  5.0.406 [C:\Program Files\dotnet\sdk]
  6.0.201 [C:\Program Files\dotnet\sdk]

Windows after calling actions/setup-dotnet (similar for Ubuntu)

.NET SDKs installed:
  3.1.417 [C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\sdk] <- installed
  5.0.406 [C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\sdk] <- installed
  6.0.201 [C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\sdk] <- installed

Where's versions 3.1.120, 3.1.202, 3.1.302, 5.0.104, 5.0.212, 5.0.303?

[vsafonkin]

Hi @xt0rted, you are absolutely correct, there is pull request with ADR for this problem: #208

We will try to resolve this issue in future. Since it's known issue, I'm going to close this one. Please, contact with us if you have any concerns, thank you!

[xt0rted]

I think a workaround for this is to set the DOTNET_INSTALL_DIR environment variable. Doing so skips the versions already installed and preserves those that are installed.

- run: echo "DOTNET_INSTALL_DIR=/usr/share/dotnet" >> $GITHUB_ENV
  if: startsWith(matrix.os, 'ubuntu')
  shell: bash

- run: echo "DOTNET_INSTALL_DIR=C:\Program Files\dotnet" >> $GITHUB_ENV
  if: startsWith(matrix.os, 'windows')
  shell: bash

https://github.com/xt0rted-test/setup-dotnet-test/runs/5974572967?check_suite_focus=true#step:6:17

[PureKrome]

@vsafonkin That's great news that there's a PR to handle this issue! .. except .. that PR was created in July June 2021. That's like 10 months ago! Surely there can be someone to review it?

[vsafonkin]

@PureKrome, sure, it was discussed by our team but now it's not priority feature unfortunately.

[PureKrome]

Cheers @vsafonkin for the prompt reply - really appreciate it! 🍻

it's not priority feature unfortunately.

I'll actually edit your reply, on behalf of a large chunk of the community when they actually read what you're saying:

"It was discussed by our team but we believe .NET is a 3rd class citizen behind all the other cooler langs so no one is going to be bothered. Look, I know it's a simple'ish fix but ... nope. Go learn node then talk to us. kthxbai! 👋🏻 "

sadness :(

[vsafonkin]

@PureKrome, our team supports several setup actions and setup-dotnet is used almost ten times less than for example setup-python or setup-node. So the more frequently used actions are considered first.

[PureKrome]

@vsafonkin cheers for the reply!

are you (or someone else?) able to list/release top setup-xxx actions that are used? Can we see the data to backup these claims? (yes, I believe that there would be more people using python or node over dotnet)

[xt0rted]

You can see usage in public repos, but that's it. Action authors can't see usage stats either unfortunately. My guess is setup-dotnet is used in a lot of private repos making this number not accurate but who knows. I'm sure there's a fair amount of missed opportunities here with people sticking with Azure DevOps too.

Action	Usage
setup-node	710,438
setup-python	444,788
setup-java	260,679
setup-go	189,716
setup-dotnet	86,306
setup-ruby (archived)	27,067
setup-haskell (archived)	2,233
setup-elixir (archived)	2,078

[PureKrome]

Great data @xt0rted !!! Awesome to see the public repo breakdown 👍🏻 👏🏻

( but I'm crying inside 😢 )

[mattjohnsonpint]

An alternative form of the workaround, if you don't want to run additional steps:

env:
  DOTNET_INSTALL_DIR: ${{ startsWith(matrix.os, 'ubuntu') && '/usr/share/dotnet' || startsWith(matrix.os, 'windows') && 'C:\Program Files\dotnet' || '' }}

[xt0rted]

In the end I set up a composite action that handles this and a few other things that aren't yet supported so it's easier to apply to all of my repos. The workaround was adjusted so it supports all three platforms now:

- shell: bash
  run: |
    case "${{ runner.os }}" in
      macOS) echo "DOTNET_INSTALL_DIR=/Users/runner/.dotnet" >> $GITHUB_ENV;;
      Linux) echo "DOTNET_INSTALL_DIR=/usr/share/dotnet" >> $GITHUB_ENV;;
      Windows) echo "DOTNET_INSTALL_DIR=C:\Program Files\dotnet" >> $GITHUB_ENV;;
      *) echo "::warning::Unsupported runner os: ${{ runner.os }}";;
    esac

[Piedone]

With v3 out, shouldn't there be no installation happen if the desired version is already installed on the image? I don't see any change in behavior. Running the following under Windows, for example, still takes about 43s, not what I'd expect if it would just use the preinstalled .NET SDK:

    - name: Set up .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: '6.0.x'

[IvanZosimov]

Hi, @Piedone 👋 Thanks for the question! The latest version of the .NET SDK on the 6.0 channel now is 6.0.402. The latest preinstalled .NET SDK version on our hosted runners is still 6.0.401 ( due to the deployment delays, but it will be updated very soon). That's why when you're specifying dotnet-version as 6.0.x you can see the process of downloading and installing .NET 6.0.402 which takes some time. If you specify dotnet-version as 6.0.401 which is preinstalled on the runner, setup-dotnet won't take so long.

[Piedone]

Ah, I see, that makes sense, my understanding of the behavior was wrong. Thank you for your quick reply! I can verify that it works faster if I specify a version already installed (<10s vs 15s under Ubuntu, and <25s vs almost 3 minutes under Windows).