From: Junio C Hamano <gitster@pobox.com>
To: Britton Kerin <britton.kerin@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: script to pre-build all commits in a git-bisect, and use them during testing
Date: Wed, 21 Feb 2024 15:20:22 -0800 [thread overview]
Message-ID: <xmqqo7c9l809.fsf@gitster.g> (raw)
In-Reply-To: <CAC4O8c-tgDQ42upWorMi3Cw+KdPoHT2YxvZEirt_dtjQXreXAw@mail.gmail.com> (Britton Kerin's message of "Wed, 21 Feb 2024 13:57:55 -0900")
Britton Kerin <britton.kerin@gmail.com> writes:
> Problem: it's annoying to have to build each commit when
> git-bisect'ing for something that isn't being tested automatically (so
> no git bisect run).
>
> Solution: https://github.com/bkerin/git-batch-bisect
So, because "git bisect run" would not be usable for whatever reason
to run a "build and then test" from the command line, you would
build all revisions using
git batch-bisect runinall 'autoreconf --install && ./configure && make'
before starting to test any revision, and then after building
everything, you would do:
git batch-bisect runincurrent ./test_program
git batch-bisect good
git batch-bisect runincurrent ./test_program
git batch-bisect bad
...
where ./test_program cannot signal if it is good or bad mechanically
(e.g., by exiting with non-zero status for failure) but the testers
need to judge the good/bad manually before they can say "git
batch-bisect good/bad", I presume.
It's an interesting workaround for a test program that cannot be
automated. You are willing to waste CPU cycles and diskspace to
build upfront and hold the build products for all N revisions in the
range, where with bisection you would have to build far fewer
revisions (which is the point of bisection), to optimize for
developer/tester latency, which tends to be more expensive. The
trade-off may make good sense.
prev parent reply other threads:[~2024-02-21 23:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-21 22:57 script to pre-build all commits in a git-bisect, and use them during testing Britton Kerin
2024-02-21 23:20 ` Junio C Hamano [this message]
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=xmqqo7c9l809.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=britton.kerin@gmail.com \
--cc=git@vger.kernel.org \
/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.