Core: The .NET Core SDK requires a restart before installing tools

[TomasHubelbauer]

I'm using the .NET Core SDK that comes with a GitHub Actions agent (3.0.101) and since it comes with the agent image I don't even need to install it, it comes out of the box. However, on the image, it is installed, but never invoked, so my workflow running in the first run experience. The first line of my workflow script is dotnet tool install -g dotnet-script, but it fails with * Since you just installed the .NET Core SDK, you will need to logout or restart your session before running the tool you installed.*. I cannot restart the GitHub Actions agent, it is an ephemeral VM which runs only for the workflow run. Is there any way to around this? I would like to install and use the tool on the agent, but if it truly requires a restart and there is no way around it, I don't think that is going to be possible.

[scalablecory]

I believe Github Actions uses Docker. @MichaelSimons any advice here?

[TomasHubelbauer]

You make a good point, I am not aware of how GitHub Actions are ran "on the outside", but I supposed I could use Docker within the action to have a docker-in-docker (assuming GitHub Actions indeed run in a Docker container) scenario where I can restart the internal container at will. However, that's not how my Action is currently structured, most my Actions are a simple Bash script and I think it would be a shame to have to lose that simplicity just to use .NET Core.

BTW I fixed this particular problem by installing .NET Script from a binary download and calling it by its full path (not using dotnet script), so I'm not blocked on this, but this issue serves for a discussion about the broader point of the forced restart which I believe deserves some attention.

[carlossanlop]

Adding @livarcocc and @nguerrera in case they can provide information about why this error showed up.

[nguerrera]

Does a step actually fail or is that message just printed as information? If the latter, I imagine you could add a step to add ~/.dotnet/tools (from memory, not sure that is the exact path) to PATH and ignore the message. @wli3 can you confirm?

[nguerrera]

Or add to PATH before calling dotnet install and not even get the message?

[wli3]

In an environment that you don't have full control, I suggest avoid using -g with tools. Since it is installed globally and require PATH change. You should use --tool-path and invoke the tool with full path. Or you could do as Nick suggested, add ~/.dotnet/tools to PATH of your current session.

This is by design (--tool-path is added for this specific scenario).

[TomasHubelbauer]

I'm slightly confused about what --tool-path brings. This is likely wrong, so correct me please, but doesn't using --tool-path defeat the whole purpose of dotnet tool? At that point I can continue doing as I do - invoking the tool by its path directly, or as Nick suggested, adding it to PATH myself and then calling it that way. In any case, this being by design resolves the issue. I wonder if there's a future improvement possibility where it is installed in session PATH if unable to install to system PATH, pit of success and all that, but for now, this is good enough for me, just wanted to know what's up.

[wli3]

I wonder if there's a future improvement possibility where it is installed in session PATH if unable to install to system PATH

Changing path by a program for the current session is impossible for Linux or Windows shells(or induce a great security risk). Although we could print out the message to ask the user to manually add it.

https://github.com/dotnet/sdk/issues/4051

[TomasHubelbauer]

Awesome 🙂

[nguerrera]

doesn't using --tool-path defeat the whole purpose of dotnet tool

You still get to use dotnet tool to easily acquire the tools, you just tell it to put the tools in a specific place and execute them from there instead of expecting them to be globally available.

[grassit]

In an environment that you don't have full control, I suggest avoid using -g with tools. Since it is installed globally and require PATH change. You should use --tool-path and invoke the tool with full path. Or you could do as Nick suggested, add ~/.dotnet/tools to PATH of your current session.

This is by design (--tool-path is added for this specific scenario).

When "it is installed globally and require PATH change", can a user the path where it is installed into their own PATH and thus solve the problem?

[wli3]

@grassit You could. You can use --tool-path to drop the asset into a directory that is already on the PATH.