From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Subject: Re: [PATCH 8/8] t/test-lib: make feature-testbed job more accessible
Date: Wed, 28 Oct 2026 08:39:41 +0100 [thread overview]
Message-ID: <auGmvTuD1NcFIw37@pks.im> (raw)
In-Reply-To: <20261027212349.GA774120@coredump.intra.peff.net>
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
next prev parent reply other threads:[~2026-10-28 7:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 8:18 [PATCH 0/8] ci: consolidate test variables Patrick Steinhardt
2026-10-27 8:18 ` [PATCH 1/8] ci: consolidate setup of test environment Patrick Steinhardt
2026-10-27 8:18 ` [PATCH 2/8] ci/lib: always set GIT_TEST_USE_SET_E on Linux jobs Patrick Steinhardt
2026-10-27 8:18 ` [PATCH 3/8] ci/lib: deduplicate test variables by pattern matching Patrick Steinhardt
2026-10-27 8:18 ` [PATCH 4/8] ci/lib: merge switches for specific job names Patrick Steinhardt
2026-10-27 8:18 ` [PATCH 5/8] t: honor default ref storage format Patrick Steinhardt
2026-10-27 8:18 ` [PATCH 6/8] ci/lib: add another NO_RUST build using glibc Patrick Steinhardt
2026-10-27 8:18 ` [PATCH 7/8] ci: don't override initial branch name in testbed job Patrick Steinhardt
2026-10-27 8:18 ` [PATCH 8/8] t/test-lib: make feature-testbed job more accessible Patrick Steinhardt
2026-10-27 14:53 ` Phillip Wood
2026-10-27 20:59 ` Junio C Hamano
2026-10-28 7:41 ` Patrick Steinhardt
2026-10-27 21:23 ` Jeff King
2026-10-27 21:47 ` Junio C Hamano
2026-10-28 7:39 ` Patrick Steinhardt [this message]
2026-10-28 14:33 ` Phillip Wood
2026-10-27 15:00 ` [PATCH 0/8] ci: consolidate test variables Phillip Wood
2026-10-27 20:59 ` Junio C Hamano
2026-10-27 21:24 ` Jeff King
2026-10-28 14:40 ` Toon Claes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=auGmvTuD1NcFIw37@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kaartic.sivaraam@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.