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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The sanity check scripts verify that the binding covers all APIs in the
libvirt library/headers being built against. This is primarily there for
libvirt maintainers to identify when there are gaps in API coverage.
This is not something downstream consumers of libvirt-python should be
running themselves, so we shouldn't added it to tests by default.
In addition if people are working on branches or submitting merge
requests for python changes, we shouldn't block their work for failed
API coverage sanity tests, if the python binding otherwise builds fine
and passes regular unit tests.
Thus, we introduce a new gitlab job "api-coverage" with some conditions:
- If pushing to a branch, the job is treated as non-fatal
- For regular scheduled builds, it is mandatory
- Don't run in any other scenarios
This job uses the artifacts from the centos-8-git-build job and re-runs
the test suite, requesting the sanity tests to be run too.
This will achieve the result of letting us see missing API coverage
in nightly builds, without blocking other contributions.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The software we use for running tests - nose - has been
deprecated in favor of nose2.
We don't use anything nose-specific, just unittest.TestCase,
which pytest can handle just fine.
Switch to using pytest, which we already use for libvirt-dbus.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
This function says we have libvirtaio on Python >= 3.3,
however we already mandate Python >= 3.5 at the start of the file.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The current code assumes the version number string will be only three
characters long, which fails with "3.10".
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Python 3.5 is the oldest Python version available across our supported
build platforms.
Reviewed-by: Philipp Hahn <hahn@univention.de>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
python2 will be end of life by the time of the next
libvirt release. All our supported build targets, including
CentOS7, have a python3 build available.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Although we're capable of building against any libvirt >= 0.9.11, 99% of the
time we want RPM builds to be done against matching libvirt version, otherwise
we might silently build against an unexpected/wrong version.
We don't support building against a native libvirt that's newer than the
python binding, since the generator may incorrectly handle new APIs. So use
== instead of >= too.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This is particularly useful on operating systems that don't ship
Python as part of the base system (eg. FreeBSD) while still working
just as well as it did before on Linux.
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Enable builds on several python versions, and against several versions
of libvirt. Ideally we would build all the way back to 0.9.11, since
that is the min supported libvirt for python binding. It is not possible
to build this old libvirt version on modern distros though, so using
1.2.0 as the oldest for now.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
