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

[Erik Skultety]

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 at redhat.com>
> > ---
> >  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.

Erik