Re: [libvirt PATCH 05/33] ci: build.sh: Add a wrapper function executing 'shell' commands

On Fri, Sep 01, 2023 at 10:10:55AM +0100, Daniel P. Berrangé wrote: > On Fri, Aug 25, 2023 at 07:55:13PM +0200, Erik Skultety wrote: > > This would normally be not needed at all, but the problem here is the > > Shell-in-YAML which GitLab interprets. It outputs every command that > > appears as a line in the 'script' segment in a color-coded fashion for > > easy identification of problems. Well, that useful feature is lost when > > there's indirection and one script calls into another in which case it > > would only output the respective script name which would make failure > > investigation harder. This simple helper tackles that by echoing the > > command to be run by any script/function with a color escape sequence > > so that we don't lose track of the *actual* shell commands being run as > > part of the GitLab job pipelines. An example of what the output then > > might look like: > > [RUN COMMAND]: 'meson compile -C build install-web' > > > > Signed-off-by: Erik Skultety <eskultet(a)redhat.com&gt; > > --- > > ci/build.sh | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/ci/build.sh b/ci/build.sh > > index 02ff1a8388..d4fbf0ab37 100644 > > --- a/ci/build.sh > > +++ b/ci/build.sh > > @@ -25,6 +25,12 @@ meson setup build --werror -Dsystem=true $MESON_ARGS || \ > > > > ninja -C build $NINJA_ARGS > > > > +run_cmd() { > > + local CMD="$(echo $CMD | tr -s ' ')" # truncate any additional spaces > > + > > + printf "\e[93m[RUN COMMAND]: '%s'\e[0m\n" "$CMD"; eval "$CMD" > > +} > > I think we sould just get rid of the $CMD env variable in the caller > entirely and pass in arguments individual. eg so this method becomes > > run_cmd() { > printf "\e[93m[RUN COMMAND]: '%s'\e[0m\n" "$*" > $@ > } > > Then in the callers instead of > > local CMD="meson compile -C build $BUILD_ARGS" > run_cmd "$CMD" > > We get > > run_cmd meson compile -C build "$BUILD_ARGS" > > this would have avoided the bug you just posted a fix for where > we set 'local CMD' but forget the actual 'run_cmd' call. My only complaint is, again, readability - this particular example is fine, it would IMO become a mess with commands taking several arguments which would not fit onto a single line. I don't expect these functions to change much, so while you're absolutely right about preventing bugs like that, I think having some reasonable readability (shell--) would be a good tradeoff.