Open sbrinkerhoff opened 1 year ago
Hi, @sbrinkerhoff 👋 Thanks for the issue, we will investigate it and get back to you with updates.
@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.
@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.
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.
same issue here
@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 theActions
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.
+1 – I have the same problem
+1 here as well
+1
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
I'll publish this as a release from my repo
anyone annoyed by this like me, swap actions/setup-dotnet@...
with jasoncouture/setup-dotnet@v4.0.1
or just drop to v2.0.0
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
+1
Description: A default usage of The Github/Microsoft
setup-dotnet
action on a Github Runner managed by the GitHub/Microsoftactions-runner-controller
fails to install.Task version:
v3
Platform:
Runner type:
Repro steps:
Expected behavior: The
setup-dotnet
should install into an unpriviledges path similar tosetup-node
,setup-python
,setup-java
. These actions all work out of the box on the Github/Microsoft Actions Runner Controller.Actual behavior: