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
