[libvirt-ci PATCH v2] guests: add libvirt-php project packages
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- guests/vars/mappings.yml | 12 ++++++++++++ guests/vars/projects/libvirt-php.yml | 6 ++++++ 2 files changed, 18 insertions(+) create mode 100644 guests/vars/projects/libvirt-php.yml diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml index 4808b12..3290201 100644 --- a/guests/vars/mappings.yml +++ b/guests/vars/mappings.yml @@ -831,6 +831,18 @@ mappings: OpenSUSE: CentOS7: + php: + deb: php-dev + rpm: php-devel + pkg: php74 + + php-imagick: + default: php-imagick + FreeBSD: php74-pecl-imagick + Fedora: php-pecl-imagick + CentOS: php-pecl-imagick + CentOS8: + pkg-config: default: pkgconf rpm: pkgconfig diff --git a/guests/vars/projects/libvirt-php.yml b/guests/vars/projects/libvirt-php.yml new file mode 100644 index 0000000..c911dc6 --- /dev/null +++ b/guests/vars/projects/libvirt-php.yml @@ -0,0 +1,6 @@ +--- +packages: + - php + - php-imagick + - xmllint + - xsltproc -- 2.26.2
On Tue, 2020-05-05 at 12:48 +0100, Daniel P. Berrangé wrote:
+ php-imagick: + default: php-imagick + FreeBSD: php74-pecl-imagick + Fedora: php-pecl-imagick + CentOS: php-pecl-imagick + CentOS8:
This could be php-imagick: deb: php-imagick rpm: php-pecl-imagick pkg: php74-pecl-imagick CentOS8: This patch is also missing the part where the libvirt-php project is added to the 'projects' fact for all targets that actually support building it, which would be all of them but CentOS 8 in this case I guess? We're also missing build steps for the project. I understand that, as we move stuff off CentOS CI and into GitLab CI containers become more important than VMs, but I think keeping 'lcitool build' working is still important, if nothing else as a development tool. It certainly makes my life easier as a reviewer... Not to mention it is the only way we can currently validate FreeBSD changes. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
On Tue, 2020-05-05 at 12:48 +0100, Daniel P. Berrangé wrote:
+ php-imagick: + default: php-imagick + FreeBSD: php74-pecl-imagick + Fedora: php-pecl-imagick + CentOS: php-pecl-imagick + CentOS8:
This could be
php-imagick: deb: php-imagick rpm: php-pecl-imagick pkg: php74-pecl-imagick CentOS8:
Ok.
This patch is also missing the part where the libvirt-php project is added to the 'projects' fact for all targets that actually support building it, which would be all of them but CentOS 8 in this case I guess?
We're also missing build steps for the project. I understand that, as we move stuff off CentOS CI and into GitLab CI containers become more important than VMs, but I think keeping 'lcitool build' working is still important, if nothing else as a development tool. It certainly makes my life easier as a reviewer... Not to mention it is the only way we can currently validate FreeBSD changes.
There's a bunch of projects we don't have in Jenkins CI right now, and I'm trying to get them all wired up into GitLab CI. I don't want to invest any more time in VM build aspects right now, as I don't have the time to spend testing & debugging that part too. So I'm only going to do the minimal required to get container builds work, which is defining the package lists used to feed the container build. The extra VM build stuff can be done separately at a later date if we decide we need that still for CI. 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 :|
On Tue, May 05, 2020 at 02:19:27PM +0100, Daniel P. Berrangé wrote:
On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
On Tue, 2020-05-05 at 12:48 +0100, Daniel P. Berrangé wrote:
+ php-imagick: + default: php-imagick + FreeBSD: php74-pecl-imagick + Fedora: php-pecl-imagick + CentOS: php-pecl-imagick + CentOS8:
This could be
php-imagick: deb: php-imagick rpm: php-pecl-imagick pkg: php74-pecl-imagick CentOS8:
Ok.
Actually that's not right, because it gives the wrong RPM name for OpenSuse. 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 :|
On Tue, 2020-05-05 at 14:22 +0100, Daniel P. Berrangé wrote:
On Tue, May 05, 2020 at 02:19:27PM +0100, Daniel P. Berrangé wrote:
On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
On Tue, 2020-05-05 at 12:48 +0100, Daniel P. Berrangé wrote:
+ php-imagick: + default: php-imagick + FreeBSD: php74-pecl-imagick + Fedora: php-pecl-imagick + CentOS: php-pecl-imagick + CentOS8:
This could be
php-imagick: deb: php-imagick rpm: php-pecl-imagick pkg: php74-pecl-imagick CentOS8:
Ok.
Actually that's not right, because it gives the wrong RPM name for OpenSuse.
Yeah, you're right. A slightly improved version would be php-imagick: default: php-imagick pkg: php74-pecl-imagick CentOS: php-pecl-imagick Fedora: php-pecl-imagick CentOS8: -- Andrea Bolognani / Red Hat / Virtualization
On Tue, 2020-05-05 at 14:19 +0100, Daniel P. Berrangé wrote:
On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
This patch is also missing the part where the libvirt-php project is added to the 'projects' fact for all targets that actually support building it, which would be all of them but CentOS 8 in this case I guess?
We're also missing build steps for the project. I understand that, as we move stuff off CentOS CI and into GitLab CI containers become more important than VMs, but I think keeping 'lcitool build' working is still important, if nothing else as a development tool. It certainly makes my life easier as a reviewer... Not to mention it is the only way we can currently validate FreeBSD changes.
There's a bunch of projects we don't have in Jenkins CI right now, and I'm trying to get them all wired up into GitLab CI. I don't want to invest any more time in VM build aspects right now, as I don't have the time to spend testing & debugging that part too. So I'm only going to do the minimal required to get container builds work, which is defining the package lists used to feed the container build. The extra VM build stuff can be done separately at a later date if we decide we need that still for CI.
I guess I'll have to put my money where my mouth is and add the build steps myself. That's fair. Please at least update the inventory so that it accurately records which targets are supposed to be able to build the new project. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, May 05, 2020 at 03:31:55PM +0200, Andrea Bolognani wrote:
On Tue, 2020-05-05 at 14:19 +0100, Daniel P. Berrangé wrote:
On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
This patch is also missing the part where the libvirt-php project is added to the 'projects' fact for all targets that actually support building it, which would be all of them but CentOS 8 in this case I guess?
We're also missing build steps for the project. I understand that, as we move stuff off CentOS CI and into GitLab CI containers become more important than VMs, but I think keeping 'lcitool build' working is still important, if nothing else as a development tool. It certainly makes my life easier as a reviewer... Not to mention it is the only way we can currently validate FreeBSD changes.
There's a bunch of projects we don't have in Jenkins CI right now, and I'm trying to get them all wired up into GitLab CI. I don't want to invest any more time in VM build aspects right now, as I don't have the time to spend testing & debugging that part too. So I'm only going to do the minimal required to get container builds work, which is defining the package lists used to feed the container build. The extra VM build stuff can be done separately at a later date if we decide we need that still for CI.
I guess I'll have to put my money where my mouth is and add the build steps myself. That's fair. Please at least update the inventory so that it accurately records which targets are supposed to be able to build the new project.
That's only required for VM builds, and would use of the "all" wildcard when building VMs, so I'm not wanting to do that, as I won't have tested anything related to VMs. 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 :|
On Tue, 2020-05-05 at 14:49 +0100, Daniel P. Berrangé wrote:
On Tue, May 05, 2020 at 03:31:55PM +0200, Andrea Bolognani wrote:
Please at least update the inventory so that it accurately records which targets are supposed to be able to build the new project.
That's only required for VM builds, and would use of the "all" wildcard when building VMs, so I'm not wanting to do that, as I won't have tested anything related to VMs.
It also serves as documentation for our expectations when it comes to which project can be built on which platform, and was intended to prevent the use of ./lctiool $action $target $project when $target is known not to support $project, even though we didn't enfore that for 'update' and 'build' in order to make ./lcitool $action all all work smoothly, and 'dockerfile' lost the check in one of your recent patches... -- Andrea Bolognani / Red Hat / Virtualization
On Tue, May 05, 2020 at 04:33:48PM +0200, Andrea Bolognani wrote:
On Tue, 2020-05-05 at 14:49 +0100, Daniel P. Berrangé wrote:
On Tue, May 05, 2020 at 03:31:55PM +0200, Andrea Bolognani wrote:
Please at least update the inventory so that it accurately records which targets are supposed to be able to build the new project.
That's only required for VM builds, and would use of the "all" wildcard when building VMs, so I'm not wanting to do that, as I won't have tested anything related to VMs.
It also serves as documentation for our expectations when it comes to which project can be built on which platform, and was intended to prevent the use of
./lctiool $action $target $project
when $target is known not to support $project, even though we didn't enfore that for 'update' and 'build' in order to make
./lcitool $action all all
work smoothly, and 'dockerfile' lost the check in one of your recent patches...
IIUC, "lcitool build libvirt-fedora-32 all" will try to build all projects in the host's inventory. So if we add libvirt-rust, to the host inventory we need to full the full VM setup for the project, otherwise we'll break this build. 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 :|
On Tue, 2020-05-05 at 15:51 +0100, Daniel P. Berrangé wrote:
On Tue, May 05, 2020 at 04:33:48PM +0200, Andrea Bolognani wrote:
On Tue, 2020-05-05 at 14:49 +0100, Daniel P. Berrangé wrote:
That's only required for VM builds, and would use of the "all" wildcard when building VMs, so I'm not wanting to do that, as I won't have tested anything related to VMs.
It also serves as documentation for our expectations when it comes to which project can be built on which platform, and was intended to prevent the use of
./lctiool $action $target $project
when $target is known not to support $project, even though we didn't enfore that for 'update' and 'build' in order to make
./lcitool $action all all
work smoothly, and 'dockerfile' lost the check in one of your recent patches...
IIUC, "lcitool build libvirt-fedora-32 all" will try to build all projects in the host's inventory. So if we add libvirt-rust, to the host inventory we need to full the full VM setup for the project, otherwise we'll break this build.
Mh, that's correct. Another consequence of not really having planned for things to be introduced only partially. -- Andrea Bolognani / Red Hat / Virtualization
participants (2)
-
Andrea Bolognani -
Daniel P. Berrangé