The 'potfile' job is lacking the 'variables' section which defines the
'NAME' variable used by the 'image' property resulting in the 'potfile'
job failing with:
Pulling docker image registry.gitlab.com/libvirt/libvirt/ci-:latest ...
WARNING: Failed to pull image with policy "always": invalid reference format (manager.go:235:0s)
ERROR: Job failed: failed to pull image "registry.gitlab.com/libvirt/libvirt/ci-:latest" with specified policies [always]: invalid reference format (manager.go:235:0s)
Fixes: 491d918502
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Right now we're setting the prefix to a custom path, which
results in paths like
/builds/libvirt/libvirt/vroot/etc/libvirt/virtqemud.conf
ending up in the generated HTML. In order to avoid that,
set the prefix and other installation paths to reasonable
default values by passing
-Dsystem=true
and then take advantage of $DESTDIR support to still be able
to write the HTML files without requiring root privileges.
Reported-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
One specfile containing both native and mingw builds is the
new best practice for Fedora. This reduces the maint burden
and ensures the mingw packages don't fall behind.
Note this adds many more BuildRequires for anyone building
on Fedora, which will now need installing.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The container jobs are all optional in upstream now, only
running if dockerfile changes were made. Thus any build
jobs which reference the container jobs need to mark their
dependency as optional too.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This stage will download build artifacts from both the libvirt and
libvirt-perl (multi-project CI) builds, install all them on the custom
runners and configures libvirt debug logging on the runners prior to
executing the actual test suite. In case of a failure, libvirt and
Avocado logs will be saved and published as pipeline artifacts.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We're already building libvirt in the containers already, if we publish
the build in form of, say, RPMs, later stages of the pipeline can
consume the RPMs instead of re-building libvirt from scratch.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upstream lcitool suggests that as a solution to 'centos-8' being
removed.
Move also the website and other jobs to depend on
'x86_64-almalinux-8-container'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When a build fails it is helpful to know what packages were installed,
because by the time we look at the build job output, the original
container image might have changed.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We previously had a 'rules:' entry that caused a job to be skipped if
the variable "TEMPORARILY_DISABLED" was set. This is no longer needed
since we can set a similar flag in ci/manifest.yml and re-generate
to temporarily skip a job.
Unfortunately the 'rules:' entry had an unexpected side-effect on
the pipelines that was never previously noticed. Instead of only
running pipelines on push, the mere existance of the 'rules:' entry
caused triggering of pipelines on merge requests too.
The newly auto-generated ci/gitlab.yml file does not have a 'rules:'
for the container job template, and thus only runs on git push.
The result is that build jobs try to run on merge requests and the
container jobs they depend on don't exist. This breaks the entire
pipeline with a message that the config is invalid due to broken
job dependencies.
This fixes a regression introduced in
commit ccc7a44adb
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Sep 9 14:49:01 2021 +0100
ci: re-generate containers/gitlab config from manifest
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This uses the command "lcitool manifest ci/manifest.yml" to re-generate
all existing dockerfiles and gitlab CI config.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The sanitizer jobs run in ubuntu 20.04 containers and thus overlap with
testing already done for the regular ubuntu 20.04 build job. Fold the
sanitizer run for GCC into the regular build job and add a second
ubuntu 20.04 build job for CLang sanitizers.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It was in the build stage previously to let it run in parallel with
other build jobs, but with the "needs" clause this is not required.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current docker:dind container has broken default seccomp filter that
results in clone3 being blocked, which in turn breaks Fedora 35 rawhide.
This custom image has a workaround that causes the seccomp filter to
return ENOSYS for clone3 instad of EPERM, thus triggering glibc to
fallback to clone correctly.
Reviewed-by: Erik Skultety <eskultet@redhat>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The nature of Fedora rawhide means that it will inevitably have failures
periodically. Currently it is failing to even update packages due to
glibc switching to use of clone3 syscall, which is mistakenly blocked by
seccomp in container runtimes using EPERM instead of ENOSYS.
When we fail to build the rawhide containers, it is quite likely that we
still have the previous build available in the gitlab registry, so it is
reasonable to allow the container job to fail and try the build job
anyway.
Ideally we would ignore the container build failure if-and-only-if the
previous container was build with the same list of packages. We don't
record the original dependency package list though, so that's not
currently possible.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The undefined behaviour sanitizer (UBSAN) defaults to merely printing an
error message if it detects undefined behaviour. These error messages often
end up in captured output and do not fail the tests, effectively hiding
the warning. Make the test cases fail to make the issues visible.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The base OS image might include outdated contents, and we don't
want to get spurious failures caused by bugs that have already been
fixed in the respective packages.
This is particularly important on macOS, because 'brew install foo'
will fail if 'foo' is already installed but outdated: upgrading all
packages first ensures we never run into this scenario.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Docs are not sanitized, thus there's no point in building them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
meson supports the following sanitizers: "address" (e.g. out-of-bounds
memory access, use-after-free, etc.), "thread" (data races), "undefined"
(e.g. signed integer overflow), and "memory" (use of uninitialized
memory). Note that not all sanitizers are supported by all compilers,
and that more sanitizers exist.
Not all sanitizers can be enabled at the same time, but "address" and
"undefined" can. Both thread and memory sanitizers require an instrumented
build of all dependencies, including libc.
gcc and clang use different implementations of these sanitizers and
have proven to find different issues. Create CI jobs for both.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In the distros using RPMs, we build libvirt once as a side effect
of running "ninja dist", and once via rpmbuild.
In addition "ninja dist" will run all tests including the "syntax-check"
suite, despite use having a separate "codestyle" job for for that.
There is no way to pass "--no-suite" when creating the dist, but if we
switch to invoking "meson dist", we can skip the build+test part
entirely using "--no-tests".
When doing this we then run explicit "meson compile" and "meson test"
commands for the distros that don't build the RPMs, and in the latter
case we can now skip the "syntax-check" suite.
The RPM builds already skipped the "syntax-check" suite.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The "dist" and "test" targets in ninja end up calling back into
the equivalent meson commands. The meson commands support various
arguments that are not accessible when invoked via ninja, so it
is preferrable to use meson directly.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The "DIST=skip" flag as used in CentOS 7 jobs to workaround a problem
with older git versions. This is no longer required since
commit d35003aee7
Author: Andrea Bolognani <abologna@redhat.com>
Date: Tue May 4 10:45:29 2021 +0200
ci: Drop CentOS 7
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
"meson test" will only print a list of which tests fail by default,
so we were sending the full test log to stdout on failure. This makes
it really hard to see the errors though as the test log has all
succcesful tests too.
"ninja test" will print the same as "meson test", following by details
of each failure.
It does this using the "--print-errorlog" flag, so lets use that in
the codestyle job.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When CI jobs fail on the test suite, we don't see much helpful
information by default:
stderr:
TEST: bhyvexml2argvtest
......!!.............!......!........... 40
........................!...... 71 FAIL
Some tests failed. Run them using:
VIR_TEST_DEBUG=1 VIR_TEST_RANGE=7-8,22,29,65
/tmp/cirrus-ci-build/build/meson-private/dist-build/tests/bhyvexml2argvtest
Following the instructions to re-run the test with VIR_TEST_DEBUG=1 is
quite unfriendly when we could have had that set for CI already.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The names have been recently changed in libvirt-ci to be more
accurate, so we should follow along.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We should always pass --werror and display the contents of the
log file in case of failure.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
FreeBSD 12 was released in December 2018, so according to our
platform support policy we can now drop support for the previous
major release. It would be going EOL in September anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Since the string "ci" is already contained in the path, it
seems unnecessary to include it into the filename too: in fact,
we only do that for Dockerfiles and not for files in ci/cirrus,
even though those are generated the very same way.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
macOS builder capacity on Cirrus CI is quite limited, and so we
can't afford to keep the old build job around after adding the
new one like we do for FreeBSD.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While pkgng on FreeBSD updates the package list automatically
when it's run, homebrew on macOS doesn't do the same thing, which
can result in stale packages being installed. Explicitly call
'brew update' before 'brew install' to avoid that scenario.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The FreeBSD 12.1 image on Cirrus CI is currently broken, but
that's okay because a FreeBSD 12.2 image is also available and
we'd rather build on the more up-to-date target anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Debian sid is currently broken on ppc64le, so move the build to
Debian 10; do the opposite for the aarch64 and mips64el builds to
try and restore the 10/sid balance.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Whether a container build job is considered required depends on
whether the corresponding cross-build job exists, and in a few
cases the two got out of sync over time.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Keep them ordered by architecture, the same way the corresponding
container jobs are, to make it easier to jump between the two
sections and compare them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
A couple of these were wrong, resulting in the build job not
waiting for the correct container to be built before starting.
Fixes: 77296c807b
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Fedora 34 rawhide has pulled in a new GCC 11 build which now
defaults to dwarf5 format. This format is not compatible with
the pdwtags program used in our test suite to validate the
RPC files.
We have no need for debuginfo in CI except for pdwtags,
so the simplest short term fix is to force the older dwarf
version in the hope that a fixed dwarves release will
arrive before Fedora 34 is released, or GCC 11 becomes more
widespread. Eventually we might need to figure out a way to
probe for compatibility but for now, we'll hope that any
distro with GCC 11 will be able to have a fixed dwarves too.
https://bugzilla.redhat.com/show_bug.cgi?id=1919965
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Leap 15.1 will reach EOL on January 31st 2021, so we should not test on
it during the current development cycle ending on March 1st.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Thanks to the 'rules' syntax, this will translate to
'allow_failure:true' and let the job fail but will not affect the rest
of the pipeline.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
'rules' syntax replaces the only/except syntax with which it is
mutually exclusive. In some cases the 'rules' syntax is more readable
than the 'only/except' equivalent, in some cases it is not.
The idea behind this conversion is to introduce an explicit env variable
controlling the 'allow_failure' attribute which would then be attached
to a broken build job which would in turn result in a soft failure.
Such behaviour is not possible to achieve with the older 'only/except'
syntax.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
'extends' is slightly more readable and definitely more flexible in
terms of allowing includes of templates.
The main reason for this patch though is that the next patch converts
the 'only/except' syntax to the new (preferable) 'rules' syntax.
Variable anchors are still kept intact because the use case there is
different from regular template anchors.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
In this refresh the PIP variable is renamed to PIP3 and the
PYPI_PKGS variable disappears since we (currently) don't have
any need for it.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The "libvirt-" prefix was removed from hostnames in libvirt-ci.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
