On Mon, 2020-06-29 at 17:35 +0100, Daniel P. Berrangé wrote:
On Mon, Jun 29, 2020 at 06:08:27PM +0200, Erik Skultety wrote:
> On Mon, Jun 29, 2020 at 03:32:22PM +0100, Daniel P. Berrangé wrote:
> > This part can then be stored in ci/cirrus/build.yml since it is
> > common to freebsd & macos.
> >
> > So now in gitlab-ci.yml we can just concatenate the two into a
> > temp file:
> >
> > cat ci/cirrus/$NAME.yml ci/cirrus/build.yml > ci/cirrus/$NAME.yml.j2
> > cirrus-run ci/cirrus/$NAME.yml.j2
>
> How about instead of storing the same build.yml in every secondary project's ci
> directory we store the build.yml in libvirt-ci repo and generate the whole
> thing with lcitool? I think the way the build YAML would look like for every
> single subproject, we could achieve the level of similarity we have for lcitool
> native builds - IOW the build job abstraction we have across projects under
> guests/playbooks/build/projects could also be achieved here with cirrus, just
> an idea.
Yep, I hesitated to suggest that, as I thought it might need boiling the
ocean in the short, whereas the other pieces are 100% static data we
can trivially emit with next to no effort. Long term if we can generate
the build commands too, that could be nice though. I'd even think about
the possibility of generating the main gitlab-ci.yml file to some degree,
though at some point you spend more time in the generator than on the
original file, so I'm not sure where the line is.
I agree that it would be incredibly neat if we could take the same
information used by 'lcitool build' and generate at least part of the
various .gitlab-ci.yml files.
However, I think we should *not* attempt something like that until
later, when we have enabled full GitLab CI support (including, where
applicable, FreeBSD and macOS) for all projects and we can hopefully
see the proper path forward more clearly thanks to the insights
gained in the process.
--
Andrea Bolognani / Red Hat / Virtualization