-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Support shared .NET installation #51725
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
Support shared .NET installation #51725
Conversation
|
I'm not a fan of being broken by changes to in the build agent. Thoughts on containerizing this stage to better isolate ourselves against these types of breaks? |
We could do that, but my fix is simply allowing us to use whichever .NET installation was provided by Created an issue for improvements in resiliency of |
Per offline discussion, both our comments are complimentary to each other. dotnet/source-build#5418 was logged to ensure a resilient solution is in place in main going forward that we can decide on backporting. |
|
Failing check is unrelated to my changes. This is an infra change - merging. |
06f40fb
into
dotnet:release/9.0.1xx
Fixes: dotnet/source-build#5408
VMR's
Tag & Scanstage runs multiple commands that require .NET. All scripts in the stage assumed that .NET is installed locally, to.dotnet. Installation is done viaarcade'sInitializeDotNetClifunction (in eng/common/tools.sh).InitializeDotNetCliskips .NET installation if the machine has the required version installed to a shared location.InitializeDotNetClisets the_InitializeDotNetClito the .NET path, local or shared.The fix is to use the .NET path that was obtained with
InitializeDotNetCli.Validation build