mailing list mirror (one of many)
 help / Atom feed
From: Stefan Beller <>
To: Ævar Arnfjörð Bjarmason <>
Cc: Lars Schneider <>,
	Junio C Hamano <>,
	Git Mailing List <>
Subject: Re: [PATCH] test-lib: add ability to cap the runtime of tests
Date: Mon, 5 Jun 2017 12:03:00 -0700
Message-ID: <> (raw)
In-Reply-To: <>

> That's never going to be a problem on a less beefy machine with
> --state=slow,save, since the 30s test is going to be long over by the
> time the rest of the tests run.
> Cutting down on these long tail tests allows me to e.g. replace this:
>     git rebase -i --exec '(make -j56 all && cd t && prove -j56 <some
> limited glob>)'
> With a glob that runs the entire test suite, with the rebase only
> taking marginally longer in most cases while getting much better test
> coverage than I'd otherwise bother with.

I wonder if this functionality is rather best put into prove?

Also prove doesn't know which tests are "interesting",
e.g. if you were working on interactive rebase, then you really
want the longest test to be run in full?

And this "judge by time, not by interest" doesn't bode well with

I have a non-beefy machine such that this particular problem
doesn't apply to me, but instead the whole test suite takes just
long to run.

For that I reduce testing intelligently, i.e. I know where I am
working on, so I run only some given tests (in case of
submodules I'd go with "prove t74*") which would also fix
your issue IIUC?

  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-03 22:13 Ævar Arnfjörð Bjarmason
2017-06-04  0:31 ` Junio C Hamano
2017-06-04  7:29   ` Ævar Arnfjörð Bjarmason
2017-06-05  1:55     ` Junio C Hamano
2017-06-05  5:48       ` Christian Couder
2017-06-05 18:56         ` Stefan Beller
2017-06-07 10:24       ` Jeff King
2017-06-08  0:59         ` Ramsay Jones
2017-06-05 13:17     ` Lars Schneider
2017-06-05 18:15       ` Ævar Arnfjörð Bjarmason
2017-06-05 19:03         ` Stefan Beller [this message]
2017-06-05 20:37           ` Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publically 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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox