CI/yaml: inlining or providing an "upstream" utility

[Peter Hutterer]

On Mon, Mar 25, 2024 at 11:19:49AM +0100, tlaronde at kergis.com wrote:
> On Mon, Mar 25, 2024 at 08:07:24PM +1000, Peter Hutterer wrote:
> > On Mon, Mar 25, 2024 at 08:36:44AM +0100, tlaronde at kergis.com wrote:
> > > In a previous mail, I proposed, when autotools and meson are both
> > > provided to build a module, to not verify what they provide by simply
> > > diffing the resulting installation directories, but to treat pkgconfig
> > > generated *.pc files specially, by comparing them semantically and
> > > not lexically (just ensure that they "say" the same thing, with
> > > corresponding default configurations, even if they do not say it
> > > the same way---autotools uses ${variable} for some default definitions,
> > > which is not bad per se; but meson has not the same variables, and
> > > the files can end up different).
> > > 
> > > In the .gitlab-ci.yml, adding an -x '*.pc' to diff would pass these
> > > files; then comparing all the matching basename pc files would do the
> > > trick with the script I proposed previously.
> > > 
> > > The problem is: is it possible to add such a script so that it is
> > > available as an utility (like libtool and others) to the CI in the
> > > docker; or do we have to inline the command as a multi-lines script
> > > directly in the
> > > .gitlab-ci.yml file?
> > 
> > Convention is that scripts that are only used in the CI usually go into
> > .gitlab-ci/
> 
> But this does mean that I will have to copy the very same script in
> every module? And that I will have to update all the modules whenever
> I change the script?
> 
> Or, put in other words: is there a way to contribute such an
> utility---under whatever license: it's not rocket-science---to gitlab
> so that it is available for whatever module for CI?

util/modular I guess? or otherwise you put it in the logical primary
repository (whichever this is depends on the context of the patch, e.g.
libX11 for all X libraries, xserver for anything server specific etc)
and then curl the script in the gitlab ci of the dependent modules.

Cheers,
  Peter