Default installation fails on ARC managed runners

[sbrinkerhoff]

Description:
A default usage of The Github/Microsoft setup-dotnet action on a Github Runner managed by the GitHub/Microsoft actions-runner-controller fails to install.

Task version:

v3

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:

name: "Test dotnet"

on:
  workflow_dispatch:
  
jobs:
  "test-aws-secure-access":
    name: "install dot net"
    runs-on: MyOrg-Enterprise-Testing
    steps:
    - uses: actions/setup-dotnet@v3
      with:
        dotnet-version: '3.1.x'

Expected behavior:
The setup-dotnet should install into an unpriviledges path similar to setup-node, setup-python, setup-java. These actions all work out of the box on the Github/Microsoft Actions Runner Controller.

Actual behavior:

Run actions/setup-dotnet@v3
/runner/_work/_actions/actions/setup-dotnet/v3/externals/install-dotnet.sh --channel 3.1
dotnet-install: Note that the intended use of this script is for Continuous Integration (CI) scenarios, where:
dotnet-install: - The SDK needs to be installed without user interaction and without admin rights.
dotnet-install: - The SDK installation doesn't need to persist across multiple CI runs.
dotnet-install: To set up a development environment or to run apps, use installers rather than this script. Visit https://dotnet.microsoft.com/download to get the installer.

mkdir: cannot create directory '/usr/share/dotnet': Permission denied
Error: Failed to install dotnet 1. dotnet-install: Note that the intended use of this script is for Continuous Integration (CI) scenarios, where:

[IvanZosimov]

Hi, @sbrinkerhoff 👋 Thanks for the issue, we will investigate it and get back to you with updates.

[IvanZosimov]

@sbrinkerhoff , the thing is that the setup-dotnet by default installs .NET SDKs into the default folder, which contains preinstalled versions of . NET. If on your own self-hosted runner you don't have write permissions to this default folder, you can specify the environment variable DOTNET_INSTALL_DIR, and the action will use the specified folder to install .NET SDKs there. Check our documentation with workflow examples to learn more.

[sbrinkerhoff]

@IvanZosimov I understand that the DOTNET_INSTALL_DIR can be altered. My original understanding was that this action was a Github owned action. I believe this living in the Actions Org suggests this action is github owned.

I have also opened a Github Enterprise Support Ticket #1927614.

Github owns the Actions Runner Controller project which is their recommended pattern for self-hosted runners.

This action is not compatible with that platform out of the box.

I certainly understand the technically correct answer of "the environment variable can be utilized" however from an ergonomics standpoint this means that every enterprise user of this action has to create their own action to wrap this action to have it work as intended.

My ask would be that this action be aware of the Actions Runner Controller project that Github owns and operates, and it works correctly on that environment without having to specify configuration changes.

setup-node, setup-python, setup-java (off the top of my head) all respect the Actions Runner Controller for example.

[mikeclayton]

I've just run into this issue as well on ARC scaleset runners.

I've noticed this still works with the v1 action:

      - name: setup
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: 7.0.x

which successfully executes .../setup-dotnet/v1/externals/install-dotnet.sh --version 7.0.304 to download and install https://dotnetcli.azureedge.net/dotnet/Sdk/7.0.304/dotnet-sdk-7.0.304-linux-x64.tar.gz.

but this fails with the v3 action:

      - name: setup
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: 7.0.x

while running .../setup-dotnet/v3/externals/install-dotnet.sh --channel 7.0 to download and install : https://dotnetcli.azureedge.net/dotnet/Sdk/7.0.304/dotnet-sdk-7.0.304-linux-x64.tar.gz.

This is on ephemeral single-use runners, so a clean image every time.

I've not tried the v2 action to confirm either way if it works or not, but I'll report back if / when I get a chance...

---

update - setup-dotnet@v2 appears to work as well. I've also tested with v3.0.0 which fails.

[chenghuang-mdsol]

same issue here

[felixlut]

@IvanZosimov I understand that the DOTNET_INSTALL_DIR can be altered. My original understanding was that this action was a Github owned action. I believe this living in the Actions Org suggests this action is github owned.

I have also opened a Github Enterprise Support Ticket #1927614.

Github owns the Actions Runner Controller project which is their recommended pattern for self-hosted runners.

This action is not compatible with that platform out of the box.

I certainly understand the technically correct answer of "the environment variable can be utilized" however from an ergonomics standpoint this means that every enterprise user of this action has to create their own action to wrap this action to have it work as intended.

My ask would be that this action be aware of the Actions Runner Controller project that Github owns and operates, and it works correctly on that environment without having to specify configuration changes.

setup-node, setup-python, setup-java (off the top of my head) all respect the Actions Runner Controller for example.

Just gonna drop a +1 here as well. The GHES docs about pre-populating the tools cache mentions that the setup-actions generally should place the tool in RUNNER_DIR/_work/_tool. GitHub not following their own recommendations for dotnet is a bit inconsistent.

[dnaprawa]

+1 – I have the same problem

[jasoncouture]

+1 here as well

[jasoncouture]

+1

[jasoncouture]

Posted PR #498 to fix the issue
Tested with one of my own repos, on ARC runner scale sets running on k8s: https://github.com/jasoncouture/dhcpr/actions/runs/7509545156/job/20446802058

[jasoncouture]

I'll publish this as a release from my repo

[jasoncouture]

anyone annoyed by this like me, swap actions/setup-dotnet@... with jasoncouture/setup-dotnet@v4.0.1
or just drop to v2.0.0

[bliles]

This setup-dotnet@v3 also breaks for my AWS self-hosted runners since they don't have root access. It seems like this should actually be a bug since it is a regression from setup-dotnet@v2

[joaopedrocg27]

+1