tools path are not in the env PATH Azure DevOps VMs

[wli3]

https://github.com/dotnet/cli/issues/8368#issuecomment-424963647

[wli3]

@bishal-pdMSFT can I create a smilar PR microsoft/azure-pipelines-tasks#7306 to add global tools path to PATH?

However, for non first party case. global tools requires changing global state of the machine. If the user does not have access like changing the PATH or repoen a shell session. --tool-path is the right option. It is targeted specific for this scenario.

[bishal-pdMSFT]

@wli3 I have already tried to do so in the PR: microsoft/azure-pipelines-tasks#8432. You can review it.
What kind of global state change are you talking about? Azure pipelines run tasks with a user credential which is not necessarily an admin user. Can that cause problem if we try to use global path?
Couple of folks already told that they would expect Azure pipelines to work without setting --tool-path.

[cosmoKenney]

@wli3 @bishal-pdMSFT I agree that we shouldn't have to use --tool-path. The problem with using this is that global tools are supposed to be, um, global.
My problem is that my global tool is installed on my dev box to the default location, and the .csproj for several projects run the tool during a build. However when I check-in, the CI build/publish pipeline is triggered and publishes the project which is expecting the tool in the default location (or in the path), but cannot find it (yes, there is a step before "dotnet publish" that installs the tool).
So I would either have have multiple installs of the global tool on my dev box (which defeats the "global" aspect of global tools), or I need a build/environment variable that I can use to specify the location for installed tools. It needs to be something that can be set once on my dev box, but overridden in the CI Pipeline.

[wli3]

@bishal-pdMSFT global state means PATH and dropping files in users' directory (compared with last only in the build)

[wli3]

i think the PR should be good

[wli3]

@cosmoKenney agree that keeping CI and local dev in sync is a problem for global tools. We are working on the local tools, that might help this situation. https://github.com/dotnet/cli/issues/9924

[3GDXC]

aws/aws-toolkit-azure-devops#336