consolidating CI builds

[Enrico Weigelt, metux IT consult]

On 11.06.24 09:09, Peter Hutterer wrote:

hi folks,

> With my ci-templates maintainer hat on: no to xorg-specific templates in
> there, it gets too messy.

Indeed that would be the most wrong place.

> Note that you can include any file from another repo (I think) so in
> theory we could ship the templates in e.g.
> xserver/.gitlab-templates/foo.yml or whatever. Not saying we should do
> that, just noting it's possible.

Actually though of that. It has some logic: drivers are depending on
Xserver anyways, it already provides some "sdk" for them.

By the way: most of that stuff isn't actually gitlab specific - they're
also designed to be called directly, eg. from within chroot or VM.
So they're also helpful for scenarios that we can't easily integrate
on gitlab (Solaris, NetBSD, ...). They also hold the logic for OS
specific tweaks (eg. special pkgconf pathes), detecting the actual build
system (xserver as well as driver), etc, etc.

The more I'm thinking about it, the stronger my feeling that xserver
repo smells like the best candidate.

> ci-fairy (in ci-templates) also has a generate-templates command that
> e.g. libinput uses to generate templates from a config.yml and a jinja
> file. This could also be an option - have a shared *source* template
> somewhere, then generate the .gitlab-ci.yml it with repo-specific config
> values.

Maybe I'm not really understanding your idea, but I don't feel that's
the best way: there's not really anything to generate, and the way it's
done with current templates (eg. the generator has to put in blob
hashes, etc) IMHO isn't the fine art.

Speaking of which: why doesn't it just clone the git repo for getting
scripts like cbuild, etc ? IMHO would make things a lot easier than
having "hardcoded" hashes in the generated templates. By the way, while
working on on the CI stuff, learned that a lot of sophisticated things
can be done via gitlab templates (still far away from jenkins
capabilities) ... maybe we could do it even w/o generating templates.
But that's another topic of it's own.

Back to xorg drivers:

As things are now, moving that all out to separate repo just doesn't
work: cbuild (when building the container images) makes it's own git
clone of the project's repo, and we don't have any means for injecting
extra steps. So, when $FDO_DISTRIBUTION_EXEC is called, the scripts
are missing :(

I've played around with job inheritance and before_script, so the aux
repo is cloned before anything else. But that failed at cbuild for
the reasons above.

Just got one spontanous idea I'll yet have to try: also add those
commands to $FDO_DISTRIBUTION_EXEC. Clumpsy, but maybe it could work.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info at metux.net -- +49-151-27565287