[libvirt PATCH 07/11] ci: helper: Improve output for list-images action

Andrea Bolognani abologna at redhat.com
Mon Apr 26 16:15:22 UTC 2021


On Mon, Apr 26, 2021 at 11:59:19AM +0200, Erik Skultety wrote:
> On Fri, Apr 23, 2021 at 05:03:04PM +0200, Andrea Bolognani wrote:
> > Later on, when we change the actions that operate on
> > container images to accept an lcitool-style --cross-arch
> > argument instead of expecting the name of the image to have
> > the cross-building architecture baked in, this will allow
> > users to quickly copy-and-paste the necessary information.
>
> ...you can quickly copy-and-paste the image name even now and I would argue
> that it's even quicker than after this series:
>
> ./helper list-images
> ./helper <action> <copy-paste image name>  vs
>
> ./helper list-images
> ./helper <action> <copy-paste image name> --cross-arch <copy-paste cross arch>
>
> Right now you wouldn't even need the verification code introduced in patch 12
> since you have to paste the image verbatim which IMO for this utility helper
> that only serves a very specific use case of a single repo is "good enough".

That assumes the target name only comes from copying and pasting from
the output of the list-images action... Right now, if you pass some
invalid / obsolete value you get

  $ ./ci/helper build ubuntu-1604
  make: Entering directory '/home/abologna/src/upstream/libvirt/ci'
  make -C /home/abologna/src/upstream/libvirt/ci
ci-run-command at ubuntu-1604 CI_COMMAND="/home/abologna/build"
  make[1]: Entering directory '/home/abologna/src/upstream/libvirt/ci'
  Checking if podman is available...yes
  Cloning /home/abologna/src/upstream/libvirt to
/home/abologna/src/upstream/libvirt/ci/scratch/src
  Cloning /home/abologna/src/upstream/libvirt/src/keycodemapdb to
/home/abologna/src/upstream/libvirt/ci/scratch/src/src/keycodemapdb
  podman run \
  	--rm --interactive --tty --user "1000":"1000" --workdir
"/home/abologna" --env CI_CONT_SRCDIR="/home/abologna/libvirt" --env
CI_MESON_ARGS="" --env CI_NINJA_ARGS="" --uidmap 0:1:1000 --uidmap
1000:0:1 --uidmap 1001:1001:64536 --gidmap 0:1:1000 --gidmap 1000:0:1
--gidmap 1001:1001:64536  --volume
/home/abologna/src/upstream/libvirt/ci/scratch/group:/etc/group:ro,z
--volume /home/abologna/src/upstream/libvirt/ci/scratch/passwd:/etc/passwd:ro,z
 --volume /home/abologna/src/upstream/libvirt/ci/scratch/home:/home/abologna:z
 --volume /home/abologna/src/upstream/libvirt/ci/scratch/build:/home/abologna/build:z
 --volume /home/abologna/src/upstream/libvirt/ci/scratch/src:/home/abologna/libvirt:z
--ulimit nofile=1024:1024 --cap-add=SYS_PTRACE  \
  	registry.gitlab.com/libvirt/libvirt/ci-ubuntu-1604:latest \
  	/home/abologna/build
  Trying to pull registry.gitlab.com/libvirt/libvirt/ci-ubuntu-1604:latest...
    manifest unknown: manifest unknown
  Error: Error initializing source
docker://registry.gitlab.com/libvirt/libvirt/ci-ubuntu-1604:latest:
Error reading manifest latest in
registry.gitlab.com/libvirt/libvirt/ci-ubuntu-1604: manifest unknown:
manifest unknown
  make[1]: *** [Makefile:199: ci-run-command at ubuntu-1604] Error 125
  make[1]: Leaving directory '/home/abologna/src/upstream/libvirt/ci'
  make: *** [Makefile:209: ci-build at ubuntu-1604] Error 2
  make: Leaving directory '/home/abologna/src/upstream/libvirt/ci'
  error: 'make' failed

With my patches, the output is a much more reasonable

  $ ./ci/helper build ubuntu-1604
  Unknown target 'ubuntu-1604'

I agree that having to input the target OS and the target
architecture separately is slightly more copy-and-paste work, but
really those are two semantically separate bits of information and
it's just wrong for the user to provide a single argument that
encodes both.

It was an acceptable trade-off when we were using make, but now that
we have an actual command-line parser at our disposal we should take
advantage of it.

> I guess the idea is to eventually integrate this helper somehow to lcitool, so
> I'm wondering what is it we're trying to solve here. As for the output itself,
> if we want to change it, then I'd be probably more inclined towards something
> like virt-builder --list. There's massive information redundancy in there -
> no need to argue - but because the output is formatted like a simple table,
> tools like grep,sort,uniq and cut make the customization of the output for the
> average linux user an absolute no-brainer and they always get information they
> were looking for easily with almost no added effort.

Changing the output to be similar to that of 'virt-builder --list'
sounds good to me.




More information about the libvir-list mailing list