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

[maxim-lobanov]

Description:

By default, dotnet is downloaded and installed under /usr/share/dotnet folder:

setup-dotnet/src/installer.ts

Line 220 in 5d1464d

linux: '/usr/share/dotnet',

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.

[HarithaVattikuti]

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.

[tremblaysimon]

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!

[maxim-lobanov]

@tremblaysimon I think #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.

#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.

[cjj196]

+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.