Jeffrey Walton [off-list ref] writes:
On Thu, Mar 25, 2021 at 3:57 AM Jeffrey Walton [off-list ref] wrote:
quoted
...
Cancel this. It just tested OK a second time around.
Which may indicate that the test is flakey (e.g. timing dependent,
only reproducing when two commands in the test sequence are executed
across a second boundary, or something like that), which may be
worth fixing.
On Thu, Mar 25, 2021 at 05:45:52PM -0700, Junio C Hamano wrote:
Jeffrey Walton [off-list ref] writes:
quoted
On Thu, Mar 25, 2021 at 3:57 AM Jeffrey Walton [off-list ref] wrote:
quoted
...
Cancel this. It just tested OK a second time around.
Which may indicate that the test is flakey (e.g. timing dependent,
only reproducing when two commands in the test sequence are executed
across a second boundary, or something like that), which may be
worth fixing.
I can't get it to fail with "./t4202-log.sh --stress", which usually
turns up races or other flakes. But perhaps there is something unique
about your (Jeff) system that triggers it.
It's hard to tell more without any verbose output from the failing test.
In general, failure reports accompanied by the output (or at least the
end of the output) of "./t4202-log.sh -v -i -x" will be a lot more
useful.
If you're seeing intermittent failures from a larger "make test",
consider putting "--verbose-log -x" into GIT_TEST_OPTS (either on the
make command-line, or in config.mak). The logs will be in
t/test-results/t4202-log.out, etc.
-Peff