The arcade tools.ps1 and tools.sh scripts currently set the ArtifactsDir or artifacts_dir unconditionally. It looks like they respect the DOTNET_INSTALL_DIR environment variable, but if it is set then it needs to be to a location where the .NET SDK is already installed. There's no way to specify a path to override the location where the scripts will download the .NET SDK to if necessary.
I'd like to be able to override both of these locations with environment variables. RepoLayout.props might also need to be adjusted in sync with the script changes.
This would be helpful because in dotnet/core-sdk, we use Docker to build for various flavors of Linux. This is also useful for local development if we need to work with a specific version of Linux. However, since the repo root is shared from the host to the docker container, the build in the docker container would try to use the version of the .NET SDK that the host had installed, and would produce its output in the same paths as the host OS did. So to do a Docker build, we would need to clean the .dotnet and artifacts folder in the repo. This makes it more painful to switch between building in the host and using Docker.
@tmat
The arcade
tools.ps1andtools.shscripts currently set theArtifactsDirorartifacts_dirunconditionally. It looks like they respect the DOTNET_INSTALL_DIR environment variable, but if it is set then it needs to be to a location where the .NET SDK is already installed. There's no way to specify a path to override the location where the scripts will download the .NET SDK to if necessary.I'd like to be able to override both of these locations with environment variables.
RepoLayout.propsmight also need to be adjusted in sync with the script changes.This would be helpful because in dotnet/core-sdk, we use Docker to build for various flavors of Linux. This is also useful for local development if we need to work with a specific version of Linux. However, since the repo root is shared from the host to the docker container, the build in the docker container would try to use the version of the .NET SDK that the host had installed, and would produce its output in the same paths as the host OS did. So to do a Docker build, we would need to clean the .dotnet and artifacts folder in the repo. This makes it more painful to switch between building in the host and using Docker.
@tmat