git/ci, branch v2.53.0

Merge branch 'js/ci-leak-skip-svn'

2026-01-23T21:34:36Z

Dscho observed that SVN tests are taking too much time in CI leak checking tasks, but most time is spent not in our code but in libsvn code (which happen to be written in Perl), whose leaks have little value to discover for us. Skip SVN, P4, and CVS tests in the leak checking tasks. * js/ci-leak-skip-svn: ci: skip CVS and P4 tests in leaks job, too ci(*-leaks): skip the git-svn tests to save time

ci: skip CVS and P4 tests in leaks job, too

2026-01-19T19:02:31Z

Looking at the CI logs, the p4 and cvs tests account for another 24 minutes of test time and they offer minimal value for quite a similar reason as the previous step. Let's introduce and use a mechanism to skip these tests to save some resources. Suggested-by: Phillip Wood Signed-off-by: Junio C Hamano

ci(*-leaks): skip the git-svn tests to save time

2026-01-17T18:23:59Z

I noticed recently that the leak-checking jobs still take a lot of time, and upon analysis, the git-svn tests contribute significantly to this. Analyzing a recent CI run, I saw that the Git test suite contains 1,017 tests, running for approximately 5¼ hours total. Of these, 65 git-svn-related tests (~6% of test count) took 42.24 minutes combined, accounting for ~13.% of the total runtime. This implies that the git-svn tests are roughly twice as expernsive compared to the other tests. However, testing git-svn in the leak-checking jobs provides minimal value: git-svn is implemented as a Perl script, and leak checking only handles C code. While git-svn does call into Git's built-in commands that are implemented in C, these are standard Git operations that are already thoroughly exercised elsewhere in the test suite. Therefore, running the git-svn tests in the leak-checking jobs only adds to the overall run time with little value in return. Given that the leak-checking jobs are particularly time-intensive and these 42+ minutes of SVN tests per job provide no additional leak detection value, skip them in the *-leaks jobs to reduce CI runtime. Assisted-by: Claude Sonnet 4.5 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

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(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 'jc/ci-use-arm64-p4-on-macos'

2025-11-17T15:00:12Z

We replaced deprecated macos-13 with macos-14 image in GitHub Actions CI, but we forgot that the image is for arm64. We have been seeing a lot of test failures ever since. Switch to arm64 binary for Perforce tests. * jc/ci-use-arm64-p4-on-macos: Use Perforce arm64 binary on macOS CI jobs

Use Perforce arm64 binary on macOS CI jobs

2025-11-16T23:11:41Z

The previous step replaced deprecated macos-13 image with macos-14 image on GitHub Actions CI. While x86-64 binaries can work there, because macos-14 images are arm64 based (we could replace it with macos-14-large that is x86-64), it makes more sense to use arm64 binary there. Without this change, we have been getting unusually higher rate of failures from random macOS CI jobs railing to run t98xx series of tests. Helped-by: Koji Nakamaru Signed-off-by: Junio C Hamano

Merge branch 'ps/ci-rust'

2025-10-28T17:29:09Z

CI improvements to handle the recent Rust integration better. * ps/ci-rust: rust: support for Windows ci: verify minimum supported Rust version ci: check for common Rust mistakes via Clippy rust/varint: add safety comments ci: check formatting of our Rust code ci: deduplicate calls to `apt-get update`

ci: verify minimum supported Rust version

2025-10-15T15:10:17Z

In the current state of our Rust code base we don't really have any requirements for the minimum supported Rust version yet, as we don't use any features introduced by a recent version of Rust. Consequently, we have decided that we want to aim for a rather old version and edition of Rust, where the hope is that using an old version will make alternatives like gccrs viable earlier for compiling Git. But while we specify the Rust edition, we don't yet specify a Rust version. And even if we did, the Rust version would only be enforced for our own code, but not for any of our dependencies. We don't yet have any dependencies at the current point in time. But let's add some safeguards by specifying the minimum supported Rust version and using cargo-msrv(1) to verify that this version can be satisfied for all of our dependencies. Note that we fix the version of cargo-msrv(1) at v0.18.1. This is the latest release supported by Ubuntu's Rust version. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

ci: check for common Rust mistakes via Clippy

2025-10-15T15:10:17Z

Introduce a CI check that uses Clippy to perform checks for common mistakes and suggested code improvements. Clippy is the official static analyser of the Rust project and thus the de-facto standard. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano