Re: [PATCH] test: fix for TEST_OUTPUT_DIRECTORY

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux