You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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");
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.
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:
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
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");
NuGet/Home#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
The text was updated successfully, but these errors were encountered: