Re: [PATCH] test: fix for TEST_OUTPUT_DIRECTORY

From: Jeff King <peff@peff.net>
Date: Jun 13, 2021, 04:42 UTC
Message-ID: <YMWMuDbctae7tF6J@coredump.intra.peff.net>
In-Reply-To: <20210609170520.67014-1-felipe.contreras@gmail.com>

On Wed, Jun 09, 2021 at 12:05:20PM -0500, Felipe Contreras wrote:

Show 17 quoted lines

> 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).

Show 5 quoted lines

> 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