[libvirt-ci PATCH 0/3] vault: Add Fedora 32, remove unused secrets
by Andrea Bolognani
Pushed under the unreviewable vault update rule.
Andrea Bolognani (3):
vault: Remove unused secrets
vault: Add secret for Fedora 32
vault: Remove secret for Fedora 30
guests/vars/vault.yml | 100 +++++++++++++++++-------------------------
1 file changed, 41 insertions(+), 59 deletions(-)
--
2.25.4
4 years, 7 months
[libvirt-perl PATCH v3 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
v2: https://www.redhat.com/archives/libvir-list/2020-April/msg01408.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/README.rst | 12 ++
ci/libvirt-centos-7.Dockerfile | 97 ++++++++++++++++
ci/libvirt-centos-8.Dockerfile | 68 ++++++++++++
ci/libvirt-debian-10.Dockerfile | 68 ++++++++++++
ci/libvirt-debian-9.Dockerfile | 71 ++++++++++++
ci/libvirt-debian-sid.Dockerfile | 68 ++++++++++++
ci/libvirt-fedora-30.Dockerfile | 66 +++++++++++
ci/libvirt-fedora-31.Dockerfile | 66 +++++++++++
ci/libvirt-fedora-rawhide.Dockerfile | 67 ++++++++++++
ci/libvirt-opensuse-151.Dockerfile | 66 +++++++++++
ci/libvirt-ubuntu-1604.Dockerfile | 71 ++++++++++++
ci/libvirt-ubuntu-1804.Dockerfile | 71 ++++++++++++
ci/refresh | 22 ++++
15 files changed, 972 insertions(+), 1 deletion(-)
create mode 100644 ci/README.rst
create mode 100644 ci/libvirt-centos-7.Dockerfile
create mode 100644 ci/libvirt-centos-8.Dockerfile
create mode 100644 ci/libvirt-debian-10.Dockerfile
create mode 100644 ci/libvirt-debian-9.Dockerfile
create mode 100644 ci/libvirt-debian-sid.Dockerfile
create mode 100644 ci/libvirt-fedora-30.Dockerfile
create mode 100644 ci/libvirt-fedora-31.Dockerfile
create mode 100644 ci/libvirt-fedora-rawhide.Dockerfile
create mode 100644 ci/libvirt-opensuse-151.Dockerfile
create mode 100644 ci/libvirt-ubuntu-1604.Dockerfile
create mode 100644 ci/libvirt-ubuntu-1804.Dockerfile
create mode 100755 ci/refresh
--
2.25.4
4 years, 7 months
[libvirt-ci PATCH v2] guests: introduce libvirt+dist and libvirt+minimal projects
by Daniel P. Berrangé
The language bindings have traditionally built against a full libvirt,
however, this is serious overkill because all they should really need
most of the time is access to the main API, and the test driver if they
want to run functional tests. The full libvirt build with virt drivers
is only needed for integration testing which most bindings won't do.
Thus this introduces a new project "libvirt+minimal" which lists the
bare minimum dependencies required to build libvirt.
Taking libvirt-perl as an example, if creating a container using the
current "libvirt,libvirt-perl" project set, the result with 1.4 GB
in size for Fedora 31. With the "libvirt+minimal,libvirt-perl" set,
the size is just 777 MB.
Some projects also wish to have the ability to build against the distro
provided libvirt instead of the latest git master, and for this purpose
a "libvirt+dist" project is defined which pulls in the package needed
for building against the distro libvirt.
Thus when building any downstream project there is now a choice of
building it against "libvirt" (full git) or "libvirt+minimal" (minimal
git) or "libvirt+dist" (prebuilt distro). The same can be added later
for example "libvirt-perl+dist" to refer to the distro provided perl
binding.
In the lcitool dockerfile command, there is a check that the requested
project is configured against the requested host. These new projects are
not listed against any host, because we don't want them installed by
default in the VMs. Thus the dockerfile check is no longer valid and is
removed. Whomever is invoking lcitool knows what combination they want
and whether it will work.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
In v2:
- Use "+suffix" syntax for new projects
- Rename new package to "libvirt"
guests/lcitool | 7 -------
guests/vars/mappings.yml | 5 +++++
guests/vars/projects/libvirt+dist.yml | 3 +++
guests/vars/projects/libvirt+minimal.yml | 12 ++++++++++++
4 files changed, 20 insertions(+), 7 deletions(-)
create mode 100644 guests/vars/projects/libvirt+dist.yml
create mode 100644 guests/vars/projects/libvirt+minimal.yml
diff --git a/guests/lcitool b/guests/lcitool
index 0c89e13..abc87d2 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -1007,13 +1007,6 @@ class Application:
for project in projects:
if project.rfind("+mingw") >= 0:
raise Exception("Obsolete syntax, please use --cross-arch")
- if project not in facts["projects"]:
- raise Exception(
- "Host {} doesn't support project {}".format(
- host,
- project,
- )
- )
varmap = self._dockerfile_build_varmap(facts, mappings, pip_mappings, projects, cross_arch)
self._dockerfile_format(facts, cross_arch, varmap)
diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index 4a19fb4..9dcad46 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -450,6 +450,11 @@ mappings:
rpm: libuuid-devel
cross-policy-deb: foreign
+ libvirt:
+ rpm: libvirt-devel
+ deb: libvirt-dev
+ pkg: libvirt
+
libxml2:
deb: libxml2-dev
pkg: libxml2
diff --git a/guests/vars/projects/libvirt+dist.yml b/guests/vars/projects/libvirt+dist.yml
new file mode 100644
index 0000000..1fc1b2c
--- /dev/null
+++ b/guests/vars/projects/libvirt+dist.yml
@@ -0,0 +1,3 @@
+---
+packages:
+ - libvirt
diff --git a/guests/vars/projects/libvirt+minimal.yml b/guests/vars/projects/libvirt+minimal.yml
new file mode 100644
index 0000000..96335f2
--- /dev/null
+++ b/guests/vars/projects/libvirt+minimal.yml
@@ -0,0 +1,12 @@
+---
+packages:
+ - glib2
+ - gnutls
+ - libnl3
+ - libnlroute3
+ - libtirpc
+ - libxml2
+ - python3-docutils
+ - rpcgen
+ - xmllint
+ - xsltproc
--
2.25.4
4 years, 7 months
[libvirt-ci PATCH 0/4] Add Fedora 32, drop Fedora 30
by Andrea Bolognani
Fedora 32 was released earlier this week, and Fedora 30 goes EOL
the next one.
Andrea Bolognani (4):
guests: Add Fedora 32
Start building on Fedora 32
Stop building on Fedora 30
guests: Remove Fedora 30
guests/host_vars/libvirt-fedora-30/docker.yml | 2 -
guests/host_vars/libvirt-fedora-32/docker.yml | 2 +
.../install.yml | 2 +-
.../main.yml | 2 +-
guests/inventory | 2 +-
guests/playbooks/build/jobs/defaults.yml | 4 +-
guests/playbooks/build/projects/gtk-vnc.yml | 2 +-
guests/playbooks/build/projects/libosinfo.yml | 2 +-
.../playbooks/build/projects/libvirt-dbus.yml | 4 +-
.../build/projects/libvirt-sandbox.yml | 4 +-
.../playbooks/build/projects/libvirt-tck.yml | 4 +-
guests/playbooks/build/projects/libvirt.yml | 2 +-
.../build/projects/osinfo-db-tools.yml | 2 +-
.../playbooks/build/projects/virt-manager.yml | 6 +-
.../playbooks/build/projects/virt-viewer.yml | 2 +-
jenkins/jobs/defaults.yaml | 4 +-
jenkins/new.xml | 6423 ++++++++++++++++
jenkins/old.xml | 6435 +++++++++++++++++
jenkins/projects/gtk-vnc.yaml | 2 +-
jenkins/projects/libosinfo.yaml | 2 +-
jenkins/projects/libvirt-dbus.yaml | 4 +-
jenkins/projects/libvirt-sandbox.yaml | 4 +-
jenkins/projects/libvirt-tck.yaml | 4 +-
jenkins/projects/libvirt.yaml | 2 +-
jenkins/projects/osinfo-db-tools.yaml | 2 +-
jenkins/projects/virt-manager.yaml | 6 +-
jenkins/projects/virt-viewer.yaml | 2 +-
27 files changed, 12895 insertions(+), 37 deletions(-)
delete mode 100644 guests/host_vars/libvirt-fedora-30/docker.yml
create mode 100644 guests/host_vars/libvirt-fedora-32/docker.yml
rename guests/host_vars/{libvirt-fedora-30 => libvirt-fedora-32}/install.yml (66%)
rename guests/host_vars/{libvirt-fedora-30 => libvirt-fedora-32}/main.yml (97%)
create mode 100644 jenkins/new.xml
create mode 100644 jenkins/old.xml
--
2.25.4
4 years, 7 months
[libvirt-python PATCH 0/3] gitlab: introduce CI jobs for validating python build
by Daniel P. Berrangé
This introduces GitLab CI to the python module. Traditional Jenkins has
validated the python build across all distros, using libvirt git. This
tested one axis - a variety of python versions - but failed to test the
other interesting axis - a variety of libvirt versions.
This new CI setup fixes that mistake validating both axis and in the
process uncovered a bug in Ubuntu 1804.
Daniel P. Berrangé (3):
test: workaround missing VIR_TYPED_PARAM enums in API definition
gitlab: introduce CI jobs testing git master & distro libvirt
travis: delete redundant configuration
.gitlab-ci.yml | 172 ++++++++++++++++++++++++++++++++++
.travis.yml | 55 -----------
ci/libvirt-centos-7.dkr | 85 +++++++++++++++++
ci/libvirt-centos-8.dkr | 64 +++++++++++++
ci/libvirt-debian-10.dkr | 55 +++++++++++
ci/libvirt-debian-9.dkr | 58 ++++++++++++
ci/libvirt-debian-sid.dkr | 55 +++++++++++
ci/libvirt-fedora-30.dkr | 52 ++++++++++
ci/libvirt-fedora-31.dkr | 52 ++++++++++
ci/libvirt-fedora-rawhide.dkr | 53 +++++++++++
ci/libvirt-opensuse-151.dkr | 54 +++++++++++
ci/libvirt-ubuntu-1604.dkr | 58 ++++++++++++
ci/libvirt-ubuntu-1804.dkr | 58 ++++++++++++
ci/refresh | 21 +++++
sanitytest.py | 6 +-
15 files changed, 842 insertions(+), 56 deletions(-)
create mode 100644 .gitlab-ci.yml
delete mode 100644 .travis.yml
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
4 years, 7 months
[libvirt-ci PATCH] guests: introduce libvirt-dist and libvirt-minimal projects
by Daniel P. Berrangé
The language bindings have traditionally built against a full libvirt,
however, this is serious overkill because all they should really need
most of the time is access to the main API, and the test driver if they
want to run functional tests. The full libvirt build with virt drivers
is only needed for integration testing which most bindings won't do.
Thus this introduces a new project "libvirt-minimal" which lists the
bare minimum dependencies required to build libvirt.
Taking libvirt-perl as an example, if creating a container using the
current "libvirt,libvirt-perl" project set, the result with 1.4 GB
in size for Fedora 31. With the "libvirt-minimal,libvirt-perl" set,
the size is just 777 MB.
Some projects also wish to have the ability to build against the distro
provided libvirt instead of the latest git master, and for this purpose
a "libvirt-dist" project is defined which pulls in the package needed
for building against the distro libvirt.
In the lcitool dockerfile command, there is a check that the requested
project is configured against the requested host. These new projects are
not listed against any host, because we don't want them installed by
default in the VMs. Thus the dockerfile check is no longer valid and is
removed. Whomever is invoking lcitool knows what combination they want
and whether it will work.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
guests/lcitool | 7 -------
guests/vars/mappings.yml | 5 +++++
guests/vars/projects/libvirt-dist.yml | 3 +++
guests/vars/projects/libvirt-minimal.yml | 13 +++++++++++++
4 files changed, 21 insertions(+), 7 deletions(-)
create mode 100644 guests/vars/projects/libvirt-dist.yml
create mode 100644 guests/vars/projects/libvirt-minimal.yml
diff --git a/guests/lcitool b/guests/lcitool
index 0c89e13..abc87d2 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -1007,13 +1007,6 @@ class Application:
for project in projects:
if project.rfind("+mingw") >= 0:
raise Exception("Obsolete syntax, please use --cross-arch")
- if project not in facts["projects"]:
- raise Exception(
- "Host {} doesn't support project {}".format(
- host,
- project,
- )
- )
varmap = self._dockerfile_build_varmap(facts, mappings, pip_mappings, projects, cross_arch)
self._dockerfile_format(facts, cross_arch, varmap)
diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index 753f0fe..a9ab3d5 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -450,6 +450,11 @@ mappings:
rpm: libuuid-devel
cross-policy-deb: foreign
+ libvirt-devel:
+ rpm: libvirt-devel
+ deb: libvirt-dev
+ pkg: libvirt
+
libxml2:
deb: libxml2-dev
pkg: libxml2
diff --git a/guests/vars/projects/libvirt-dist.yml b/guests/vars/projects/libvirt-dist.yml
new file mode 100644
index 0000000..aa95f23
--- /dev/null
+++ b/guests/vars/projects/libvirt-dist.yml
@@ -0,0 +1,3 @@
+---
+packages:
+ - libvirt-devel
diff --git a/guests/vars/projects/libvirt-minimal.yml b/guests/vars/projects/libvirt-minimal.yml
new file mode 100644
index 0000000..9402c4f
--- /dev/null
+++ b/guests/vars/projects/libvirt-minimal.yml
@@ -0,0 +1,13 @@
+---
+packages:
+ - glib2
+ - gnutls
+ - libnl3
+ - libnlroute3
+ - libpcap
+ - libtirpc
+ - libxml2
+ - python3-docutils
+ - rpcgen
+ - xmllint
+ - xsltproc
--
2.25.4
4 years, 7 months
Live migration garp
by Ignazio Cassano
Hello All, I am facing issues under openstack rocky with last libvirt
available on centos 7.
There is an open discussione here:
https://bugs.launchpad.net/neutron/+bug/1866139
About sending garp when an instance live migrate.
What must send garp ?
The problem is this: when live migrate a vm from a node to another it stops
to responds to ping requests. It starts to respond only when it send a
network request for example when its chrony daemon pools a server.
Anyone could help me, please?
Best Regards
Ignazio
4 years, 7 months
Re: Libvirt Application Development Guide
by Daniel P. Berrangé
Replying again to re-add the mailing list
On Thu, Apr 30, 2020 at 08:56:12AM +0000, charalambous s. (sc3n17) wrote:
> Hello Daniel,
>
> Thank you for getting back to me!
>
> I understand that the state of the document was perhaps not as polished
> as one would like, however it was immensely helpful to me when developing
> my project. If it is not too difficult / costly, I personally would prefer
> if it was left up, since there aren't really any alternatives that are as
> useful. I do understand however that if I'm the only person that has used
> it in recent times, it may not be worth the effort.
Since you say it was useful to you, it is likely useful to other people
as well. Based on this I've temporarily re-enabled the cronjob that
was publishing it at:
https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/
I only re-enabled it for the python appdev guide, not the even older
C appdev guide.
I'll see about moving the cronjob into GitLab CI so we have a more
formal publishing approach. This will mean we can validate it when
we accept merge requests for the content too.
> Personally, I feel that the guide was good enough to guide me in
> the right direction when using the library, and the examples
> provided were useful in getting an idea of what was going on. A
> section of my project report is a short list of improvements that
> could be made to the guide, so if you do decide to reinstate it,
> I could help with improving some sections a little bit.
Since it lacks any current maintainer, we'd be happy if anyone wants
to volunteer to contribute improvements to it, whether little or large!
Thankyou for your interest in, and feedback to, the libvirt project.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4 years, 7 months
Libvirt Application Development Guide
by charalambous s. (sc3n17)
Hello,
For my third year project, I've developed a piece of software in python, making use of the Libvirt application development guide for python. I'm currently writing a report that references it.
I've noticed that you seem to have removed the guide from the libvirt site - has it been moved somewhere else, or deleted entirely? Will it be reinstated at some point, or is this a permanent change?
Thank you in advance and Best Regards,
Stephanos Charalambous
4 years, 7 months
[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
4 years, 7 months
