Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
maxim-lobanov opened this issue Mar 22, 2024 · 5 comments
Labels
feature request New feature or request to improve the current logic

Comments

@maxim-lobanov
Copy link
Contributor

Description:

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

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:

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 maxim-lobanov added feature request New feature or request to improve the current logic needs triage labels Mar 22, 2024
@HarithaVattikuti
Copy link
Contributor

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
Copy link

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
Copy link
Contributor Author

@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
Copy link

cjj196 commented May 7, 2024

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

@no1melman
Copy link

no1melman commented Sep 9, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

5 participants