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

[Jeff King <peff@peff.net>]

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