patch, 5 partsWire up Windows-based jobs in GitLab CI

Hi,

there's been multiple cases where changes I did recently broke Windows systems. This was in the context of reftables, the libification refactorings and other parts. Also, with my investigation of a more modern build system I spent a ton of time in Windows overall. So it was high time that I finally wire up support for Windows jobs in GitLab CI, which is something I wanted to do for a long time.

This patch series does this with the help of Johannes. He helped me out quite significantly by starting to publish new build artifacts as part of the Git for Windows SDK pipelines that we can now easily download and use. This makes it trivial to reimplement the "setup-git-for-windows" GitHub Action as a simple PowerShell script such that both GitHub and GitLab share the same implementation.

I've created a pull request in GitHub [1] and a merge request in GitLab [2] to demonstrate that the pipelines work on both platforms.

Thanks!

Patrick

[1]: https://github.com/git/git/pull/1806 [2]: https://gitlab.com/gitlab-org/git/-/merge_requests/204

Patrick Steinhardt (5):
  t7300: work around platform-specific behaviour with long paths on
    MinGW
  ci: create script to set up Git for Windows SDK
  ci: handle Windows-based CI jobs in GitLab CI
  gitlab-ci: introduce stages and dependencies
  gitlab-ci: exercise Git on Windows

 .github/workflows/main.yml | 16 +++++++-----
 .gitlab-ci.yml             | 51 ++++++++++++++++++++++++++++++++++++++
 ci/install-sdk.ps1         | 12 +++++++++
 ci/lib.sh                  | 18 ++++++++++----
 t/t7300-clean.sh           |  2 +-
 5 files changed, 87 insertions(+), 12 deletions(-)
 create mode 100755 ci/install-sdk.ps1

Windows by default has a restriction in place to only allow paths up to 260 characters. This restriction can nowadays be lifted by setting a registry key, but is still active by default.

In t7300 we have one test that exercises the behaviour of git-clean(1) with such long paths. Interestingly enough, this test fails on my system that uses Windows 10 with mingw-w64 installed via MSYS2: instead of observing ENAMETOOLONG, we observe ENOENT. This behaviour is consistent across multiple different environments I have tried.

I cannot say why exactly we observe a different error here, but I would not be surprised if this was either dependent on the Windows version, the version of MinGW, the current working directory of Git or any kind of combination of these.

Work around the issue by handling both errors.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 t/t7300-clean.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Patrick Steinhardt <ps@pks.im> writes:

I find it amusing that this talks about limiting the test to MINGW yet we need to accept two variants ;-)

The solution looks obviously good enough.

Thanks.

On Wed, Oct 09, 2024 at 11:31:25AM -0700, Junio C Hamano wrote:

Agreed, I was quite confused by this. I hope that Johannes may shed a bit more light on this, as I couldn't make much sense of it. Was this a change on our side? Did MinGW change? Is it something else entirely? No idea.

Patrick

In order to build and test Git, we have to first set up the Git for Windows SDK, which contains various required tools and libraries. The SDK is basically a clone of [1], but that repository is quite large due to all the binaries it contains. We thus use both shallow clones and sparse checkouts to speed up the setup. To handle this complexity we use a GitHub action that is hosted externally at [2].

Unfortunately, this makes it rather hard to reuse the logic for CI platforms other than GitHub Actions. After chatting with Johannes Schindelin we came to the conclusion that it would be nice if the Git for Windows SDK would regularly publish releases that one can easily download and extract, thus moving all of the complexity into that single step. Like this, all that a CI job needs to do is to fetch and extract the resulting archive. This published release comes in the form of a new "ci-artifacts" tag that gets updated regularly [3].

Implement a new script that knows how to fetch and extract that script and convert GitHub Actions to use it.

[1]: https://github.com/git-for-windows/git-sdk-64/ [2]: https://github.com/git-for-windows/setup-git-for-windows-sdk/ [3]: https://github.com/git-for-windows/git-sdk-64/releases/tag/ci-artifacts/

Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 16 ++++++++++------
 ci/install-sdk.ps1         | 12 ++++++++++++
 2 files changed, 22 insertions(+), 6 deletions(-)
 create mode 100755 ci/install-sdk.ps1

We try to abstract away any differences between different CI platforms in "ci/lib.sh", such that knowledge specific to e.g. GitHub Actions or GitLab CI is neatly encapsulated in a single place. Next to some generic variables, we also set up some variables that are specific to the actual platform that the CI operates on, e.g. Linux or macOS.

We do not yet support Windows runners on GitLab CI. Unfortunately, those systems do not use the same "CI_JOB_IMAGE" environment variable as both Linux and macOS do. Instead, we can use the "OS" variable, which should have a value of "Windows_NT" on Windows platforms.

Handle the combination of "$OS,$CI_JOB_IMAGE" and introduce support for Windows.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/lib.sh | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

We're about to add a couple of jobs for Windows. As the Windows runners are quite slow, we will split those up across two stages: one stage to build the artifacts, and one stage that runs test slices in parallel.

Introduce stages and "needs" dependencies for the preexisting jobs as a preparatory step. The stages will lead to a more natural representation of jobs in the UI, whereas the "needs" dependency ensures that jobs do not have to wait for all jobs in the preceding stage to finish.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .gitlab-ci.yml | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

Add jobs that exercise Git on Windows. Unfortunately, building and especially testing Git on Windows is inherently slower compared to other Unix-like systems, mostly because spawning processes is way slower. We thus use the same layout as we use in GitHub Actions, where we have one build job, and then pass on the resulting build artifacts to ten test jobs that split up the work across each other.

Unfortunately, the GitLab runners for Windows machines are embarassingly slow by themselves. So while this strategy leads to around 20 minutes of build time in GitHub Actions, the same pipeline takes around an hour in GitLab CI. Still, having late coverage is certainly better than having none at all.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .gitlab-ci.yml | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)