On Fri, Sep 01, 2023 at 11:16:09AM +0200, Erik Skultety wrote:
> 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@xxxxxxxxxx>
> > > ---
> > > 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.
A line continuation isn't that hard to add for comamnds which get too
long.
Avoiding the intermediate variable is also more robust by eliminating
two levels of extra quoting. Quoting/expansion problems are one of the
more painful aspects of working in shell, so I think its good to cull
extra variables where practical.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
