unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Florian Weimer <fweimer@redhat.com>, DJ Delorie <dj@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] test-in-container: Do not set GCONV_PATH, LOCPATH
Date: Thu, 23 May 2019 09:22:11 -0500	[thread overview]
Message-ID: <03367ccd-23af-4137-1ad3-a13f8f594d37@redhat.com> (raw)
In-Reply-To: <87d0k9xodo.fsf@oldenburg2.str.redhat.com>

On 5/23/19 8:59 AM, Florian Weimer wrote:
> * DJ Delorie:
> 
>> Florian Weimer <fweimer@redhat.com> writes:
>>> Sorry, I don't understand.  Why would the user want to run distcc *in
>>> the container*?
>>
>> That was just an example of an environment variable that affects the
>> build.  I don't know what environment variables affect the test cases.
>> Timeout-related?  Without a review of *every* test that might be run in
>> a container, we won't know what environment variables are valid for the
>> user to specify.
> 
> But right now, only new tests run in a container, so I think we should
> focus on what helps us to write such new tests, so that they run in an
> environment that is as realistic as possible.
> 
> We do not have many environment dependencies in the test harness itself:
> 
> support/support_test_main.c:  char *envstr_timeoutfactor = getenv ("TIMEOUTFACTOR");
> support/support_test_main.c:      test_dir = getenv ("TMPDIR");
> support/support_test_main.c:  const char *envstr_direct = getenv ("TEST_DIRECT");
> support/support_test_main.c:    const char *coredumps = getenv ("TEST_COREDUMPS");
> 
> TIMEOUTFACTOR and TEST_COREDUMPS are relevant, I think, and should not
> be filtered out.  But TMPDIR and TEST_DIRECT are unlikely to work
> because they specify paths which may not be relevant in the chroot.

I agree.

I expect many refinements like this which hone our concept
of what it means to run a test in a clean environment.

Initially when we did the implementation we needed to keep
the environment variables because historically DJ's testing
included running *every* test through test-in-container just
to prove we could and see if anything failed. This was good
during the bootstrap process of writing test-in-container.

However, now that we have test-in-container upstream, we have
to use a guiding principle to make decisions.

I would suggest that test-in-container's initial environment
should be as clean as possible, free of any host environment
variables. Then the test sets whatever environment variables
are required. The only environment variables that are worth
passing down are those related to test framework control
e.g. TIMEOUTFACTOR.

-- 
Cheers,
Carlos.

  reply	other threads:[~2019-05-23 14:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-20 17:40 [PATCH] test-in-container: Do not set GCONV_PATH, LOCPATH Florian Weimer
2019-05-20 18:19 ` DJ Delorie
2019-05-20 18:23   ` Florian Weimer
2019-05-20 19:26     ` DJ Delorie
2019-05-20 19:38       ` Florian Weimer
2019-05-21 12:49         ` DJ Delorie
2019-05-21 13:06           ` Florian Weimer
2019-05-21 13:24             ` DJ Delorie
2019-05-21 14:04               ` Zack Weinberg
2019-05-23 13:59               ` Florian Weimer
2019-05-23 14:22                 ` Carlos O'Donell [this message]
2019-05-23 19:48                   ` DJ Delorie
2019-05-24  4:05                     ` Carlos O'Donell

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: https://www.gnu.org/software/libc/involved.html

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

  git send-email \
    --in-reply-to=03367ccd-23af-4137-1ad3-a13f8f594d37@redhat.com \
    --to=carlos@redhat.com \
    --cc=dj@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /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.
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).