Re: [PATCH 0/5] ci: add GitLab CI definition

[Taylor Blau <me@ttaylorr.com>]

On Thu, Oct 26, 2023 at 09:59:59AM +0200, Patrick Steinhardt wrote:
> And this is exactly what this patch series does: it adds GitLab-specific
> knowledge to our CI scripts and adds a CI definition that builds on top
> of those scripts. This is rather straight forward, as the scripts
> already know to discern Azure Pipelines and GitHub Actions, and adding
> a third item to this list feels quite natural. And by building on top of
> the preexisting infra, the actual ".gitlab-ci.yml" is really quite
> small.
>
> I acknowledge that the Git project may not be willing to fully support
> GitLab CI, and that's fine with me. If we want to further stress that
> point then I'd also be perfectly happy to move the definitions into the
> "contrib/" directory -- it would still be a huge win for our workflow.
> In any case, I'm happy to keep on maintaining the intgeration with
> GitLab CI, and if things break I'll do my best to fix them fast.

I don't have any strong opinions here, but my preference would probably
be to keep any GitLab-specific CI configuration limited to "contrib", if
it lands in the tree at all.

We already have a rather complicated CI setup on GitHub, which I think
we generally consider authoritative in terms of determining whether "CI"
is green. I know we have some Azure remnants in "ci", but I'm not aware
of any of the details there.

So I have some hesitation about trying to mirror this rather complicated
set of build rules in another CI environment. My primary concern would
be that the two might fall out of sync and a series that is green on
GitHub would be red on GitLab, or vice-versa. Importantly, this can
happen even without changes to the build definitions, since (AFAICT)
both forges distribute new images automatically, so the set of packages
installed in GitHub may not exactly match what's in GitLab (and
vice-versa).

My other concern is that we're doubling the cost of any new changes to
our CI definition. Perhaps this is more of an academic concern, but I
think my fear would be that one or the other would fall behind on in
implementation leading to further divergence between the two.

I think having the new CI definition live in "contrib" somewhat
addresses the "which CI is authoritative?" problem, but that it doesn't
address the "we have two of these" problem.

So my preference would probably to have this live out of Junio's tree,
but I'm curious to hear what others think.

Thanks,
Taylor