[PATCH 0/8] ci: consolidate test variables

[PATCH 0/8] ci: consolidate test variables

[Patrick Steinhardt]

Hi,

this patch series consolidates our test variables as a follow up on the
discussions in [1].

The series is built on top of 37b3475fb53 (The 9th batch, 2026-10-25).

Thanks!

Patrick

[1]: <20261008-pks-ci-housekeeping-v1-0-baf015c589c0@pks.im>

---
Patrick Steinhardt (8):
      ci: consolidate setup of test environment
      ci/lib: always set GIT_TEST_USE_SET_E on Linux jobs
      ci/lib: deduplicate test variables by pattern matching
      ci/lib: merge switches for specific job names
      t: honor default ref storage format
      ci/lib: add another NO_RUST build using glibc
      ci: don't override initial branch name in testbed job
      t/test-lib: make feature-testbed job more accessible

 .github/workflows/main.yml |  3 ---
 .gitlab-ci.yml             |  3 ---
 ci/lib.sh                  | 34 ++++++++++++++++++++++++++++++++--
 ci/run-build-and-tests.sh  | 44 --------------------------------------------
 t/README                   |  5 +++++
 t/test-lib-functions.sh    |  2 +-
 t/test-lib.sh              | 25 ++++++++++++++++++++++++-
 t/unit-tests/unit-test.c   |  1 +
 8 files changed, 63 insertions(+), 54 deletions(-)


---
base-commit: 37b3475fb530c14109211faca33716a173db61ed
change-id: 20261016-b4-pks-ci-test-vars-consolidation-8d0c6a53ca28

[PATCH 1/8] ci: consolidate setup of test environment

[Patrick Steinhardt]

The setup of our test environment is split up across "ci/lib.sh" and
"ci/run-build-and-tests.sh". It is not exactly obvious why that split
even exists, and because of the split you have to know about both of the
locations to be able to figure out the specific environment that applies
to a specific job.

Consolidate the setup into "ci/lib.sh". Note that this is a pure move
for now that results in some awkward duplication. This duplication will
be cleaned up in subsequent commits.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/lib.sh                 | 43 +++++++++++++++++++++++++++++++++++++++++++
 ci/run-build-and-tests.sh | 44 --------------------------------------------
 2 files changed, 43 insertions(+), 44 deletions(-)

diff --git a/ci/lib.sh b/ci/lib.sh
index 2e63d652543..d0bd8113d35 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -394,7 +394,50 @@ osx-meson)
 	;;
 esac
 
+case "$jobname" in
+linux-musl-meson)
+	MESONFLAGS="$MESONFLAGS -Drust=disabled"
+	export GIT_TEST_USE_SET_E=yes
+	;;
+almalinux-*|debian-*|fedora-*|linux-*)
+	export GIT_TEST_USE_SET_E=yes
+	;;
+esac
+
+case "$jobname" in
+fedora-breaking-changes-meson|linux-breaking-changes)
+	export WITH_BREAKING_CHANGES=YesPlease
+	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
+	;;
+linux-feature-testbed)
+	export OPENSSL_SHA1_UNSAFE=YesPlease
+	export GIT_TEST_SPLIT_INDEX=yes
+	export GIT_TEST_FULL_IN_PACK_ARRAY=true
+	export GIT_TEST_OE_SIZE=10
+	export GIT_TEST_OE_DELTA_SIZE=5
+	export GIT_TEST_COMMIT_GRAPH=1
+	export GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=1
+	export GIT_TEST_MULTI_PACK_INDEX=1
+	export GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1
+	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
+	export GIT_TEST_NO_WRITE_REV_INDEX=1
+	export GIT_TEST_CHECKOUT_WORKERS=2
+	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
+	;;
+linux-sha256)
+	export GIT_TEST_DEFAULT_HASH=sha256
+	;;
+linux-reftable-sha256)
+	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
+	export GIT_TEST_DEFAULT_HASH=sha256
+	;;
+linux-reftable-leaks|osx-reftable)
+	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
+	;;
+esac
+
 MAKEFLAGS="$MAKEFLAGS CC=${CC:-cc}"
+export TEST_CONTRIB_TOO=yes
 
 end_group "CI setup via $(basename $0)"
 set -x
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 68b91e31439..b81d654b561 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -5,50 +5,6 @@
 
 . ${0%/*}/lib.sh
 
-export TEST_CONTRIB_TOO=yes
-
-case "$jobname" in
-linux-musl-meson)
-	MESONFLAGS="$MESONFLAGS -Drust=disabled"
-	export GIT_TEST_USE_SET_E=yes
-	;;
-almalinux-*|debian-*|fedora-*|linux-*)
-	export GIT_TEST_USE_SET_E=yes
-	;;
-esac
-
-case "$jobname" in
-fedora-breaking-changes-meson|linux-breaking-changes)
-	export WITH_BREAKING_CHANGES=YesPlease
-	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
-	;;
-linux-feature-testbed)
-	export OPENSSL_SHA1_UNSAFE=YesPlease
-	export GIT_TEST_SPLIT_INDEX=yes
-	export GIT_TEST_FULL_IN_PACK_ARRAY=true
-	export GIT_TEST_OE_SIZE=10
-	export GIT_TEST_OE_DELTA_SIZE=5
-	export GIT_TEST_COMMIT_GRAPH=1
-	export GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=1
-	export GIT_TEST_MULTI_PACK_INDEX=1
-	export GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1
-	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
-	export GIT_TEST_NO_WRITE_REV_INDEX=1
-	export GIT_TEST_CHECKOUT_WORKERS=2
-	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
-	;;
-linux-sha256)
-	export GIT_TEST_DEFAULT_HASH=sha256
-	;;
-linux-reftable-sha256)
-	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
-	export GIT_TEST_DEFAULT_HASH=sha256
-	;;
-linux-reftable-leaks|osx-reftable)
-	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
-	;;
-esac
-
 case "$jobname" in
 *-meson)
 	group "Configure" meson setup build . \

-- 
2.56.0.341.g393f52fd96.dirty

[PATCH 2/8] ci/lib: always set GIT_TEST_USE_SET_E on Linux jobs

[Patrick Steinhardt]

The GIT_TEST_USE_SET_E test variable determines whether we run our test
suite with `set -e` enabled or not. This works on all of our supported
Linux distributions, but it doesn't work on macOS because the version of
Bash used there is rather old and thus has some differences in
behaviour.

We currently set that variable for a bunch of distros explicitly, which
is tedious to keep up-to-date. For example, our "linux32" job does not
enable the test variable even though it could. Adapt the script to
instead set it on any Linux distribution.

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

diff --git a/ci/lib.sh b/ci/lib.sh
index d0bd8113d35..560d785f67c 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -367,6 +367,12 @@ esac
 CUSTOM_PATH="${CUSTOM_PATH:-$HOME/path}"
 export PATH="$CUSTOM_PATH:$PATH"
 
+case "$CI_OS_NAME" in
+linux)
+	export GIT_TEST_USE_SET_E=yes
+	;;
+esac
+
 case "$jobname" in
 linux32)
 	CC=gcc
@@ -397,10 +403,6 @@ esac
 case "$jobname" in
 linux-musl-meson)
 	MESONFLAGS="$MESONFLAGS -Drust=disabled"
-	export GIT_TEST_USE_SET_E=yes
-	;;
-almalinux-*|debian-*|fedora-*|linux-*)
-	export GIT_TEST_USE_SET_E=yes
 	;;
 esac
 

-- 
2.56.0.341.g393f52fd96.dirty

[PATCH 3/8] ci/lib: deduplicate test variables by pattern matching

[Patrick Steinhardt]

We have a couple of test variables that we set in multiple different
jobs. These jobs always have specific identifiers in their names and can
thus easily be told apart from the other jobs.

Use this fact to deduplicate the setup of those test variables by
pattern matching for those identifiers.

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

diff --git a/ci/lib.sh b/ci/lib.sh
index 560d785f67c..de4b94d4d33 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -373,6 +373,25 @@ linux)
 	;;
 esac
 
+case "$jobname" in
+*breaking-changes*)
+	export WITH_BREAKING_CHANGES=YesPlease
+	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
+	;;
+esac
+
+case "$jobname" in
+*reftable*)
+	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
+	;;
+esac
+
+case "$jobname" in
+*sha256*)
+	export GIT_TEST_DEFAULT_HASH=sha256
+	;;
+esac
+
 case "$jobname" in
 linux32)
 	CC=gcc
@@ -407,10 +426,6 @@ linux-musl-meson)
 esac
 
 case "$jobname" in
-fedora-breaking-changes-meson|linux-breaking-changes)
-	export WITH_BREAKING_CHANGES=YesPlease
-	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
-	;;
 linux-feature-testbed)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
 	export GIT_TEST_SPLIT_INDEX=yes
@@ -426,16 +441,6 @@ linux-feature-testbed)
 	export GIT_TEST_CHECKOUT_WORKERS=2
 	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
 	;;
-linux-sha256)
-	export GIT_TEST_DEFAULT_HASH=sha256
-	;;
-linux-reftable-sha256)
-	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
-	export GIT_TEST_DEFAULT_HASH=sha256
-	;;
-linux-reftable-leaks|osx-reftable)
-	export GIT_TEST_DEFAULT_REF_STORAGE_FORMAT=reftable
-	;;
 esac
 
 MAKEFLAGS="$MAKEFLAGS CC=${CC:-cc}"

-- 
2.56.0.341.g393f52fd96.dirty

[PATCH 4/8] ci/lib: merge switches for specific job names

[Patrick Steinhardt]

With the preceding consolidations of test variables we now pointlessly
have three switches over "$jobname". Merge them into a single switch.

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

diff --git a/ci/lib.sh b/ci/lib.sh
index de4b94d4d33..7f67a95cdcc 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -396,11 +396,26 @@ case "$jobname" in
 linux32)
 	CC=gcc
 	;;
+linux-feature-testbed)
+	export OPENSSL_SHA1_UNSAFE=YesPlease
+	export GIT_TEST_SPLIT_INDEX=yes
+	export GIT_TEST_FULL_IN_PACK_ARRAY=true
+	export GIT_TEST_OE_SIZE=10
+	export GIT_TEST_OE_DELTA_SIZE=5
+	export GIT_TEST_COMMIT_GRAPH=1
+	export GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=1
+	export GIT_TEST_MULTI_PACK_INDEX=1
+	export GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1
+	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
+	export GIT_TEST_NO_WRITE_REV_INDEX=1
+	export GIT_TEST_CHECKOUT_WORKERS=2
+	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
+	;;
 linux-meson)
 	MESONFLAGS="$MESONFLAGS -Dcredential_helpers=libsecret,netrc"
 	;;
 linux-musl-meson)
-	MESONFLAGS="$MESONFLAGS -Dtest_utf8_locale=C.UTF-8"
+	MESONFLAGS="$MESONFLAGS -Dtest_utf8_locale=C.UTF-8 -Drust=disabled"
 	;;
 linux-leaks|linux-reftable-leaks)
 	export SANITIZE=leak
@@ -419,30 +434,6 @@ osx-meson)
 	;;
 esac
 
-case "$jobname" in
-linux-musl-meson)
-	MESONFLAGS="$MESONFLAGS -Drust=disabled"
-	;;
-esac
-
-case "$jobname" in
-linux-feature-testbed)
-	export OPENSSL_SHA1_UNSAFE=YesPlease
-	export GIT_TEST_SPLIT_INDEX=yes
-	export GIT_TEST_FULL_IN_PACK_ARRAY=true
-	export GIT_TEST_OE_SIZE=10
-	export GIT_TEST_OE_DELTA_SIZE=5
-	export GIT_TEST_COMMIT_GRAPH=1
-	export GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=1
-	export GIT_TEST_MULTI_PACK_INDEX=1
-	export GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1
-	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
-	export GIT_TEST_NO_WRITE_REV_INDEX=1
-	export GIT_TEST_CHECKOUT_WORKERS=2
-	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
-	;;
-esac
-
 MAKEFLAGS="$MAKEFLAGS CC=${CC:-cc}"
 export TEST_CONTRIB_TOO=yes
 

-- 
2.56.0.341.g393f52fd96.dirty

[PATCH 5/8] t: honor default ref storage format

[Patrick Steinhardt]

When running with breaking changes enabled then we will also run tests
with the SHA256 object hash by default, unless explicitly overridden.
But we don't do the same for ref storage format and will continue to run
tests with the "files" backend even though "reftables" are going to be
the default backend there.

Adapt the logic to also use the compiled-in default ref storage backend
for running our tests. Like this we'll now exercise the "reftable"
backend when breaking changes are enabled.

This of course also applies to our CI jobs, where jobs exercising
breaking changes will run now with both SHA256 and reftables. This
renders the explicit "linux-reftable-sha256" job obsolete. Drop it.

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

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index fe8155772ab..4353af2354e 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-sha256
-          image: ubuntu:rolling
-          cc: clang
         - jobname: linux-feature-testbed
           image: ubuntu:latest
         - jobname: linux-breaking-changes
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 9b7698a0037..52c26f72671 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-sha256
-        image: ubuntu:rolling
-        CC: clang
       - jobname: linux-feature-testbed
         image: ubuntu:latest
       - jobname: linux-breaking-changes
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 09a41d51adc..6f319cd54ba 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -1737,7 +1737,7 @@ test_detect_hash () {
 
 # Detect the ref format in use.
 test_detect_ref_format () {
-	echo "${GIT_TEST_DEFAULT_REF_STORAGE_FORMAT:-files}"
+	echo "${GIT_TEST_DEFAULT_REF_STORAGE_FORMAT:-$GIT_TEST_BUILTIN_REF_STORAGE_FORMAT}"
 }
 
 # Load common hash metadata and common placeholder object IDs for use with
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a893963f86c..de566309861 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -576,7 +576,9 @@ export EDITOR
 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}"
+
+GIT_TEST_BUILTIN_REF_STORAGE_FORMAT=$("$GIT_BINARY" version --build-options | sed -ne 's/^default-ref-storage-format: //p')
+GIT_DEFAULT_REF_STORAGE_FORMAT="${GIT_TEST_DEFAULT_REF_STORAGE_FORMAT:-$GIT_TEST_BUILTIN_REF_STORAGE_FORMAT}"
 export GIT_DEFAULT_REF_STORAGE_FORMAT
 
 # Tests using GIT_TRACE typically don't want <timestamp> <file>:<line> output

-- 
2.56.0.341.g393f52fd96.dirty

[PATCH 6/8] ci/lib: add another NO_RUST build using glibc

[Patrick Steinhardt]

With 32d5b90590 (Enable Rust by default, 2026-04-09) we have enabled
Rust by default. As part of that change we also lost test coverage of
non-Rust builds, as the only platform where we still exercise without
Rust is on Alpine Linux with musl libc.

Adapt the "linux-asan-ubsan" job to disable Rust to restore some of that
coverage. This job was chosen because we also get more bang for the buck
checking for memory safety issues in a job where we use C instead of
Rust, as Rust is supposedly memory-safe by itself already.

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

diff --git a/ci/lib.sh b/ci/lib.sh
index 7f67a95cdcc..82bc169ed7a 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -427,7 +427,7 @@ linux-leaks|linux-reftable-leaks)
 linux-asan-ubsan)
 	export SANITIZE=address,undefined
 	export NO_SVN_TESTS=LetsSaveSomeTime
-	MAKEFLAGS="$MAKEFLAGS NO_PYTHON=YepBecauseP4FlakesTooOften"
+	MAKEFLAGS="$MAKEFLAGS NO_PYTHON=YepBecauseP4FlakesTooOften NO_RUST=Yes"
 	;;
 osx-meson)
 	MESONFLAGS="$MESONFLAGS -Dcredential_helpers=osxkeychain"

-- 
2.56.0.341.g393f52fd96.dirty

[PATCH 7/8] ci: don't override initial branch name in testbed job

[Patrick Steinhardt]

The testbed job overrides GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME to
"master". This is rather pointless nowadays though, as we already
configure the initial branch name to either "main" or "master" depending
on the "WITH_BREAKING_CHANGES" toggle.

Drop this override.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/lib.sh | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ci/lib.sh b/ci/lib.sh
index 82bc169ed7a..fbb13ca6c6a 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -406,7 +406,6 @@ linux-feature-testbed)
 	export GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=1
 	export GIT_TEST_MULTI_PACK_INDEX=1
 	export GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1
-	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
 	export GIT_TEST_NO_WRITE_REV_INDEX=1
 	export GIT_TEST_CHECKOUT_WORKERS=2
 	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1

-- 
2.56.0.341.g393f52fd96.dirty

[PATCH 8/8] t/test-lib: make feature-testbed job more accessible

[Patrick Steinhardt]

Our "feature-testbed" job sets up a bunch of GIT_TEST environment
variables and then executes our tests. This is mostly intended as a
testbed for features that aren't default-enabled, but that may
eventually become so.

Due to the job being special it has a higher potential of failing even
though a local test run succeeds. But running these tests locally with
the same environment is somewhat painful, as the developer has to
manually set all of these environment variables.

Introduce a new "--feature-testbed" toggle for our test suite that, when
set, sets up exactly these environment variables. Migrate our CI to use
this toggle so that we have a single source of truth, only.

Note that we only set these GIT_TEST variables in the case where they
haven't already been configured. This serves two purposes:

  - The user can continue to manually override a subset of those
    variables, if they desire.

  - Test scripts typically source "t/test-lib.sh" after they already
    overrode GIT_TEST variables, and we don't want to discard that.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/lib.sh                | 12 +-----------
 t/README                 |  5 +++++
 t/test-lib.sh            | 21 +++++++++++++++++++++
 t/unit-tests/unit-test.c |  1 +
 4 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/ci/lib.sh b/ci/lib.sh
index fbb13ca6c6a..c3a5ec48f22 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -398,17 +398,7 @@ linux32)
 	;;
 linux-feature-testbed)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
-	export GIT_TEST_SPLIT_INDEX=yes
-	export GIT_TEST_FULL_IN_PACK_ARRAY=true
-	export GIT_TEST_OE_SIZE=10
-	export GIT_TEST_OE_DELTA_SIZE=5
-	export GIT_TEST_COMMIT_GRAPH=1
-	export GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=1
-	export GIT_TEST_MULTI_PACK_INDEX=1
-	export GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1
-	export GIT_TEST_NO_WRITE_REV_INDEX=1
-	export GIT_TEST_CHECKOUT_WORKERS=2
-	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
+	GIT_TEST_OPTS="$GIT_TEST_OPTS --feature-testbed"
 	;;
 linux-meson)
 	MESONFLAGS="$MESONFLAGS -Dcredential_helpers=libsecret,netrc"
diff --git a/t/README b/t/README
index fd7e8504b51..211bf78aed9 100644
--- a/t/README
+++ b/t/README
@@ -119,6 +119,11 @@ appropriately before running "make". Short options can be bundled, i.e.
 	This causes additional long-running tests to be run (where
 	available), for more exhaustive testing.
 
+--feature-testbed::
+	This causes tests to run with several `GIT_TEST` environment
+	variables set. The intent is to test Git with optional features
+	and non-default configuration.
+
 -r::
 --run=<test-selector>::
 	Run only the subset of tests indicated by
diff --git a/t/test-lib.sh b/t/test-lib.sh
index de566309861..8863bcac930 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -202,6 +202,14 @@ finalize_test_case_output () { :; }
 finalize_test_leak_output () { :; }
 finalize_test_output () { :; }
 
+set_default_env () {
+	if eval "test -z \"\${$1+set}\""
+	then
+		eval "$1=\$2"
+	fi
+	export "$1"
+}
+
 parse_option () {
 	local opt="$1"
 
@@ -212,6 +220,19 @@ parse_option () {
 		immediate=t ;;
 	-l|--l|--lo|--lon|--long|--long-|--long-t|--long-te|--long-tes|--long-test|--long-tests)
 		GIT_TEST_LONG=true; export GIT_TEST_LONG ;;
+	--feature-testbed)
+		set_default_env GIT_TEST_SPLIT_INDEX yes
+		set_default_env GIT_TEST_FULL_IN_PACK_ARRAY true
+		set_default_env GIT_TEST_OE_SIZE 10
+		set_default_env GIT_TEST_OE_DELTA_SIZE 5
+		set_default_env GIT_TEST_COMMIT_GRAPH 1
+		set_default_env GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS 1
+		set_default_env GIT_TEST_MULTI_PACK_INDEX 1
+		set_default_env GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL 1
+		set_default_env GIT_TEST_NO_WRITE_REV_INDEX 1
+		set_default_env GIT_TEST_CHECKOUT_WORKERS 2
+		set_default_env GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL 1
+		;;
 	-r)
 		mark_option_requires_arg "$opt" run_list
 		;;
diff --git a/t/unit-tests/unit-test.c b/t/unit-tests/unit-test.c
index 752fb38fb32..f4898353045 100644
--- a/t/unit-tests/unit-test.c
+++ b/t/unit-tests/unit-test.c
@@ -27,6 +27,7 @@ int cmd_main(int argc, const char **argv)
 		 * options understood by integration tests.
 		 */
 		OPT_NOOP_NOARG('d', "debug"),
+		OPT_NOOP_NOARG(0, "feature-testbed"),
 		OPT_NOOP_NOARG(0, "github-workflow-markup"),
 		OPT_NOOP_NOARG(0, "no-bin-wrappers"),
 		OPT_NOOP_ARG(0, "no-chain-lint"),

-- 
2.56.0.341.g393f52fd96.dirty

Re: [PATCH 8/8] t/test-lib: make feature-testbed job more accessible

[Phillip Wood]

Hi Patrick

On 27/10/2026 08:18, Patrick Steinhardt wrote:
> Our "feature-testbed" job sets up a bunch of GIT_TEST environment
> variables and then executes our tests. This is mostly intended as a
> testbed for features that aren't default-enabled, but that may
> eventually become so.
> 
> Due to the job being special it has a higher potential of failing even
> though a local test run succeeds. But running these tests locally with
> the same environment is somewhat painful, as the developer has to
> manually set all of these environment variables.
> 
> Introduce a new "--feature-testbed" toggle for our test suite that, when
> set, sets up exactly these environment variables. Migrate our CI to use
> this toggle so that we have a single source of truth, only.
> 
> Note that we only set these GIT_TEST variables in the case where they
> haven't already been configured. This serves two purposes:
> 
>    - The user can continue to manually override a subset of those
>      variables, if they desire.
> 
>    - Test scripts typically source "t/test-lib.sh" after they already
>      overrode GIT_TEST variables, and we don't want to discard that.

That all sounds sensible, the commit message could maybe flag that the 
"feature-testbed" also sets OPENSSL_SHA1_UNSAFE which 
"--feature-testbed" does not because it is only concerned with GIT_TEST_*.

> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index de566309861..8863bcac930 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -202,6 +202,14 @@ finalize_test_case_output () { :; }
>   finalize_test_leak_output () { :; }
>   finalize_test_output () { :; }
>   
> +set_default_env () {
> +	if eval "test -z \"\${$1+set}\""

This made me scratch my head for a couple of minutes, but I think it is 
correct

	set_default_env ABC 1

evaluates

	test -z "${ABC+set}"

to see if $ABC is unset.

Thanks

Phillip
> +	then
> +		eval "$1=\$2"
> +	fi
> +	export "$1"
> +}
> +
>   parse_option () {
>   	local opt="$1"
>   
> @@ -212,6 +220,19 @@ parse_option () {
>   		immediate=t ;;
>   	-l|--l|--lo|--lon|--long|--long-|--long-t|--long-te|--long-tes|--long-test|--long-tests)
>   		GIT_TEST_LONG=true; export GIT_TEST_LONG ;;
> +	--feature-testbed)
> +		set_default_env GIT_TEST_SPLIT_INDEX yes
> +		set_default_env GIT_TEST_FULL_IN_PACK_ARRAY true
> +		set_default_env GIT_TEST_OE_SIZE 10
> +		set_default_env GIT_TEST_OE_DELTA_SIZE 5
> +		set_default_env GIT_TEST_COMMIT_GRAPH 1
> +		set_default_env GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS 1
> +		set_default_env GIT_TEST_MULTI_PACK_INDEX 1
> +		set_default_env GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL 1
> +		set_default_env GIT_TEST_NO_WRITE_REV_INDEX 1
> +		set_default_env GIT_TEST_CHECKOUT_WORKERS 2
> +		set_default_env GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL 1
> +		;;
>   	-r)
>   		mark_option_requires_arg "$opt" run_list
>   		;;
> diff --git a/t/unit-tests/unit-test.c b/t/unit-tests/unit-test.c
> index 752fb38fb32..f4898353045 100644
> --- a/t/unit-tests/unit-test.c
> +++ b/t/unit-tests/unit-test.c
> @@ -27,6 +27,7 @@ int cmd_main(int argc, const char **argv)
>   		 * options understood by integration tests.
>   		 */
>   		OPT_NOOP_NOARG('d', "debug"),
> +		OPT_NOOP_NOARG(0, "feature-testbed"),
>   		OPT_NOOP_NOARG(0, "github-workflow-markup"),
>   		OPT_NOOP_NOARG(0, "no-bin-wrappers"),
>   		OPT_NOOP_ARG(0, "no-chain-lint"),
> 

Re: [PATCH 8/8] t/test-lib: make feature-testbed job more accessible

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

> That all sounds sensible, the commit message could maybe flag that the 
> "feature-testbed" also sets OPENSSL_SHA1_UNSAFE which 
> "--feature-testbed" does not because it is only concerned with GIT_TEST_*.
>
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index de566309861..8863bcac930 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -202,6 +202,14 @@ finalize_test_case_output () { :; }
>>   finalize_test_leak_output () { :; }
>>   finalize_test_output () { :; }
>>   
>> +set_default_env () {
>> +	if eval "test -z \"\${$1+set}\""
>
> This made me scratch my head for a couple of minutes, but I think it is 
> correct
>
> 	set_default_env ABC 1
>
> evaluates
>
> 	test -z "${ABC+set}"
>
> to see if $ABC is unset.
>
> Thanks
>
> Phillip
>> +	then
>> +		eval "$1=\$2"

This one may want to quote the right hand side to be more widely
portable, i.e., eval "$1=\"\$2\"" or something along that line.
POSIX Bourne shell does not require the right hand side 

    VARIABLE=$VAR

to be quoted, but CodingGuidelines has observed some buggy shells.
It may be better to be extra clear than sorry.

Re: [PATCH 8/8] t/test-lib: make feature-testbed job more accessible

[Patrick Steinhardt]

On Tue, Oct 27, 2026 at 01:59:31PM -0700, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
> > That all sounds sensible, the commit message could maybe flag that the 
> > "feature-testbed" also sets OPENSSL_SHA1_UNSAFE which 
> > "--feature-testbed" does not because it is only concerned with GIT_TEST_*.
> >
> >> diff --git a/t/test-lib.sh b/t/test-lib.sh
> >> index de566309861..8863bcac930 100644
> >> --- a/t/test-lib.sh
> >> +++ b/t/test-lib.sh
> >> @@ -202,6 +202,14 @@ finalize_test_case_output () { :; }
> >>   finalize_test_leak_output () { :; }
> >>   finalize_test_output () { :; }
> >>   
> >> +set_default_env () {
> >> +	if eval "test -z \"\${$1+set}\""
> >
> > This made me scratch my head for a couple of minutes, but I think it is 
> > correct
> >
> > 	set_default_env ABC 1
> >
> > evaluates
> >
> > 	test -z "${ABC+set}"
> >
> > to see if $ABC is unset.
> >
> > Thanks
> >
> > Phillip
> >> +	then
> >> +		eval "$1=\$2"
> 
> This one may want to quote the right hand side to be more widely
> portable, i.e., eval "$1=\"\$2\"" or something along that line.
> POSIX Bourne shell does not require the right hand side 
> 
>     VARIABLE=$VAR
> 
> to be quoted, but CodingGuidelines has observed some buggy shells.
> It may be better to be extra clear than sorry.

Fair. I've queued this change locally for now, but will wait for the
discussion to figure out whether I'll keep this change in the first
place.

Thanks!

Patrick

Re: [PATCH 8/8] t/test-lib: make feature-testbed job more accessible

[Jeff King]

On Tue, Oct 27, 2026 at 09:18:28AM +0100, Patrick Steinhardt wrote:

> Due to the job being special it has a higher potential of failing even
> though a local test run succeeds. But running these tests locally with
> the same environment is somewhat painful, as the developer has to
> manually set all of these environment variables.

OK. I've usually just cut-and-paste them, as my first step is figuring
out which is the culprit anyway. My biggest question was: what if the
culprit is a build flag, and indeed, we leave the one build flag here:

>  linux-feature-testbed)
>  	export OPENSSL_SHA1_UNSAFE=YesPlease
> -	export GIT_TEST_SPLIT_INDEX=yes
> -	export GIT_TEST_FULL_IN_PACK_ARRAY=true
> -	export GIT_TEST_OE_SIZE=10
> -	export GIT_TEST_OE_DELTA_SIZE=5
> -	export GIT_TEST_COMMIT_GRAPH=1
> -	export GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=1
> -	export GIT_TEST_MULTI_PACK_INDEX=1
> -	export GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1
> -	export GIT_TEST_NO_WRITE_REV_INDEX=1
> -	export GIT_TEST_CHECKOUT_WORKERS=2
> -	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
> +	GIT_TEST_OPTS="$GIT_TEST_OPTS --feature-testbed"

which makes this feature only half-work (well, 11/12 if we want to be
pedantic).

IMHO this whole thing isn't really worth the complexity, but if we are
going to do it, should it be "make FEATURE_TESTBED=1", and then that
enables the right build knobs, and test-lib.sh respects that variable
coming from BUILD-OPTIONS rather than the command line?

-Peff

Re: [PATCH 8/8] t/test-lib: make feature-testbed job more accessible

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Oct 27, 2026 at 09:18:28AM +0100, Patrick Steinhardt wrote:
>
>> Due to the job being special it has a higher potential of failing even
>> though a local test run succeeds. But running these tests locally with
>> the same environment is somewhat painful, as the developer has to
>> manually set all of these environment variables.
>
> OK. I've usually just cut-and-paste them, as my first step is figuring
> out which is the culprit anyway. My biggest question was: what if the
> culprit is a build flag, and indeed, we leave the one build flag here:
>
>>  linux-feature-testbed)
>>  	export OPENSSL_SHA1_UNSAFE=YesPlease
>> -	export GIT_TEST_SPLIT_INDEX=yes
>> -	export GIT_TEST_FULL_IN_PACK_ARRAY=true
>> -	export GIT_TEST_OE_SIZE=10
>> -	export GIT_TEST_OE_DELTA_SIZE=5
>> -	export GIT_TEST_COMMIT_GRAPH=1
>> -	export GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=1
>> -	export GIT_TEST_MULTI_PACK_INDEX=1
>> -	export GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1
>> -	export GIT_TEST_NO_WRITE_REV_INDEX=1
>> -	export GIT_TEST_CHECKOUT_WORKERS=2
>> -	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
>> +	GIT_TEST_OPTS="$GIT_TEST_OPTS --feature-testbed"
>
> which makes this feature only half-work (well, 11/12 if we want to be
> pedantic).
>
> IMHO this whole thing isn't really worth the complexity, but if we are
> going to do it, should it be "make FEATURE_TESTBED=1", and then that
> enables the right build knobs, and test-lib.sh respects that variable
> coming from BUILD-OPTIONS rather than the command line?

Yes, I love the simplicity of that approach.

Re: [PATCH 8/8] t/test-lib: make feature-testbed job more accessible

[Patrick Steinhardt]

On Tue, Oct 27, 2026 at 05:23:49PM -0400, Jeff King wrote:
> On Tue, Oct 27, 2026 at 09:18:28AM +0100, Patrick Steinhardt wrote:
> 
> > Due to the job being special it has a higher potential of failing even
> > though a local test run succeeds. But running these tests locally with
> > the same environment is somewhat painful, as the developer has to
> > manually set all of these environment variables.
> 
> OK. I've usually just cut-and-paste them, as my first step is figuring
> out which is the culprit anyway. My biggest question was: what if the
> culprit is a build flag, and indeed, we leave the one build flag here:
> 
> >  linux-feature-testbed)
> >  	export OPENSSL_SHA1_UNSAFE=YesPlease
> > -	export GIT_TEST_SPLIT_INDEX=yes
> > -	export GIT_TEST_FULL_IN_PACK_ARRAY=true
> > -	export GIT_TEST_OE_SIZE=10
> > -	export GIT_TEST_OE_DELTA_SIZE=5
> > -	export GIT_TEST_COMMIT_GRAPH=1
> > -	export GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=1
> > -	export GIT_TEST_MULTI_PACK_INDEX=1
> > -	export GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL=1
> > -	export GIT_TEST_NO_WRITE_REV_INDEX=1
> > -	export GIT_TEST_CHECKOUT_WORKERS=2
> > -	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
> > +	GIT_TEST_OPTS="$GIT_TEST_OPTS --feature-testbed"
> 
> which makes this feature only half-work (well, 11/12 if we want to be
> pedantic).
> 
> IMHO this whole thing isn't really worth the complexity, but if we are
> going to do it, should it be "make FEATURE_TESTBED=1", and then that
> enables the right build knobs, and test-lib.sh respects that variable
> coming from BUILD-OPTIONS rather than the command line?

I dunno. Until now I've never had the case myself where the issue is
because of the above build flag, test errors were only ever caused by
one of the GIT_TEST variables. So what I typically want is to toggle
between GIT_TEST- and non-GIT_TEST test runs, and ideally without having
to recompile everything. And more often than not I want to only do this
for a single test file, only.

So I'm not much of a fan of moving this into our BUILD-OPTIONS, as it
would kind of defeat my own use case for it. I'm thus inclined to either
leave this as-is, or drop the patch altogether. I don't terribly mind
either of those outcomes.

Patrick

Re: [PATCH 8/8] t/test-lib: make feature-testbed job more accessible

[Phillip Wood]

On 27/10/2026 21:23, Jeff King wrote:
> 
> IMHO this whole thing isn't really worth the complexity, but if we are
> going to do it, should it be "make FEATURE_TESTBED=1", and then that
> enables the right build knobs, and test-lib.sh respects that variable
> coming from BUILD-OPTIONS rather than the command line?

If we want to be able to recreate the CI job locally then I agree a 
Makefile flag is a better solution. I seem to remember Ævar trying to 
add Makefile targets for some of the CI jobs so they could be run locally.

Thanks

Phillip

Re: [PATCH 0/8] ci: consolidate test variables

[Phillip Wood]

Hi Patrick

On 27/10/2026 08:18, Patrick Steinhardt wrote:
> Hi,
> 
> this patch series consolidates our test variables as a follow up on the
> discussions in [1].
> 
> The series is built on top of 37b3475fb53 (The 9th batch, 2026-10-25).

I looked at the diff for the whole series rather than the individual 
patches and it looks nice. The changes to move all the job dependent 
variable assignments into ci/lib.sh and the removal of the 
linux-reftable-sha256 job while maintaining our coverage are very 
welcome. It probably makes sense to disable rust for the sanitizer job 
which is aimed at checking our C code, though if we end up with more 
unsafe rust in the future maybe the balance will shift?

Thanks

Phillip

> 
> Thanks!
> 
> Patrick
> 
> [1]: <20261008-pks-ci-housekeeping-v1-0-baf015c589c0@pks.im>
> 
> ---
> Patrick Steinhardt (8):
>        ci: consolidate setup of test environment
>        ci/lib: always set GIT_TEST_USE_SET_E on Linux jobs
>        ci/lib: deduplicate test variables by pattern matching
>        ci/lib: merge switches for specific job names
>        t: honor default ref storage format
>        ci/lib: add another NO_RUST build using glibc
>        ci: don't override initial branch name in testbed job
>        t/test-lib: make feature-testbed job more accessible
> 
>   .github/workflows/main.yml |  3 ---
>   .gitlab-ci.yml             |  3 ---
>   ci/lib.sh                  | 34 ++++++++++++++++++++++++++++++++--
>   ci/run-build-and-tests.sh  | 44 --------------------------------------------
>   t/README                   |  5 +++++
>   t/test-lib-functions.sh    |  2 +-
>   t/test-lib.sh              | 25 ++++++++++++++++++++++++-
>   t/unit-tests/unit-test.c   |  1 +
>   8 files changed, 63 insertions(+), 54 deletions(-)
> 
> 
> ---
> base-commit: 37b3475fb530c14109211faca33716a173db61ed
> change-id: 20261016-b4-pks-ci-test-vars-consolidation-8d0c6a53ca28

Re: [PATCH 0/8] ci: consolidate test variables

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

> Hi Patrick
>
> On 27/10/2026 08:18, Patrick Steinhardt wrote:
>> Hi,
>> 
>> this patch series consolidates our test variables as a follow up on the
>> discussions in [1].
>> 
>> The series is built on top of 37b3475fb53 (The 9th batch, 2026-10-25).
>
> I looked at the diff for the whole series rather than the individual 
> patches and it looks nice. The changes to move all the job dependent 
> variable assignments into ci/lib.sh and the removal of the 
> linux-reftable-sha256 job while maintaining our coverage are very 
> welcome. It probably makes sense to disable rust for the sanitizer job 
> which is aimed at checking our C code, though if we end up with more 
> unsafe rust in the future maybe the balance will shift?
>
> Thanks
>
> Phillip

Thanks for writing and reviewing.

Re: [PATCH 0/8] ci: consolidate test variables

[Jeff King]

On Tue, Oct 27, 2026 at 09:18:20AM +0100, Patrick Steinhardt wrote:

> this patch series consolidates our test variables as a follow up on the
> discussions in [1].

Thanks for following up. 1-7 seem obviously good to me. I'm lukewarm on
the final patch (and left a comment there), but if you really love it, I
can live with it. :)

-Peff

Re: [PATCH 0/8] ci: consolidate test variables

[Toon Claes]

Jeff King <peff@peff.net> writes:

> On Tue, Oct 27, 2026 at 09:18:20AM +0100, Patrick Steinhardt wrote:
>
>> this patch series consolidates our test variables as a follow up on the
>> discussions in [1].
>
> Thanks for following up. 1-7 seem obviously good to me.

Yes, 1-7 look good and are pretty much noncontroversial.

> I'm lukewarm on the final patch (and left a comment there), but if you
> really love it, I can live with it. :)

I understand the stance of both of you. To be honest, I don't really
have an opinion. The cleanest fix probably would be to split the build
flags from test flags, because it's a mix now and Peff prefers to have
them all fixed, while Patrick likes to change them run-by-run. Although,
that would probably lead this patch series beyond their intentions.

-- 
Laters,
Toon