Allow artifacts and dotnet installation directory to be overridden

[dsplaisted]

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

[Chrisboh]

I dont think this is related to Helix. Kicking back to triage.

[markwilkie]

@dsplaisted - given the guidance in https://github.com/dotnet/arcade/blob/master/Documentation/DefaultsGuidance.md what do you think the right next steps are?

[dsplaisted]

@markwilkie This isn't really about preference for a different folder, which seems to be what the guidance is about. This is about making it easier to develop for multiple operating systems.

I had sent a PR to allow this, but Tomas had some feedback about it that we never resolved, mainly because this is only a priority for me sporadically, when I have to do OS-specific work.

[markwilkie]

I see - makes sense. Thoughts on next steps for this issue?

[dsplaisted]

I ended up needing this feature again, so I prototyped @tmat's suggestion from #1471: dotnet/installer@a99199e

How does that look?

[markwilkie]

The attached PR was stale and got closed - thus, am closing this issue as well.

[tmat]

@markwilkie Although we haven't had time to do this the scenario is still valid. I think we should keep the issue open on a backlog.