You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we are using tart for running gitlab-ci pipelines (great project btw, it's really the thing i've been looking for)
now, a couple of our pipelines have code like this:
FLAGS="--foo --bar"
./somecmd ${FLAGS}
under bash (which used to be the default shell for all our cross-platform pipelines until now) this will run ./somecmd --foo --bar.
however, the tart executor defaults to using zsh, which does not do word-splitting for non-quoted variables, and the command excuted is effectively ./somecmd "--foo --bar", which of course is something completely different.
now seeing that there is a TART_EXECUTOR_SHELL variable that i can set to bash, i figured that this would solve my problems...
only to discover, that the bash-environment significantly differs from the default environment.
for me the difference is most prominently the lack of the brew, which stems from paths not being initialized.
so here's a test-pipeline to examine the current behaviour
just for completeness sake: the original problem i'was trying to solve with using TART_EXECUTOR_SHELL (that zsh does not do word-splitting on unquoted variables), can be worked around by adding something like this to the pipeline:
set -o shwordsplit ||true
but it nevertheless seems that the TART_EXECUTOR_SHELL's usefulness is severely lessened if many tools cannot be used when it is set.
we are using
tart
for running gitlab-ci pipelines (great project btw, it's really the thing i've been looking for)now, a couple of our pipelines have code like this:
under
bash
(which used to be the default shell for all our cross-platform pipelines until now) this will run./somecmd --foo --bar
.however, the tart executor defaults to using
zsh
, which does not do word-splitting for non-quoted variables, and the command excuted is effectively./somecmd "--foo --bar"
, which of course is something completely different.now seeing that there is a
TART_EXECUTOR_SHELL
variable that i can set tobash
, i figured that this would solve my problems...only to discover, that the bash-environment significantly differs from the default environment.
for me the difference is most prominently the lack of the
brew
, which stems from paths not being initialized.so here's a test-pipeline to examine the current behaviour
which gives me one successful job (where
TART_EXECUTOR_SHELL
is unset) and two failing ones (where it is set):TART_EXECUTOR_SHELL
$PATH
/Users/admin/flutter:/Users/admin/flutter/bin/:/Users/admin/flutter/bin/cache/dart-sdk/bin:/usr/local/bin/:/Users/admin/.rbenv/shims:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Users/admin/android-sdk/cmdline-tools/latest/bin:/Users/admin/android-sdk/platform-tools:/Users/admin/android-sdk/emulator
bash
/usr/bin:/bin:/usr/sbin:/sbin
zsh
/usr/bin:/bin:/usr/sbin:/sbin
is this expected behaviour?
The text was updated successfully, but these errors were encountered: