8:53 a.m.
On Thu, Feb 10, 2022 at 09:40:45AM +0000, Daniel P. Berrangé wrote:
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(a)redhat.com>
> ---
> .gitlab-ci-integration.yml | 116 +++++++++++++++++++++++++++++++++++++
...
> 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
I'd prefer it if we can just 'dnf install avocado' on Fedora at least,
so that we validate that if someone is running avocado locally we're
compatible with what's packaged.
That's my desire as well, but that is currently not possible because:
a) the Avocado shipped over the standard package manager channel is too old for
^this, to be precise it would mark every skipped job as failed due to a
a missing TAP parser fix (we need avocado-91+)
b) the 3rd party RPM repo currently returns 404 on my Fedora-34, nevertheless
last time I checked, even this repo shipped avocado-90 only
Cleber, how realistic is it for the Avocado project to build RPMs with every
release?
...
> +
> +
> +libvirt-perl-bindings:
> + stage: bindings
> + trigger:
> + project: eskultety/libvirt-perl
> + branch: multi-project-ci
> + strategy: depend
IIUC, what this does is to spawn a pipeline in the
'libvirt-perl' project on the 'multi-project-ci'
branch. Normally this is asyncronous, but
because of the 'strategy: depend' that causes us
to block until this async pipeline is complete.
Yes, that's correct.
> +centos-stream-8-tests:
> + extends: .tests
> + needs:
> + - libvirt-perl-bindings
So this triggers the perl bindings pipeline build
No, the trigger is the job 'libvirt-perl-bindings' above, but we need to wait
for the trigger as well, otherwise the integration job would not wait until the
new RPMs are available and instead it would just download the currently latest
ones (which will be available even if expired!)
I don't know whether this is a bug, but I originally didn't do it and I noticed
the integration jobs never waited for the bindings to be built and instead
downloaded the latest available copy.
> + - pipeline: $PARENT_PIPELINE_ID
> + job: x86_64-centos-stream-8
This is making us wait for the centos-tream-8
job in the normal CI pipeline.
Should we need 'artifacts: true' here too ?
I guess we can be explicit, but as long as the dependencies come from the same
pipeline, artifacts are automatically available (that is by design)
IIRC, artifacts true was the default, but it
feels sane to make it explicit, especially
since you were explicit for the libvirt-perl
job below
I can try whether gitlab is happy with that too, but conceptually, sure, why
not.
> + - project: eskultety/libvirt-perl
> + job: x86_64-centos-stream-8
> + ref: multi-project-ci
> + artifacts: true
And this making us wait for the cento-stream-8
job in te lbivirt-perl pipeline that we spawned
in the 'libvirt-perl-bindings'. IIUC there should
be no waiting needed since 'libvirt-perl-bindings'
was blocking on completion of the trigger pipeline,
so this effectivectly justpulls in the artifacts from
the already finishd job.
Yes, exactly, this would only download the artifacts, but the syntax hints that
a job is spawned :/ . However, as I wrote above, without waiting for the
trigger job, ^this hunk would just pull the latest available artifacts instead
of waiting for the ones currently being built
I presume your eskultety/libvirt-perl repo
multi-project-ci branch has a cyhange that causes
the perl-Sys-Virt RPMs to be publish as artifacts,
similar to your change in the previous patch in
this series.
Yes, in fact, I just submitted the following MRs:
https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/54
https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/55
with the latter enabling what we need here.
> + variables:
> + DISTRO: centos-stream-8
> + tags:
> + - centos-stream-vm
This means none of these jobs will run by default, unless
you're registered a custom runner with this tag. So no
forks will get these jobs, it'll be post-merge only.
That's fine for now. When we switch to merge requests
we will gain ability to trigger this even for forks without
runners as merge request jobs will attach to the primary
project runners, which is nice.
Yes. Custom runners are always private to the project, so forks never have
access to those unless we manually run the MR in context of the libvirt project.
> 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
Perhaps just put this in the 'sanity_checks' stage ? Since all
the real jobs are in the child pipeline, I don't think we need
an extra stage here.
Not my preference, but I can have it either way, a new stage can be added at
any time if needed.
> .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=(a)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
Ok, so any job in the child pipeline with a dependancy on a
job in this pipeline needs to have the dependancy repeated
here.
I don't think you need it really, but we have so many container build running
that waiting for ALL of them seemed pointless to me, so I added explicitly the
ones we need so that the integration stage can start ASAP.
Thanks,
Erik