On Mon, Jan 31, 2022 at 07:01:01PM +0100, Erik Skultety wrote:
> Create an integration child pipeline in this stage which will trigger a
> multi-project CI build of Perl bindings which are required by the TCK
> test suite.
> In general, this stage will install all the necessary build artifacts
> and configure logging on the worker node prior to executing the actual
> test suite. In case of a failure, libvirt and Avocado logs are saved
> and published as artifacts.
>
> Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx>
> ---
> .gitlab-ci-integration.yml | 116 +++++++++++++++++++++++++++++++++++++
> .gitlab-ci.yml | 14 +++++
> 2 files changed, 130 insertions(+)
> create mode 100644 .gitlab-ci-integration.yml
>
> diff --git a/.gitlab-ci-integration.yml b/.gitlab-ci-integration.yml
> new file mode 100644
> index 0000000000..cabefc5166
> --- /dev/null
> +++ b/.gitlab-ci-integration.yml
> @@ -0,0 +1,116 @@
> +stages:
> + - bindings
> + - integration
> +
> +.tests:
> + stage: integration
> + before_script:
> + - mkdir "$SCRATCH_DIR"
> + - sudo dnf install -y libvirt-rpms/* libvirt-perl-rpms/*
> + - sudo pip3 install --prefix=/usr avocado-framework
> + - 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 virtlogd virtlockd";
> + else
> + DAEMONS="virtproxyd virtqemud virtinterfaced virtsecretd virtstoraged virtnwfilterd virtnodedevd virtlogd virtlockd";
> + fi
> + - for daemon in $DAEMONS;
> + do
> + sudo sed -Ei "s/^(#)?(log_outputs=).*/\2'1:file:\/var\/log\/libvirt\/${daemon}.log'/" /etc/libvirt/${daemon}.conf;
> + sudo sed -Ei "s/^(#)?(log_filters=).*/\2'4:*object* 4:*json* 4:*event* 4:*rpc* 4:daemon.remote 4:util.threadjob 4:*access* 1:*'/" /etc/libvirt/${daemon}.conf;
> + sudo systemctl --quiet stop ${daemon}.service;
> + sudo systemctl restart ${daemon}.socket;
> + done
> + - sudo virsh net-start default &>/dev/null || true;
What context is all this being run in ?
There's no docker image listed in the container, and I see the
'tags' referring to VMs. Is this really installing stuff as
root in the VM runnerrs ?
Basically I'm not seeing where any of this work is cleaned up
to give a pristine environment for the next pipeline, or what
happens if two pipelines run concurrently ?
> +
> + script:
> + - mkdir logs
> + - 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
> + after_script:
> + - if test -e "$SCRATCH_DIR"/avocado;
> + then
> + sudo mv "$SCRATCH_DIR"/avocado/latest/test-results logs/avocado;
> + fi
> + - sudo mv /var/log/libvirt logs/libvirt
> + - sudo chown -R $(whoami):$(whoami) logs
> + variables:
> + SCRATCH_DIR: "/tmp/scratch"
> + artifacts:
> + name: logs
> + paths:
> + - logs
> + when: on_failure
> +
> +
> +libvirt-perl-bindings:
> + stage: bindings
> + trigger:
> + project: eskultety/libvirt-perl
I assume pointing to this personal repo is a temp hack for some fix
that's not merged into main libvirt-perl ?
> + branch: multi-project-ci
> + strategy: depend
> +
> +
> +centos-stream-8-tests:
> + extends: .tests
> + needs:
> + - libvirt-perl-bindings
> + - pipeline: $PARENT_PIPELINE_ID
> + job: x86_64-centos-stream-8
> + - project: eskultety/libvirt-perl
> + job: x86_64-centos-stream-8
> + ref: multi-project-ci
> + artifacts: true
> + variables:
> + DISTRO: centos-stream-8
> + tags:
> + - centos-stream-vm
> +
> +centos-stream-9-tests:
> + extends: .tests
> + needs:
> + - libvirt-perl-bindings
> + - pipeline: $PARENT_PIPELINE_ID
> + job: x86_64-centos-stream-9
> + - project: eskultety/libvirt-perl
> + job: x86_64-centos-stream-9
> + ref: multi-project-ci
> + artifacts: true
> + variables:
> + DISTRO: centos-stream-9
> + tags:
> + - centos-stream-vm
> +
> +fedora-34-tests:
> + extends: .tests
> + needs:
> + - libvirt-perl-bindings
> + - pipeline: $PARENT_PIPELINE_ID
> + job: x86_64-fedora-34
> + - project: eskultety/libvirt-perl
> + job: x86_64-fedora-34
> + ref: multi-project-ci
> + artifacts: true
> + variables:
> + DISTRO: fedora-34
> + tags:
> + - fedora-vm
> +
> +fedora-35-tests:
> + extends: .tests
> + needs:
> + - libvirt-perl-bindings
> + - pipeline: $PARENT_PIPELINE_ID
> + job: x86_64-fedora-35
> + - project: eskultety/libvirt-perl
> + job: x86_64-fedora-35
> + ref: multi-project-ci
> + artifacts: true
> + variables:
> + DISTRO: fedora-35
> + tags:
> + - fedora-vm
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 4bcaf22ce2..453472c8be 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -4,6 +4,7 @@ variables:
> stages:
> - containers
> - builds
> + - test
> - sanity_checks
>
> .script_variables: &script_variables |
> @@ -128,3 +129,16 @@ coverity:
> - curl https://scan.coverity.com/builds?project=$COVERITY_SCAN_PROJECT_NAME --form token=$COVERITY_SCAN_TOKEN --form email=$GITLAB_USER_EMAIL --form file=@cov-int.tar.gz --form version="$(git describe --tags)" --form description="$(git describe --tags) / $CI_COMMIT_TITLE / $CI_COMMIT_REF_NAME:$CI_PIPELINE_ID"
> rules:
> - if: "$CI_PIPELINE_SOURCE == 'schedule' && $COVERITY_SCAN_PROJECT_NAME && $COVERITY_SCAN_TOKEN"
> +
> +integration:
> + stage: test
> + needs:
> + - x86_64-centos-stream-8
> + - x86_64-centos-stream-9
> + - x86_64-fedora-34
> + - x86_64-fedora-35
> + trigger:
> + include: .gitlab-ci-integration.yml
> + strategy: depend
> + variables:
> + PARENT_PIPELINE_ID: $CI_PIPELINE_ID
I've not really thought about the implications, so I'm curious what's
the rationale for using a separate pipeline in this way, as opposed to
have x86_64-fedora-35-integration, x86_64-centos-stream-9-integration,
etc jobs in the existing pipeline ?
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 :|
