Fix path handling in shell exectutor for bash-on-Windows
Description
For bash on Windows, different bash implementations use different path transformations. This leads to the runner having trouble locating the build and cache dirs, and to the general failure for artifact upload [issue #1246 (closed)].
The former problem has a simple work-around: specifying cache-dir
and build-dir
in the config overrides the paths set in executor_shell.go's init(). These default paths don't work because the $PWD
expands to a windows path rather than an msys or cygwin path.
The artifact upload problem arises from the same location: the line
runnerCommand, err := osext.Executable()
expects that the path to self is usable inside the shell environment the runner spawns. This isn't true for the bash-on-Windows case, and it breaks artifact handling.
Proposal
There are a few possible approaches:
-
Add a config item for the
runnerCommand
that can override the deduced gitlab-runner location, just as in thebuild-dir
/cache-dir
case. This would be relatively simple, pushing the bash-on-Windows problem onto the user as is done with the other properties (hey, anyone doing this knows they're dealing with an odd duck). -
Invoke the runner command without an absolute path. The user would have to ensure that the runner of their choice was available inside the shell environment in the PATH as with any other command. This might break existing working configurations, but it looks like an even easier change than (1).
-
Improve the path deduction for
$PWD
andosext.Executable()
to somehow be aware of the shell where these paths will be used and perform appropriate translation. This would be a complete solution, but seems complicated.