Conversation
| string shellCommand; | ||
| string shellCommandPath = null; | ||
| bool validateShellOnHost = !(StepHost is ContainerStepHost); | ||
| string prependPath = string.Join(Path.PathSeparator.ToString(), ExecutionContext.PrependPath.Reverse<string>()); |
There was a problem hiding this comment.
This is just duplicated from Handler.AddPrependPathToEnvironment so it should function the same. Might could refactor a bit to reduce duplication
| var isContainerStepHost = StepHost is ContainerStepHost; | ||
|
|
||
| // Prepend PATH before locating shell tool | ||
| AddPrependPathToEnvironment(); |
There was a problem hiding this comment.
do we still need move AddPrependPathToEnvironment up?
There was a problem hiding this comment.
Actually no, I misunderstood that it was using System.Environment vs ExecutionContext.Environment so this doesnt do anything. Ill move it back to minimize unnecessary changes
| public static class WhichUtil | ||
| { | ||
| public static string Which(string command, bool require = false, ITraceWriter trace = null) | ||
| public static string Which(string command, bool require = false, ITraceWriter trace = null, string prependPath = null) |
There was a problem hiding this comment.
maybe check all reference of the Which method to make sure we don't miss something else?
There was a problem hiding this comment.
I dont see anywhere else that it would be useful. Most/all other uses are "internal" such as locating chmod, chown, and cmd/tar (in self-updater) so it seems like we should avoid letting users do things that might get in the way of runner operations
Other than that, the GitSourceProvider uses it, and some people may want to use an updated version of git, but Im not very familiar with what this is used for, since I thought we just check out via action now. Is that somewhere this would be useful?
There was a problem hiding this comment.
i think we should be good, leave the gitsourceprovider along since we already switch to checkout@v2 which has the right behavior anyway. :)
* Prepend path before locating shell tool * Join optional prepended path to path before searching it * Use prepended path when whiching shell tool * Addition prependPath location * Also use prepended paths when writing out run details * Small tweak to undo unnecessary change
Fix for: https://github.com/actions/toolkit/issues/232
Setting a prepended path for a tool installation should work for anything downstream of that step (within a job). When we locate the tool via path to use for the
run.shelloption, we are using just the process env PATH and not the runner-tracked prepended pathsTested with this sample:
Previously, in the first job the last step (Verify new node via interpreter) would have printed 10 (installed on my vm) instead of 12. For containers it works because we use the container runtime to locate it (we just exec node, not exec by full path since we didnt know the path inside the container)
With this fix the node installed on the host by setup-node is used as the shell
In case anyone cares now or later, heres the (slightly trimmed down) logs from my sample: