[libvirt PATCH 1/7] ci: integration: Extract several hidden job definitions to a script

[Erik Skultety]

On Mon, Jan 23, 2023 at 12:06:21PM +0000, Daniel P. Berrangé wrote:
> On Fri, Jan 20, 2023 at 04:05:57PM +0100, Erik Skultety wrote:
> > This will allow us to re-use the script in other scenarios like local
> > executions where up until now one had to copy-paste the recipe
> > line-by-line.
> > 
> > Signed-off-by: Erik Skultety <eskultet at redhat.com>
> > ---
> >  ci/integration-template.yml | 36 +-----------------------------------
> >  ci/integration.sh           | 32 ++++++++++++++++++++++++++++++++
> >  2 files changed, 33 insertions(+), 35 deletions(-)
> >  create mode 100644 ci/integration.sh
> > 
> > diff --git a/ci/integration-template.yml b/ci/integration-template.yml
> > index 9141d5cedf..f9903cdbb4 100644
> > --- a/ci/integration-template.yml
> > +++ b/ci/integration-template.yml
> > @@ -27,34 +27,6 @@
> >  .install-deps: &install-deps
> >    - sudo dnf install -y libvirt-rpms/* libvirt-perl-rpms/* libvirt-python-rpms/*
> >  
> > -  # Avocado >98.0 fails with the nwfilter TCK tests, so stick with 98.0 for now
> > -  - sudo pip3 install --prefix=/usr avocado-framework==98.0
> > -
> > -
> > -.enable-core-dumps: &enable-core-dumps
> > -  - sudo sh -c "echo DefaultLimitCORE=infinity >> /etc/systemd/system.conf" # Explicitly allow storing cores globally
> > -  - sudo systemctl daemon-reexec # need to reexec systemd after changing config
> > -
> > -
> > -.enable-libvirt-debugging: &enable-libvirt-debugging
> > -  - source /etc/os-release  # in order to query the vendor-provided variables
> > -  - if test "$ID" = "centos" && test "$VERSION_ID" -lt 9 ||
> > -       test "$ID" = "fedora" && test "$VERSION_ID" -lt 35;
> > -    then
> > -      DAEMONS="libvirtd virtlockd virtlogd";
> > -    else
> > -      DAEMONS="virtinterfaced virtlockd virtlogd virtnetworkd virtnodedevd virtnwfilterd virtproxyd virtqemud virtsecretd virtstoraged";
> > -    fi
> > -  - for daemon in $DAEMONS;
> > -    do
> > -      LOG_OUTPUTS="1:file:/var/log/libvirt/${daemon}.log";
> > -      LOG_FILTERS="3:remote 4:event 3:util.json 3:util.object 3:util.dbus 3:util.netlink 3:node_device 3:rpc 3:access 1:*";
> > -      sudo augtool set /files/etc/libvirt/${daemon}.conf/log_filters "'$LOG_FILTERS'" &>/dev/null;
> > -      sudo augtool set /files/etc/libvirt/${daemon}.conf/log_outputs "'$LOG_OUTPUTS'" &>/dev/null;
> > -      sudo systemctl --quiet stop ${daemon}.service;
> > -      sudo systemctl restart ${daemon}.socket;
> > -    done
> > -
> >  
> >  .collect-logs: &collect-logs
> >    - set +e
> > @@ -79,14 +51,8 @@
> >    before_script:
> >      - mkdir "$SCRATCH_DIR"
> >      - *install-deps
> > -    - *enable-core-dumps
> > -    - *enable-libvirt-debugging
> > -    - sudo virsh net-start default &>/dev/null || true;
> >    script:
> > -    - cd "$SCRATCH_DIR"
> > -    - git clone --depth 1 https://gitlab.com/libvirt/libvirt-tck.git
> > -    - cd libvirt-tck
> > -    - sudo avocado --config avocado.config run --job-results-dir "$SCRATCH_DIR"/avocado
> > +    - chmod +x ci/integration.sh && ci/integration.sh
> >    after_script:
> >      - test "$CI_JOB_STATUS" = "success" && exit 0;
> >      - *collect-logs
> 
> Kind of makes me wish for a command that could take a gitlab job
> name, and extract the shell commands from the YAML and run them.
> I guess that's a gitlab runner really, but taking YML directly
> instead of getting jobs sent from gitlab

Yeah, I don't think that's going to happen. Then again, we'd be probably the
only consumers of such thing by far, so adding an explicit script which
everyone can read and run  without anything else is for the best.

Regards,
Erik