git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
	"John Keeping" <john@keeping.me.uk>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] test: fix for TEST_OUTPUT_DIRECTORY
Date: Sun, 13 Jun 2021 00:42:32 -0400	[thread overview]
Message-ID: <YMWMuDbctae7tF6J@coredump.intra.peff.net> (raw)
In-Reply-To: <20210609170520.67014-1-felipe.contreras@gmail.com>

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

  reply	other threads:[~2021-06-13  4:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09 17:05 [PATCH] test: fix for TEST_OUTPUT_DIRECTORY Felipe Contreras
2021-06-13  4:42 ` Jeff King [this message]
2021-06-13 15:44   ` Felipe Contreras
2021-06-14  7:43     ` Jeff King
2021-06-14  8:39       ` Felipe Contreras
2021-06-14  9:33         ` Ævar Arnfjörð Bjarmason
2021-06-14 14:25           ` Jeff King
2021-06-14 16:55             ` Ævar Arnfjörð Bjarmason
2021-06-15 11:10               ` Jeff King
2021-06-15 11:21                 ` Bagas Sanjaya
2021-06-15 11:23                   ` Jeff King
2021-06-15 18:09                 ` Felipe Contreras
2021-06-15 17:45           ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YMWMuDbctae7tF6J@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=carenas@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=john@keeping.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).