This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] test-in-container: Do not set GCONV_PATH, LOCPATH


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]