setup-dotnet icon indicating copy to clipboard operation
setup-dotnet copied to clipboard

Fallback to different installation directory if `/usr/share/dotnet` doesn't available due to permissions

Open maxim-lobanov opened this issue 11 months ago • 5 comments

Description:

By default, dotnet is downloaded and installed under /usr/share/dotnet folder: https://github.com/actions/setup-dotnet/blob/5d1464d5da459f3d7085106d52e499f4dc5d0f59/src/installer.ts#L220 Unfortunately, it is not great location because on some self-hosted runners and some Larger Runners (Linux Arm64 private beta), user doesn't have enough permissions to create / modify this folder.

In this case, action will fail with error: Error: Failed to install dotnet, exit code: 1. mkdir: cannot create directory '/usr/share/dotnet': Permission denied

Proposed solution I guess it is not possible to change default location /usr/share/dotnet to some new location because it will be a breaking change. So I am proposing adding a new fallback location in case if user doesn't have permissions for /usr/share/dotnet. It won't be a breaking change because fallback will be used only in cases when the current version of action would fail.

This action can check permissions of /usr/share/dotnet folder. If user doesn't have permissions to create / modify this folder, then the action should use different DOTNET_INSTALL_DIR directory instead of /usr/share/dotnet.

For example, it can use:

  • $HOME/.dotnet -> this way location will be consistent with MacOS Runners + user always have permissions to $HOME
  • <runner.temp>/.dotnet -> https://docs.github.com/en/actions/learn-github-actions/contexts#runner-context

Alternative solutions

There are two alternative solutions:

  • Change permissions of /usr/share/dotnet once on self-hosted agent -> Unfortunately, it won't fix Linux Arm64 Larger Runners. Also, it is not super convenient and involve manual actions
  • User can override DOTNET_INSTALL_DIR environment variable by themselves -> it is definitely possible option but it is not super convenient and user needs to do it for every workflow YAML

We definitely have workarounds but it would be great if action can handle this case without workarounds.

maxim-lobanov avatar Mar 22 '24 15:03 maxim-lobanov

Hello @maxim-lobanov Thank you for creating this feature request. We will investigate it and get back to you as soon as we have some feedback.

HarithaVattikuti avatar Mar 22 '24 15:03 HarithaVattikuti

Seems to be a duplicate of #360.

@HarithaVattikuti, if you could check the PR #498 that seems to fix those issues.

Thank you in advance!

tremblaysimon avatar Apr 01 '24 18:04 tremblaysimon

@tremblaysimon I think https://github.com/actions/setup-dotnet/pull/498 implements a bit different approach and I worry that it can't be accepted because it will be a breaking change.

The current path priorities:

  1. env['DOTNET_INSTALL_DIR']
  2. /usr/share/dotnet
  3. env['RUNNER_TOOL_CACHE'] -> I propose adding a new location on third position in list of priorities.

https://github.com/actions/setup-dotnet/pull/498 changes path priorities to:

  1. env['DOTNET_INSTALL_DIR']
  2. env['RUNNER_TOOL_CACHE']
  3. /usr/share/dotnet

I could be wrong but It will be a breaking change for all hosted runners because all hosted runners will change default location from /usr/share/dotnet to env['RUNNER_TOOL_CACHE']. Hosted runners have a cache of dotnet versions which is stored under /usr/share/dotnet: https://github.com/actions/runner-images/blob/2fd9adccce8acd226d394935c55b8a932b04d315/images/ubuntu/toolsets/toolset-2204.json#L274. Changing the priorities order means that task will ignore cache on all hosted runners and will always download dotnet on flight. It can significantly increase workflow run duration for users of hosted runners.

maxim-lobanov avatar Apr 02 '24 10:04 maxim-lobanov

+1, this same issue occurs with windows self hosted runners as well. For example when trying to install 6.0.x using v4 a pair of access denied exceptions occur.

Access to the path 'C:\Program Files\dotnet\host\fxr\8.0.4' is denied. Access to the path 'C:\Program Files\dotnet\sdk\6.0.421' is denied.

cjj196 avatar May 07 '24 16:05 cjj196

The interesting case we have with this, is that on Ubuntu 24.04 it's all installed to /usr/lib/dotnet not /usr/share/dotnet - however, even when you change the ~/.bashrc file to override the DOTNET_INSTALL_DIR to /usr/lib/dotnet the action still doesn't seem to work ..... the action still tries to point at /usr/share/dotnet

no1melman avatar Sep 09 '24 16:09 no1melman