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

[tlaronde at kergis.com]

On Wed, Mar 27, 2024 at 09:00:12PM +1000, Peter Hutterer wrote:
> 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.

Thanks! I will try with util/modular.

Best,
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C