patch, 7 partsSome assorted fixes for GitLab CI

Hi,

I recently had the pleasure of debugging a couple of failing MSVC+Windows jobs in GitLab CI, which hasn't been quite fun because we didn't know to print error logs, and neither did we upload the failed test artifacts. This patch series is the result of this frustration and fixes a couple of smaller issues in the context of our CI:

  - I noticed that test slicing is slightly wrong because of a
    difference between zero- and one-based indices, which causes us to
    skip the first test on GitLab.

  - I deduplicated how we run Meson tests so that both GitLab and GitHub
    use the same "run-test-slice-meson.sh" script.

  - I add logic to handle failing tests via "print-test-failures.sh".

The result can be found at [1]. Note that tests are failing, but those failures are fixed in a separate patch series via [2]. In any case, I guess those test failures also serve as a good demonstration how the failing tests show up now.

Changes in v2:
  - Fix syntax in GitHub workflow.
  - Add another patch on top that fixes win+Meson tests in GitHub. Those
    tests didn't execute at all, even before this patch series.
  - This uncovers another bug in how we set up MERGE_TOOLS_DIR, so this
    results in another commit.
  - I've now tested also tested the changes on GitHub [3].
  - Link to v1: https://lore.kernel.org/r/20260209-b4-pks-ci-msvc-iconv-fixes-v1-0-1e3167cd8828@pks.im

Thanks!

Patrick

[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/497 [2]: <20260209-b4-pks-ci-msvc-iconv-fixes-v1-0-1e3167cd8828@pks.im> [3]: https://github.com/git/git/pull/2195

---
Patrick Steinhardt (7):
      ci: handle failures of test-slice helper
      ci: don't skip smallest test slice in GitLab
      meson: fix MERGE_TOOL_DIR with "--no-bin-wrappers"
      github: fix Meson tests not executing at all
      ci: make test slicing consistent across Meson/Make
      gitlab-ci: use "run-test-slice-meson.sh"
      gitlab-ci: handle failed tests on MSVC+Meson job

 .github/workflows/main.yml |  6 +++---
 .gitlab-ci.yml             | 17 +++++++++++++++--
 ci/run-test-slice-meson.sh |  2 +-
 ci/run-test-slice.sh       |  6 +++---
 t/helper/test-path-utils.c | 18 ++++++++++++------
 t/meson.build              |  1 +
 6 files changed, 35 insertions(+), 15 deletions(-)

--- base-commit: 3e0db84c88c57e70ac8be8c196dfa92c5d656fbc change-id: 20260209-b4-pks-ci-meson-improvements-93d8a1ffdd27

The "run-test-slice.sh" script executes the test helper to slice up tests passed to it. As the execution is part of a pipe though, we end up ignoring any potential error code returned by the helper.

Make the code more robust by storing the tests in a variable first so that we can split up the pipeline.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-test-slice.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

The "ci/run-test-slice.sh" script can be used to slice up all of our tests into N pieces and then run each of them on a separate CI job. This is used by both GitLab and GitHub CI to speed up Windows tests, which would otherwise be painfully slow.

The infra itself is fueled by `test-tool path-utils slice-tests`. This tool receives as input an "offset" and a "stride" that can be combined to slice up tests. This framing can be misleading though: you are expected to pass a zero-based index as "offset", and the complete number of slices to the "stride". The latter makes sense, but it is somewhat surprising that the offset needs to be zero-based. And this is in fact biting us: while GitHub passes zero-based indices, GitLab passes `$CI_NODE_INDEX`, which is a one-based indice.

Ideally, we should have verification that the parameters make sense. And naturally, one would for example expect that it's an error to call the binary with an offset larger than the stride. But with the current framing as "offset" it's not even wrong to do so, as it is of course well-defined to start at a larger offset than the stride.

This means that we get this wrong on GitLab's CI, as we pass a one based index there, and this causes us to skip one of the tests. Interestingly, it's not the lexicographically first test that we skip. Instead, as we sort tests by size before slicing them, we skip the _smallest_ test.

Reframe the problem to instead talk about "slice number" and "total number of slices". For all of our use cases this is semantically equivalent, but it allows us to perform some verifications:

  - The total number of slices must be greater than 1.

  - The selected slice must be between 1 <= nr <= slices_total.

As the indices are now one-based it means that GitLab's CI is fixed. The GitHub workflow is updated accordingly.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml |  2 +-
 t/helper/test-path-utils.c | 18 ++++++++++++------
 2 files changed, 13 insertions(+), 7 deletions(-)

On Windows, we execute tests with "--no-bin-wrappers". This has been introduced via a87e427e35 (ci: speed up Windows phase, 2019-01-29) to save some time: spawning processes is expensive on Windows, and shell scripts tend to spawn a bunch of them. So overall, the bin-wrappers led to a performance overhead of ~10-30%.

This causes test failures when using Meson on Windows:

  failure: t7610.28 mergetool --tool-help shows recognized tools
    ++ git mergetool --tool-help
    /d/a/git/git/build/git-mergetool--lib: line 45: cd: D:/a/git/git/build/mergetools: No such file or directory

The root cause here is that our bin-wrappers are usually responsible for setting up the `MERGE_TOOL_DIR` environment variable so that we can locate these scripts. But as we don't use the bin-wrappers, we'll instead use the default location for merge tools, which is derived from `GIT_EXEC_PATH`. And as `GIT_EXEC_PATH` points to our build directory, which won't ever contain any of the merge tools, we will fail to locate any of the merge tools.

This issue has went unnoticed for a long time given that we only skip bin-wrappers on Windows, and because the CI jobs on Windows didn't execute due to a bug.

Fix the issue by always setting the `MERGE_TOOL_DIR` environment variable to the correct directory.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 t/meson.build | 1 +
 1 file changed, 1 insertion(+)

While the win+Meson test jobs run in GitHub workflows, the shell script that is supposed to run the jobs is seemingly not running at all. All that the CI job prints is the following:

  Run ci/run-test-slice-meson.sh build 1 10
    ci/run-test-slice-meson.sh build 1 10
    shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"
    env:
      DEVELOPER: 1

The step is currently defined to use PowerShell, and of course it doesn't know how to execute POSIX shell scripts. What's surprising though is that this step doesn't even lead to a CI failure.

Fix the issue by using Bash instead of PowerShell, as we do in other steps that execute shell scripts.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

In the preceding commit we have adjusted test slicing to be one-based when using the "ci/run-test-slice.sh" script. But we also have an equivalent script for Meson that is still zero-based, which is of course inconsistent.

Adapt the script to be one-based, as well, and adapt the GitHub workflow accordingly. Note that GitLab doesn't yet use the script, so it does not need to be adapted. This will change in the next commit though.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 2 +-
 ci/run-test-slice-meson.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Hi Patrick,

On Wed, 11 Feb 2026, Patrick Steinhardt wrote:

This seems to require the following to be squashed in:

-- snip --
From 677370c8cd3b73358713a0efac6bb573b347d53f Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Wed, 18 Feb 2026 22:12:27 +0100
Subject: [PATCH] fixup??? ci: make test slicing consistent across Meson/Make

This seems to be needed to let the first "win+VS test" job pass. See https://github.com/git-for-windows/git/actions/runs/22153194896/job/64053953314#step:5:70 ("fatal: slice must be in the range 1 <= slice <= 10, got '0'").

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 .github/workflows/main.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Wed, Feb 18, 2026 at 10:32:20PM +0100, Johannes Schindelin wrote:

Huh, weird, why didn't I spot this myself? Oh, these tests don't execute by default, right? That's why.

Yup, looks obviously correct. Will squash in, thanks!

Patrick

While our GitHub workflow already uses "ci/run-test-slice-meson.sh", GitLab CI open-codes the parameters. Adapt the latter to also use the same script so that we always use the same Meson options across both CI systems.

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

The MSVC+Meson job does not currently have any logic to print failing tests, nor does it upload the failed test artifacts. Backfill this logic to make help debugging efforts in case any of its jobs has failed.

GitHub already knows to do this, so we don't need an equivalent change over there.

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

On Wed, Feb 11, 2026 at 11:34:26AM +0100, Patrick Steinhardt wrote:

Oops, sorry, I've screwed up this version a bit. This is supposed to be v2 of the series at [1].

Patrick

[1]: <20260209-b4-pks-ci-meson-improvements-v1-0-38444dec4874@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Will replace.  Thanks!