From: Josh Steadmon <steadmon@google•com>
To: Johannes Schindelin <Johannes.Schindelin@gmx•de>
Cc: Jeff King <peff@peff•net>,
Johannes Schindelin via GitGitGadget <gitgitgadget@gmail•com>,
Phillip Wood <phillip.wood@dunelm•org.uk>,
git@vger•kernel.org
Subject: Re: Feasibility of folding `unit-tests` into `make test`, was Re: [PATCH] ci: avoid running the test suite _twice_
Date: Thu, 4 Jan 2024 15:54:11 -0800 [thread overview]
Message-ID: <ZZdFI8KXsVaZuQiY@google.com> (raw)
In-Reply-To: <850ea42c-f103-68d5-896b-9120e2628686@gmx.de>
On 2023.11.16 09:42, Johannes Schindelin wrote:
> Hi Josh,
>
> On Wed, 15 Nov 2023, Josh Steadmon wrote:
[snip]
> > If I was forced to pick a way to get everything under one process, I'd
> > lean towards autogenerating individual shell script wrappers for each
> > unit test. But I'm open to discussion, especially if people have other
> > approaches I haven't thought of.
>
> One alternative would be to avoid running the unit tests via `prove` in
> the first place.
>
> For example, we could use the helper from be5d88e11280 (test-tool
> run-command: learn to run (parts of) the testsuite, 2019-10-04) [*1*]. It
> would probably need a few improvements, but certainly no wizardry nor
> witchcraft would be required. It would also help on Windows, where running
> a simple test helper written in C is vastly faster than running a complex
> Perl script (which `prove` is).
>
> Ciao,
> Johannes
>
> Footnote *1*: I had always wanted to improve that test helper to the point
> where it could replace our use of `prove`, at least on Windows. It seems,
> however, that as of 4c2c38e800f3 (ci: modification of main.yml to use
> cmake for vs-build job, 2020-06-26) we do not use the helper at all
> anymore. Hopefully it can still be useful. 🤞
Sorry for the silence on this topic; the holidays plus some family
illnesses kept me away from the list for a while. I have a working
implementation of this. I plan on cleaning it up a bit and sending it as
an RFC series either tomorrow or next week. Thank you for the
suggestion!
next prev parent reply other threads:[~2024-01-04 23:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 17:00 [PATCH] ci: avoid running the test suite _twice_ Johannes Schindelin via GitGitGadget
2023-11-13 18:49 ` Jeff King
2023-11-13 23:55 ` Junio C Hamano
2023-11-14 21:29 ` Josh Steadmon
2023-11-15 1:00 ` Junio C Hamano
2023-11-15 21:28 ` Josh Steadmon
2023-11-16 8:42 ` Feasibility of folding `unit-tests` into `make test`, was " Johannes Schindelin
2023-11-16 15:05 ` phillip.wood123
2024-01-04 23:54 ` Josh Steadmon [this message]
2023-11-16 20:02 ` Jeff King
2023-11-13 20:25 ` [PATCH v2] " Johannes Schindelin via GitGitGadget
2023-11-14 0:24 ` Junio C Hamano
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=ZZdFI8KXsVaZuQiY@google.com \
--to=steadmon@google$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=peff@peff$(echo .)net \
--cc=phillip.wood@dunelm$(echo .)org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox