Set DOTNET_CLI_HOME to a repo-local path

[dsplaisted]

• This issue is blocking
• This issue is causing unreasonable pain

By default, the CLI will use a user-specific folder for a few things, including first run sentinels and global tool information. The folder can be overridden with the DOTNET_CLI_HOME environment variable. Arcade should set this variable to a repo-local path, to avoid different builds (ie on CI machines or build servers) sharing this folder. While we should generally keep compatibility, that may not always be true between interim preview builds.

This has broken builds at least twice:

• SDK with net5.0 change fails to restore dotnet repo tools sdk#10938 (comment)
• Upgrade to more recent .NET SDK aspnetcore#21017 (comment)

[ViktorHofer]

@janvorli that's the issue that is tracking the right fix for the issue that you were seeing locally. cc @jaredpar

[riarenas]

Running this test build where I set the variable to the build workspace directory: https://dev.azure.com/dnceng/internal/_build/results?buildId=724637&view=results

[riarenas]

Ahh, forgot that arcade doesn't have a linux build leg. Will test this in arcade-validation instead.

[riarenas]

PR to set this during CI: #5775

[riarenas]

My fix doesn't work for docker containers that are started during the build, as oposed as having the entire leg running inside a container. Reopening.

https://dev.azure.com/dnceng/internal/_build/results?buildId=735034&view=logs&j=b72e85ab-3386-5aa9-6405-3837662d9688&t=f60252b2-6cdd-5047-3d04-b33edb9d8faa

[riarenas]

Made a better fix, which sets the variable to the root of the repo during CI in #5805

[MattGal]

Reopening and putting in the backlog. This change was the source for #5813 , but since it has the context I'm reactivating this one.

The latest arcade validation builds were failing to resolve nuget v3 paths, reverting just this change unblocked them, as shown in this build

[riarenas]

I believe the change is still the correct change, and whoever picks this up next can investigate why this fails runtime's build. My guess is that Runtime is doing something weird and they should react to the change, rather than not making it.

[alexperovich]

Okay I figured out why this change broke runtime. The build uses a NuGetAuthenticate task (https://github.com/microsoft/azure-pipelines-tasks/blob/d925deb300d85a09f8ed2d5d8a16f74cdb6fa8c5/Tasks/NuGetAuthenticateV0/main.ts#L16) to authenticate to private azure feeds.

That task installs the credential provider into the $HOME directory, if we then set DOTNET_CLI_HOME to something else, that credential provider is lost and the restore can't use private feeds.

I think we just.... can't set DOTNET_CLI_HOME, unless we want to copy the plugins from $HOME into the new location at the same time.

[MattGal]

Thanks @alexperovich . I think at this point let's drop it out of FR (remove epic and labels) so we can make sure there's consensus on "won't fix-ing" tomorrow at triage?

[alexperovich]

Yea, thats probably good.

[ViktorHofer]

Great finding, thanks Alex. Should we fix https://github.com/microsoft/azure-pipelines-tasks/blob/69bdf79bd5d624cf5f8733cd25636df5008f7cf2/Tasks/Common/artifacts-common/credentialProviderUtils.ts#L96 to respect the environment variable and not blindly read from the hardcoded location? cc @nkolev92

[alexperovich]

Making that task respect the environment variable is probably good, but it wouldn't fix it in this case because the variable isn't until tools.ps1 is called. We would need to set that variable in the build earlier than the restore task.

…

-------- Original message -------- From: Viktor Hofer <notifications@github.com> Date: 7/30/20 9:31 AM (GMT-08:00) To: dotnet/arcade <arcade@noreply.github.com> Cc: Alex Perovich <Alex.Perovich@microsoft.com>, Mention <mention@noreply.github.com> Subject: Re: [dotnet/arcade] Set DOTNET_CLI_HOME to a repo-local path (#5402) Great finding, thanks Alex. Should we fix https://github.com/microsoft/azure-pipelines-tasks/blob/69bdf79bd5d624cf5f8733cd25636df5008f7cf2/Tasks/Common/artifacts-common/credentialProviderUtils.ts#L96<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fazure-pipelines-tasks%2Fblob%2F69bdf79bd5d624cf5f8733cd25636df5008f7cf2%2FTasks%2FCommon%2Fartifacts-common%2FcredentialProviderUtils.ts%23L96&data=02%7C01%7CAlex.Perovich%40microsoft.com%7C5814eb3aa50e49a13aa108d834a60411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317234925248414&sdata=onuUCV%2FzcKv5Htbs4vYJ1aRI3fsWmpWfDGpgt%2F9OpRI%3D&reserved=0> to respect the environment variable and not blindly read from the hardcoded location? cc @nkolev92<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnkolev92&data=02%7C01%7CAlex.Perovich%40microsoft.com%7C5814eb3aa50e49a13aa108d834a60411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317234925258406&sdata=vD8zW47%2BSr9lOOSSYMCfYsDbH6srM5xeScMnEhgp8Hs%3D&reserved=0> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Farcade%2Fissues%2F5402%23issuecomment-666508927&data=02%7C01%7CAlex.Perovich%40microsoft.com%7C5814eb3aa50e49a13aa108d834a60411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317234925268405&sdata=QK1xFd8Zxa75TDfNV1MEmZ3sISyXFdCy3jQO82bV%2Fvc%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACQTOIWN72QFLKNM5ZM5HADR6GN6FANCNFSM4MY4TDBQ&data=02%7C01%7CAlex.Perovich%40microsoft.com%7C5814eb3aa50e49a13aa108d834a60411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317234925268405&sdata=TK97TnnMsFeWQ%2BB0TVMyUMKWsqgacSl6uWr2rSKu4Bk%3D&reserved=0>.

[alexperovich]

Filed issue with azure pipelines: microsoft/azure-pipelines-tasks#13375

[garath]

Triage: For Helix, a Big Improvement would be to recycle machines for every build (hosted pool does this).

[lukas-lansky]

I'm all for better isolation between CI builds – it really makes everything so much simpler – but dotnet/runtime#34994 is a local build problem and is waiting for the resolution of this issue.

[ViktorHofer]

This issue points to a local build problem, you are right. But we would still see the issue if we wouldn't have disable repo tools being restored in CI temporarily: dotnet/runtime@97d1f96. So this still very much applies and needs to be fixed.