[PATCH 0/8] ci: some housekeeping and modernizations

[PATCH 0/8] ci: some housekeeping and modernizations

[Patrick Steinhardt]

Hi,

this patch series is a result from the discussions in [1]. It fixes a
couple of smaller issues in our CI and bumps jobs that use EOL Docker
images to instead use supported ones.

Passing test runs can be found at [2] and [3] for GitLab and GitHub,
respectively.

Note that I've also merged the Meson changes (ps/meson-improvements at
ce4a600322 (gitlab-ci: fix hanging MSVC jobs, 2026-09-24)) in there so
that GitLab passes, but those are not strictly required as a dependency.

Thanks!

Patrick

[1]: <20260906151137.GA328152@coredump.intra.peff.net>
[2]: https://gitlab.com/gitlab-org/git/-/merge_requests/687
[3]: https://github.com/git/git/pull/2445

---
Patrick Steinhardt (8):
      t5004: skip SHA-1-only test in SHA-256 repository
      ci: fix "fedora-breaking-changes-meson" job
      ci: drop unused "linux-clang" logic
      ci: switch away from unsupported i386/ubuntu image
      ci: rename linux-TEST-vars job
      ci: switch away from EOL'd Ubuntu version in linux-exotic
      ci: drop now-dead Python 2 coverage
      ci: drop redundant linux-reftable job

 .github/workflows/main.yml      | 12 +++---------
 .gitlab-ci.yml                  | 12 +++---------
 ci/install-dependencies.sh      |  8 ++------
 ci/lib.sh                       | 13 ++-----------
 ci/run-build-and-tests.sh       | 10 +++-------
 t/t5004-archive-corner-cases.sh |  2 +-
 6 files changed, 14 insertions(+), 43 deletions(-)


---
base-commit: 8e383dedc6bbc4fd7bbb203512fbf2eafc151e04
change-id: 20261008-pks-ci-housekeeping-4cf7fac3b0df

[PATCH 1/8] t5004: skip SHA-1-only test in SHA-256 repository

[Patrick Steinhardt]

One of the tests in t5004 extracts a ZIP file that contains some objects
larger than 4GB and then double-checks whether we can read and archive
such an object. That test has a bunch of prerequities: it requires a 64
bit `long`, unzip with 64-bit support and it only runs when EXPENSIVE is
enabled. Consequently, not a lot of jobs even exercise this.

One of the jobs that does run it though our Fedora-based job, as it
ticks all the necessary boxes. But that job was silently broken: while
the intent was to run on Fedora with breaking changes enabled, they are
in fact disabled due to a typo.

We're about to fix that typo in the next commit, but this will also
uncover that the above test case is broken when running in SHA-256
repositories. The extracted objects are SHA-1 objects, so extracting
them into a SHA-256 repository is not going to yield anything good. So
once we fix the Fedora-based job to enable breaking changes, which will
make tests use SHA-256 by default, the test will break.

Fix this issue by adding the SHA1 prerequisite.

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

diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
index 768b0ff85d..c9c879cc5f 100755
--- a/t/t5004-archive-corner-cases.sh
+++ b/t/t5004-archive-corner-cases.sh
@@ -185,7 +185,7 @@ test_expect_success EXPENSIVE,UNZIP,UNZIP_ZIP64_SUPPORT \
 	"$GIT_UNZIP" -t many-big.zip
 '
 
-test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
+test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO,SHA1 \
 	'zip archive with files bigger than 4GB' '
 	# Pack created with:
 	#   dd if=/dev/zero of=file bs=1M count=4100 && git hash-object -w file

-- 
2.56.0.406.ga2d225a756.dirty

[PATCH 2/8] ci: fix "fedora-breaking-changes-meson" job

[Patrick Steinhardt]

The "fedora-breaking-changes-meson" job exercises Git with breaking
changes enabled on Fedora with Meson. There's a typo in our CI scripts
though, which has the effect that the build does not enable breaking
changes by accident.

Fix the typo.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-build-and-tests.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 6a3b43b366..bc5058c917 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -18,7 +18,7 @@ almalinux-*|debian-*|fedora-*|linux-*)
 esac
 
 case "$jobname" in
-fedora-breaking-changes-musl|linux-breaking-changes)
+fedora-breaking-changes-meson|linux-breaking-changes)
 	export WITH_BREAKING_CHANGES=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;

-- 
2.56.0.406.ga2d225a756.dirty

[PATCH 3/8] ci: drop unused "linux-clang" logic

[Patrick Steinhardt]

In d88d727143 (ci: drop linux-clang job, 2023-06-01) we have dropped the
"linux-clang" job because another job already uses Clang anyway. But we
forgot to also drop the logic in "ci/run-build-and-tests.sh", so we now
have some unused logic in there.

Drop it.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-build-and-tests.sh | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index bc5058c917..23e87cbbd6 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -37,10 +37,6 @@ linux-TEST-vars)
 	export GIT_TEST_CHECKOUT_WORKERS=2
 	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
 	;;
-linux-clang)
-	export NO_RUST=UnfortunatelyYes
-	export GIT_TEST_DEFAULT_HASH=sha1
-	;;
 linux-sha256)
 	export GIT_TEST_DEFAULT_HASH=sha256
 	;;

-- 
2.56.0.406.ga2d225a756.dirty

[PATCH 4/8] ci: switch away from unsupported i386/ubuntu image

[Patrick Steinhardt]

The linux32 job is used to exercise Git on a 32 bit platform. That job
uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
nowadays. Furthermore, Ubuntu has dropped support for 32 bit entirely
with the 20.04 release, so we cannot easily upgrade it to a more recent
image anymore.

Switch the job over to use i386/debian instead. Note that starting with
Debian 13, support for i386 has been reduced [1]. But Debian still
releases 32 bit Docker images for the latest release nowadays, so we
will have coverage until at least 2030.

[1]: https://www.debian.org/releases/trixie/release-notes/issues.en.html#i386-reduced-support

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 3 +--
 .gitlab-ci.yml             | 3 +--
 ci/install-dependencies.sh | 6 +-----
 ci/lib.sh                  | 2 +-
 4 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index b229739be8..6d1e37c8f1 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -431,9 +431,8 @@ jobs:
           cc: gcc
         - jobname: linux-musl-meson
           image: alpine:latest
-        # Supported until 2025-04-02.
         - jobname: linux32
-          image: i386/ubuntu:20.04
+          image: i386/debian:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 3f24835500..7d972f0c8b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -65,9 +65,8 @@ test:linux:
         CC: gcc
       - jobname: linux-musl-meson
         image: alpine:latest
-        # Supported until 2025-04-02.
       - jobname: linux32
-        image: i386/ubuntu:20.04
+        image: i386/debian:latest
       # A RHEL 8 compatible distro.  Supported until 2029-05-31.
       - jobname: almalinux-8
         image: almalinux:8
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d57dce5663..8783b48951 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -39,7 +39,7 @@ fedora-*|almalinux-*)
 	dnf -yq update >/dev/null &&
 	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS cargo >/dev/null
 	;;
-ubuntu-*|i386/ubuntu-*|debian-*)
+ubuntu-*|i386/debian-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
 	export DEBIAN_FRONTEND=noninteractive
 
@@ -48,10 +48,6 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		SVN='libsvn-perl subversion'
 		LANGUAGES='language-pack-is'
 		;;
-	i386/ubuntu-*)
-		SVN=
-		LANGUAGES='language-pack-is'
-		;;
 	*)
 		SVN='libsvn-perl subversion'
 		LANGUAGES='locales-all'
diff --git a/ci/lib.sh b/ci/lib.sh
index c6ccbf8c17..d99e7b9da1 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -262,7 +262,7 @@ then
 		CI_OS_NAME=osx
 		JOBS=$(nproc)
 		;;
-	*,almalinux:*|*,alpine:*|*,debian:*|*,fedora:*|*,ubuntu:*|*,i386/ubuntu:*)
+	*,almalinux:*|*,alpine:*|*,debian:*|*,fedora:*|*,ubuntu:*|*,i386/debian:*)
 		CI_OS_NAME=linux
 		JOBS=$(nproc)
 		;;

-- 
2.56.0.406.ga2d225a756.dirty

[PATCH 5/8] ci: rename linux-TEST-vars job

[Patrick Steinhardt]

The "linux-TEST-vars" job exercises Git with a bunch of non-default
options enabled. The name of that job makes you want to cry though due
to the weird upper-casing and because it doesn't really tell you what it
even intends to do.

Rename the job to "linux-exotic" instead.

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

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 6d1e37c8f1..d7a301ec98 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -408,7 +408,7 @@ jobs:
         - jobname: linux-reftable
           image: ubuntu:rolling
           cc: clang
-        - jobname: linux-TEST-vars
+        - jobname: linux-exotic
           image: ubuntu:20.04
           cc: gcc
           cc_package: gcc-8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 7d972f0c8b..27a16ed086 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -42,7 +42,7 @@ test:linux:
       - jobname: linux-reftable
         image: ubuntu:rolling
         CC: clang
-      - jobname: linux-TEST-vars
+      - jobname: linux-exotic
         image: ubuntu:20.04
         CC: gcc
         CC_PACKAGE: gcc-8
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 23e87cbbd6..9381ff8893 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -22,7 +22,7 @@ fedora-breaking-changes-meson|linux-breaking-changes)
 	export WITH_BREAKING_CHANGES=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
-linux-TEST-vars)
+linux-exotic)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
 	export GIT_TEST_SPLIT_INDEX=yes
 	export GIT_TEST_FULL_IN_PACK_ARRAY=true

-- 
2.56.0.406.ga2d225a756.dirty

[PATCH 6/8] ci: switch away from EOL'd Ubuntu version in linux-exotic

[Patrick Steinhardt]

The "linux-exotic" job still uses Ubuntu 20.04, which is end of life
nowadays and starting to show some cracks. Switch it over to use the
"latest" tag instead so that we don't have to constantly update it
anymore.

Now arguably, this reduces test coverage for old versions of Ubuntu.
But "latest" at least points to the most up-to-date LTS release of
Ubuntu, compared to the "rolling" tag that uses the latest release
regardless of the LTS status. So while "latest" and "rolling" are the
same right now, that's not always the case.

Furthermore, we have other jobs that test with ancient versions of
Linux, like for example the one that uses AlmaLinux 8 (2021, originally
tracking RHEL 8 from 2019) or Debian 12 (2023).

Note that this also requires us to switch away from GCC 8, which is not
supported by Ubuntu 26.04 anymore. Instead we simply use the default
version of GCC.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 4 +---
 .gitlab-ci.yml             | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index d7a301ec98..5b772dab55 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -409,9 +409,7 @@ jobs:
           image: ubuntu:rolling
           cc: clang
         - jobname: linux-exotic
-          image: ubuntu:20.04
-          cc: gcc
-          cc_package: gcc-8
+          image: ubuntu:latest
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 27a16ed086..de40434ae3 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -43,9 +43,7 @@ test:linux:
         image: ubuntu:rolling
         CC: clang
       - jobname: linux-exotic
-        image: ubuntu:20.04
-        CC: gcc
-        CC_PACKAGE: gcc-8
+        image: ubuntu:latest
       - jobname: linux-breaking-changes
         image: ubuntu:rolling
         CC: gcc

-- 
2.56.0.406.ga2d225a756.dirty

[PATCH 7/8] ci: drop now-dead Python 2 coverage

[Patrick Steinhardt]

In the preceding commit we've dropped the last job that still used
Ubuntu 20.04. We still had some conditional logic for that specific
image that made us use Python 2 instead of Python 3, but this is dead
code now.

We could of course exercise Python 2 in any of our other CI jobs. But it
reached end of life in 2020 already, and none of the distros that we use
have it packaged anymore. Furthermore, it seems like the world has
finally adapted to Python 3. So it doesn't feel all that useful to still
exercise it.

Drop the logic and instead use Python 3 unconditionally.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh |  2 +-
 ci/lib.sh                  | 11 +----------
 2 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 8783b48951..4b1733ad15 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -61,7 +61,7 @@ ubuntu-*|i386/debian-*|debian-*)
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
 		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
-		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
+		${CC_PACKAGE:-${CC:-gcc}} python3
 
 	# Starting with Ubuntu 25.10, sudo can now be provided via either
 	# sudo(1) or sudo-rs(1), with the latter being the default. The problem
diff --git a/ci/lib.sh b/ci/lib.sh
index d99e7b9da1..3ec10488d4 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -335,16 +335,7 @@ esac
 
 case "$distro" in
 ubuntu-*)
-	# Python 2 is end of life, and Ubuntu 23.04 and newer don't actually
-	# have it anymore. We thus only test with Python 2 on older LTS
-	# releases.
-	if test "$distro" = "ubuntu-20.04"
-	then
-		PYTHON_PACKAGE=python2
-	else
-		PYTHON_PACKAGE=python3
-	fi
-	MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=/usr/bin/$PYTHON_PACKAGE"
+	MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=/usr/bin/python3"
 
 	export GIT_TEST_HTTPD=true
 

-- 
2.56.0.406.ga2d225a756.dirty

[PATCH 8/8] ci: drop redundant linux-reftable job

[Patrick Steinhardt]

The "linux-reftable" job exercises Git with reftables as its default
backend. But this job is arguably redundant because we already have the
"linux-reftable-leaks" job that exercises reftables with the leak
sanitizer enabled, and it is unlikely that we will catch any extra bugs
with the leak sanitizer disabled.

Drop the job.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 3 ---
 .gitlab-ci.yml             | 3 ---
 ci/run-build-and-tests.sh  | 2 +-
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 5b772dab55..4be3f2337d 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -405,9 +405,6 @@ jobs:
         - jobname: linux-sha256
           image: ubuntu:rolling
           cc: clang
-        - jobname: linux-reftable
-          image: ubuntu:rolling
-          cc: clang
         - jobname: linux-exotic
           image: ubuntu:latest
         - jobname: linux-breaking-changes
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index de40434ae3..f0424bab5b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -39,9 +39,6 @@ test:linux:
       - jobname: linux-sha256
         image: ubuntu:rolling
         CC: clang
-      - jobname: linux-reftable
-        image: ubuntu:rolling
-        CC: clang
       - jobname: linux-exotic
         image: ubuntu:latest
       - jobname: linux-breaking-changes
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 9381ff8893..df63e79319 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -40,7 +40,7 @@ linux-exotic)
 linux-sha256)
 	export GIT_TEST_DEFAULT_HASH=sha256
 	;;
-linux-reftable|linux-reftable-leaks|osx-reftable)
+linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
 	;;
 

-- 
2.56.0.406.ga2d225a756.dirty

Re: [PATCH 4/8] ci: switch away from unsupported i386/ubuntu image

[Todd Zullinger]

Patrick Steinhardt wrote:
> The linux32 job is used to exercise Git on a 32 bit platform. That job
> uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
> nowadays. Furthermore, Ubuntu has dropped support for 32 bit entirely
> with the 20.04 release, so we cannot easily upgrade it to a more recent
> image anymore.

Should "with the 20.04 release" be 22.04 (or whatever
release dropped i386)?

We've been using 20.04, so i386 support wasn't dropped
there, I presume.

You could say "after the 20.04 release" perhaps, but that
seems less useful.  In that case, you avoid using a version
at all, e.g. "dropped support ...  entirely in subsequent
releases" or something.

Cheers,

-- 
Todd

Re: [PATCH 1/8] t5004: skip SHA-1-only test in SHA-256 repository

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> One of the tests in t5004 extracts a ZIP file that contains some objects
> larger than 4GB and then double-checks whether we can read and archive
> such an object. That test has a bunch of prerequities: it requires a 64
> bit `long`, unzip with 64-bit support and it only runs when EXPENSIVE is
> enabled. Consequently, not a lot of jobs even exercise this.
>
> One of the jobs that does run it though our Fedora-based job, as it

"One of the jobs that does run it though" IS "our Fedora-based job"?

> ticks all the necessary boxes. But that job was silently broken: while
> the intent was to run on Fedora with breaking changes enabled, they are
> in fact disabled due to a typo.
>
> We're about to fix that typo in the next commit, but this will also
> uncover that the above test case is broken when running in SHA-256
> repositories. The extracted objects are SHA-1 objects, so extracting
> them into a SHA-256 repository is not going to yield anything good. So
> once we fix the Fedora-based job to enable breaking changes, which will
> make tests use SHA-256 by default, the test will break.
>
> Fix this issue by adding the SHA1 prerequisite.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  t/t5004-archive-corner-cases.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
> index 768b0ff85d..c9c879cc5f 100755
> --- a/t/t5004-archive-corner-cases.sh
> +++ b/t/t5004-archive-corner-cases.sh
> @@ -185,7 +185,7 @@ test_expect_success EXPENSIVE,UNZIP,UNZIP_ZIP64_SUPPORT \
>  	"$GIT_UNZIP" -t many-big.zip
>  '
>  
> -test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
> +test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO,SHA1 \
>  	'zip archive with files bigger than 4GB' '
>  	# Pack created with:
>  	#   dd if=/dev/zero of=file bs=1M count=4100 && git hash-object -w file

Re: [PATCH 4/8] ci: switch away from unsupported i386/ubuntu image

[Junio C Hamano]

Todd Zullinger <tmz@pobox.com> writes:

> Patrick Steinhardt wrote:
>> The linux32 job is used to exercise Git on a 32 bit platform. That job
>> uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
>> nowadays. Furthermore, Ubuntu has dropped support for 32 bit entirely
>> with the 20.04 release, so we cannot easily upgrade it to a more recent
>> image anymore.
>
> Should "with the 20.04 release" be 22.04 (or whatever
> release dropped i386)?

FWIW, I read the above to mean "32bit support, together with 20.04,
are now gone", and did not feel any need for rephrasing.  But
reading it again, yes, it can be read both ways.

    Ubuntu has dropped support for 32-bit entirely, together with
    20.04 release, so upgrading it to a more recent image would not
    help us keeping 32-bit support.

perhaps?

Re: [PATCH 8/8] ci: drop redundant linux-reftable job

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> The "linux-reftable" job exercises Git with reftables as its default
> backend. But this job is arguably redundant because we already have the
> "linux-reftable-leaks" job that exercises reftables with the leak
> sanitizer enabled, and it is unlikely that we will catch any extra bugs
> with the leak sanitizer disabled.
>
> Drop the job.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  .github/workflows/main.yml | 3 ---
>  .gitlab-ci.yml             | 3 ---
>  ci/run-build-and-tests.sh  | 2 +-
>  3 files changed, 1 insertion(+), 7 deletions(-)

As linux-reftable-leaks job uses NO_{CVS,SVN,PR}_TESTS in ci/lib.sh
to disable tests on these foreign-scm interoperability tests, this
change means reftable is no longer tested with them at all, no?

Not that I personally see specific value in testing git-p4 with both
reftable and reffiles backend, the loss of coverage needs to be
noted, if not justified, in the proposed commit log message.

Other than that, nice thinking.

Thanks.

Re: [PATCH 1/8] t5004: skip SHA-1-only test in SHA-256 repository

[Patrick Steinhardt]

On Thu, Oct 08, 2026 at 11:05:28AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > One of the tests in t5004 extracts a ZIP file that contains some objects
> > larger than 4GB and then double-checks whether we can read and archive
> > such an object. That test has a bunch of prerequities: it requires a 64
> > bit `long`, unzip with 64-bit support and it only runs when EXPENSIVE is
> > enabled. Consequently, not a lot of jobs even exercise this.
> >
> > One of the jobs that does run it though our Fedora-based job, as it
> 
> "One of the jobs that does run it though" IS "our Fedora-based job"?

Oops, good catch.

Patrick

Re: [PATCH 4/8] ci: switch away from unsupported i386/ubuntu image

[Patrick Steinhardt]

On Thu, Oct 08, 2026 at 11:12:11AM -0700, Junio C Hamano wrote:
> Todd Zullinger <tmz@pobox.com> writes:
> 
> > Patrick Steinhardt wrote:
> >> The linux32 job is used to exercise Git on a 32 bit platform. That job
> >> uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
> >> nowadays. Furthermore, Ubuntu has dropped support for 32 bit entirely
> >> with the 20.04 release, so we cannot easily upgrade it to a more recent
> >> image anymore.
> >
> > Should "with the 20.04 release" be 22.04 (or whatever
> > release dropped i386)?
> 
> FWIW, I read the above to mean "32bit support, together with 20.04,
> are now gone", and did not feel any need for rephrasing.  But
> reading it again, yes, it can be read both ways.
> 
>     Ubuntu has dropped support for 32-bit entirely, together with
>     20.04 release, so upgrading it to a more recent image would not
>     help us keeping 32-bit support.
> 
> perhaps?

I think that still reads a bit awkward. I've rewritten it to the
following:

  The linux32 job is used to exercise Git on a 32 bit platform. That job
  uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
  nowadays. Furthermore, Ubuntu 20.04 is the last release that has support
  for 32 bit, so we cannot upgrade the image to a later version, either.

Patrick

Re: [PATCH 8/8] ci: drop redundant linux-reftable job

[Patrick Steinhardt]

On Thu, Oct 08, 2026 at 11:18:14AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > The "linux-reftable" job exercises Git with reftables as its default
> > backend. But this job is arguably redundant because we already have the
> > "linux-reftable-leaks" job that exercises reftables with the leak
> > sanitizer enabled, and it is unlikely that we will catch any extra bugs
> > with the leak sanitizer disabled.
> >
> > Drop the job.
> >
> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> > ---
> >  .github/workflows/main.yml | 3 ---
> >  .gitlab-ci.yml             | 3 ---
> >  ci/run-build-and-tests.sh  | 2 +-
> >  3 files changed, 1 insertion(+), 7 deletions(-)
> 
> As linux-reftable-leaks job uses NO_{CVS,SVN,PR}_TESTS in ci/lib.sh
> to disable tests on these foreign-scm interoperability tests, this
> change means reftable is no longer tested with them at all, no?
> 
> Not that I personally see specific value in testing git-p4 with both
> reftable and reffiles backend, the loss of coverage needs to be
> noted, if not justified, in the proposed commit log message.
> 
> Other than that, nice thinking.

Hm, that's something I missed indeed. I don't really think that those
tests are all that important, and I'd rather have all of these tools
removed from our code base anyway. But I find it hard to argue that we
should just drop test coverage for them altogether.

So how about arguing the other way round and making the job more useful?
We don't have good test coverage of reftables with SHA256, so we could
adapt the job to exercise that combination.

Patrick

[PATCH v2 0/8] ci: some housekeeping and modernizations

[Patrick Steinhardt]

Hi,

this patch series is a result from the discussions in [1]. It fixes a
couple of smaller issues in our CI and bumps jobs that use EOL Docker
images to instead use supported ones.

Passing test runs can be found at [2] and [3] for GitLab and GitHub,
respectively.

Note that I've also merged the Meson changes (ps/meson-improvements at
ce4a600322 (gitlab-ci: fix hanging MSVC jobs, 2026-09-24)) in there so
that GitLab passes, but those are not strictly required as a dependency.

Changes in v2:
  - Improve commit messages.
  - Rework the "linux-reftable" job to be more useful instead of
    dropping it.
  - Link to v1: https://patch.msgid.link/20261008-pks-ci-housekeeping-v1-0-baf015c589c0@pks.im

Thanks!

Patrick

[1]: <20260906151137.GA328152@coredump.intra.peff.net>
[2]: https://gitlab.com/gitlab-org/git/-/merge_requests/687
[3]: https://github.com/git/git/pull/2445

---
Patrick Steinhardt (8):
      t5004: skip SHA-1-only test in SHA-256 repository
      ci: fix "fedora-breaking-changes-meson" job
      ci: drop unused "linux-clang" logic
      ci: switch away from unsupported i386/ubuntu image
      ci: rename linux-TEST-vars job
      ci: switch away from EOL'd Ubuntu version in linux-exotic
      ci: drop now-dead Python 2 coverage
      ci: improve reftable test coverage

 .github/workflows/main.yml      | 11 ++++-------
 .gitlab-ci.yml                  | 11 ++++-------
 ci/install-dependencies.sh      |  8 ++------
 ci/lib.sh                       | 13 ++-----------
 ci/run-build-and-tests.sh       | 14 +++++++-------
 t/t5004-archive-corner-cases.sh |  2 +-
 6 files changed, 20 insertions(+), 39 deletions(-)

Range-diff versus v1:

1:  654fa99d33 ! 1:  61d0ab3180 t5004: skip SHA-1-only test in SHA-256 repository
    @@ Commit message
         bit `long`, unzip with 64-bit support and it only runs when EXPENSIVE is
         enabled. Consequently, not a lot of jobs even exercise this.
     
    -    One of the jobs that does run it though our Fedora-based job, as it
    +    One of the jobs that does run it though is our Fedora-based job, as it
         ticks all the necessary boxes. But that job was silently broken: while
         the intent was to run on Fedora with breaking changes enabled, they are
         in fact disabled due to a typo.
2:  c75705d4c3 = 2:  d3bef5a21e ci: fix "fedora-breaking-changes-meson" job
3:  1d74ddf095 = 3:  e6d5135719 ci: drop unused "linux-clang" logic
4:  8c1d17e976 ! 4:  21a32d6f33 ci: switch away from unsupported i386/ubuntu image
    @@ Commit message
     
         The linux32 job is used to exercise Git on a 32 bit platform. That job
         uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
    -    nowadays. Furthermore, Ubuntu has dropped support for 32 bit entirely
    -    with the 20.04 release, so we cannot easily upgrade it to a more recent
    -    image anymore.
    +    nowadays. Furthermore, Ubuntu 20.04 is the last release that has support
    +    for 32 bit, so we cannot upgrade the image to a later version, either.
     
         Switch the job over to use i386/debian instead. Note that starting with
         Debian 13, support for i386 has been reduced [1]. But Debian still
5:  4b919ad40e = 5:  01496b2238 ci: rename linux-TEST-vars job
6:  ab371f734c = 6:  f248065fb5 ci: switch away from EOL'd Ubuntu version in linux-exotic
7:  d0ff091832 = 7:  1148ebcab3 ci: drop now-dead Python 2 coverage
8:  2b0df6d4a2 < -:  ---------- ci: drop redundant linux-reftable job
-:  ---------- > 8:  71c2422b22 ci: improve reftable test coverage

---
base-commit: 8e383dedc6bbc4fd7bbb203512fbf2eafc151e04
change-id: 20261008-pks-ci-housekeeping-4cf7fac3b0df

[PATCH v2 1/8] t5004: skip SHA-1-only test in SHA-256 repository

[Patrick Steinhardt]

One of the tests in t5004 extracts a ZIP file that contains some objects
larger than 4GB and then double-checks whether we can read and archive
such an object. That test has a bunch of prerequities: it requires a 64
bit `long`, unzip with 64-bit support and it only runs when EXPENSIVE is
enabled. Consequently, not a lot of jobs even exercise this.

One of the jobs that does run it though is our Fedora-based job, as it
ticks all the necessary boxes. But that job was silently broken: while
the intent was to run on Fedora with breaking changes enabled, they are
in fact disabled due to a typo.

We're about to fix that typo in the next commit, but this will also
uncover that the above test case is broken when running in SHA-256
repositories. The extracted objects are SHA-1 objects, so extracting
them into a SHA-256 repository is not going to yield anything good. So
once we fix the Fedora-based job to enable breaking changes, which will
make tests use SHA-256 by default, the test will break.

Fix this issue by adding the SHA1 prerequisite.

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

diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
index 768b0ff85d..c9c879cc5f 100755
--- a/t/t5004-archive-corner-cases.sh
+++ b/t/t5004-archive-corner-cases.sh
@@ -185,7 +185,7 @@ test_expect_success EXPENSIVE,UNZIP,UNZIP_ZIP64_SUPPORT \
 	"$GIT_UNZIP" -t many-big.zip
 '
 
-test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
+test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO,SHA1 \
 	'zip archive with files bigger than 4GB' '
 	# Pack created with:
 	#   dd if=/dev/zero of=file bs=1M count=4100 && git hash-object -w file

-- 
2.56.0.170.g584c36229d.dirty

[PATCH v2 2/8] ci: fix "fedora-breaking-changes-meson" job

[Patrick Steinhardt]

The "fedora-breaking-changes-meson" job exercises Git with breaking
changes enabled on Fedora with Meson. There's a typo in our CI scripts
though, which has the effect that the build does not enable breaking
changes by accident.

Fix the typo.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-build-and-tests.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 6a3b43b366..bc5058c917 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -18,7 +18,7 @@ almalinux-*|debian-*|fedora-*|linux-*)
 esac
 
 case "$jobname" in
-fedora-breaking-changes-musl|linux-breaking-changes)
+fedora-breaking-changes-meson|linux-breaking-changes)
 	export WITH_BREAKING_CHANGES=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;

-- 
2.56.0.170.g584c36229d.dirty

[PATCH v2 3/8] ci: drop unused "linux-clang" logic

[Patrick Steinhardt]

In d88d727143 (ci: drop linux-clang job, 2023-06-01) we have dropped the
"linux-clang" job because another job already uses Clang anyway. But we
forgot to also drop the logic in "ci/run-build-and-tests.sh", so we now
have some unused logic in there.

Drop it.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-build-and-tests.sh | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index bc5058c917..23e87cbbd6 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -37,10 +37,6 @@ linux-TEST-vars)
 	export GIT_TEST_CHECKOUT_WORKERS=2
 	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
 	;;
-linux-clang)
-	export NO_RUST=UnfortunatelyYes
-	export GIT_TEST_DEFAULT_HASH=sha1
-	;;
 linux-sha256)
 	export GIT_TEST_DEFAULT_HASH=sha256
 	;;

-- 
2.56.0.170.g584c36229d.dirty

[PATCH v2 4/8] ci: switch away from unsupported i386/ubuntu image

[Patrick Steinhardt]

The linux32 job is used to exercise Git on a 32 bit platform. That job
uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
nowadays. Furthermore, Ubuntu 20.04 is the last release that has support
for 32 bit, so we cannot upgrade the image to a later version, either.

Switch the job over to use i386/debian instead. Note that starting with
Debian 13, support for i386 has been reduced [1]. But Debian still
releases 32 bit Docker images for the latest release nowadays, so we
will have coverage until at least 2030.

[1]: https://www.debian.org/releases/trixie/release-notes/issues.en.html#i386-reduced-support

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 3 +--
 .gitlab-ci.yml             | 3 +--
 ci/install-dependencies.sh | 6 +-----
 ci/lib.sh                  | 2 +-
 4 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index b229739be8..6d1e37c8f1 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -431,9 +431,8 @@ jobs:
           cc: gcc
         - jobname: linux-musl-meson
           image: alpine:latest
-        # Supported until 2025-04-02.
         - jobname: linux32
-          image: i386/ubuntu:20.04
+          image: i386/debian:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 3f24835500..7d972f0c8b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -65,9 +65,8 @@ test:linux:
         CC: gcc
       - jobname: linux-musl-meson
         image: alpine:latest
-        # Supported until 2025-04-02.
       - jobname: linux32
-        image: i386/ubuntu:20.04
+        image: i386/debian:latest
       # A RHEL 8 compatible distro.  Supported until 2029-05-31.
       - jobname: almalinux-8
         image: almalinux:8
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d57dce5663..8783b48951 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -39,7 +39,7 @@ fedora-*|almalinux-*)
 	dnf -yq update >/dev/null &&
 	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS cargo >/dev/null
 	;;
-ubuntu-*|i386/ubuntu-*|debian-*)
+ubuntu-*|i386/debian-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
 	export DEBIAN_FRONTEND=noninteractive
 
@@ -48,10 +48,6 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		SVN='libsvn-perl subversion'
 		LANGUAGES='language-pack-is'
 		;;
-	i386/ubuntu-*)
-		SVN=
-		LANGUAGES='language-pack-is'
-		;;
 	*)
 		SVN='libsvn-perl subversion'
 		LANGUAGES='locales-all'
diff --git a/ci/lib.sh b/ci/lib.sh
index c6ccbf8c17..d99e7b9da1 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -262,7 +262,7 @@ then
 		CI_OS_NAME=osx
 		JOBS=$(nproc)
 		;;
-	*,almalinux:*|*,alpine:*|*,debian:*|*,fedora:*|*,ubuntu:*|*,i386/ubuntu:*)
+	*,almalinux:*|*,alpine:*|*,debian:*|*,fedora:*|*,ubuntu:*|*,i386/debian:*)
 		CI_OS_NAME=linux
 		JOBS=$(nproc)
 		;;

-- 
2.56.0.170.g584c36229d.dirty

[PATCH v2 5/8] ci: rename linux-TEST-vars job

[Patrick Steinhardt]

The "linux-TEST-vars" job exercises Git with a bunch of non-default
options enabled. The name of that job makes you want to cry though due
to the weird upper-casing and because it doesn't really tell you what it
even intends to do.

Rename the job to "linux-exotic" instead.

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

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 6d1e37c8f1..d7a301ec98 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -408,7 +408,7 @@ jobs:
         - jobname: linux-reftable
           image: ubuntu:rolling
           cc: clang
-        - jobname: linux-TEST-vars
+        - jobname: linux-exotic
           image: ubuntu:20.04
           cc: gcc
           cc_package: gcc-8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 7d972f0c8b..27a16ed086 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -42,7 +42,7 @@ test:linux:
       - jobname: linux-reftable
         image: ubuntu:rolling
         CC: clang
-      - jobname: linux-TEST-vars
+      - jobname: linux-exotic
         image: ubuntu:20.04
         CC: gcc
         CC_PACKAGE: gcc-8
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 23e87cbbd6..9381ff8893 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -22,7 +22,7 @@ fedora-breaking-changes-meson|linux-breaking-changes)
 	export WITH_BREAKING_CHANGES=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
-linux-TEST-vars)
+linux-exotic)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
 	export GIT_TEST_SPLIT_INDEX=yes
 	export GIT_TEST_FULL_IN_PACK_ARRAY=true

-- 
2.56.0.170.g584c36229d.dirty

[PATCH v2 6/8] ci: switch away from EOL'd Ubuntu version in linux-exotic

[Patrick Steinhardt]

The "linux-exotic" job still uses Ubuntu 20.04, which is end of life
nowadays and starting to show some cracks. Switch it over to use the
"latest" tag instead so that we don't have to constantly update it
anymore.

Now arguably, this reduces test coverage for old versions of Ubuntu.
But "latest" at least points to the most up-to-date LTS release of
Ubuntu, compared to the "rolling" tag that uses the latest release
regardless of the LTS status. So while "latest" and "rolling" are the
same right now, that's not always the case.

Furthermore, we have other jobs that test with ancient versions of
Linux, like for example the one that uses AlmaLinux 8 (2021, originally
tracking RHEL 8 from 2019) or Debian 12 (2023).

Note that this also requires us to switch away from GCC 8, which is not
supported by Ubuntu 26.04 anymore. Instead we simply use the default
version of GCC.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 4 +---
 .gitlab-ci.yml             | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index d7a301ec98..5b772dab55 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -409,9 +409,7 @@ jobs:
           image: ubuntu:rolling
           cc: clang
         - jobname: linux-exotic
-          image: ubuntu:20.04
-          cc: gcc
-          cc_package: gcc-8
+          image: ubuntu:latest
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 27a16ed086..de40434ae3 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -43,9 +43,7 @@ test:linux:
         image: ubuntu:rolling
         CC: clang
       - jobname: linux-exotic
-        image: ubuntu:20.04
-        CC: gcc
-        CC_PACKAGE: gcc-8
+        image: ubuntu:latest
       - jobname: linux-breaking-changes
         image: ubuntu:rolling
         CC: gcc

-- 
2.56.0.170.g584c36229d.dirty

[PATCH v2 7/8] ci: drop now-dead Python 2 coverage

[Patrick Steinhardt]

In the preceding commit we've dropped the last job that still used
Ubuntu 20.04. We still had some conditional logic for that specific
image that made us use Python 2 instead of Python 3, but this is dead
code now.

We could of course exercise Python 2 in any of our other CI jobs. But it
reached end of life in 2020 already, and none of the distros that we use
have it packaged anymore. Furthermore, it seems like the world has
finally adapted to Python 3. So it doesn't feel all that useful to still
exercise it.

Drop the logic and instead use Python 3 unconditionally.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh |  2 +-
 ci/lib.sh                  | 11 +----------
 2 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 8783b48951..4b1733ad15 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -61,7 +61,7 @@ ubuntu-*|i386/debian-*|debian-*)
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
 		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
-		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
+		${CC_PACKAGE:-${CC:-gcc}} python3
 
 	# Starting with Ubuntu 25.10, sudo can now be provided via either
 	# sudo(1) or sudo-rs(1), with the latter being the default. The problem
diff --git a/ci/lib.sh b/ci/lib.sh
index d99e7b9da1..3ec10488d4 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -335,16 +335,7 @@ esac
 
 case "$distro" in
 ubuntu-*)
-	# Python 2 is end of life, and Ubuntu 23.04 and newer don't actually
-	# have it anymore. We thus only test with Python 2 on older LTS
-	# releases.
-	if test "$distro" = "ubuntu-20.04"
-	then
-		PYTHON_PACKAGE=python2
-	else
-		PYTHON_PACKAGE=python3
-	fi
-	MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=/usr/bin/$PYTHON_PACKAGE"
+	MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=/usr/bin/python3"
 
 	export GIT_TEST_HTTPD=true
 

-- 
2.56.0.170.g584c36229d.dirty

[PATCH v2 8/8] ci: improve reftable test coverage

[Patrick Steinhardt]

The "linux-reftable" job exercises Git with reftables as its default
backend. But this job is arguably redundant because we already have the
"linux-reftable-leaks" job that exercises reftables with the leak
sanitizer enabled, and it is unlikely that we will catch any extra bugs
with the leak sanitizer disabled.

One may thus be triggered to just drop the "linux-reftable" job in favor
of the leak-checking variant. But the latter disables a couple of other
tests that exercise git-p4, git-svn and other tools. Those tools may not
be an essential part of Git nowadays, but I don't quite feel comfortable
with reducing test coverage.

Instead, adapt the job to run reftables together with SHA256. which is
an area that we don't have test coverage for.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 2 +-
 .gitlab-ci.yml             | 2 +-
 ci/run-build-and-tests.sh  | 6 +++++-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 5b772dab55..0939833e57 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -405,7 +405,7 @@ jobs:
         - jobname: linux-sha256
           image: ubuntu:rolling
           cc: clang
-        - jobname: linux-reftable
+        - jobname: linux-reftable-sha256
           image: ubuntu:rolling
           cc: clang
         - jobname: linux-exotic
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index de40434ae3..b814963ff7 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -39,7 +39,7 @@ test:linux:
       - jobname: linux-sha256
         image: ubuntu:rolling
         CC: clang
-      - jobname: linux-reftable
+      - jobname: linux-reftable-sha256
         image: ubuntu:rolling
         CC: clang
       - jobname: linux-exotic
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 9381ff8893..c6e61d5794 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -40,7 +40,11 @@ linux-exotic)
 linux-sha256)
 	export GIT_TEST_DEFAULT_HASH=sha256
 	;;
-linux-reftable|linux-reftable-leaks|osx-reftable)
+linux-reftable-sha256)
+	export GIT_TEST_DEFAULT_HASH=sha256
+	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
+	;;
+linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
 	;;
 

-- 
2.56.0.170.g584c36229d.dirty

Re: [PATCH v2 5/8] ci: rename linux-TEST-vars job

[SZEDER Gábor]

On Fri, Oct 09, 2026 at 01:32:02PM +0200, Patrick Steinhardt wrote:
> The "linux-TEST-vars" job exercises Git with a bunch of non-default
> options enabled. The name of that job makes you want to cry though due
> to the weird upper-casing

Yeah, it's an eyesore indeed.

> and because it doesn't really tell you what it
> even intends to do.

It intends to set a bunch of GIT_TEST_* variables, and since it has
test vars in its name, I'd say that it does a decent job at conveying
its intentions.

> Rename the job to "linux-exotic" instead.

Seeing "linux-exotic", I would think of a job running tests on an
exotic Linux distro, or on an exotic platform...  but it wouldn't
occur to me that it intends to set a bunch of GIT_TEST_* variables,
simply because there is nothing in its name to indicate that.

I think this patch makes things worse.

Re: [PATCH 8/8] ci: drop redundant linux-reftable job

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> So how about arguing the other way round and making the job more useful?
> We don't have good test coverage of reftables with SHA256, so we could
> adapt the job to exercise that combination.

Yeah, instead of doing sha1 and leaks, doing sha1 and sha256 would
be much more useful ;-).

Re: [PATCH v2 5/8] ci: rename linux-TEST-vars job

[Patrick Steinhardt]

On Fri, Oct 09, 2026 at 05:31:32PM +0200, SZEDER Gábor wrote:
> On Fri, Oct 09, 2026 at 01:32:02PM +0200, Patrick Steinhardt wrote:
> > The "linux-TEST-vars" job exercises Git with a bunch of non-default
> > options enabled. The name of that job makes you want to cry though due
> > to the weird upper-casing
> 
> Yeah, it's an eyesore indeed.
> 
> > and because it doesn't really tell you what it
> > even intends to do.
> 
> It intends to set a bunch of GIT_TEST_* variables, and since it has
> test vars in its name, I'd say that it does a decent job at conveying
> its intentions.

That only tells you anything in case you evne know about the GIT_TEST
variariables, but doesn't really give you much of an idea what the
intent of that job is. But...

> > Rename the job to "linux-exotic" instead.
> 
> Seeing "linux-exotic", I would think of a job running tests on an
> exotic Linux distro, or on an exotic platform...  but it wouldn't
> occur to me that it intends to set a bunch of GIT_TEST_* variables,
> simply because there is nothing in its name to indicate that.
> 
> I think this patch makes things worse.

... I think it's still a fair point. The question is whether we can come
up with a better name then that is not an eyesore and that gives you a
clue what the job is doing without you having to know about the
underlying mechanism.

A couple of names that come to my mind would be "linux-nondefault",
"linux-optional-features"... and not much else. Do you have any
suggestions?

Thanks!

Patrick

Re: [PATCH v2 5/8] ci: rename linux-TEST-vars job

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

>> Seeing "linux-exotic", I would think of a job running tests on an
>> exotic Linux distro, or on an exotic platform...  but it wouldn't
>> occur to me that it intends to set a bunch of GIT_TEST_* variables,
>> simply because there is nothing in its name to indicate that.
>> 
>> I think this patch makes things worse.
>
> ... I think it's still a fair point. The question is whether we can come
> up with a better name then that is not an eyesore and that gives you a
> clue what the job is doing without you having to know about the
> underlying mechanism.
>
> A couple of names that come to my mind would be "linux-nondefault",
> "linux-optional-features"... and not much else. Do you have any
> suggestions?

Among the following, my current favourite is "feathre testbed".

== Feature & Capability Focus ==

* linux-experimental-features / linux-experimental

  Directly states that the job enables experimental features.  This
  is clear, standard industry terminology, and avoids any ambiguity
  about the Linux distribution itself.

* linux-feature-testbed

  Positions the job as a testbed specifically for experimental
  features, which aligns perfectly with its testing nature.

* linux-exotic-features

  Keeps the "exotic" keyword you proposed but qualifies it with
  "features", immediately removing the risk of sounding like an
  exotic Linux distribution.

== Build & Configuration Focus ==

* linux-nondefault / linux-nonstandard

  A build that departs from the standard, out-of-the-box
  configuration.

* linux-extra-knobs

  Uses Git-centric terminology.  Since you customize build-time
  configuration knobs to enable these experimental features, this is
  highly descriptive and intuitive for developers.

* linux-super-tweaked / linux-highly-tweaked

  Emphasizes that the build variables have been heavily customized.

* linux-custom-vars

  A direct, no-nonsense replacement for 'linux-TEST-vars' that
  clarifies that the variables are custom/customized rather than
  just "test" variables.

== Testing & Robustness Focus ==

* linux-stress-features

  Implies that we are stretching the capabilities of the build by
  turning on non-standard configurations.

* linux-edge-cases

  Focuses on the goal of the job: testing edge cases enabled by
  experimental configuration variables.

* linux-all-features

  If the experimental variables essentially turn on all optional
  features, this is a very clean and positive name.
k

Re: [PATCH v2 5/8] ci: rename linux-TEST-vars job

[Patrick Steinhardt]

On Tue, Oct 13, 2026 at 07:47:35AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> >> Seeing "linux-exotic", I would think of a job running tests on an
> >> exotic Linux distro, or on an exotic platform...  but it wouldn't
> >> occur to me that it intends to set a bunch of GIT_TEST_* variables,
> >> simply because there is nothing in its name to indicate that.
> >> 
> >> I think this patch makes things worse.
> >
> > ... I think it's still a fair point. The question is whether we can come
> > up with a better name then that is not an eyesore and that gives you a
> > clue what the job is doing without you having to know about the
> > underlying mechanism.
> >
> > A couple of names that come to my mind would be "linux-nondefault",
> > "linux-optional-features"... and not much else. Do you have any
> > suggestions?
> 
> Among the following, my current favourite is "feathre testbed".
> 
> == Feature & Capability Focus ==
> 
> * linux-experimental-features / linux-experimental
> 
>   Directly states that the job enables experimental features.  This
>   is clear, standard industry terminology, and avoids any ambiguity
>   about the Linux distribution itself.

Not all of the features are experimental though, so I feel like this is
a bit misleading.

> * linux-feature-testbed
> 
>   Positions the job as a testbed specifically for experimental
>   features, which aligns perfectly with its testing nature.

I like this one, will adopt the naming. Thanks!

Patrick

[PATCH v3 0/8] ci: some housekeeping and modernizations

[Patrick Steinhardt]

Hi,

this patch series is a result from the discussions in [1]. It fixes a
couple of smaller issues in our CI and bumps jobs that use EOL Docker
images to instead use supported ones.

Passing test runs can be found at [2] and [3] for GitLab and GitHub,
respectively.

Note that I've also merged the Meson changes (ps/meson-improvements at
ce4a600322 (gitlab-ci: fix hanging MSVC jobs, 2026-09-24)) in there so
that GitLab passes, but those are not strictly required as a dependency.

Changes in v2:
  - Improve commit messages.
  - Rework the "linux-reftable" job to be more useful instead of
    dropping it.
  - Rename "linux-exotic" to "linux-feature-testbed".
  - Link to v1: https://patch.msgid.link/20261008-pks-ci-housekeeping-v1-0-baf015c589c0@pks.im

Thanks!

Patrick

[1]: <20260906151137.GA328152@coredump.intra.peff.net>
[2]: https://gitlab.com/gitlab-org/git/-/merge_requests/687
[3]: https://github.com/git/git/pull/2445

---
Patrick Steinhardt (8):
      t5004: skip SHA-1-only test in SHA-256 repository
      ci: fix "fedora-breaking-changes-meson" job
      ci: drop unused "linux-clang" logic
      ci: switch away from unsupported i386/ubuntu image
      ci: rename linux-TEST-vars job
      ci: switch away from EOL'd Ubuntu version in linux-feature-testbed
      ci: drop now-dead Python 2 coverage
      ci: improve reftable test coverage

 .github/workflows/main.yml      | 11 ++++-------
 .gitlab-ci.yml                  | 11 ++++-------
 ci/install-dependencies.sh      |  8 ++------
 ci/lib.sh                       | 13 ++-----------
 ci/run-build-and-tests.sh       | 14 +++++++-------
 t/t5004-archive-corner-cases.sh |  2 +-
 6 files changed, 20 insertions(+), 39 deletions(-)

Range-diff versus v2:

1:  6bf6c0285e = 1:  f000630dda t5004: skip SHA-1-only test in SHA-256 repository
2:  ad57a87914 = 2:  93fce3a349 ci: fix "fedora-breaking-changes-meson" job
3:  7f80b65aed = 3:  a79409be82 ci: drop unused "linux-clang" logic
4:  1e2dfbc1b1 = 4:  7566046967 ci: switch away from unsupported i386/ubuntu image
5:  e2e71b0760 ! 5:  b6117e4ed7 ci: rename linux-TEST-vars job
    @@ Commit message
         to the weird upper-casing and because it doesn't really tell you what it
         even intends to do.
     
    -    Rename the job to "linux-exotic" instead.
    +    Rename the job to "linux-feature-testbed" instead.
     
    +    Helped-by: Junio C Hamano <gitster@pobox.com>
         Signed-off-by: Patrick Steinhardt <ps@pks.im>
     
      ## .github/workflows/main.yml ##
    @@ .github/workflows/main.yml: jobs:
                image: ubuntu:rolling
                cc: clang
     -        - jobname: linux-TEST-vars
    -+        - jobname: linux-exotic
    ++        - jobname: linux-feature-testbed
                image: ubuntu:20.04
                cc: gcc
                cc_package: gcc-8
    @@ .gitlab-ci.yml: test:linux:
              image: ubuntu:rolling
              CC: clang
     -      - jobname: linux-TEST-vars
    -+      - jobname: linux-exotic
    ++      - jobname: linux-feature-testbed
              image: ubuntu:20.04
              CC: gcc
              CC_PACKAGE: gcc-8
    @@ ci/run-build-and-tests.sh: fedora-breaking-changes-meson|linux-breaking-changes)
      	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
      	;;
     -linux-TEST-vars)
    -+linux-exotic)
    ++linux-feature-testbed)
      	export OPENSSL_SHA1_UNSAFE=YesPlease
      	export GIT_TEST_SPLIT_INDEX=yes
      	export GIT_TEST_FULL_IN_PACK_ARRAY=true
6:  0a83a736af ! 6:  e434629907 ci: switch away from EOL'd Ubuntu version in linux-exotic
    @@ Metadata
     Author: Patrick Steinhardt <ps@pks.im>
     
      ## Commit message ##
    -    ci: switch away from EOL'd Ubuntu version in linux-exotic
    +    ci: switch away from EOL'd Ubuntu version in linux-feature-testbed
     
    -    The "linux-exotic" job still uses Ubuntu 20.04, which is end of life
    -    nowadays and starting to show some cracks. Switch it over to use the
    -    "latest" tag instead so that we don't have to constantly update it
    +    The "linux-feature-testbed" job still uses Ubuntu 20.04, which is end of
    +    life nowadays and starting to show some cracks. Switch it over to use
    +    the "latest" tag instead so that we don't have to constantly update it
         anymore.
     
         Now arguably, this reduces test coverage for old versions of Ubuntu.
    @@ .github/workflows/main.yml
     @@ .github/workflows/main.yml: jobs:
                image: ubuntu:rolling
                cc: clang
    -         - jobname: linux-exotic
    +         - jobname: linux-feature-testbed
     -          image: ubuntu:20.04
     -          cc: gcc
     -          cc_package: gcc-8
    @@ .gitlab-ci.yml
     @@ .gitlab-ci.yml: test:linux:
              image: ubuntu:rolling
              CC: clang
    -       - jobname: linux-exotic
    +       - jobname: linux-feature-testbed
     -        image: ubuntu:20.04
     -        CC: gcc
     -        CC_PACKAGE: gcc-8
7:  9f7b154520 = 7:  72736847d4 ci: drop now-dead Python 2 coverage
8:  d97f36f5f9 ! 8:  fc15ae0fcc ci: improve reftable test coverage
    @@ .github/workflows/main.yml: jobs:
     +        - jobname: linux-reftable-sha256
                image: ubuntu:rolling
                cc: clang
    -         - jobname: linux-exotic
    +         - jobname: linux-feature-testbed
     
      ## .gitlab-ci.yml ##
     @@ .gitlab-ci.yml: test:linux:
    @@ .gitlab-ci.yml: test:linux:
     +      - jobname: linux-reftable-sha256
              image: ubuntu:rolling
              CC: clang
    -       - jobname: linux-exotic
    +       - jobname: linux-feature-testbed
     
      ## ci/run-build-and-tests.sh ##
    -@@ ci/run-build-and-tests.sh: linux-exotic)
    +@@ ci/run-build-and-tests.sh: linux-feature-testbed)
      linux-sha256)
      	export GIT_TEST_DEFAULT_HASH=sha256
      	;;

---
base-commit: 8e383dedc6bbc4fd7bbb203512fbf2eafc151e04
change-id: 20261008-pks-ci-housekeeping-4cf7fac3b0df

[PATCH v3 1/8] t5004: skip SHA-1-only test in SHA-256 repository

[Patrick Steinhardt]

One of the tests in t5004 extracts a ZIP file that contains some objects
larger than 4GB and then double-checks whether we can read and archive
such an object. That test has a bunch of prerequities: it requires a 64
bit `long`, unzip with 64-bit support and it only runs when EXPENSIVE is
enabled. Consequently, not a lot of jobs even exercise this.

One of the jobs that does run it though is our Fedora-based job, as it
ticks all the necessary boxes. But that job was silently broken: while
the intent was to run on Fedora with breaking changes enabled, they are
in fact disabled due to a typo.

We're about to fix that typo in the next commit, but this will also
uncover that the above test case is broken when running in SHA-256
repositories. The extracted objects are SHA-1 objects, so extracting
them into a SHA-256 repository is not going to yield anything good. So
once we fix the Fedora-based job to enable breaking changes, which will
make tests use SHA-256 by default, the test will break.

Fix this issue by adding the SHA1 prerequisite.

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

diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
index 768b0ff85d..c9c879cc5f 100755
--- a/t/t5004-archive-corner-cases.sh
+++ b/t/t5004-archive-corner-cases.sh
@@ -185,7 +185,7 @@ test_expect_success EXPENSIVE,UNZIP,UNZIP_ZIP64_SUPPORT \
 	"$GIT_UNZIP" -t many-big.zip
 '
 
-test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
+test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO,SHA1 \
 	'zip archive with files bigger than 4GB' '
 	# Pack created with:
 	#   dd if=/dev/zero of=file bs=1M count=4100 && git hash-object -w file

-- 
2.56.0.212.g129ede20d9.dirty

[PATCH v3 2/8] ci: fix "fedora-breaking-changes-meson" job

[Patrick Steinhardt]

The "fedora-breaking-changes-meson" job exercises Git with breaking
changes enabled on Fedora with Meson. There's a typo in our CI scripts
though, which has the effect that the build does not enable breaking
changes by accident.

Fix the typo.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-build-and-tests.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 6a3b43b366..bc5058c917 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -18,7 +18,7 @@ almalinux-*|debian-*|fedora-*|linux-*)
 esac
 
 case "$jobname" in
-fedora-breaking-changes-musl|linux-breaking-changes)
+fedora-breaking-changes-meson|linux-breaking-changes)
 	export WITH_BREAKING_CHANGES=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;

-- 
2.56.0.212.g129ede20d9.dirty

[PATCH v3 3/8] ci: drop unused "linux-clang" logic

[Patrick Steinhardt]

In d88d727143 (ci: drop linux-clang job, 2023-06-01) we have dropped the
"linux-clang" job because another job already uses Clang anyway. But we
forgot to also drop the logic in "ci/run-build-and-tests.sh", so we now
have some unused logic in there.

Drop it.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-build-and-tests.sh | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index bc5058c917..23e87cbbd6 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -37,10 +37,6 @@ linux-TEST-vars)
 	export GIT_TEST_CHECKOUT_WORKERS=2
 	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
 	;;
-linux-clang)
-	export NO_RUST=UnfortunatelyYes
-	export GIT_TEST_DEFAULT_HASH=sha1
-	;;
 linux-sha256)
 	export GIT_TEST_DEFAULT_HASH=sha256
 	;;

-- 
2.56.0.212.g129ede20d9.dirty

[PATCH v3 4/8] ci: switch away from unsupported i386/ubuntu image

[Patrick Steinhardt]

The linux32 job is used to exercise Git on a 32 bit platform. That job
uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
nowadays. Furthermore, Ubuntu 20.04 is the last release that has support
for 32 bit, so we cannot upgrade the image to a later version, either.

Switch the job over to use i386/debian instead. Note that starting with
Debian 13, support for i386 has been reduced [1]. But Debian still
releases 32 bit Docker images for the latest release nowadays, so we
will have coverage until at least 2030.

[1]: https://www.debian.org/releases/trixie/release-notes/issues.en.html#i386-reduced-support

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 3 +--
 .gitlab-ci.yml             | 3 +--
 ci/install-dependencies.sh | 6 +-----
 ci/lib.sh                  | 2 +-
 4 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index b229739be8..6d1e37c8f1 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -431,9 +431,8 @@ jobs:
           cc: gcc
         - jobname: linux-musl-meson
           image: alpine:latest
-        # Supported until 2025-04-02.
         - jobname: linux32
-          image: i386/ubuntu:20.04
+          image: i386/debian:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 3f24835500..7d972f0c8b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -65,9 +65,8 @@ test:linux:
         CC: gcc
       - jobname: linux-musl-meson
         image: alpine:latest
-        # Supported until 2025-04-02.
       - jobname: linux32
-        image: i386/ubuntu:20.04
+        image: i386/debian:latest
       # A RHEL 8 compatible distro.  Supported until 2029-05-31.
       - jobname: almalinux-8
         image: almalinux:8
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d57dce5663..8783b48951 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -39,7 +39,7 @@ fedora-*|almalinux-*)
 	dnf -yq update >/dev/null &&
 	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS cargo >/dev/null
 	;;
-ubuntu-*|i386/ubuntu-*|debian-*)
+ubuntu-*|i386/debian-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
 	export DEBIAN_FRONTEND=noninteractive
 
@@ -48,10 +48,6 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		SVN='libsvn-perl subversion'
 		LANGUAGES='language-pack-is'
 		;;
-	i386/ubuntu-*)
-		SVN=
-		LANGUAGES='language-pack-is'
-		;;
 	*)
 		SVN='libsvn-perl subversion'
 		LANGUAGES='locales-all'
diff --git a/ci/lib.sh b/ci/lib.sh
index c6ccbf8c17..d99e7b9da1 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -262,7 +262,7 @@ then
 		CI_OS_NAME=osx
 		JOBS=$(nproc)
 		;;
-	*,almalinux:*|*,alpine:*|*,debian:*|*,fedora:*|*,ubuntu:*|*,i386/ubuntu:*)
+	*,almalinux:*|*,alpine:*|*,debian:*|*,fedora:*|*,ubuntu:*|*,i386/debian:*)
 		CI_OS_NAME=linux
 		JOBS=$(nproc)
 		;;

-- 
2.56.0.212.g129ede20d9.dirty

[PATCH v3 5/8] ci: rename linux-TEST-vars job

[Patrick Steinhardt]

The "linux-TEST-vars" job exercises Git with a bunch of non-default
options enabled. The name of that job makes you want to cry though due
to the weird upper-casing and because it doesn't really tell you what it
even intends to do.

Rename the job to "linux-feature-testbed" instead.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 2 +-
 .gitlab-ci.yml             | 2 +-
 ci/run-build-and-tests.sh  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 6d1e37c8f1..60f262db39 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -408,7 +408,7 @@ jobs:
         - jobname: linux-reftable
           image: ubuntu:rolling
           cc: clang
-        - jobname: linux-TEST-vars
+        - jobname: linux-feature-testbed
           image: ubuntu:20.04
           cc: gcc
           cc_package: gcc-8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 7d972f0c8b..726c1c1865 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -42,7 +42,7 @@ test:linux:
       - jobname: linux-reftable
         image: ubuntu:rolling
         CC: clang
-      - jobname: linux-TEST-vars
+      - jobname: linux-feature-testbed
         image: ubuntu:20.04
         CC: gcc
         CC_PACKAGE: gcc-8
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 23e87cbbd6..611bf6e56d 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -22,7 +22,7 @@ fedora-breaking-changes-meson|linux-breaking-changes)
 	export WITH_BREAKING_CHANGES=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
-linux-TEST-vars)
+linux-feature-testbed)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
 	export GIT_TEST_SPLIT_INDEX=yes
 	export GIT_TEST_FULL_IN_PACK_ARRAY=true

-- 
2.56.0.212.g129ede20d9.dirty

[PATCH v3 6/8] ci: switch away from EOL'd Ubuntu version in linux-feature-testbed

[Patrick Steinhardt]

The "linux-feature-testbed" job still uses Ubuntu 20.04, which is end of
life nowadays and starting to show some cracks. Switch it over to use
the "latest" tag instead so that we don't have to constantly update it
anymore.

Now arguably, this reduces test coverage for old versions of Ubuntu.
But "latest" at least points to the most up-to-date LTS release of
Ubuntu, compared to the "rolling" tag that uses the latest release
regardless of the LTS status. So while "latest" and "rolling" are the
same right now, that's not always the case.

Furthermore, we have other jobs that test with ancient versions of
Linux, like for example the one that uses AlmaLinux 8 (2021, originally
tracking RHEL 8 from 2019) or Debian 12 (2023).

Note that this also requires us to switch away from GCC 8, which is not
supported by Ubuntu 26.04 anymore. Instead we simply use the default
version of GCC.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 4 +---
 .gitlab-ci.yml             | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 60f262db39..47f174ed0e 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -409,9 +409,7 @@ jobs:
           image: ubuntu:rolling
           cc: clang
         - jobname: linux-feature-testbed
-          image: ubuntu:20.04
-          cc: gcc
-          cc_package: gcc-8
+          image: ubuntu:latest
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 726c1c1865..3e2e6083cb 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -43,9 +43,7 @@ test:linux:
         image: ubuntu:rolling
         CC: clang
       - jobname: linux-feature-testbed
-        image: ubuntu:20.04
-        CC: gcc
-        CC_PACKAGE: gcc-8
+        image: ubuntu:latest
       - jobname: linux-breaking-changes
         image: ubuntu:rolling
         CC: gcc

-- 
2.56.0.212.g129ede20d9.dirty

[PATCH v3 7/8] ci: drop now-dead Python 2 coverage

[Patrick Steinhardt]

In the preceding commit we've dropped the last job that still used
Ubuntu 20.04. We still had some conditional logic for that specific
image that made us use Python 2 instead of Python 3, but this is dead
code now.

We could of course exercise Python 2 in any of our other CI jobs. But it
reached end of life in 2020 already, and none of the distros that we use
have it packaged anymore. Furthermore, it seems like the world has
finally adapted to Python 3. So it doesn't feel all that useful to still
exercise it.

Drop the logic and instead use Python 3 unconditionally.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh |  2 +-
 ci/lib.sh                  | 11 +----------
 2 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 8783b48951..4b1733ad15 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -61,7 +61,7 @@ ubuntu-*|i386/debian-*|debian-*)
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
 		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
-		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
+		${CC_PACKAGE:-${CC:-gcc}} python3
 
 	# Starting with Ubuntu 25.10, sudo can now be provided via either
 	# sudo(1) or sudo-rs(1), with the latter being the default. The problem
diff --git a/ci/lib.sh b/ci/lib.sh
index d99e7b9da1..3ec10488d4 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -335,16 +335,7 @@ esac
 
 case "$distro" in
 ubuntu-*)
-	# Python 2 is end of life, and Ubuntu 23.04 and newer don't actually
-	# have it anymore. We thus only test with Python 2 on older LTS
-	# releases.
-	if test "$distro" = "ubuntu-20.04"
-	then
-		PYTHON_PACKAGE=python2
-	else
-		PYTHON_PACKAGE=python3
-	fi
-	MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=/usr/bin/$PYTHON_PACKAGE"
+	MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=/usr/bin/python3"
 
 	export GIT_TEST_HTTPD=true
 

-- 
2.56.0.212.g129ede20d9.dirty

[PATCH v3 8/8] ci: improve reftable test coverage

[Patrick Steinhardt]

The "linux-reftable" job exercises Git with reftables as its default
backend. But this job is arguably redundant because we already have the
"linux-reftable-leaks" job that exercises reftables with the leak
sanitizer enabled, and it is unlikely that we will catch any extra bugs
with the leak sanitizer disabled.

One may thus be triggered to just drop the "linux-reftable" job in favor
of the leak-checking variant. But the latter disables a couple of other
tests that exercise git-p4, git-svn and other tools. Those tools may not
be an essential part of Git nowadays, but I don't quite feel comfortable
with reducing test coverage.

Instead, adapt the job to run reftables together with SHA256. which is
an area that we don't have test coverage for.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 2 +-
 .gitlab-ci.yml             | 2 +-
 ci/run-build-and-tests.sh  | 6 +++++-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 47f174ed0e..fe8155772a 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -405,7 +405,7 @@ jobs:
         - jobname: linux-sha256
           image: ubuntu:rolling
           cc: clang
-        - jobname: linux-reftable
+        - jobname: linux-reftable-sha256
           image: ubuntu:rolling
           cc: clang
         - jobname: linux-feature-testbed
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 3e2e6083cb..9b7698a003 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -39,7 +39,7 @@ test:linux:
       - jobname: linux-sha256
         image: ubuntu:rolling
         CC: clang
-      - jobname: linux-reftable
+      - jobname: linux-reftable-sha256
         image: ubuntu:rolling
         CC: clang
       - jobname: linux-feature-testbed
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 611bf6e56d..1c549634e0 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -40,7 +40,11 @@ linux-feature-testbed)
 linux-sha256)
 	export GIT_TEST_DEFAULT_HASH=sha256
 	;;
-linux-reftable|linux-reftable-leaks|osx-reftable)
+linux-reftable-sha256)
+	export GIT_TEST_DEFAULT_HASH=sha256
+	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
+	;;
+linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
 	;;
 

-- 
2.56.0.212.g129ede20d9.dirty

Re: [PATCH v3 1/8] t5004: skip SHA-1-only test in SHA-256 repository

[Jeff King]

On Wed, Oct 14, 2026 at 10:30:27AM +0200, Patrick Steinhardt wrote:

> We're about to fix that typo in the next commit, but this will also
> uncover that the above test case is broken when running in SHA-256
> repositories. The extracted objects are SHA-1 objects, so extracting
> them into a SHA-256 repository is not going to yield anything good. So
> once we fix the Fedora-based job to enable breaking changes, which will
> make tests use SHA-256 by default, the test will break.
> 
> Fix this issue by adding the SHA1 prerequisite.

Does that mean we'll basically never run the test once Git 3.0 shifts to
sha256 by default? I guess we'll have a sha1 ci job (like we have sha256
today), but would that job actually hit all the other prereqs?

If we instead teach it to use its own repo, independent of the defaults,
then we could run it everywhere (that allows all of the other prereqs).

Something like:

diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
index 768b0ff85d..3a5c01c475 100755
--- a/t/t5004-archive-corner-cases.sh
+++ b/t/t5004-archive-corner-cases.sh
@@ -187,6 +187,9 @@ test_expect_success EXPENSIVE,UNZIP,UNZIP_ZIP64_SUPPORT \
 
 test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
 	'zip archive with files bigger than 4GB' '
+	git init --object-format=sha1 big-file &&
+	(
+	cd big-file &&
 	# Pack created with:
 	#   dd if=/dev/zero of=file bs=1M count=4100 && git hash-object -w file
 	mkdir -p .git/objects/pack &&
@@ -206,6 +209,7 @@ test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
 	"$GIT_UNZIP" -t big.zip &&
 	"$ZIPINFO" big.zip >big.lst &&
 	test_grep $size big.lst
+	)
 '
 
 build_tree() {


A real patch obviously would also indent the test body one level; I
skipped that here to keep the diff readable.

-Peff

Re: [PATCH v3 2/8] ci: fix "fedora-breaking-changes-meson" job

[Jeff King]

On Wed, Oct 14, 2026 at 10:30:28AM +0200, Patrick Steinhardt wrote:

> The "fedora-breaking-changes-meson" job exercises Git with breaking
> changes enabled on Fedora with Meson. There's a typo in our CI scripts
> though, which has the effect that the build does not enable breaking
> changes by accident.
>
> [...]
>
>  case "$jobname" in
> -fedora-breaking-changes-musl|linux-breaking-changes)
> +fedora-breaking-changes-meson|linux-breaking-changes)
>  	export WITH_BREAKING_CHANGES=YesPlease
>  	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
>  	;;

Seems obviously correct, but I wonder if just:

  *breaking-changes*)

would fix this and prevent any issues for possible future jobs. The
downside of a loose pattern is false matches, but it seems like a small
risk given our universe of jobs.

-Peff

Re: [PATCH v3 4/8] ci: switch away from unsupported i386/ubuntu image

[Jeff King]

On Wed, Oct 14, 2026 at 10:30:30AM +0200, Patrick Steinhardt wrote:

> The linux32 job is used to exercise Git on a 32 bit platform. That job
> uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
> nowadays. Furthermore, Ubuntu 20.04 is the last release that has support
> for 32 bit, so we cannot upgrade the image to a later version, either.
> 
> Switch the job over to use i386/debian instead. Note that starting with
> Debian 13, support for i386 has been reduced [1]. But Debian still
> releases 32 bit Docker images for the latest release nowadays, so we
> will have coverage until at least 2030.

Makes sense. I did notice this hunk, though:

> @@ -48,10 +48,6 @@ ubuntu-*|i386/ubuntu-*|debian-*)
>  		SVN='libsvn-perl subversion'
>  		LANGUAGES='language-pack-is'
>  		;;
> -	i386/ubuntu-*)
> -		SVN=
> -		LANGUAGES='language-pack-is'
> -		;;

I think we have some tests which use is_IS as an exotic locale, which I
assume is why we add this dependency. Do we need to do something similar
for Debian so we don't skip those gettext tests on the 32-bit job, or
does it just work on Debian?

-Peff

Re: [PATCH v3 5/8] ci: rename linux-TEST-vars job

[Jeff King]

On Wed, Oct 14, 2026 at 10:30:31AM +0200, Patrick Steinhardt wrote:

> The "linux-TEST-vars" job exercises Git with a bunch of non-default
> options enabled. The name of that job makes you want to cry though due
> to the weird upper-casing and because it doesn't really tell you what it
> even intends to do.

FWIW, I have always hated the name, too. ;)

> Rename the job to "linux-feature-testbed" instead.

I saw the name discussion upthread, and I agree this one is good.

-Peff

Re: [PATCH v3 6/8] ci: switch away from EOL'd Ubuntu version in linux-feature-testbed

[Jeff King]

On Wed, Oct 14, 2026 at 10:30:32AM +0200, Patrick Steinhardt wrote:

> The "linux-feature-testbed" job still uses Ubuntu 20.04, which is end of
> life nowadays and starting to show some cracks. Switch it over to use
> the "latest" tag instead so that we don't have to constantly update it
> anymore.
> 
> Now arguably, this reduces test coverage for old versions of Ubuntu.
> But "latest" at least points to the most up-to-date LTS release of
> Ubuntu, compared to the "rolling" tag that uses the latest release
> regardless of the LTS status. So while "latest" and "rolling" are the
> same right now, that's not always the case.
> 
> Furthermore, we have other jobs that test with ancient versions of
> Linux, like for example the one that uses AlmaLinux 8 (2021, originally
> tracking RHEL 8 from 2019) or Debian 12 (2023).

Yep, nicely explained and I agree this is a good direction.

-Peff

Re: [PATCH v3 8/8] ci: improve reftable test coverage

[Jeff King]

On Wed, Oct 14, 2026 at 10:30:34AM +0200, Patrick Steinhardt wrote:

> The "linux-reftable" job exercises Git with reftables as its default
> backend. But this job is arguably redundant because we already have the
> "linux-reftable-leaks" job that exercises reftables with the leak
> sanitizer enabled, and it is unlikely that we will catch any extra bugs
> with the leak sanitizer disabled.
> 
> One may thus be triggered to just drop the "linux-reftable" job in favor
> of the leak-checking variant. But the latter disables a couple of other
> tests that exercise git-p4, git-svn and other tools. Those tools may not
> be an essential part of Git nowadays, but I don't quite feel comfortable
> with reducing test coverage.
> 
> Instead, adapt the job to run reftables together with SHA256. which is
> an area that we don't have test coverage for.

Hmm. Aren't both sha256 and reftables by default part of the breaking
changes flag? So I think we probably are already getting coverage there.

-Peff

Re: [PATCH v3 0/8] ci: some housekeeping and modernizations

[Jeff King]

On Wed, Oct 14, 2026 at 10:30:26AM +0200, Patrick Steinhardt wrote:

> this patch series is a result from the discussions in [1]. It fixes a
> couple of smaller issues in our CI and bumps jobs that use EOL Docker
> images to instead use supported ones.
> 
> Passing test runs can be found at [2] and [3] for GitLab and GitHub,
> respectively.

Sorry I missed the earlier rounds. The overall direction looks good to
me, and thanks for working on this. I did raise a few small issues that
might be worth addressing.

-Peff

Re: [PATCH v3 1/8] t5004: skip SHA-1-only test in SHA-256 repository

[Patrick Steinhardt]

On Wed, Oct 14, 2026 at 05:07:46AM -0400, Jeff King wrote:
> On Wed, Oct 14, 2026 at 10:30:27AM +0200, Patrick Steinhardt wrote:
> 
> > We're about to fix that typo in the next commit, but this will also
> > uncover that the above test case is broken when running in SHA-256
> > repositories. The extracted objects are SHA-1 objects, so extracting
> > them into a SHA-256 repository is not going to yield anything good. So
> > once we fix the Fedora-based job to enable breaking changes, which will
> > make tests use SHA-256 by default, the test will break.
> > 
> > Fix this issue by adding the SHA1 prerequisite.
> 
> Does that mean we'll basically never run the test once Git 3.0 shifts to
> sha256 by default? I guess we'll have a sha1 ci job (like we have sha256
> today), but would that job actually hit all the other prereqs?
> 
> If we instead teach it to use its own repo, independent of the defaults,
> then we could run it everywhere (that allows all of the other prereqs).
> 
> Something like:
> 
> diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
> index 768b0ff85d..3a5c01c475 100755
> --- a/t/t5004-archive-corner-cases.sh
> +++ b/t/t5004-archive-corner-cases.sh
> @@ -187,6 +187,9 @@ test_expect_success EXPENSIVE,UNZIP,UNZIP_ZIP64_SUPPORT \
>  
>  test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
>  	'zip archive with files bigger than 4GB' '
> +	git init --object-format=sha1 big-file &&
> +	(
> +	cd big-file &&
>  	# Pack created with:
>  	#   dd if=/dev/zero of=file bs=1M count=4100 && git hash-object -w file
>  	mkdir -p .git/objects/pack &&
> @@ -206,6 +209,7 @@ test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
>  	"$GIT_UNZIP" -t big.zip &&
>  	"$ZIPINFO" big.zip >big.lst &&
>  	test_grep $size big.lst
> +	)
>  '
>  
>  build_tree() {
> 
> 
> A real patch obviously would also indent the test body one level; I
> skipped that here to keep the diff readable.

Hmm. Yeah, I guess that wouldn't hurt.

Patrick

Re: [PATCH v3 2/8] ci: fix "fedora-breaking-changes-meson" job

[Patrick Steinhardt]

On Wed, Oct 14, 2026 at 05:10:37AM -0400, Jeff King wrote:
> On Wed, Oct 14, 2026 at 10:30:28AM +0200, Patrick Steinhardt wrote:
> 
> > The "fedora-breaking-changes-meson" job exercises Git with breaking
> > changes enabled on Fedora with Meson. There's a typo in our CI scripts
> > though, which has the effect that the build does not enable breaking
> > changes by accident.
> >
> > [...]
> >
> >  case "$jobname" in
> > -fedora-breaking-changes-musl|linux-breaking-changes)
> > +fedora-breaking-changes-meson|linux-breaking-changes)
> >  	export WITH_BREAKING_CHANGES=YesPlease
> >  	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
> >  	;;
> 
> Seems obviously correct, but I wonder if just:
> 
>   *breaking-changes*)
> 
> would fix this and prevent any issues for possible future jobs. The
> downside of a loose pattern is false matches, but it seems like a small
> risk given our universe of jobs.

In general I think the way we structure these is somewhat lackluster:

  - I never really understood the split between "ci/lib.sh" and
    "ci/run-build-and-tests.sh".

  - There is a bunch of duplication that could be avoided.

  - And your suggestion makes sense, too.

I originally carried a patch that merges all of this into "ci/lib.sh",
and it also did changes similar to what you propose. We could probably
revive that patch, but if so I'd propose to do that as a follow-up.

Patrick

Re: [PATCH v3 4/8] ci: switch away from unsupported i386/ubuntu image

[Patrick Steinhardt]

On Wed, Oct 14, 2026 at 05:17:05AM -0400, Jeff King wrote:
> On Wed, Oct 14, 2026 at 10:30:30AM +0200, Patrick Steinhardt wrote:
> 
> > The linux32 job is used to exercise Git on a 32 bit platform. That job
> > uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
> > nowadays. Furthermore, Ubuntu 20.04 is the last release that has support
> > for 32 bit, so we cannot upgrade the image to a later version, either.
> > 
> > Switch the job over to use i386/debian instead. Note that starting with
> > Debian 13, support for i386 has been reduced [1]. But Debian still
> > releases 32 bit Docker images for the latest release nowadays, so we
> > will have coverage until at least 2030.
> 
> Makes sense. I did notice this hunk, though:
> 
> > @@ -48,10 +48,6 @@ ubuntu-*|i386/ubuntu-*|debian-*)
> >  		SVN='libsvn-perl subversion'
> >  		LANGUAGES='language-pack-is'
> >  		;;
> > -	i386/ubuntu-*)
> > -		SVN=
> > -		LANGUAGES='language-pack-is'
> > -		;;
> 
> I think we have some tests which use is_IS as an exotic locale, which I
> assume is why we add this dependency. Do we need to do something similar
> for Debian so we don't skip those gettext tests on the 32-bit job, or
> does it just work on Debian?

On Debian we already install "locales-all", so I don't think we have to
do anything there.

Patrick

Re: [PATCH v3 8/8] ci: improve reftable test coverage

[Patrick Steinhardt]

On Wed, Oct 14, 2026 at 05:21:37AM -0400, Jeff King wrote:
> On Wed, Oct 14, 2026 at 10:30:34AM +0200, Patrick Steinhardt wrote:
> 
> > The "linux-reftable" job exercises Git with reftables as its default
> > backend. But this job is arguably redundant because we already have the
> > "linux-reftable-leaks" job that exercises reftables with the leak
> > sanitizer enabled, and it is unlikely that we will catch any extra bugs
> > with the leak sanitizer disabled.
> > 
> > One may thus be triggered to just drop the "linux-reftable" job in favor
> > of the leak-checking variant. But the latter disables a couple of other
> > tests that exercise git-p4, git-svn and other tools. Those tools may not
> > be an essential part of Git nowadays, but I don't quite feel comfortable
> > with reducing test coverage.
> > 
> > Instead, adapt the job to run reftables together with SHA256. which is
> > an area that we don't have test coverage for.
> 
> Hmm. Aren't both sha256 and reftables by default part of the breaking
> changes flag? So I think we probably are already getting coverage there.

SHA256 is, but reftables is not. Quoting "t/test-lib.sh":

  GIT_TEST_BUILTIN_HASH=$("$GIT_BINARY" version --build-options | sed -ne 's/^default-hash: //p')
  GIT_DEFAULT_HASH="${GIT_TEST_DEFAULT_HASH:-$GIT_TEST_BUILTIN_HASH}"
  export GIT_DEFAULT_HASH
  GIT_DEFAULT_REF_STORAGE_FORMAT="${GIT_TEST_DEFAULT_REF_STORAGE_FORMAT:-files}"
  export GIT_DEFAULT_REF_STORAGE_FORMAT

So we will run our tests with the default hash function, but we will
run with the "files" backend by default.

Patrick

Re: [PATCH v3 2/8] ci: fix "fedora-breaking-changes-meson" job

[Jeff King]

On Wed, Oct 14, 2026 at 12:35:08PM +0200, Patrick Steinhardt wrote:

> > Seems obviously correct, but I wonder if just:
> > 
> >   *breaking-changes*)
> > 
> > would fix this and prevent any issues for possible future jobs. The
> > downside of a loose pattern is false matches, but it seems like a small
> > risk given our universe of jobs.
> 
> In general I think the way we structure these is somewhat lackluster:
> 
>   - I never really understood the split between "ci/lib.sh" and
>     "ci/run-build-and-tests.sh".
> 
>   - There is a bunch of duplication that could be avoided.
> 
>   - And your suggestion makes sense, too.

Yeah, I think there is a combination of organic growth and the fact that
nobody really cares about ci unless it's failing. It is probably ripe
for cleanup if somebody cares to spend time on it.

> I originally carried a patch that merges all of this into "ci/lib.sh",
> and it also did changes similar to what you propose. We could probably
> revive that patch, but if so I'd propose to do that as a follow-up.

I'm OK with doing it later. I noticed some other similar spots in the
context while reading your patches. E.g., anything with *-sha256* could
set the default hash, and so on. I expect you might have found them for
your patch, too. ;)

-Peff

Re: [PATCH v3 4/8] ci: switch away from unsupported i386/ubuntu image

[Jeff King]

On Wed, Oct 14, 2026 at 12:35:13PM +0200, Patrick Steinhardt wrote:

> > Makes sense. I did notice this hunk, though:
> > 
> > > @@ -48,10 +48,6 @@ ubuntu-*|i386/ubuntu-*|debian-*)
> > >  		SVN='libsvn-perl subversion'
> > >  		LANGUAGES='language-pack-is'
> > >  		;;
> > > -	i386/ubuntu-*)
> > > -		SVN=
> > > -		LANGUAGES='language-pack-is'
> > > -		;;
> > 
> > I think we have some tests which use is_IS as an exotic locale, which I
> > assume is why we add this dependency. Do we need to do something similar
> > for Debian so we don't skip those gettext tests on the 32-bit job, or
> > does it just work on Debian?
> 
> On Debian we already install "locales-all", so I don't think we have to
> do anything there.

That makes sense. ISTR having to tell Debian which locales I cared
about, but I think that's because I _don't_ have locales-all installed.

-Peff

Re: [PATCH v3 8/8] ci: improve reftable test coverage

[Jeff King]

On Wed, Oct 14, 2026 at 12:35:17PM +0200, Patrick Steinhardt wrote:

> > > Instead, adapt the job to run reftables together with SHA256. which is
> > > an area that we don't have test coverage for.
> > 
> > Hmm. Aren't both sha256 and reftables by default part of the breaking
> > changes flag? So I think we probably are already getting coverage there.
> 
> SHA256 is, but reftables is not. Quoting "t/test-lib.sh":
> 
>   GIT_TEST_BUILTIN_HASH=$("$GIT_BINARY" version --build-options | sed -ne 's/^default-hash: //p')
>   GIT_DEFAULT_HASH="${GIT_TEST_DEFAULT_HASH:-$GIT_TEST_BUILTIN_HASH}"
>   export GIT_DEFAULT_HASH
>   GIT_DEFAULT_REF_STORAGE_FORMAT="${GIT_TEST_DEFAULT_REF_STORAGE_FORMAT:-files}"
>   export GIT_DEFAULT_REF_STORAGE_FORMAT
> 
> So we will run our tests with the default hash function, but we will
> run with the "files" backend by default.

Ah, OK. That feels...weird, since the point of WITH_BREAKING_CHANGES is
to check the new changes. Maybe reftables aren't breaking enough? :)

I'd say we can punt it to another day, but if we _do_ think it's a bug,
and we fix it, then that would make this new job pointless. I dunno.
Maybe there is a good reason we are not pulling the ref format from
build-options in the same way.

Re: [PATCH v3 8/8] ci: improve reftable test coverage

[Patrick Steinhardt]

On Wed, Oct 14, 2026 at 07:13:44AM -0400, Jeff King wrote:
> On Wed, Oct 14, 2026 at 12:35:17PM +0200, Patrick Steinhardt wrote:
> 
> > > > Instead, adapt the job to run reftables together with SHA256. which is
> > > > an area that we don't have test coverage for.
> > > 
> > > Hmm. Aren't both sha256 and reftables by default part of the breaking
> > > changes flag? So I think we probably are already getting coverage there.
> > 
> > SHA256 is, but reftables is not. Quoting "t/test-lib.sh":
> > 
> >   GIT_TEST_BUILTIN_HASH=$("$GIT_BINARY" version --build-options | sed -ne 's/^default-hash: //p')
> >   GIT_DEFAULT_HASH="${GIT_TEST_DEFAULT_HASH:-$GIT_TEST_BUILTIN_HASH}"
> >   export GIT_DEFAULT_HASH
> >   GIT_DEFAULT_REF_STORAGE_FORMAT="${GIT_TEST_DEFAULT_REF_STORAGE_FORMAT:-files}"
> >   export GIT_DEFAULT_REF_STORAGE_FORMAT
> > 
> > So we will run our tests with the default hash function, but we will
> > run with the "files" backend by default.
> 
> Ah, OK. That feels...weird, since the point of WITH_BREAKING_CHANGES is
> to check the new changes. Maybe reftables aren't breaking enough? :)

Yeah, I agree it's weird.

> I'd say we can punt it to another day, but if we _do_ think it's a bug,
> and we fix it, then that would make this new job pointless. I dunno.
> Maybe there is a good reason we are not pulling the ref format from
> build-options in the same way.

As you mentioned in a preceding message, it's probably just that stuff
has grown organically. We added the job when reftables was not slated as
a breaking change, so we couldn't really pull it from the build-options
at that point in time.

I'd punt on this for now and just leave this as-is, because right now it
increases our test coverage. But if we revisit I agree we should figure
out whether this job is still worth it.

Patrick

Re: [PATCH v3 2/8] ci: fix "fedora-breaking-changes-meson" job

[Patrick Steinhardt]

On Wed, Oct 14, 2026 at 07:07:16AM -0400, Jeff King wrote:
> On Wed, Oct 14, 2026 at 12:35:08PM +0200, Patrick Steinhardt wrote:
> 
> > > Seems obviously correct, but I wonder if just:
> > > 
> > >   *breaking-changes*)
> > > 
> > > would fix this and prevent any issues for possible future jobs. The
> > > downside of a loose pattern is false matches, but it seems like a small
> > > risk given our universe of jobs.
> > 
> > In general I think the way we structure these is somewhat lackluster:
> > 
> >   - I never really understood the split between "ci/lib.sh" and
> >     "ci/run-build-and-tests.sh".
> > 
> >   - There is a bunch of duplication that could be avoided.
> > 
> >   - And your suggestion makes sense, too.
> 
> Yeah, I think there is a combination of organic growth and the fact that
> nobody really cares about ci unless it's failing. It is probably ripe
> for cleanup if somebody cares to spend time on it.
> 
> > I originally carried a patch that merges all of this into "ci/lib.sh",
> > and it also did changes similar to what you propose. We could probably
> > revive that patch, but if so I'd propose to do that as a follow-up.
> 
> I'm OK with doing it later. I noticed some other similar spots in the
> context while reading your patches. E.g., anything with *-sha256* could
> set the default hash, and so on. I expect you might have found them for
> your patch, too. ;)

Yes. sha256, breaking-changes, reftables, meson all fall in the same
category.

Patrick

Re: [PATCH v3 8/8] ci: improve reftable test coverage

[Jeff King]

On Wed, Oct 14, 2026 at 01:18:50PM +0200, Patrick Steinhardt wrote:

> > I'd say we can punt it to another day, but if we _do_ think it's a bug,
> > and we fix it, then that would make this new job pointless. I dunno.
> > Maybe there is a good reason we are not pulling the ref format from
> > build-options in the same way.
> 
> As you mentioned in a preceding message, it's probably just that stuff
> has grown organically. We added the job when reftables was not slated as
> a breaking change, so we couldn't really pull it from the build-options
> at that point in time.
> 
> I'd punt on this for now and just leave this as-is, because right now it
> increases our test coverage. But if we revisit I agree we should figure
> out whether this job is still worth it.

That's fine by me. We should just try to remember to re-evaluate the
sha256-reftables job when that happens.

-Peff