-
Notifications
You must be signed in to change notification settings - Fork 981
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
shell from prependpath #231
Conversation
@@ -56,26 +57,27 @@ public override void PrintActionDetails(ActionRunStage stage) | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just duplicated from Handler.AddPrependPathToEnvironment so it should function the same. Might could refactor a bit to reduce duplication
@@ -144,23 +146,27 @@ public async Task RunAsync(ActionRunStage stage) | |||
Inputs.TryGetValue("shell", out var shell); | |||
var isContainerStepHost = StepHost is ContainerStepHost; | |||
|
|||
// Prepend PATH before locating shell tool | |||
AddPrependPathToEnvironment(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we still need move AddPrependPathToEnvironment
up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -7,7 +7,7 @@ namespace GitHub.Runner.Sdk | |||
{ | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe check all reference of the Which
method to make sure we don't miss something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.shell
option, 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: