[libvirt-jenkins-ci PATCH] guests: allow for container image inheritance
by Daniel P. Berrangé
Currently when creating a Dockerfile for a container, we include the
full set of base packages, along with the packages for the project
itself. If building a Perl binding, this would require us to install
the base package, libvirt packages and Perl packages. With the use
of the "--inherit libvirt-fedora-30" arg, it is possible to have a
dockerfile that only adds the Perl packages, getting everything
else from the parent image.
For example, a full Dockerfile for libvirt-go would thus be:
FROM libvirt-centos-7:latest
RUN yum install -y \
golang && \
yum autoremove -y && \
yum clean all -y
Note there is no need to set ENV either, as that's inherited from the
parent container.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
guests/lcitool | 108 ++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 98 insertions(+), 10 deletions(-)
diff --git a/guests/lcitool b/guests/lcitool
index 689a8cf..b3afb6a 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -396,6 +396,12 @@ class Application:
help="target architecture for cross compiler",
)
+ def add_inherit_arg(parser):
+ parser.add_argument(
+ "-i", "--inherit",
+ help="inherit from an intermediate container image",
+ )
+
def add_wait_arg(parser):
parser.add_argument(
"-w", "--wait",
@@ -442,6 +448,7 @@ class Application:
add_hosts_arg(dockerfileparser)
add_projects_arg(dockerfileparser)
add_cross_arch_arg(dockerfileparser)
+ add_inherit_arg(dockerfileparser)
def _execute_playbook(self, playbook, hosts, projects, git_revision):
base = Util.get_base()
@@ -644,11 +651,11 @@ class Application:
with open(keyfile, "r") as r:
return r.read().rstrip()
- def _dockerfile_build_varmap(self, facts, mappings, pip_mappings, projects, cross_arch):
+ def _dockerfile_build_varmap(self, facts, mappings, pip_mappings, projects, cross_arch, needbase):
if facts["package_format"] == "deb":
- varmap = self._dockerfile_build_varmap_deb(facts, mappings, pip_mappings, projects, cross_arch)
+ varmap = self._dockerfile_build_varmap_deb(facts, mappings, pip_mappings, projects, cross_arch, needbase)
if facts["package_format"] == "rpm":
- varmap = self._dockerfile_build_varmap_rpm(facts, mappings, pip_mappings, projects, cross_arch)
+ varmap = self._dockerfile_build_varmap_rpm(facts, mappings, pip_mappings, projects, cross_arch, needbase)
varmap["package_manager"] = facts["package_manager"]
varmap["cc"] = facts["cc"]
@@ -662,7 +669,7 @@ class Application:
return varmap
- def _dockerfile_build_varmap_deb(self, facts, mappings, pip_mappings, projects, cross_arch):
+ def _dockerfile_build_varmap_deb(self, facts, mappings, pip_mappings, projects, cross_arch, needbase):
package_format = facts["package_format"]
package_manager = facts["package_manager"]
os_name = facts["os_name"]
@@ -682,7 +689,10 @@ class Application:
# We need to add the base project manually here: the standard
# machinery hides it because it's an implementation detail
- for project in projects + ["base"]:
+ pkgprojects = projects
+ if needbase:
+ pkgprojects = projects + ["base"]
+ for project in pkgprojects:
for package in self._projects.get_packages(project):
cross_policy = "native"
for key in cross_keys:
@@ -730,7 +740,7 @@ class Application:
return varmap
- def _dockerfile_build_varmap_rpm(self, facts, mappings, pip_mappings, projects, cross_arch):
+ def _dockerfile_build_varmap_rpm(self, facts, mappings, pip_mappings, projects, cross_arch, needbase):
package_format = facts["package_format"]
package_manager = facts["package_manager"]
os_name = facts["os_name"]
@@ -744,7 +754,10 @@ class Application:
# We need to add the base project manually here: the standard
# machinery hides it because it's an implementation detail
- for project in projects + ["base"]:
+ pkgprojects = projects
+ if needbase:
+ pkgprojects = projects + ["base"]
+ for project in pkgprojects:
for package in self._projects.get_packages(project):
for key in keys:
if key in mappings[package]:
@@ -791,7 +804,7 @@ class Application:
return varmap
- def _dockerfile_format(self, facts, cross_arch, varmap):
+ def _dockerfile_base_format(self, facts, cross_arch, varmap):
package_format = facts["package_format"]
package_manager = facts["package_manager"]
os_name = facts["os_name"]
@@ -931,6 +944,74 @@ class Application:
ENV CONFIGURE_OPTS "--host={cross_abi}"
""").format(**varmap))
+ def _dockerfile_child_format(self, facts, cross_arch, inherit, varmap):
+ package_format = facts["package_format"]
+ package_manager = facts["package_manager"]
+ os_name = facts["os_name"]
+ os_version = facts["os_version"]
+
+ print("FROM {}".format(inherit))
+
+ commands = []
+
+ if package_format == "deb":
+ commands.extend([
+ "export DEBIAN_FRONTEND=noninteractive",
+ "{package_manager} update",
+ "{package_manager} install --no-install-recommends -y {pkgs}",
+ "{package_manager} autoremove -y",
+ "{package_manager} autoclean -y",
+ ])
+ elif package_format == "rpm":
+ commands.extend([
+ "{package_manager} install -y {pkgs}",
+ ])
+
+ # openSUSE doesn't seem to have a convenient way to remove all
+ # unnecessary packages, but CentOS and Fedora do
+ if os_name == "OpenSUSE":
+ commands.extend([
+ "{package_manager} clean --all",
+ ])
+ else:
+ commands.extend([
+ "{package_manager} autoremove -y",
+ "{package_manager} clean all -y",
+ ])
+
+
+ script = "\nRUN " + (" && \\\n ".join(commands)) + "\n"
+ sys.stdout.write(script.format(**varmap))
+
+ if cross_arch:
+ cross_commands = []
+
+ # Intentionally a separate RUN command from the above
+ # so that the common packages of all cross-built images
+ # share a Docker image layer.
+ if package_format == "deb":
+ cross_commands.extend([
+ "export DEBIAN_FRONTEND=noninteractive",
+ "{package_manager} update",
+ "{package_manager} install --no-install-recommends -y {cross_pkgs}",
+ "{package_manager} autoremove -y",
+ "{package_manager} autoclean -y",
+ ])
+ elif package_format == "rpm":
+ cross_commands.extend([
+ "{package_manager} install -y {cross_pkgs}",
+ "{package_manager} clean all -y",
+ ])
+
+ cross_script = "\nRUN " + (" && \\\n ".join(cross_commands)) + "\n"
+ sys.stdout.write(cross_script.format(**varmap))
+
+ if "pip_pkgs" in varmap:
+ sys.stdout.write(textwrap.dedent("""
+ RUN pip3 install {pip_pkgs}
+ """).format(**varmap))
+
+
def _action_dockerfile(self, args):
mappings = self._projects.get_mappings()
pip_mappings = self._projects.get_pip_mappings()
@@ -947,6 +1028,7 @@ class Application:
os_version = facts["os_version"]
os_full = os_name + os_version
cross_arch = args.cross_arch
+ inherit = args.inherit
if package_format not in ["deb", "rpm"]:
raise Exception("Host {} doesn't support Dockerfiles".format(host))
@@ -983,8 +1065,14 @@ class Application:
)
)
- varmap = self._dockerfile_build_varmap(facts, mappings, pip_mappings, projects, cross_arch)
- self._dockerfile_format(facts, cross_arch, varmap)
+ needbase = True
+ if inherit is not None:
+ needbase = False
+ varmap = self._dockerfile_build_varmap(facts, mappings, pip_mappings, projects, cross_arch, needbase)
+ if inherit is None:
+ self._dockerfile_base_format(facts, cross_arch, varmap)
+ else:
+ self._dockerfile_child_format(facts, cross_arch, inherit, varmap)
def run(self):
args = self._parser.parse_args()
--
2.24.1
5 years
Re: [PATCH] qemu: fix code format problem
by yubihong
OK, Michal. I will do this job later, thanks for your advice.
> On 4/26/20 1:56 PM, yubihong wrote:
> > There are some code format problems in src/libvirt-domain.c. This
> > patch fixes these problems.
> >
> >>From 55cd85345b2dc50f44c1e382563482d40142382b Mon Sep 17 00:00:00
> > 2001
> > From: yubihong <yubihong(a)huawei.com>
> > Date: Fri, 24 Apr 2020 17:44:43 +0800
> > Subject: [PATCH] qemu: fix code format problem
> >
> > Signed-off-by:Yu Bihong <yubihong(a)huawei.com>
> > ---
> > src/libvirt-domain.c | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index
> > a12809c..d659f1b
> > 100644
> > --- a/src/libvirt-domain.c
> > +++ b/src/libvirt-domain.c
> > @@ -8194,11 +8194,11 @@ virDomainAttachDevice(virDomainPtr domain,
> > const char *xml)
> > virCheckReadOnlyGoto(conn->flags, error);
> >
> > if (conn->driver->domainAttachDevice) {
> > - int ret;
> > - ret = conn->driver->domainAttachDevice(domain, xml);
> > - if (ret < 0)
> > - goto error;
> > - return ret;
> > + int ret;
> > + ret = conn->driver->domainAttachDevice(domain, xml);
> > + if (ret < 0)
> > + goto error;
> > + return ret;
> > }
> >
> > virReportUnsupportedError();
> > @@ -8299,9 +8299,9 @@ virDomainDetachDevice(virDomainPtr domain,
> const
> > char *xml)
> > if (conn->driver->domainDetachDevice) {
> > int ret;
> > ret = conn->driver->domainDetachDevice(domain, xml);
> > - if (ret < 0)
> > - goto error;
> > - return ret;
> > + if (ret < 0)
> > + goto error;
> > + return ret;
> > }
> >
> > virReportUnsupportedError();
> > --
> > 1.8.3.1
> >
>
> This patch doesn't apply cleanly. Can you please resend using git-send-email
> as our documentation suggest?
>
> https://libvirt.org/submitting-patches.html
>
> The idea looks good, but I guess there are more places in the file that are
> misaligned. Might be worth extending your patch and include them.
>
> Michal
5 years
[libvirt-ci PATCH] vars: Add python3-wheel to the base package dependencies
by Erik Skultety
On platforms where we need to install meson from pip, one will very
likely see something similar to this when building a container from the
generated Dockerfile:
Collecting meson==0.49.0
Downloading <url>/meson-0.49.0.tar.gz (1.3MB)
100% |################################| 1.3MB 874kB/s
Building wheels for collected packages: meson
Running setup.py bdist_wheel for meson ... error
error: invalid command 'bdist_wheel'
----------------------------------------
Failed building wheel for meson
Running setup.py clean for meson
Failed to build meson
Pip is missing the 'wheel' package necessary to build a wheel from
sources, if it fails to do that, it falls back to the good old:
$ setup.py install meson
which succeeds and no harm was done. However, seeing an error in the
log always raises eyebrows, so let's fix that very simply by installing
the 'wheel' package which is available on all supported platforms.
Signed-off-by: Erik Skultety <eskultet(a)redhat.com>
---
Alternatively, we could use --no-cache-dir with pip install, but I'm not sure
whether it would be enough with new versions of pip. I still feel like
installing the 'wheel' package explicitly is a more transparent and safe fix
even though we don't benefit from the resulting meson wheel package inside
containers at all.
guests/vars/mappings.yml | 4 ++++
guests/vars/projects/base.yml | 1 +
2 files changed, 5 insertions(+)
diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index 753f0fe..4a19fb4 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -909,6 +909,10 @@ mappings:
default: python3-setuptools
FreeBSD: py37-setuptools
+ python3-wheel:
+ default: python3-wheel
+ FreeBSD: py37-wheel
+
qemu-img:
default: qemu-utils
rpm: qemu-img
diff --git a/guests/vars/projects/base.yml b/guests/vars/projects/base.yml
index 29c10b4..81c4462 100644
--- a/guests/vars/projects/base.yml
+++ b/guests/vars/projects/base.yml
@@ -28,6 +28,7 @@ packages:
- python3
- python3-pip
- python3-setuptools
+ - python3-wheel
- rpmbuild
- screen
- strace
--
2.25.3
5 years
[libvirt-jenkins-ci PATCH] guests: Run libvirt-dbus test suite on Fedora 31
by Andrea Bolognani
This was left out by mistake.
Fixes: f7ffff9cd9cc250ac32d7e343c15b4697e931a68
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Pushed as trivial.
guests/playbooks/build/projects/libvirt-dbus.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/guests/playbooks/build/projects/libvirt-dbus.yml b/guests/playbooks/build/projects/libvirt-dbus.yml
index e29d74b..4cf435d 100644
--- a/guests/playbooks/build/projects/libvirt-dbus.yml
+++ b/guests/playbooks/build/projects/libvirt-dbus.yml
@@ -19,6 +19,7 @@
- libvirt-debian-10
- libvirt-debian-sid
- libvirt-fedora-30
+ - libvirt-fedora-31
- libvirt-fedora-rawhide
- libvirt-opensuse-151
- libvirt-ubuntu-1804
--
2.25.4
5 years
[jenkins-ci PATCH] jenkins: Fix machine order for libvirt-sandbox
by Andrea Bolognani
Fixes: f7ffff9cd9cc250ac32d7e343c15b4697e931a68
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Pushed as trivial.
jenkins/projects/libvirt-sandbox.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/jenkins/projects/libvirt-sandbox.yaml b/jenkins/projects/libvirt-sandbox.yaml
index 6a8acec..10c2441 100644
--- a/jenkins/projects/libvirt-sandbox.yaml
+++ b/jenkins/projects/libvirt-sandbox.yaml
@@ -25,5 +25,5 @@
parent_jobs: 'libvirt-sandbox-check'
machines:
- libvirt-fedora-30
- - libvirt-fedora-rawhide
- libvirt-fedora-31
+ - libvirt-fedora-rawhide
--
2.25.4
5 years
[PATCH] docs: Describe protected virtualization guest setup
by Boris Fiuczynski
From: Viktor Mihajlovski <mihajlov(a)linux.ibm.com>
Protected virtualization/IBM Secure Execution for Linux protects
guest memory and state from the host.
Add some basic information about technology and a brief guide
on setting up secure guests with libvirt.
Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
Reviewed-by: Paulo de Rezende Pinatti <ppinatti(a)linux.ibm.com>
---
docs/kbase.html.in | 3 +
docs/kbase/protected_virtualization.rst | 188 ++++++++++++++++++++++++
2 files changed, 191 insertions(+)
create mode 100644 docs/kbase/protected_virtualization.rst
diff --git a/docs/kbase.html.in b/docs/kbase.html.in
index c586e0f676..05a3239224 100644
--- a/docs/kbase.html.in
+++ b/docs/kbase.html.in
@@ -14,6 +14,9 @@
<dt><a href="kbase/secureusage.html">Secure usage</a></dt>
<dd>Secure usage of the libvirt APIs</dd>
+ <dt><a href="kbase/protected_virtualization.html">Protected virtualization</a></dt>
+ <dd>Running secure guests with IBM Secure Execution</dd>
+
<dt><a href="kbase/launch_security_sev.html">Launch security</a></dt>
<dd>Securely launching VMs with AMD SEV</dd>
diff --git a/docs/kbase/protected_virtualization.rst b/docs/kbase/protected_virtualization.rst
new file mode 100644
index 0000000000..48f2add14e
--- /dev/null
+++ b/docs/kbase/protected_virtualization.rst
@@ -0,0 +1,188 @@
+========================
+Protected Virtualization
+========================
+
+.. contents::
+
+Overview
+========
+
+Protected virtualization, also known as IBM Secure Execution is a
+hardware-based privacy protection technology for s390x (IBM Z).
+It allows to execute virtual machines such that the host system
+has no access to a VM's state and memory contents.
+
+Unlike other similar technologies, the memory of a running guest
+is not encrypted but protected by hardware access controls, which
+may only be manipulated by trusted system firmware, called
+ultravisor.
+
+For the cases where the host needs access to guest memory (e.g. for
+paging), it can request pages to be exported to it. The exported page
+will be encrypted with a unique key for the running guest by the
+ultravisor. The ultravisor also computes an integrity value for
+the page, and stores it in a special table, together with the page
+index and a counter. This way it can verify the integrity of
+the page content upon re-import into the guest.
+
+In other cases it may be necessary for a guest to grant the host access
+to dedicated memory regions (e.g. for I/O). The guest can request
+that the ultravisor removes the memory protection from individual
+pages, so that they can be shared with the host. Likewise, the
+guest can undo the sharing.
+
+A secure guest will initially start in a regular non-protected VM.
+The start-up is controlled by a small bootstrap program loaded
+into memory together with encrypted operating system components and
+a control structure (the PV header).
+The operating system components (e.g. Linux kernel, initial RAM
+file system, kernel parameters) are encrypted and integrity
+protected. The component encryption keys and integrity values are
+stored in the PV header.
+The PV header is wrapped with a public key belonging to a specific
+system (in fact it can be wrapped with multiple such keys). The
+matching private key is only accessible by trusted hardware and
+firmware in that specific system.
+Consequently, such a secure guest boot image can only be run on the
+systems it has been prepared for. Its contents can't be decrypted
+without access to the private key and it can't be modified as
+it is integrity protected.
+
+Host Requirements
+=================
+
+IBM Secure Execution for Linux has some hardware and firmware
+requirements. The system hardware must be an IBM z15 (or newer),
+or an IBM LinuxONE III (or newer).
+
+It is also necessary that the IBM Secure Execution feature is
+enabled for that system. Check for facility '158', e.g.
+
+::
+
+ $ grep facilities /proc/cpuinfo | grep 158
+
+The kernel must include the protected virtualization support
+which can be verified by checking for the presence of directory
+``/sys/firmware/uv``. It will only be present when both the
+hardware and the kernel support are available.
+
+Finally, the host operating system must donate some memory to
+the ultravisor needed to store memory security information.
+This is achieved by specifying the following kernel command
+line parameter to the host boot configuration
+
+::
+
+ prot_virt=1
+
+
+Guest Requirements
+==================
+
+Guest Boot
+----------
+
+To start a guest in protected virtualization secure mode, the
+boot image must have been prepared first with the program
+``genprotimg`` using the correct public key for this host.
+``genprotimg`` is part of the package ``s390-tools``, or
+``s390-utils``, depending on the Linux distribution being used.
+It can also be found at
+`<https://github.com/ibm-s390-tools/s390-tools/tree/master/genprotimg>`_
+
+The guests have to be configured to use the host CPU model, which
+must contain the ``unpack`` facility indicating ultravisor guest support.
+
+With the following command it's possible to check whether the host
+CPU model satisfies the requirement
+
+::
+
+ $ virsh domcapabilities | grep unpack
+
+which should return
+
+::
+
+ <feature policy='require' name='unpack'/>
+
+If the check fails despite the host system actually supporting
+protected virtualization guests, this can be caused by a stale
+libvirt capabilities cache. To recover, run the following
+commands
+
+::
+
+ $ systemctl stop libvirtd
+ $ rm /var/cache/libvirt/qemu/capabilities/*.xml
+ $ systemctl start libvirtd
+
+
+Guest I/O
+---------
+
+Protected virtualization guests support I/O using virtio devices.
+As the virtio datastructures of secure guests are not accessible
+by the host, it is necessary to use shared memory ('bounce buffers').
+
+To enable virtio devices to use shared buffers, it is necessary
+to configure them with platform_iommu enabled. This can done by adding
+``iommu='on'`` to the driver element of a virtio device definition in the
+guest's XML, e.g.
+
+::
+
+ <interface type='network'>
+ <source network='default'/>
+ <model type='virtio'/>
+ <driver name='vhost' iommu='on'/>
+ </interface>
+
+It is mandatory to define all virtio bus devices in this way to
+prevent the host from attempting to access protected memory.
+Ballooning will not work and is fenced by QEMU. It should be
+disabled by specifying
+
+::
+
+ <memballoon model='none'/>
+
+Finally, the guest Linux must be instructed to allocate I/O
+buffers using memory shared between host and guest using SWIOTLB.
+This is done by adding ``swiotlb=nnn`` to the guest's kernel command
+line string, where ``nnn`` stands for the number of statically
+allocated 2K entries. A commonly used value for swiotlb is 262144.
+
+Example guest definition
+========================
+
+Minimal domain XML for a protected virtualization guest, essentially
+it's mostly about the ``iommu`` property
+
+::
+
+ <domain type='kvm'>
+ <name>protected</name>
+ <memory unit='KiB'>2048000</memory>
+ <currentMemory unit='KiB'>2048000</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='s390x'>hvm</type>
+ </os>
+ <cpu mode='host-model'/>
+ <devices>
+ <disk type='file' device='disk'>
+ <driver name='qemu' type='qcow2' cache='none' io='native' iommu='on'>
+ <source file='/var/lib/libvirt/images/protected.qcow2'/>
+ <target dev='vda' bus='virtio'/>
+ </disk>
+ <interface type='network'>
+ <driver iommu='on'/>
+ <source network='default'/>
+ <model type='virtio'/>
+ </interface>
+ <console type='pty'/>
+ <memballoon model='none'/>
+ </devices>
+ </domain>
--
2.25.1
5 years
[PATCH 0/3] doc: minor improvements
by Sebastian Mitterle
Minor man/doc improvements related to blockpull.
Sebastian Mitterle (3):
Improve blockpull man entry
Improve Disk image chains documentation
Add version info on domaincaps doc
docs/formatdomaincaps.html.in | 3 ++-
docs/kbase/backing_chains.rst | 36 +++++++++++++++++------------------
docs/manpages/virsh.rst | 19 ++++++++++++------
3 files changed, 33 insertions(+), 25 deletions(-)
--
2.25.2
5 years
[jenkins-ci PATCH] lcitool: Move gtk-vnc MinGW builds to Fedora Rawhide
by Andrea Bolognani
When moving MinGW builds off Fedora 30, gtk-vnc was mistakenly
left behind.
Fixes: 6ede7a19e7aa1670bbe13b10d8014977d3bb2203
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Pushed as a CI fix.
guests/host_vars/libvirt-fedora-30/main.yml | 2 --
guests/host_vars/libvirt-fedora-rawhide/main.yml | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/guests/host_vars/libvirt-fedora-30/main.yml b/guests/host_vars/libvirt-fedora-30/main.yml
index 227db89..a8f6fb9 100644
--- a/guests/host_vars/libvirt-fedora-30/main.yml
+++ b/guests/host_vars/libvirt-fedora-30/main.yml
@@ -1,8 +1,6 @@
---
projects:
- gtk-vnc
- - gtk-vnc+mingw32
- - gtk-vnc+mingw64
- libosinfo
- libvirt
- libvirt-cim
diff --git a/guests/host_vars/libvirt-fedora-rawhide/main.yml b/guests/host_vars/libvirt-fedora-rawhide/main.yml
index 2367fe1..bd42a87 100644
--- a/guests/host_vars/libvirt-fedora-rawhide/main.yml
+++ b/guests/host_vars/libvirt-fedora-rawhide/main.yml
@@ -1,6 +1,8 @@
---
projects:
- gtk-vnc
+ - gtk-vnc+mingw32
+ - gtk-vnc+mingw64
- libosinfo
- libosinfo+mingw32
- libosinfo+mingw64
--
2.25.4
5 years
[libvirt-perl PATCH v2 0/3] gitlab: introduce CI coverage
by Daniel P. Berrangé
This series introduces CI jobs for the Perl binding, enabling the switch
over to use of Merge Requests with pre-merge build validation.
v1: https://www.redhat.com/archives/libvir-list/2020-April/msg01157.html
This is a different approach from v1, because we don't inherit from the
main libvirt container images. Instead we use the libvirt-minimal
project as a dependancy. The cost is that the container build stage is
more expensive, but the main project build stage is cheaper. This is a
net win because the container build stage is cached so is only a penalty
the first time, or when the distro parent image has changes to pull in.
It also makes the CI process of the binding more self-contained avoiding
by avoiding a dep on the container image for libvirt.
Daniel P. Berrangé (3):
Build: bump min perl to 5.16.0
gitlab: add CI jobs for validating build across platforms
gitlab: add a simple job that publishes the API docs as HTML
.gitlab-ci.yml | 158 ++++++++++++++++++++++++++++++++++
Build.PL | 2 +-
ci/libvirt-centos-7.dkr | 97 +++++++++++++++++++++
ci/libvirt-centos-8.dkr | 68 +++++++++++++++
ci/libvirt-debian-10.dkr | 68 +++++++++++++++
ci/libvirt-debian-9.dkr | 71 +++++++++++++++
ci/libvirt-debian-sid.dkr | 68 +++++++++++++++
ci/libvirt-fedora-30.dkr | 66 ++++++++++++++
ci/libvirt-fedora-31.dkr | 66 ++++++++++++++
ci/libvirt-fedora-rawhide.dkr | 67 ++++++++++++++
ci/libvirt-opensuse-151.dkr | 66 ++++++++++++++
ci/libvirt-ubuntu-1604.dkr | 71 +++++++++++++++
ci/libvirt-ubuntu-1804.dkr | 71 +++++++++++++++
ci/refresh | 16 ++++
14 files changed, 954 insertions(+), 1 deletion(-)
create mode 100644 ci/libvirt-centos-7.dkr
create mode 100644 ci/libvirt-centos-8.dkr
create mode 100644 ci/libvirt-debian-10.dkr
create mode 100644 ci/libvirt-debian-9.dkr
create mode 100644 ci/libvirt-debian-sid.dkr
create mode 100644 ci/libvirt-fedora-30.dkr
create mode 100644 ci/libvirt-fedora-31.dkr
create mode 100644 ci/libvirt-fedora-rawhide.dkr
create mode 100644 ci/libvirt-opensuse-151.dkr
create mode 100644 ci/libvirt-ubuntu-1604.dkr
create mode 100644 ci/libvirt-ubuntu-1804.dkr
create mode 100755 ci/refresh
--
2.25.4
5 years
[libvirt-ci PATCH 0/2] Move MinGW builds back to Fedora Rawhide
by Andrea Bolognani
Andrea Bolognani (2):
lcitool: Prepare Fedora Rawhide for MinGW builds
Move MinGW builds back to Fedora Rawhide
guests/host_vars/libvirt-fedora-30/main.yml | 10 ----------
guests/host_vars/libvirt-fedora-rawhide/main.yml | 10 ++++++++++
guests/playbooks/build/jobs/defaults.yml | 2 +-
jenkins/jobs/defaults.yaml | 2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
--
2.25.3
5 years
