git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/1] Makefile: add prove and coverage-prove targets

From
SZEDER Gábor <szeder.dev@gmail.com>
Date
Jan 29, 2019, 21:58 UTC
Message-ID
<20190129215827.GF13764@szeder.dev>
In-Reply-To
<795f816d-d870-068a-5595-2fe617339a79@gmail.com>
On Tue, Jan 29, 2019 at 03:49:58PM -0500, Derrick Stolee wrote:
Show 29 quoted lines
> On 1/29/2019 1:10 PM, Derrick Stolee wrote:
> > On 1/29/2019 12:34 PM, SZEDER Gábor wrote:
> >> On Tue, Jan 29, 2019 at 04:58:27PM +0100, SZEDER Gábor wrote:
> >> And in the related email discussion [1]:
> >>
> >>   But even though the docs claim it [-j<N>] should be possible,
> >>   I've been getting "random" test failures when compiled with coverage
> >>   support, that went away with -j1.  So the tests still run with -j1, as
> >>   with the first version of the series.
> >>
> >> So it doesn't seem to be that bad after all, because it's not
> >> "completely breaks" but "random test failures".  Still far from ideal,
> >> but the original coverage patch is just about 3 weeks short of a
> >> decade old, so maybe things have improved since then, and it'd be
> >> worth a try to leave GIT_PROVE_OPTS as is and see what happens.
> > 
> > It would certainly be nice if the build time could be reduced through
> > parallel test runs. I've kicked off a build using GIT_PROVE_OPTS="-j12"
> > to see what happens.
> 
> I did get a failed test with this run:
> 
> t0025-crlf-renormalize.sh                 (Wstat: 256 Tests: 3 Failed: 1)
>   Failed test:  2
>   Non-zero exit status: 1
> 
> This was on the 'jch' branch, and an equivalent build with sequential
> execution did not have this failure. That's flaky enough for me to stick
> to sequential runs.

That failure is not coverage-related, but as it turned out 9e5da3d055 (add: use separate ADD_CACHE_RENORMALIZE flag, 2019-01-17) made t0025 rather flaky:

  https://public-inbox.org/git/20190129213533.GE13764@szeder.dev/

When reading those old commit messages and discussions in the afternoon, I was wondering what "random test failures" actually meant, since it was not stated explicitly that it was coverage-related. For all we know it could have been "general" test flakiness that happened to manifest under the higher load of a parallel test run.

Previous: Derrick StoleeNext: Jeff King
Message 10 of 22 in “Makefile: add prove and coverage-prove targets”
  1. 0/1 Makefile: add prove and coverage-prove targetsDerrick Stolee via GitGitGadget, Jan 29, 2019
  2. 1/1 Makefile: add prove and coverage-prove targetsDerrick Stolee via GitGitGadget, Jan 29, 2019
  3. Johannes SchindelinJan 29, 2019
  4. SZEDER GáborJan 29, 2019
  5. Derrick StoleeJan 29, 2019
  6. Jeff KingJan 29, 2019
  7. SZEDER GáborJan 29, 2019
  8. Derrick StoleeJan 29, 2019
  9. Derrick StoleeJan 29, 2019
  10. SZEDER GáborJan 29, 2019
  11. Jeff KingJan 29, 2019
  12. Derrick StoleeJan 29, 2019
  13. Jeff KingJan 29, 2019
  14. Ævar Arnfjörð BjarmasonJan 29, 2019
  15. Jeff KingJan 29, 2019
  16. Johannes SchindelinJan 30, 2019
  17. Ævar Arnfjörð BjarmasonJan 30, 2019
  18. Johannes SchindelinJan 30, 2019
  19. Ævar Arnfjörð BjarmasonJan 30, 2019
  20. Johannes SchindelinJan 31, 2019
  21. 0/1 Makefile: add prove and coverage-prove targetsDerrick Stolee via GitGitGadget, Jan 29, 2019
  22. 1/1 Makefile: add coverage-prove targetDerrick Stolee via GitGitGadget, Jan 29, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.