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

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 3344 bytes --]

Hi,

this patch series adds GitLab CI definitions to the Git project.

At GitLab, we're have already and will continue to ramp up our
involvement with the Git project. I myself will be working almost
exclusively on Git in the context of the reftable reference backend.
This has surfaced some issues in our own workflow, and the current CI
integration is one of the biggest pain points I personally feel right
now.

It's happened multiple times already that we sent patch series upstream
that passed on our own self-made pipeline at GitLab, but that didn't
pass the GitHub Actions pipeline. This is because the latter is a lot
more involved than what we have. There are pipelines for:

    - Various sanitizers in the form of the linux-leaks and
      linux-asan-ubsan jobs.

    - SHA256 in the form of the linux-sha256 job.

    - The linux-TEST-vars job, which sets several environment variables
      to non-default values.

    - The linux-musl job that tests on Alpine Linux.

We have none of that. And while we could of course iterate on our own
pipeline definition, the current setup results in quite a convoluted
workflow on our side. While I realize that this is not the problem of
the Git project, I really hope that we can integrate GitLab CI into the
Git project.

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 hope that this sheds some light on my motivations here. I do not wish
to replace GitHub Actions and would be okay if this was only a
semi-supported thing. But it would help us at GitLab and by extension
also the Git project because we will hopefully send higher-quality patch
series to the mailing list. And maybe this is even useful to somebody
outside of GitLab.

If this is accepted I'll likely eventually iterate to also support macOS
and/or Windows. A full pipeline run of this can be found at [1].

Patrick

[1]: https://gitlab.com/gitlab-org/git/-/pipelines/1045746751

Patrick Steinhardt (5):
  ci: reorder definitions for grouping functions
  ci: make grouping setup more generic
  ci: group installation of Docker dependencies
  ci: split out logic to set up failed test artifacts
  ci: add support for GitLab CI

 .gitlab-ci.yml                    |  51 +++++++++++
 ci/install-docker-dependencies.sh |  15 +++-
 ci/lib.sh                         | 139 +++++++++++++++++++++++-------
 ci/print-test-failures.sh         |   6 ++
 4 files changed, 179 insertions(+), 32 deletions(-)
 create mode 100644 .gitlab-ci.yml

-- 
2.42.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]