git/.github/workflows/main.yml, branch jch

Merge branch 'jc/ci-github-actions-use-checkout-v5'

2026-04-13T20:54:57Z

CI dependency updates. * jc/ci-github-actions-use-checkout-v5: CI: bump actions/checkout from 4 to 5 for rust-analysis job

CI: bump actions/checkout from 4 to 5 for rust-analysis job

2026-04-13T18:35:31Z

GitHub Actions started complaining about use of Node.js 20 and I was wondering why only one job uses actions/checkout@v4, while everybody else already uses actions/checkout@v5. It turns out that it is caused by a semantic mismerge between e75cd059 (ci: check formatting of our Rust code, 2025-10-15) that added a new use of actions/checkout@v4 that happened very close to another change 63541ed9 (build(deps): bump actions/checkout from 4 to 5, 2025-10-16) that updated all uses of actions/checkout@v4 to use vactions/checkout@v5. Update the leftover and the last use of actions/checkout@v4 to use actions/checkout@v5 to help ourselves to move away from Node.js 20. Signed-off-by: Junio C Hamano

ci: make test slicing consistent across Meson/Make

2026-02-19T18:22:31Z

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 Signed-off-by: Junio C Hamano

github: fix Meson tests not executing at all

2026-02-19T18:22:31Z

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 Signed-off-by: Junio C Hamano

ci: don't skip smallest test slice in GitLab

2026-02-19T18:22:30Z

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. Helped-by: Johannes Schindelin Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'js/ci-show-breakage-in-dockerized-jobs'

2025-12-05T05:49:58Z

Dockerised jobs at the GitHub Actions CI have been taught to show more details of failed tests. * js/ci-show-breakage-in-dockerized-jobs: ci(dockerized): do show the result of failing tests again

Merge branch 'jk/ci-windows-meson-test-fix'

2025-11-26T18:32:43Z

"Windows+meson" job at the GitHub Actions CI was hard to debug, as it did not show and save failed test artifacts, which has been corrected. * jk/ci-windows-meson-test-fix: ci(windows-meson-test): handle options and output like other test jobs unit-test: ignore --no-chain-lint

ci(dockerized): do show the result of failing tests again

2025-11-26T18:17:44Z

The quality of tests and test suites is most apparent not when everything passes, but in how quickly bugs can be identified, analyzed, and resolved after test failures occur. As such, it is an unfortunate side effect of 2a21098b98a (github: adapt containerized jobs to be rootless, 2025-01-10) that the output of failed test cases, which was shown before that change directly in the build logs, is now no longer shown at all. The reason is a side effect of trying to run the build and the tests with permissions other than the `root` user, but without providing the prerequisite permissions to signal what tests failed and whose output hence needs to be included in the logs. The way this signaling works is for the workflow to write into special-purpose files whose path is specific to the current workflow step and which can be accessed via the `$GITHUB_ENV` environment variable, which differs between workflow steps. It is this file that is missing write permission for the `builder` user that was introduced in above-mentioned commit. The solution is simple: make the file world-writable. Technically, this write permission should be removed after the step has completed, if proper security practices were to be upheld, but since nothing uses that file again, it does not matter, and the fix is more succinct this way. This commit is best viewed with `--color-words`. Signed-off-by: Johannes Schindelin [jc: squashed Elijah's rewrite of the first paragraph of the log message] [jc: updated chmod to match "world-writable" in the log message] Signed-off-by: Junio C Hamano

ci(windows-meson-test): handle options and output like other test jobs

2025-11-18T17:45:29Z

The GitHub windows-meson-test jobs directly run "meson test" with the --slice option. This means they skip all of the ci/lib.sh infrastructure, and in particular: 1. They do not actually set any GIT_TEST_OPTS like --verbose-log or -x. 2. They do not do the usual handle_failed_tests() magic to print test failures or tar up failed directories. As a result, you get almost no feedback at all when a test fails in this job, making debugging rather tricky. Let's try to make this behave more like the other CI jobs. Because we're on Windows, we can't just use the normal run-build-and-tests.sh script. Our build runs as a separate job (like the non-meson Windows job), and then we parallelize the tests across several job slices. So we need something like the run-test-slice.sh script that the "windows-test" job uses. In theory we could just swap out the "make" invocation there for "meson". But it doesn't quite work, because "make" knows how to pull GIT_TEST_OPTS out of GIT-BUILD-OPTIONS automatically. But for meson, we have to extract them into the --test-args option ourselves. I tried making the logic in run-test-slice.sh conditional, but there ended up being hardly any common code at all (and there are some tricky ordering constraints). So I added up with a new meson-specific test-slice runner. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'js/ci-github-actions-update'

2025-11-06T22:52:57Z

CI updates. * js/ci-github-actions-update: ci: update {download,upload}-artifact Action versions