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.

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.

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.

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...