IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We're gonna drop support for non-systemd init scripts soon,
and we don't want Travis CI builds to break when we do.
Since we have init system auto-detection, we can just rely on
that and stop passing --with-init-script to configure entirely.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
As it's currently impossible for us to create new automated
builds on Docker Hub (see [1]), and quay.io doesn't suffer
from the same problem while still having all the feature we
need, switch to the latter.
[1] https://github.com/docker/hub-feedback/issues/1676
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We build on Fedora Rawhide, same as on the CentOS CI
environment.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we use pre-built Docker images, it's very easy
to extend our test matrix; adding CentOS 7 is a good start.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of starting from the minimal Ubuntu 18.04 base
image and installing all requirements at build time,
use a Docker image that has been specifically tailored
at building libvirt and thus already includes all
required packages.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This will make further changes easier; all coverage
lost due to this will be reintroduced later on.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We already perform a full build as part of distcheck, so
we can speed things up a bit by skipping the first
compilation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Without a proper separator, all commands in the error path
end up being interpreted as a single command, which is not
what we want.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The new name is arguably more informative, especially now
that we have MACOS_CMD and knowing that MINGW_CMD will
be introduced later on.
We still use DOCKER_CMD when calling Docker, and we assign
the actual script on a per-image basis. Having this
separation will help us when we introduce MinGW builds.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It mirrors the existing DOCKER_CMD, both in how it's defined
as part of the environment and how it's called by passing it
directly to the shell.
In addition to making the configuration more consistent, this
also allows us to move from having the macOS build script
divided into four steps, some of which have slightly different
semantics and the relationship between which is not immediately
obvious without consulting the documentation, to a single
straightforward shell invocation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
All variable parts are taken from the environment, so we
can exploit inheritance and avoid duplication. This will
become more important as we start building on additional
platforms.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Upgrading takes quite a bit of time, doesn't offer any
real value and causes a lot of grief. Let's just skip it.
We need to install xz explicitly now, since it's required
to make dist and no longer being dragged in by Python 3.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The container images provided by Travis only support Ubuntu 14.04,
however, Travis has ability to run docker, which allows the build
script to use arbitrary OS images. This takes advantage of that to
convert the build over to Ubuntu 16.04 and 18.04
This is using the official Ubuntu provided images and installing
extra build deps required, as we previously did with Travis container
images.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
As documented in [1], ccache needs to be installed and
configured explicitly on macOS.
[1] https://docs.travis-ci.com/user/caching/#ccache-cache
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we have separate sections for each build
configuration, there's no reason to set PATH in the global
environment.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Since we started using `make distcheck` in travis, the part that's printing the
tests/test-suite.log file is rather pointless. Let's check for both known
locations (keeping the previous one there on purpose) so that the output is
usable again.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
numpy (needed by cgal) started having the same issue with
linking as python, which makes upgrade and thus the entire
build fail on macOS.
Instead of playing more tricks with linking/unlinking, just
uninstall the problematic packages (and those dragging them
in) before doing anything else.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For patches pushed upstream we want builds run on master branch, but
don't want them run on the -maint branches, as we are not keeping the
.travis.yml file on stable branches updated wrt latest needs of travis
CI platforms.
We can't just whitelist 'master' though, because that will prevent
developers triggering their own private travis builds. So we just
blacklist *-maint, since developers will typically use named feature
branches for any work.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The 'brew upgrade' command is pulling in the python2 package which
promptly fails due to clashing symlinks installed by the new python
package (which is python3 based):
==> Pouring python@2-2.7.14_3.sierra.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/2to3-2
Target /usr/local/bin/2to3-2
is a symlink belonging to python. You can unlink it:
brew unlink python
To force the link and overwrite all conflicting files:
brew link --overwrite python@2
To list all files that would be deleted:
brew link --overwrite --dry-run python@2
By running 'brew unlink python' we can get rid of the python3 links that
we didn't want in the first place and avoid this error.
This is the working fix for what we previously attempted todo in:
commit c9c9fc90ce
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Mon Mar 5 10:13:12 2018 +0000
travis: force install of python2 into $PATH on macOS
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The list of commands we're running for the before_install task
is rather large. We have it all on one line because we're
wrapping it all in a test against TRAVIS_OS_NAME env variable.
By moving it into the osx matrix entry we can remove the need
for the conditional shell test. This lets us put each command
on a separate line making the steps clear to understand.
Fortunately the 'before_install' task does not have the crazy
behaviour whereby travis ignores errors and runs all commands
regardless, like the 'script' task does. The first command
failing will cause an immediate stop with error status.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Make sure we install the same packages lcitool would install on
the CentOS CI so that we have consistent results. The package
list is current as of libvirt-jenkins-ci commit ad84090b6f96.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The homebrew formula's ignored Python PEP-0394 recommendations and
changed the plain python binary in /usr/local/bin to point to Python 3
instead of Python 2. Python 2 is not even installed into a location that
is in $PATH by default anymore. The homebrew packages print a message
to stderr claiming to provide a way to fix this
[quote]
This formula installs a python2 executable to /usr/local/opt/python@2/bin
If you wish to have this formula's python executable in your PATH then add
the following to ~/.bash_profile:
export PATH="/usr/local/opt/python@2/libexec/bin:$PATH"
[/quote]
When trying to update $PATH are suggested we find out this message is a
lie and /usr/local/opt/python@2 does not even exist, instead Python
seems to end up in /usr/local/Cellar/python@2/2.7.14_1
Rather than hardcoding this version specific directory in our travis
config, we change to run "brew link --force python@2", to make it create
symlinks in /usr/local/bin for the python2 binary.
The original change triggering this problem was
https://github.com/Homebrew/homebrew-core/pull/24604#issue-171653084
There are countless bug reports against homebrew-core that are closed
without fixes, so it seems they are determined to ignore the Python
PEP 0394 recommendations on this.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Enable testing of both the upstart and systemd init script handling.
We test a different one in each scenario. Even though trusty only
cares about upstart, it is fine for us to test rules that install
systemd, since we're not actually running these scripts for real.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We can't use "make distcheck" on macOS because many unit tests fail. We
can still get coverage of some of the things "distcheck" validates, by
running the "install" and "dist" targets. This is particularly useful
because many conditional features are disabled on macOS, and this helps
make sure we can still successfully install & dist when these bits are
disabled.
The default script is getting unreadable since it is all on one long
line. Rather than adding further conditional clauses to it, we make
use of the travis matrix config override for the script.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Running "make distcheck" includes the "make check", and "make dist"
targets. It ensures that we have CLEANFILES and uninstall rules setup
correctly, as well as validating VPATH builds succeed.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The precise distro is marked deprecated in travis and will be dropped
entirely in 2 months time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Installing nfs-common is broken on trusty since build #807https://travis-ci.org/libvirt/libvirt/builds/326705054
It's probably a transient error on Travis' side, so just comment
it out for the time being to allow builds to proceed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Make sure we install the same packages lcitool would install on
the CentOS CI so that we have consistent results. The package
list is current as of libvirt-jenkins-ci commit 3a559ae7bc08.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
gettext, gnutls and libgcrypt are already installed on the
system, so we don't need to request their installation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Installed packages might be outdated by the time the build
runs, so we should update them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Turns out a build job can be stuck waiting for a macOS worker to
become available for a pretty long time: if more than 5 commits
have been pushed in the meantime, the clone will be too shallow
for the worker to find the commit it's supposed to verify, and
the build job will fail.
See https://travis-ci.org/libvirt/libvirt/jobs/277244110 for an
example of the failure described.
This reverts commit 2e975abdc9.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Order them more logically and make sure that stuff that doesn't
need to be modified frequently if at all, such as the notification
settings, are out of the way.
Perform other very minor tweaks as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Since configure automatically picks up as many optional dependencies
as possible, installing more packages allows us to improve our test
coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
The default distribution is apparently ignored if an explicit test
matrix is provided, so we haven't actually been testing the precise
plus gcc combo.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Make parts of the build command OS-dependent instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
The openwsman header files are at fault here, but precise is entirely
unmaintained at this point so the issue will never be fixed.
Better to ignore the error and have coverage over the Hyper-V driver
than disabling it: if code that would trigger the warning will be
added to libvirt, the CentOS CI will catch it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
We don't need 50 commits for our purposes, so might as well save some
bandwidth and possibly some time by making the clone shallower.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
msgmerge(1) and friends are required to build libvirt, so the
corresponding package should be installed in the Travis worker.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Keeping the list of build dependencies sorted alphabetically
makes it way easier to visually scan it for issues.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The HTML pages are currently validated against an XHTML 1.0 DTD.
This makes it impossible to take advantage of features that are
introduced in HTML 5, because they'll fail validation.
There is intentionally no DTD defined for HTML 5, so there's no
alternative to XHTML 1.0 DTD that we could switch to. The only
options are to stick with XHTML 1.0 forever, or drop the DTD
validation, and we pick the latter.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Disclose the content of the 'test-suite.log' file (if available) in
case of failures inside Travis-CI. This is needed to understand what
happened and to provide hints about the proper fix (if applicable).
This travis configuration tests libvirt builds on 5 platforms that we don't
exercise in the CentOS CI system.
- Ubuntu Trusty with GCC
- Ubuntu Trusty with CLang
- Ubuntu Precise with GCC
- Ubuntu Precise with CLang
- OS-X with CLang
NB, syntax-check fails on OS-X with errors like:
/bin/sh: /usr/bin/grep: Argument list too long
Presumably their grep impl isn't as good as the GNU one, so this test
config skips syntax-check on OS-X for now.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
