bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: continuous integrations pipeline frameworks


From: Simon Josefsson
Subject: Re: continuous integrations pipeline frameworks
Date: Mon, 06 May 2024 19:34:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Bruno Haible <bruno@clisp.org> writes:

> Simon Josefsson wrote:
>> I forgot to mention: the pattern to provide re-usable GitLab CI/CD
>> definitions that I'm inspired by is Debian's pipeline project:
>> 
>> https://salsa.debian.org/salsa-ci-team/pipeline/
>> 
>> It is easy to setup a new project to use their reusable pipeline -- just
>> add the CI/CD configuration file setting pointing to their job file --
>> and gives a broad configurable and tweakable pipeline.
>
> Sorry if this sounds negative, but
>
>   - So far, I've loved to adapt my CIs as needed. For example, one package
>     has a number of --with options, so my CI first builds without these
>     --with options, then installs the extra Debian packages and builds a
>     second time with these --with options. I don't think that any
>     pipeline framework can give me this possibility without causing
>     massive hurdles.
>
>   - With such frameworks, documentation is key.

Yes, any reusable system will need to support additional system packages
and ./configure flags and so on.

>> I'm thinking we could do the same but for any project using gnulib.
>> Within some reasonable limit and assumptions, but the majority of
>> projects mentioned already are similar enough for this to be possible
>> relatively easily.
>> 
>> I'm thinking it should be sufficient to add gnu-ci.yml@gnulib/pipeline
>> (or similar) as a CI/CD configuration file setting to achieve this.
>
> It's quite possible that with this approach, you can bring more GNU packages
> into the "we have CI" camp.
>
> I wouldn't like to switch to such a framework, though, because I'm already
> too much of an expert in GitLab CI.

Right -- the key to this working well is that no switch should be
necessary.  Written properly, you add one 'include' to your existing job
definition file and that enable opt-in functionality.

I'm also quite merried to the job definition files I have so it will
take time to surrender them, but I also realize that large chunks of the
files I have repeat a lot of the same code patterns.

It's an experiment, I'm not sure how well it will work out, having
started on this a couple of times before and failed...

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]