LibraryManager icon indicating copy to clipboard operation
LibraryManager copied to clipboard

DOTNET_CLI_HOME not respected, unset HOME can break CI

Open funktionalsystems opened this issue 4 years ago • 1 comments

Describe the bug

Similar to NuGet#6989 On non-Windows platforms, DOTNET_CLI_HOME does not override HOME. And if HOME is unset, it effectively defaults to / potentially causing permissions issues in CI/CD systems etc.

To Reproduce

Steps to reproduce the behavior:

  1. Run the following Jenkinsfile in Jenkins:

pipeline {
	agent {
		docker {
			image 'mcr.microsoft.com/dotnet/sdk:5.0'
		}
	}
	environment {
		DOTNET_CLI_HOME = "/tmp/DOTNET_CLI_HOME"
		//HOME = "/tmp/DOTNET_CLI_HOME" // This line will "fix" it, but above should be enough.
	}
	stages {
		stage('Setup') {
			steps {
				sh 'dotnet tool install -g Microsoft.Web.LibraryManager.Cli'
			}
		}
		stage('Build') {
			steps {
				sh 'libman --version'
				sh 'libman restore'
			}
		}
	}
}

Expected behavior

If DOTNET_CLI_HOME is set, libman restore runs without error even if HOME is unset. If neither is set, warn, rather than assuming '/.librarymanager'

Actual behavior

+ libman restore
Unhandled exception. System.TypeInitializationException: The type initializer for 'Microsoft.Web.LibraryManager.Configuration.Settings' threw an exception.
 ---> System.UnauthorizedAccessException: Access to the path '/.librarymanager' is denied.
 ---> System.IO.IOException: Permission denied
   --- End of inner exception stack trace ---
   at System.IO.FileSystem.CreateDirectory(String fullPath)
   at System.IO.Directory.CreateDirectory(String path)
   at Microsoft.Web.LibraryManager.Configuration.Settings.SaveSettingsFile(String filePath, JToken token) in C:\A\1\3\s\src\LibraryManager\Configuration\Settings.cs:line 170
   at Microsoft.Web.LibraryManager.Configuration.Settings.InitSettingsFile(String configFilePath) in C:\A\1\3\s\src\LibraryManager\Configuration\Settings.cs:line 82
   at Microsoft.Web.LibraryManager.Configuration.Settings..ctor() in C:\A\1\3\s\src\LibraryManager\Configuration\Settings.cs:line 73
   at Microsoft.Web.LibraryManager.Configuration.Settings..cctor() in C:\A\1\3\s\src\LibraryManager\Configuration\Settings.cs:line 35
   --- End of inner exception stack trace ---
   at Microsoft.Web.LibraryManager.Configuration.Settings.get_DefaultSettings() in C:\A\1\3\s\src\LibraryManager\Configuration\Settings.cs:line 35
   at Microsoft.Web.LibraryManager.Tools.Contracts.HostInteraction.get_Settings() in C:\A\1\3\s\src\libman\Contracts\HostInteraction.cs:line 41
   at Microsoft.Web.LibraryManager.Tools.Commands.ConfigCommand..ctor(IHostEnvironment hostEnvironment, Boolean throwOnUnexpectedArg) in C:\A\1\3\s\src\libman\Commands\ConfigCommand.cs:line 25
   at Microsoft.Web.LibraryManager.Tools.Commands.LibmanApp.Configure(CommandLineApplication parent) in C:\A\1\3\s\src\libman\Commands\LibmanApp.cs:line 34
   at Microsoft.Web.LibraryManager.Tools.Program.Main(String[] args) in C:\A\1\3\s\src\libman\Program.cs:line 32
Aborted (core dumped)

Additional context

libman --version 2.1.113+g422d40002e.RR

These spots could be changed to validate before calling Path.Combine: src/LibraryManager/Cache/CacheService.cs:46: CacheFolderValue = Path.Combine(localAppData, ".librarymanager", "cache"); src/LibraryManager/Configuration/Settings.cs:97: return Path.Combine(Environment.ExpandEnvironmentVariables(envVar), ".librarymanager");

https://github.com/NuGet/Home/issues/6989 https://newbedev.com/dotnet-build-permission-denied-in-docker-container-running-jenkins https://blog.jongallant.com/2018/09/solution-users-home-directory-could-not-be-determined/ https://stackoverflow.com/questions/53556623/dotnet-build-permission-denied-in-docker-container-running-jenkins

funktionalsystems avatar Aug 30 '21 21:08 funktionalsystems

This is probably a rare/niche problem. Docker alone works: docker run --rm -it -e DOTNET_CLI_HOME="/tmp/DOTNET_CLI_HOME" mcr.microsoft.com/dotnet/sdk:5.0 bash -c 'echo $DOTNET_CLI_HOME; dotnet tool install -g Microsoft.Web.LibraryManager.Cli; export PATH="$PATH:$DOTNET_CLI_HOME/.dotnet/tools"; libman --version; echo "{\"version\":\"1.0\",\"defaultProvider\":\"cdnjs\",\"libraries\":[{\"library\":\"[email protected]\",\"destination\":\"/app/wwwroot/lib/jquery/\"}]}" > libman.json; libman restore' So this is possibly only on CI/CD systems that don't set HOME, and can be worked around by manually setting it. The trick is knowing that you have to do that, so even a warning message to that effect would be handy.

funktionalsystems avatar Aug 31 '21 12:08 funktionalsystems