The target is intentionally not added to the integration tests
at this time, because the corresponding VM template is not yet
available on the runner. A later patch will take care of that.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Notable changes:
* 'lcitool manifest' now generates GitLab CI rules spread
across a bunch of files;
* container images are built less frequently for the main
repository.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The MinGW-w64 project has effectively replaced the original
MinGW project, and distributions such as Fedora have been shipping
packages based on the former for years now.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Basically all files in the repository are already passing the
check, except for syntax-check.mk itself. Fix that, and stop
limiting the files on which the test is performed.
These changes have been generated by running
$ sed -Ei 's/[ '$'\t'']+\\$/ \\/g' $(git grep -El '[ '$'\t'']+\\$')
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
YAML anchors don't work with Shell condition structures, so we cannot
simply reference the QEMU build template YAML anchor conditionally and
hence have everything as part of a single job template.
Instead, we have to "subclass" the .integration_tests template and
inject the QEMU building bits explicitly.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This was heavily inspired by QEMU's upstream CI buildtest-template.yml.
Rather than referencing QEMU's template directly (which GitLab can do),
this patch resorts to hard-coding the build steps ourselves, solely
because there's no guarantee QEMU will keep either the template file
name or the template name from which the build steps were mostly copied
from.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There's quite a lot happening in the .integration_tests template
already even without adding upstream QEMU build into the mix.
Let's break the template into more pieces which can then reference
in the .integration_tests template when putting all the pieces back
together using YAML anchors.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Future patches will do more code extraction from the existing template
using YAML anchors so it'd be better that the templates would live
separately from job definitions.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Using an updated toolchain means we're likely to catch more
issues.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Notable changes:
* use the most recent point release for FreeBSD 12.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Mostly the tests should fail cleanly, but sometimes the test might crash
or abort. In this case we'll need to know the stack traces in order to
debug the problem. Fortunately on the Cirrus CI macOS instances, the
crash reporting service is active and saving crashes to the directory
~/Library/Logs/DiagnosticReports/
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We don't have access to the 'testlog.txt' file, so we need meson to
print the failures for any broken tests directly.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using the extended definition format is only necessary when
the defaults are not good enough, but that's not the case here.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
All build jobs for the target are explicitly disabled, so
there's no point in keeping the variables file around and we
can simply not mention it in the manifest at all.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In this batch:
- dnsmasq is dropped as build dependency
- Alpine Edge rpcgen package collision fix
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As of April 23 2022, Ubuntu 20.04 will be out for two years, which per
our platform support policy means we no longer have to support
Ubuntu 18.04.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
By default, stdout/stderr Avocado test log files do not have any file
extension which confuses GitLab's web UI to mangle the MIME type for
these and so the browser will never offer the option to open such file
from in a text editor rather than dowloading it.
Since GitLab sets a proper MIME for .txt and .log file extensions,
rename all Avocado log files without an extension to *.log . This pairs
nicely with the coredumpctl info file which we already name as
'coredumpctl.txt' because of this.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Some Red Hat-like distros have cores limited with a soft limit of 0
which means that neither a stack trace nor a core file will be
available. Since we want the stack trace we need to set the core limit
with systemd globally to unlimited/infinity.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Custom runners are private to a project, so naturally forks cannot run
any workloads on these. The integration test suite which requires
access to our custom runner is naturally disabled on forks and can be
enabled by setting LIBVIRT_CI_INTEGRATION=1.
The problem is that the current integration jobs definitions have tags
statically defined as 'redhat-vm-host'. If users are going to supply
their own private runners for their forks, they can define whatever
tags they want with it and so unless they add 'redhat-vm-host' to their
own runner's tags, the pipeline won't run.
To solve this, define the integration job tag using a variable. The
repo config will use the value defined in the job for the variable
while users can override the value easily on a project/pipeline level
thanks to GitLab's CI variable precedence [1].
[1] https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now the jobs have no rules so they will always be created in
a pipeline. If the user's fork has no runner configured, then the
jobs will never be able to execute and the pipeline will not finish.
Even on upstream, there might be times the runner has to be taken
offline for maint work, or unexpectedly fail. We need a quick way
to disable the integration tests if we decide we don't want to
have pipelines queued until the runner comes back online.
Both these problems can be addressed by requiring a environment
variable to be set
LIBVIRT_CI_INTEGRATION=1
This can be done in the GitLab repo CI settings for permanent
enablement. Alternatively it can be set for individual
scheduled jobs, or using a push option
git push -o ci.variable=LIBVIRT_CI_INTEGRATION=1
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Although we split out jobs across many files, the template / job
namespace is global, so we should use something more specific
than '.tests' as the template name.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Erik Skultety <eskultet@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>
Regenerate with lcitool as of:
commit f83b916d5efa4bd33fbf4b7ea41bf6d535cc63fb
Author: Alex Bennée <alex.bennee@linaro.org>
Date: Fri Feb 11 09:39:30 2022 +0000
mappings: skip multipath-tools for cross Debian
This package is both a mix of library files, headers and native
binaries so cannot be installed in a cross environment. For now skip
it for cross targets.
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005323
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@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>
Re-generate our CI infra with 'lcitool' as of:
commit b346752e98bd12395233ebba8c9312e08212b639 (HEAD)
Author: Erik Skultety <eskultet@redhat.com>
Date: Tue Feb 1 10:48:53 2022 +0100
tests: Replace CentOS 8 with AlmaLinux 8 in test scenarios
Switch the test target before actually dropping CentOS 8.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This is prior to upstream lcitool dropping 'centos-8' support to
minimize the differences.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The meson version provided by the package managing system satisfies our
minimum requirement.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Apart from some churn, the important is the removal of 'netcf-devel'
from the fedora rawhide container.
Update to state as of 174fe4999204afcae (libvirt-ci).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Both of the current mingw jobs are marked as 'allow_failure' because
they are running against Fedora rawhide which is an unstable distro.
We need at least one mingw job to be gating to more reliably detect
problems.
This introduces dockerfiles for both mingw variants on Fedora 35
and sets the mingw64 build to run on Fedora 34, and mingw32 on
Fedora rawhide.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
- The Cirrus CI variables are now sorted
- The dockerfiles update commands changed for some distros
- Meson in CentOS is now new enough to use
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This removes the libnetcf-dev package from Debian Sid, as it is no
longer available in that distro stream.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The non-released distros have reasonably frequent package installation
failures that can last for days at a time. This makes them unsuitable
for use as gating CI jobs.
This ensures all of the jobs in Debian Sid, Fedora Rawhide, openSUSE
Tumbleweed and FreeBSD Current are marked "allow-failure: true".
This means the jobs still run, but any failure will not be considered
fatal to the pipeline.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The layering of the cross containers is fixed to move arch specific
ccache setup out of the common base layer.
A missing Cirrus CI variable substitution is added, though this is
irrelevant given libvirt's package list.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The armv7l and ppc64le cross-builds as well as the Clang build
are adopted from Debian 10, while the mips64el build is adopted
from Debian sid. As always, the way jobs are distributed across
Debian versions is fairly arbitrary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The value 3 is the length of the "ci-" prefix, which is present
in the items returned by get_registry_images() but not in those
returned by get_dockerfiles().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Beraldo Leal <bleal@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These were removed along with the outdated information on how
to regenerate the Dockerfiles contained in the repository, but
this part is still relevant.
Reverts: 30856d2865 (partially)
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We now use lcitool's manifest feature to generate files. The logic
for checking for stale containers in the registry, however, is still
relevant so that is propagated to a standalone command.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We now use lcitool's manifest feature to generate files.
Reviewed-by: Pavel Hrdina <phrdina@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>
lcitool now uses the term "target" instead of "host" to refer to
the various operating systems it supports, and we need to adapt
our helper script so that it works with the new command line
interface.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
All the python packages got renamed from py37- to py38-
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-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>
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>
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>
Notable changes:
* the CentOS Stream 8 container is now using a proper base
image instead of starting from a CentOS 8 image and then
adding the CentOS Stream 8 repositories on top;
* distributions that have a perl-base package are now using
that one instead of the regular perl package, which
contains a bunch of features we don't need, resulting in
smaller containers.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-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>
Notable changes:
* cross-building container images are smaller because they
no longer include the native compilers;
* ccache is enabled for clang builds.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Unless you create such an commit, cirrus-ci.com will not pick up the
github project and cirrus-run will fail.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Notable changes:
* HAL is no longer installed on FreeBSD;
* the native version of libwsman is no longer installed in
containers intended for cross-compilation;
* Meson 0.55 rather than 0.54 is requested when installing
it from PyPI;
* GNU sed and GNU grep are installed explicitly everywhere.
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>
As documented at [1], the common practice with respect to private
attributes/methods naming is to prefix them with an underscore.
[1] https://docs.python.org/3/tutorial/classes.html#private-variables
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This function checks whether there are any stale Docker images in the
registry that can be purged. Since we're pulling available container
images from our GitLab registry with the 'list-images' action, it
could happen that we'd list old (already unsupported) images and make
them available for the user to consume and run a build in them.
Naturally, the build will most likely fail leaving the user confused.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The corresponding Bash script is dropped.
After this patch's rewrite, the Makefile's original image listing
target remains intact only to notify the user to use the Python helper
instead.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
With the gradual rewrite of the Makefile to the 'helper' script will
require helper functions that would better live in a separate util
module.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Offer an option to silence all output to stdout coming out of the
dockerfiles/varsfiles generating code.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This help formatter class reports the defaults we use for options
taking an argument.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We now wrap all its important functionality with the much more
user-friendly ci/helper script, and the long term plan is for
the Makefile to disappear completely.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The functionality is now available in the ci/helper script.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This simply calls the underlying Makefile target, but allows
additional arguments to be specified in a more convenient and
discoverable way.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This simply calls the underlying Makefile target, but allows
additional arguments to be specified in a more convenient and
discoverable way.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This simply calls the underlying Makefile target, but allows
additional arguments to be specified in a more convenient and
discoverable way.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This simply calls the underlying Makefile target.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This provides the same functionality as the two refresh scripts
that are currently in the repository, with the following
advantages:
* all files are refreshed with a single command;
* if lcitool is present in the user's $PATH, it will be
discovered and used automatically;
* some output is produced, so the user can follow along with
the progress of the operation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This is intended to be perform a number of CI-related operations
that are currently implemented in various different scripts
written in various different programming languages.
Eventually, all existing functionality will be reimplemented in
Python and made available through this single entry point; for
now, let's start with a very basic skeleton.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The target was renamed when moving to Meson, but the help text
was not updated accordingly.
Fixes: 1a0af38ae7
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Using locally built images is a useful feature; our commentaries even
mention overriding them may be useful in some scenarios. Expose the
variables in the help to let users know they can use the feature.
Formatting would definitely break, so this patch adds more spacing for
proper alignment.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
In commit 321293e2 I dropped the prepare.sh script, but forgot to
remove the corresponding variable from the Makefile.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@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>
More often than not I find myself debugging in the containers which
means that I need to have root inside, but without manually tweaking
the Makefile each time the execution would simply fail thanks to the
uid/gid mapping we do. What if we expose the CI_USER_LOGIN variable, so
that when needed, the root can be simply passed with this variable and
voila - you have a root shell inside the container with CWD=~root.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The purpose of this script was to prepare a customized environment in
the container, but was actually never used and it required the usage of
sudo to switch the environment from root's context to a regular user's
one.
The thing is that once someone needs a custom script they would very
likely to debug something and would also benefit from root privileges
in general, so the usage of 'sudo' in such case was a bit cumbersome.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The prepare.sh script isn't currently used and forces us to make use
of sudo to switch the user inside the container from root to $USER
which created a problem on our Debian Slim-based containers which don't
have the 'sudo' package installed.
This patch removes the sudo invocation and instead runs the CMD
directly with podman.
Summary of the changes:
- move the corresponding env variables which we need to be set in the
environment from the sudo invocation to the podman invocation
- pass --workdir to podman to retain the original behaviour we had with
sudo spawning a login shell.
- MESON_OPTS env variable doesn't need to propagated to the execution
environment anymore (like we had to do with sudo), because it's
defined in the Dockerfile
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This is necessary for the follow up patch, because the default
entrypoint for a Dockerfile is exec.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
dtrace is now also installed when cross-building.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-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>
In this refresh CentOS 7 now uses docker.io registry and the PowerTools
repo name regression was fixed for CentOS Stream this time.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@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>
Contains changes utilizing "nosync" and "eatmydata" for speedup as well
as fixes for CentOS-8 repoid regression.
ci-commit: b098ec6631a85880f818f2dd25c437d509e53680
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This makes the dockerfile name match the output container name
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This introduces Fedora 33 and removes some redundant packages.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There's no need to have different CI process between macOS and FreeBSD
as test suite has been fixed on macOS.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add meson required bits to the ci logic in the repo to be able to run
a meson build in a container.
This patch also drops several environment variables we don't need with
meson anymore.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Introduce new job to make a coverity build and upload coverity data to
scan.coverity.com where the analysis is then executed.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The corresponding lcitool change is
00d736ea99
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The previous 11.3 image provided by Cirrus did not boot, but they have
now provided a working 11.4 image
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Update the remaining 'make check' references after the
switch to meson/ninja.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The corresponding libvirt-ci commit is:
commit 512b1011559165e3f37eae675dd43a431b95baa3
projects: install clang on Linux
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
The Cirrus CI integration was modeled after the Travis CI jobs,
but those were limited to macOS where the test suite is currently
still broken. FreeBSD can run the full distcheck just fine, so
let's do that.
Fixes: 6190c14151
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The corresponding libvirt-ci commit is 5abf5e7e2326.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
All targets get cpanm, which is now part of the base system, and
xz is now installed explicitly instead of relying on it being either
present by default or dragged in indirectly.
The corresponding libvirt-ci commit is 8920e8f408ba.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Instead of having static job definitions for FreeBSD and macOS,
use a generic template for both and fill in the details that are
actually different, such as the list of packages to install, in
the GitLab CI job, right before calling cirrus-run.
The target-specific information are provided by lcitool, so that
keeping them up to date is just a matter of running the refresh
script when necessary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
All targets get pip3, which is now part of the base system, and
the number of native packages included in the MinGW containers is
significantly reduced.
The corresponding libvirt-ci commit is 4ff697ba0b5d.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The build job for this container has been failing every single
time, and as it turns out the explanation for that is very simple:
Debian is just not going to support the mips architecture going
forward.
Reported-by: Pino Toscano <ptoscano@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Document the CI_MAKE_ARGS and CI_CONFIGURE_ARGS so that users don't have
to skim through the Makefile to be able to pass arbitrary recognized
make targets to the build system.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The ci-* targets need to know where our container images are stored
and how they are called to work, so now that we use the GitLab
container registry instead of Quay some changes are necessary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of using pre-built containers hosted on Quay, build
containers as part of the GitLab CI pipeline and upload them to the
GitLab container registry for later use.
This will not significantly slow down builds, because containers are
only rebuilt when the corresponding Dockerfile has been modified.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs,
making it possible to extend our platform coverage to include
FreeBSD without having to maintain our own runners; additionally,
we'll be able to ditch Travis CI and, since results for Cirrus CI
jobs are reflected back to the GitLab CI jobs that triggered them,
we will be able to get all information from a single dashboard.
The FreeBSD and macOS job definitions can be improved further: for
example, we will want to enable caching to speed up builds, and
ultimately we should figure out a way to generate at least part of
them, notably the list of packages to be installed, using lcitool.
All of that will happen in later patches: for now, this is good
enough to start using Cirrus CI.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
As of libvirt-jenkins-ci commit e41e341f0d8f, we no longer bake
this environment variable into our container images.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two environment variables that are baked into our
cross-compilation container images at build time, $CONFIGURE_OPTS
and $PKG_CONFIG_LIBDIR: the former contain the options necessary
to convince configure to perform a cross build rather than a
native one, and the latter is necessary so that pkg-config will
locate the .pc files for MinGW libraries. Container images that
are not intended for cross-compilation will not have either one
defined.
The problem is that, while an empty $CONFIGURE_OPTS is completely
harmless, setting $PKG_CONFIG_LIBDIR to an emtpy value will
result in pkg-config not looking in its default search path, thus
not finding any library, and subsequently breaking native builds.
To work around this issue, only pass $PKG_CONFIG_LIBDIR to sudo
when the value is set in the calling environment.
Fixes: 71517ae4db
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
For container images targeted at cross-building, we bake a small
amount of architecture-specific information in the environment so
that builds can work as expected without requiring additional work
from the user; unfortunately this information got lost as soon as
we called sudo. Explicitly allow it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
This deletes all trace of gnulib from libvirt. We still
have the keycodemapdb submodule to deal with. The simple
solution taken was to update it when running autogen.sh.
Previously gnulib could auto-trigger refresh when running
'make' too. We could figure out a solution for this, but
with the pending meson rewrite it isn't worth worrying
about, given how infrequently keycodemapdb changes.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Any static list of images is destined to become outdated eventually,
so let's start generating it dynamically instead.
Unfortunately there doesn't seem to be a straightforward way to get
Podman/Docker to list all repositories under quay.io/libvirt, so we
have to resort to searching and filtering manually; and since the
two tools behave slightly differently in that regard, it's more
sane to have the logic in a separate shell script than it would be
to keep it inline in the Makefile with all the annoying escaping
doing so would entail.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Now that we're using sudo, the initial work directory is no
longer relevant since the user will find themselves in their
home directory when they get control anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In order for the prepare script to be really useful, it needs
to be able to perform privileged operations such as installing
additional packages or setting up custom mount points.
In order to achieve that, we now run the container as root,
run the prepare script with full privilege, and only then
switch to the unprivileged account with sudo.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This script is run before $(CI_BUILD_SCRIPT) and can be used
to tweak the environment as necessary before the build starts.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Both for ci-build and ci-shell we want to execute basically
the same setup and cleanup logic, the only difference being
that for the former we then run the build script and with the
latter a shell.
Rework the targets so that they both call the generic
ci-run-command rule passing an appropriate $(CI_COMMAND).
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Instead of hardcoding build instructions into the Makefile,
move them to a separate script that's mounted into the
container.
This gives us a couple of advantages: we no longer have to
deal with the awkward quoting required when embedding shell
code in a Makefile, and we also provide the users with a way
to override the default build instructions with their own.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we have a home directory for the user, storing the
source there rather than in a custom top-level directory is
the obvious choice.
Later on we're also going to add some more files related to
builds, and storing everything in the user's home directory
will keep things nice and tidy.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some applications expect the user's home directory to be
present on the system and require workarounds when that's not
the case. Creating the home directory along with everything
else is easy enough for us, so let's just do that.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We're going to have a few more CI-related files in a second, and
it makes sense to have a separate directory for them rather than
littering the root directory.
$(CI_SCRATCHDIR) can now also be created inside the CI directory,
and as a bonus the make rune necessary to start CI builds without
running configure first becomes shorter.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
