| Message ID | 20210609170520.67014-1-felipe.contreras@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | test: fix for TEST_OUTPUT_DIRECTORY | expand |
On Wed, Jun 09, 2021 at 12:05:20PM -0500, Felipe Contreras wrote: > The test_atexit unit test relies on the specific location of the > generated files. > > When TEST_OUTPUT_DIRECTORY is unset, _run_sub_test_lib_test_common sets > it to pwd, which is two levels under the pwd of the parent unit test, > and the parent can find the generated files just fine. > > But when TEST_OUTPUT_DIRECTORY is set, it's stored in GIT-BUILD-OPTIONS, > and even though _run_sub_test_lib_test_common correctly overrides it, > when the child script is run, it sources GIT-BUILD-OPTIONS, and > TEST_OUTPUT_DIRECTORY is overridden. > > Effectively both the parent and child scripts output to the same > directory. > > make TEST_OUTPUT_DIRECTORY=/tmp/foobar GIT-BUILD-OPTIONS && > make -C t t0000-basic.sh I agree things are broken when TEST_OUTPUT_DIRECTORY is set. We pollute /tmp/foobar in that case with trash directories, as well as its test-results/ directory with subtest results (mostly "counts" files). > On the other hand we could follow the alternate path suggested in > 6883047071 (t0000: set TEST_OUTPUT_DIRECTORY for sub-tests, 2013-12-28): > pass the --root parameter to the child scripts. > > The alternate solution works, so let's do that instead. Unfortunately, this isn't a complete solution. Using --root fixes the trash directories, but we still pollute test-results. No tests in t0000 rely on that, but it's still the wrong thing to be doing. That's true before your patch, as well, though it does make things slightly worse when TEST_OUTPUT_DIRECTORY isn't set (before in that case everything worked perfectly, and now it pollutes test-results/, too). I think solving the whole issue would require a mechanism for passing TEST_OUTPUT_DIRECTORY in a way that can't be overridden (whether in an environment variable or the command-line). Alternatively, it would be nice if GIT-BUILD-OPTIONS didn't override the environment. That would fix this problem, prevent similar ones in the future, and I think would do the right thing if a caller decided to do something like: PERL_PATH=/some/other/perl ./t1234-foo.sh We might be able to write GIT-BUILD-OPTIONS to use ${foo:=} default-value expansion, but I'm not sure if there are any non-shell readers of the file (I don't see any, but I feel like we've run afoul of this before). Something like this might work: diff --git a/t/test-lib.sh b/t/test-lib.sh index adaf03543e..731dd41d9c 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -54,7 +54,10 @@ then echo >&2 'error: GIT-BUILD-OPTIONS missing (has Git been built?).' exit 1 fi +# let our env take precedence over build options +current_env=$(set) . "$GIT_BUILD_DIR"/GIT-BUILD-OPTIONS +eval "$current_env" export PERL_PATH SHELL_PATH # Disallow the use of abbreviated options in the test suite by default but I think more fixes are required for $TEST_OUTPUT_DIRECTORY, since we set it so early in the script (before we read GIT-BUILD-OPTIONS, so at that point we have no idea if it came from the environment or our default settings). -Peff
Jeff King wrote: > On Wed, Jun 09, 2021 at 12:05:20PM -0500, Felipe Contreras wrote: > > > The test_atexit unit test relies on the specific location of the > > generated files. > > > > When TEST_OUTPUT_DIRECTORY is unset, _run_sub_test_lib_test_common sets > > it to pwd, which is two levels under the pwd of the parent unit test, > > and the parent can find the generated files just fine. > > > > But when TEST_OUTPUT_DIRECTORY is set, it's stored in GIT-BUILD-OPTIONS, > > and even though _run_sub_test_lib_test_common correctly overrides it, > > when the child script is run, it sources GIT-BUILD-OPTIONS, and > > TEST_OUTPUT_DIRECTORY is overridden. > > > > Effectively both the parent and child scripts output to the same > > directory. > > > > make TEST_OUTPUT_DIRECTORY=/tmp/foobar GIT-BUILD-OPTIONS && > > make -C t t0000-basic.sh > > I agree things are broken when TEST_OUTPUT_DIRECTORY is set. We pollute > /tmp/foobar in that case with trash directories, as well as its > test-results/ directory with subtest results (mostly "counts" files). > > > On the other hand we could follow the alternate path suggested in > > 6883047071 (t0000: set TEST_OUTPUT_DIRECTORY for sub-tests, 2013-12-28): > > pass the --root parameter to the child scripts. > > > > The alternate solution works, so let's do that instead. > > Unfortunately, this isn't a complete solution. Software will never be perfect. We don't need to wait for a perfect solution, all we need is something better than the current siuation. > Using --root fixes the > trash directories, but we still pollute test-results. No tests in t0000 > rely on that, but it's still the wrong thing to be doing. > > That's true before your patch, as well, though it does make things > slightly worse when TEST_OUTPUT_DIRECTORY isn't set (before in that case > everything worked perfectly, and now it pollutes test-results/, too). True. > I think solving the whole issue would require a mechanism for passing > TEST_OUTPUT_DIRECTORY in a way that can't be overridden (whether in an > environment variable or the command-line). Why do we even have TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS? Looking for a reason there's 2d14e13c56 (test output: respect $TEST_OUTPUT_DIRECTORY, 2013-04-29), there it says it's for valgrind/analyze.sh. I don't know who uses that script, or how. There's no documentaion, nothing on the mailing list, and nothing found on Google. I think whomever usses that script *and* TEST_OUTPUT_DIRECTORY, can simply do `TEST_OUTPUT_DIRECTORY=foo valgrind/analyze.sh`. So maybe: diff --git a/Makefile b/Makefile index c3565fc0f8..2e25489569 100644 --- a/Makefile +++ b/Makefile @@ -2790,9 +2790,6 @@ GIT-BUILD-OPTIONS: FORCE @echo PAGER_ENV=\''$(subst ','\'',$(subst ','\'',$(PAGER_ENV)))'\' >>$@+ @echo DC_SHA1=\''$(subst ','\'',$(subst ','\'',$(DC_SHA1)))'\' >>$@+ @echo X=\'$(X)\' >>$@+ -ifdef TEST_OUTPUT_DIRECTORY - @echo TEST_OUTPUT_DIRECTORY=\''$(subst ','\'',$(subst ','\'',$(TEST_OUTPUT_DIRECTORY)))'\' >>$@+ -endif ifdef GIT_TEST_OPTS @echo GIT_TEST_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_OPTS)))'\' >>$@+ endif diff --git a/t/valgrind/analyze.sh b/t/valgrind/analyze.sh index 2ffc80f721..378d0a8daa 100755 --- a/t/valgrind/analyze.sh +++ b/t/valgrind/analyze.sh @@ -1,8 +1,5 @@ #!/bin/sh -# Get TEST_OUTPUT_DIRECTORY from GIT-BUILD-OPTIONS if it's there... -. "$(dirname "$0")/../../GIT-BUILD-OPTIONS" -# ... otherwise set it to the default value. : ${TEST_OUTPUT_DIRECTORY=$(dirname "$0")/..} output=
On Sun, Jun 13, 2021 at 10:44:10AM -0500, Felipe Contreras wrote: > > Unfortunately, this isn't a complete solution. > > Software will never be perfect. > > We don't need to wait for a perfect solution, all we need is something > better than the current siuation. Sure, but if you don't fully understand the situation (e.g., that --root and TEST_OUTPUT_DIRECTORY are not equivalent), then you may end up revisiting the incomplete fix later, or even making things worse (as this patch did). > > I think solving the whole issue would require a mechanism for passing > > TEST_OUTPUT_DIRECTORY in a way that can't be overridden (whether in an > > environment variable or the command-line). > > Why do we even have TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS? Looking > for a reason there's 2d14e13c56 (test output: respect > $TEST_OUTPUT_DIRECTORY, 2013-04-29), there it says it's for > valgrind/analyze.sh. > > I don't know who uses that script, or how. There's no documentaion, > nothing on the mailing list, and nothing found on Google. Perhaps 268fac6919 (Add a script to coalesce the valgrind outputs, 2009-02-04) is enlightening. I don't know if anybody still uses it these days, though. I suspect it's outlived its usefulness, in that we would typically not have any valgrind errors at all (so coalescing them is not that interesting). Possibly folks investigating leak-checking via valgrind could find it useful, but even there I think LSan is a much better path forward. > So maybe: > > diff --git a/Makefile b/Makefile > index c3565fc0f8..2e25489569 100644 > --- a/Makefile > +++ b/Makefile > @@ -2790,9 +2790,6 @@ GIT-BUILD-OPTIONS: FORCE > @echo PAGER_ENV=\''$(subst ','\'',$(subst ','\'',$(PAGER_ENV)))'\' >>$@+ > @echo DC_SHA1=\''$(subst ','\'',$(subst ','\'',$(DC_SHA1)))'\' >>$@+ > @echo X=\'$(X)\' >>$@+ > -ifdef TEST_OUTPUT_DIRECTORY > - @echo TEST_OUTPUT_DIRECTORY=\''$(subst ','\'',$(subst ','\'',$(TEST_OUTPUT_DIRECTORY)))'\' >>$@+ > -endif I don't personally have any problem with that. It does mean that "make t1234-foo.sh" will behave differently than "./t1234-foo.sh", but that is already true if you set GIT_TEST_OPTS. -Peff
Jeff King wrote: > On Sun, Jun 13, 2021 at 10:44:10AM -0500, Felipe Contreras wrote: > > > > Unfortunately, this isn't a complete solution. > > > > Software will never be perfect. > > > > We don't need to wait for a perfect solution, all we need is something > > better than the current siuation. > > Sure, but if you don't fully understand the situation (e.g., that --root > and TEST_OUTPUT_DIRECTORY are not equivalent), then you may end up > revisiting the incomplete fix later, The fact that you may end up revisiting a solution is a fact for *all* changes (including 2d14e13c56 (test output: respect $TEST_OUTPUT_DIRECTORY, 2013-04-29)). > or even making things worse (as this patch did). I think breaking the test suite is objectively worse than having a few extra files in the output directory, but to each his own. > > > I think solving the whole issue would require a mechanism for passing > > > TEST_OUTPUT_DIRECTORY in a way that can't be overridden (whether in an > > > environment variable or the command-line). > > > > Why do we even have TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS? Looking > > for a reason there's 2d14e13c56 (test output: respect > > $TEST_OUTPUT_DIRECTORY, 2013-04-29), there it says it's for > > valgrind/analyze.sh. > > > > I don't know who uses that script, or how. There's no documentaion, > > nothing on the mailing list, and nothing found on Google. > > Perhaps 268fac6919 (Add a script to coalesce the valgrind outputs, > 2009-02-04) is enlightening. That makes it clearer. > I don't know if anybody still uses it these days, though. I suspect it's > outlived its usefulness, in that we would typically not have any > valgrind errors at all (so coalescing them is not that interesting). > > Possibly folks investigating leak-checking via valgrind could find it > useful, but even there I think LSan is a much better path forward. Yeah, but even if they do run this tool, they can set TEST_OUTPUT_DIRECTORY manually. The needs of the few should not otweight needs of the many. > > So maybe: > > > > diff --git a/Makefile b/Makefile > > index c3565fc0f8..2e25489569 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -2790,9 +2790,6 @@ GIT-BUILD-OPTIONS: FORCE > > @echo PAGER_ENV=\''$(subst ','\'',$(subst ','\'',$(PAGER_ENV)))'\' >>$@+ > > @echo DC_SHA1=\''$(subst ','\'',$(subst ','\'',$(DC_SHA1)))'\' >>$@+ > > @echo X=\'$(X)\' >>$@+ > > -ifdef TEST_OUTPUT_DIRECTORY > > - @echo TEST_OUTPUT_DIRECTORY=\''$(subst ','\'',$(subst ','\'',$(TEST_OUTPUT_DIRECTORY)))'\' >>$@+ > > -endif > > I don't personally have any problem with that. It does mean that "make > t1234-foo.sh" will behave differently than "./t1234-foo.sh", but that is > already true if you set GIT_TEST_OPTS. Only if you haven't changed TEST_OUTPUT_DIRECTORY since the last time you ran 'make' on the top level directory. And of course if somebody really wants their environment to be honored, that's what "make -e t1234-foo.sh" is for. Cheers.
On Mon, Jun 14 2021, Felipe Contreras wrote: > Jeff King wrote: >> On Sun, Jun 13, 2021 at 10:44:10AM -0500, Felipe Contreras wrote: >> >> > > Unfortunately, this isn't a complete solution. >> > >> > Software will never be perfect. >> > >> > We don't need to wait for a perfect solution, all we need is something >> > better than the current siuation. >> >> Sure, but if you don't fully understand the situation (e.g., that --root >> and TEST_OUTPUT_DIRECTORY are not equivalent), then you may end up >> revisiting the incomplete fix later, > > The fact that you may end up revisiting a solution is a fact for *all* > changes (including 2d14e13c56 (test output: respect > $TEST_OUTPUT_DIRECTORY, 2013-04-29)). > >> or even making things worse (as this patch did). > > I think breaking the test suite is objectively worse than having a few > extra files in the output directory, but to each his own. We've got both in-tree and out-tree things that rely on e.g. the *.counts in that directory to have a 1=1 mapping with "real" tests. E.g. "make aggregate-results". >> > > I think solving the whole issue would require a mechanism for passing >> > > TEST_OUTPUT_DIRECTORY in a way that can't be overridden (whether in an >> > > environment variable or the command-line). >> > >> > Why do we even have TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS? Looking >> > for a reason there's 2d14e13c56 (test output: respect >> > $TEST_OUTPUT_DIRECTORY, 2013-04-29), there it says it's for >> > valgrind/analyze.sh. >> > >> > I don't know who uses that script, or how. There's no documentaion, >> > nothing on the mailing list, and nothing found on Google. >> >> Perhaps 268fac6919 (Add a script to coalesce the valgrind outputs, >> 2009-02-04) is enlightening. > > That makes it clearer. > >> I don't know if anybody still uses it these days, though. I suspect it's >> outlived its usefulness, in that we would typically not have any >> valgrind errors at all (so coalescing them is not that interesting). >> >> Possibly folks investigating leak-checking via valgrind could find it >> useful, but even there I think LSan is a much better path forward. > > Yeah, but even if they do run this tool, they can set > TEST_OUTPUT_DIRECTORY manually. > > The needs of the few should not otweight needs of the many. Do we need to bring Spock into this?:) I think the following alternate/on-top patch (which you should feel free to squash in with my SOB if you agree) solves the issue both of you are noting. It will barf if you run the tests under e.g. --tee with that environment variable, but that's intentional. It's better to loudly error if we don't have the expected test-results than to silently write in the wrong place. diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh index 2c6e34b9478..29bf67d49bf 100755 --- a/t/t0000-basic.sh +++ b/t/t0000-basic.sh @@ -76,6 +76,12 @@ _run_sub_test_lib_test_common () { # this variable, so we need a stable setting under which to run # the sub-test. sane_unset HARNESS_ACTIVE && + + # These tests should emit no metrics or output that + # would normally go in the "test-results" directory. + TEST_NO_RESULTS_OUTPUT=1 && + export TEST_NO_RESULTS_OUTPUT && + cd "$name" && write_script "$name.sh" "$TEST_SHELL_PATH" <<-EOF && test_description='$descr (run in sub test-lib) @@ -89,14 +95,12 @@ _run_sub_test_lib_test_common () { EOF cat >>"$name.sh" && export TEST_DIRECTORY && - TEST_OUTPUT_DIRECTORY=$(pwd) && - export TEST_OUTPUT_DIRECTORY && sane_unset GIT_TEST_FAIL_PREREQS && if test -z "$neg" then - ./"$name.sh" "$@" >out 2>err + ./"$name.sh" --root="$(pwd)" "$@" >out 2>err else - ! ./"$name.sh" "$@" >out 2>err + ! ./"$name.sh" --root="$(pwd)" "$@" >out 2>err fi ) } diff --git a/t/test-lib.sh b/t/test-lib.sh index 54938c64279..9e9696a3185 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -252,8 +252,14 @@ TEST_STRESS_JOB_SFX="${GIT_TEST_STRESS_JOB_NR:+.stress-$GIT_TEST_STRESS_JOB_NR}" TEST_NAME="$(basename "$0" .sh)" TEST_NUMBER="${TEST_NAME%%-*}" TEST_NUMBER="${TEST_NUMBER#t}" -TEST_RESULTS_DIR="$TEST_OUTPUT_DIRECTORY/test-results" -TEST_RESULTS_BASE="$TEST_RESULTS_DIR/$TEST_NAME$TEST_STRESS_JOB_SFX" +if test -n "$TEST_NO_RESULTS_OUTPUT" +then + TEST_RESULTS_DIR=/dev/null + TEST_RESULTS_BASE=/dev/null +else + TEST_RESULTS_DIR="$TEST_OUTPUT_DIRECTORY/test-results" + TEST_RESULTS_BASE="$TEST_RESULTS_DIR/$TEST_NAME$TEST_STRESS_JOB_SFX" +fi TRASH_DIRECTORY="trash directory.$TEST_NAME$TEST_STRESS_JOB_SFX" test -n "$root" && TRASH_DIRECTORY="$root/$TRASH_DIRECTORY" case "$TRASH_DIRECTORY" in @@ -1124,7 +1130,7 @@ test_done () { finalize_junit_xml - if test -z "$HARNESS_ACTIVE" + if test -z "$HARNESS_ACTIVE$TEST_NO_RESULTS_OUTPUT" then mkdir -p "$TEST_RESULTS_DIR"
On Mon, Jun 14, 2021 at 11:33:12AM +0200, Ævar Arnfjörð Bjarmason wrote: > > I think breaking the test suite is objectively worse than having a few > > extra files in the output directory, but to each his own. > > We've got both in-tree and out-tree things that rely on e.g. the > *.counts in that directory to have a 1=1 mapping with "real" > tests. E.g. "make aggregate-results". Indeed. With Felipe's original patch, the "test" target (but not "prove") in t/Makefile will report, whether you set TEST_OUTPUT_DIRECTORY or not: failed test(s): t1234 t2345 fixed 0 success 23243 failed 2 broken 221 total 23647 though curiously it doesn't exit non-zero back to make (usually we'd also see the failures from the individual make targets, and barf there). > diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh > index 2c6e34b9478..29bf67d49bf 100755 > --- a/t/t0000-basic.sh > +++ b/t/t0000-basic.sh > @@ -76,6 +76,12 @@ _run_sub_test_lib_test_common () { > # this variable, so we need a stable setting under which to run > # the sub-test. > sane_unset HARNESS_ACTIVE && > + > + # These tests should emit no metrics or output that > + # would normally go in the "test-results" directory. > + TEST_NO_RESULTS_OUTPUT=1 && > + export TEST_NO_RESULTS_OUTPUT && I'm OK with this general approach. I do think it would be nice if we let the environment supersede the on-disk GIT-BUILD-OPTIONS, which IMHO is the real root of the problem (and possibly others), but that may be more challenging to get right (I posted a patch earlier, but it does rely on stuffing all of "set" into a variable, which makes me concerned some less-able shells may complain). It also means that t0000 can't test the results output (since we don't write it), but I assume we don't do that now (I didn't actually try running with your patch). > diff --git a/t/test-lib.sh b/t/test-lib.sh > index 54938c64279..9e9696a3185 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -252,8 +252,14 @@ TEST_STRESS_JOB_SFX="${GIT_TEST_STRESS_JOB_NR:+.stress-$GIT_TEST_STRESS_JOB_NR}" > TEST_NAME="$(basename "$0" .sh)" > TEST_NUMBER="${TEST_NAME%%-*}" > TEST_NUMBER="${TEST_NUMBER#t}" > -TEST_RESULTS_DIR="$TEST_OUTPUT_DIRECTORY/test-results" > -TEST_RESULTS_BASE="$TEST_RESULTS_DIR/$TEST_NAME$TEST_STRESS_JOB_SFX" > +if test -n "$TEST_NO_RESULTS_OUTPUT" > +then > + TEST_RESULTS_DIR=/dev/null > + TEST_RESULTS_BASE=/dev/null > +else > + TEST_RESULTS_DIR="$TEST_OUTPUT_DIRECTORY/test-results" > + TEST_RESULTS_BASE="$TEST_RESULTS_DIR/$TEST_NAME$TEST_STRESS_JOB_SFX" > +fi I wondered about this use of /dev/null, since we'd generally use this as a directory, and writing to "/dev/null/foo" is going to throw an error. But... > TRASH_DIRECTORY="trash directory.$TEST_NAME$TEST_STRESS_JOB_SFX" > test -n "$root" && TRASH_DIRECTORY="$root/$TRASH_DIRECTORY" > case "$TRASH_DIRECTORY" in > @@ -1124,7 +1130,7 @@ test_done () { > > finalize_junit_xml > > - if test -z "$HARNESS_ACTIVE" > + if test -z "$HARNESS_ACTIVE$TEST_NO_RESULTS_OUTPUT" > then > mkdir -p "$TEST_RESULTS_DIR" ...here we would never look at those variables at all, so it is just a sentinel that would let us know the assumption has been violated. We do look at them elsewhere, though (in --tee as you noted, and I think for --stress). I'd prefer to notice the "no results" flag explicitly there and report something sensible, rather than getting: mkdir: cannot create directory ‘/dev/null’: Not a directory or similar. -Peff
On Mon, Jun 14 2021, Jeff King wrote: > On Mon, Jun 14, 2021 at 11:33:12AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> > I think breaking the test suite is objectively worse than having a few >> > extra files in the output directory, but to each his own. >> >> We've got both in-tree and out-tree things that rely on e.g. the >> *.counts in that directory to have a 1=1 mapping with "real" >> tests. E.g. "make aggregate-results". > > Indeed. With Felipe's original patch, the "test" target (but not > "prove") in t/Makefile will report, whether you set > TEST_OUTPUT_DIRECTORY or not: > > failed test(s): t1234 t2345 > > fixed 0 > success 23243 > failed 2 > broken 221 > total 23647 > > though curiously it doesn't exit non-zero back to make (usually we'd > also see the failures from the individual make targets, and barf there). Odd. >> diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh >> index 2c6e34b9478..29bf67d49bf 100755 >> --- a/t/t0000-basic.sh >> +++ b/t/t0000-basic.sh >> @@ -76,6 +76,12 @@ _run_sub_test_lib_test_common () { >> # this variable, so we need a stable setting under which to run >> # the sub-test. >> sane_unset HARNESS_ACTIVE && >> + >> + # These tests should emit no metrics or output that >> + # would normally go in the "test-results" directory. >> + TEST_NO_RESULTS_OUTPUT=1 && >> + export TEST_NO_RESULTS_OUTPUT && > > I'm OK with this general approach. I do think it would be nice if we let > the environment supersede the on-disk GIT-BUILD-OPTIONS, which IMHO is > the real root of the problem (and possibly others), but that may be more > challenging to get right (I posted a patch earlier, but it does rely on > stuffing all of "set" into a variable, which makes me concerned some > less-able shells may complain). Yeah I don't know and haven't dug into who wants all this combination of GIT-BUILD-OPTIONS, passing things in the env, or passing things as paramaters to make (sometimes under the same names). > It also means that t0000 can't test the results output (since we don't > write it), but I assume we don't do that now (I didn't actually try > running with your patch). Yeah, but only in the trivial wrapper function, you can still write the test script and check the output yourself. That's much easier on top of a series to move that into a lib-subtest.sh that I submitted today: https://lore.kernel.org/git/cover-0.8-00000000000-20210614T104351Z-avarab@gmail.com/ >> diff --git a/t/test-lib.sh b/t/test-lib.sh >> index 54938c64279..9e9696a3185 100644 >> --- a/t/test-lib.sh >> +++ b/t/test-lib.sh >> @@ -252,8 +252,14 @@ TEST_STRESS_JOB_SFX="${GIT_TEST_STRESS_JOB_NR:+.stress-$GIT_TEST_STRESS_JOB_NR}" >> TEST_NAME="$(basename "$0" .sh)" >> TEST_NUMBER="${TEST_NAME%%-*}" >> TEST_NUMBER="${TEST_NUMBER#t}" >> -TEST_RESULTS_DIR="$TEST_OUTPUT_DIRECTORY/test-results" >> -TEST_RESULTS_BASE="$TEST_RESULTS_DIR/$TEST_NAME$TEST_STRESS_JOB_SFX" >> +if test -n "$TEST_NO_RESULTS_OUTPUT" >> +then >> + TEST_RESULTS_DIR=/dev/null >> + TEST_RESULTS_BASE=/dev/null >> +else >> + TEST_RESULTS_DIR="$TEST_OUTPUT_DIRECTORY/test-results" >> + TEST_RESULTS_BASE="$TEST_RESULTS_DIR/$TEST_NAME$TEST_STRESS_JOB_SFX" >> +fi > > I wondered about this use of /dev/null, since we'd generally use this as > a directory, and writing to "/dev/null/foo" is going to throw an error. > > But... > >> TRASH_DIRECTORY="trash directory.$TEST_NAME$TEST_STRESS_JOB_SFX" >> test -n "$root" && TRASH_DIRECTORY="$root/$TRASH_DIRECTORY" >> case "$TRASH_DIRECTORY" in >> @@ -1124,7 +1130,7 @@ test_done () { >> >> finalize_junit_xml >> >> - if test -z "$HARNESS_ACTIVE" >> + if test -z "$HARNESS_ACTIVE$TEST_NO_RESULTS_OUTPUT" >> then >> mkdir -p "$TEST_RESULTS_DIR" > > ...here we would never look at those variables at all, so it is just a > sentinel that would let us know the assumption has been violated. > > We do look at them elsewhere, though (in --tee as you noted, and I think > for --stress). I'd prefer to notice the "no results" flag explicitly > there and report something sensible, rather than getting: If we edit every single current callsite instead of setting it to something you can't write to then we're setting ourselves up for subtle bugss when someone uses $TEST_RESULTS_DIR for something else. > mkdir: cannot create directory ‘/dev/null’: Not a directory > > or similar. Yeah that error sucks, but nobody will see it unless they're hacking on the guts of this $TEST_NO_RESULTS_OUTPUT, and I think it beats being fragile. In any case, I'll let Felipe decide what, if anything, to do with this :)
On Mon, Jun 14, 2021 at 06:55:03PM +0200, Ævar Arnfjörð Bjarmason wrote: > > Indeed. With Felipe's original patch, the "test" target (but not > > "prove") in t/Makefile will report, whether you set > > TEST_OUTPUT_DIRECTORY or not: > > > > failed test(s): t1234 t2345 > > > > fixed 0 > > success 23243 > > failed 2 > > broken 221 > > total 23647 > > > > though curiously it doesn't exit non-zero back to make (usually we'd > > also see the failures from the individual make targets, and barf there). > > Odd. I think it's just that the aggregation script was never meant to signal to "make". In a regular "make test" (not using prove), each individual test script is a dependency than can fail on its own. That means a failure of any of them will signal "make" to fail the overall operation. Interestingly it means we will not run the "aggregate-results" at all in that case, so we would not give the nice output (you can run "make aggregate-results" yourself, though; it doesn't depend on the tests running itself, but assumes you've already run them). So arguably we could do something like this: diff --git a/t/aggregate-results.sh b/t/aggregate-results.sh index 7913e206ed..6198b2ef6b 100755 --- a/t/aggregate-results.sh +++ b/t/aggregate-results.sh @@ -44,3 +44,5 @@ printf "%-8s%d\n" success $success printf "%-8s%d\n" failed $failed printf "%-8s%d\n" broken $broken printf "%-8s%d\n" total $total + +test -z "$failed_tests" but it makes "make aggregate-results" after the fact a little noisier. I dunno. I don't really care that much about the output from this form of the tests at all, since the "prove" output is _so_ much better, and I'd highly recommend anybody use it instead. The only thing preventing me from suggesting we get rid of the old make-driven approach entirely is that there are probably platforms that run the tests where "prove" is not available. And as long as it is not generating wrong results (e.g., returning 0 when a test has failed), it is doing that job OK. > > I'm OK with this general approach. I do think it would be nice if we let > > the environment supersede the on-disk GIT-BUILD-OPTIONS, which IMHO is > > the real root of the problem (and possibly others), but that may be more > > challenging to get right (I posted a patch earlier, but it does rely on > > stuffing all of "set" into a variable, which makes me concerned some > > less-able shells may complain). > > Yeah I don't know and haven't dug into who wants all this combination of > GIT-BUILD-OPTIONS, passing things in the env, or passing things as > paramaters to make (sometimes under the same names). To be clear, I doubt it's all that important. It would occasionally be less surprising when trying to override the environment while running a test script manually (which is after all, basically the same thing that's happening here, just driven by a script). But if it's hard to do, I'm OK with an easier solution provided it doesn't regress any other cases. > > It also means that t0000 can't test the results output (since we don't > > write it), but I assume we don't do that now (I didn't actually try > > running with your patch). > > Yeah, but only in the trivial wrapper function, you can still write the > test script and check the output yourself. Sort of. You can avoid its setting of TEST_NO_RESULTS_OUTPUT, but we're still left without a way to reliably override TEST_OUTPUT_DIRECTORY. Again, I'm OK punting on that for now if there are no such tests. > > We do look at them elsewhere, though (in --tee as you noted, and I think > > for --stress). I'd prefer to notice the "no results" flag explicitly > > there and report something sensible, rather than getting: > > If we edit every single current callsite instead of setting it to > something you can't write to then we're setting ourselves up for subtle > bugss when someone uses $TEST_RESULTS_DIR for something else. I was thinking we'd still set it to /dev/null as a belt-and-suspenders (so the worst case is just an ugly error message). But... > > mkdir: cannot create directory ‘/dev/null’: Not a directory > > > > or similar. > > Yeah that error sucks, but nobody will see it unless they're hacking on > the guts of this $TEST_NO_RESULTS_OUTPUT, and I think it beats being fragile. I think that's a good point. You're unlikely to stumble into accidentally using TEST_NO_RESULTS_OUTPUT, so it might not be worth caring about too much. -Peff
Hi Jeff, On 15/06/21 18.10, Jeff King wrote: > I think it's just that the aggregation script was never meant to signal > to "make". In a regular "make test" (not using prove), each individual > test script is a dependency than can fail on its own. That means a > failure of any of them will signal "make" to fail the overall operation. > Only one failure can trigger FTBFS when make test, right?
On Tue, Jun 15, 2021 at 06:21:00PM +0700, Bagas Sanjaya wrote: > On 15/06/21 18.10, Jeff King wrote: > > I think it's just that the aggregation script was never meant to signal > > to "make". In a regular "make test" (not using prove), each individual > > test script is a dependency than can fail on its own. That means a > > failure of any of them will signal "make" to fail the overall operation. > > > Only one failure can trigger FTBFS when make test, right? I'm not sure I understand what your question means. I know that "FTBFS" means "failed to build from source", but that is not a term we use in the Git project. So if you are asking whether "make test" will exit non-zero if a single test fails, then yes. If you're asking whether a Debian package would consider that an FTBFS, then probably yes, but it depends on whether they run the tests. -Peff
Ævar Arnfjörð Bjarmason wrote: > > On Mon, Jun 14 2021, Felipe Contreras wrote: > > > Jeff King wrote: > >> or even making things worse (as this patch did). > > > > I think breaking the test suite is objectively worse than having a few > > extra files in the output directory, but to each his own. > > We've got both in-tree and out-tree things that rely on e.g. the > *.counts in that directory to have a 1=1 mapping with "real" > tests. E.g. "make aggregate-results". Yeah, that's not good, but I wouldn't call it "worse". > >> I don't know if anybody still uses it these days, though. I suspect it's > >> outlived its usefulness, in that we would typically not have any > >> valgrind errors at all (so coalescing them is not that interesting). > >> > >> Possibly folks investigating leak-checking via valgrind could find it > >> useful, but even there I think LSan is a much better path forward. > > > > Yeah, but even if they do run this tool, they can set > > TEST_OUTPUT_DIRECTORY manually. > > > > The needs of the few should not otweight needs of the many. > > Do we need to bring Spock into this?:) Hopefully not. > I think the following alternate/on-top patch (which you should feel free > to squash in with my SOB if you agree) solves the issue both of you are > noting. > > It will barf if you run the tests under e.g. --tee with that environment > variable, but that's intentional. It's better to loudly error if we > don't have the expected test-results than to silently write in the wrong > place. I'm not sure how that patch was supposed to work: 'err' is not empty, it contains: mkdir: cannot create directory '/dev/null': File exists /home/felipec/dev/git.git/git/t/test-lib.sh: line 1133: /dev/null.counts: Permission denied not ok 5 - pretend we have a fully passing test suite Does this assume the rest of the framework will be updated to properly handle TEST_NO_RESULTS_OUTPUT? Cheers.
Jeff King wrote: > On Mon, Jun 14, 2021 at 06:55:03PM +0200, Ævar Arnfjörð Bjarmason wrote: > > > mkdir: cannot create directory ‘/dev/null’: Not a directory > > > > > > or similar. > > > > Yeah that error sucks, but nobody will see it unless they're hacking on > > the guts of this $TEST_NO_RESULTS_OUTPUT, and I think it beats being fragile. > > I think that's a good point. You're unlikely to stumble into > accidentally using TEST_NO_RESULTS_OUTPUT, so it might not be worth > caring about too much. But check_sub_test_lib_test() cares: test_must_be_empty err 'err' is not empty, it contains: mkdir: cannot create directory '/dev/null': File exists /home/felipec/dev/git.git/git/t/test-lib.sh: line 1133: /dev/null.counts: Permission denied not ok 5 - pretend we have a fully passing test suite
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh index 705d62cc27..16b70ef940 100755 --- a/t/t0000-basic.sh +++ b/t/t0000-basic.sh @@ -93,14 +93,12 @@ _run_sub_test_lib_test_common () { EOF cat >>"$name.sh" && export TEST_DIRECTORY && - TEST_OUTPUT_DIRECTORY=$(pwd) && - export TEST_OUTPUT_DIRECTORY && sane_unset GIT_TEST_FAIL_PREREQS && if test -z "$neg" then - ./"$name.sh" "$@" >out 2>err + ./"$name.sh" --root="$(pwd)" "$@" >out 2>err else - ! ./"$name.sh" "$@" >out 2>err + ! ./"$name.sh" --root="$(pwd)" "$@" >out 2>err fi ) }
The test_atexit unit test relies on the specific location of the generated files. When TEST_OUTPUT_DIRECTORY is unset, _run_sub_test_lib_test_common sets it to pwd, which is two levels under the pwd of the parent unit test, and the parent can find the generated files just fine. But when TEST_OUTPUT_DIRECTORY is set, it's stored in GIT-BUILD-OPTIONS, and even though _run_sub_test_lib_test_common correctly overrides it, when the child script is run, it sources GIT-BUILD-OPTIONS, and TEST_OUTPUT_DIRECTORY is overridden. Effectively both the parent and child scripts output to the same directory. make TEST_OUTPUT_DIRECTORY=/tmp/foobar GIT-BUILD-OPTIONS && make -C t t0000-basic.sh We could simply revert 2d14e13c56 (test output: respect $TEST_OUTPUT_DIRECTORY, 2013-04-29), but presumably it was done for some reason. On the other hand we could follow the alternate path suggested in 6883047071 (t0000: set TEST_OUTPUT_DIRECTORY for sub-tests, 2013-12-28): pass the --root parameter to the child scripts. The alternate solution works, so let's do that instead. Presumably this was broken since 900721e15c (test-lib: introduce 'test_atexit', 2019-03-13). Cc: John Keeping <john@keeping.me.uk> Cc: Jeff King <peff@peff.net> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> --- t/t0000-basic.sh | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)