When the -j option is given, a new process is spawned in which the test
programs are run and from which test servers are started. Only one
process can be started at once, but this is sufficient to test that the
infrastructure can isolate those functions in a new task. There should
be no visible difference between the two modes at the moment.
Ref: #10818Closes#11064
Program arguments are marshalled and then written to the end of a pipe
which is later read from and the arguments unmarshalled before the
desired function is called normally. The function return values are
then marshalled and written into another pipe when is later read from
and unmarshalled before being returned to the caller.
The implementation is currently blocking but can be made non-blocking
without any changes to the API. This allows calling multiple runners
without blocking in the future.
Ref: #10818
There will soon be multiple log directories so the paths will no longer
be static in runtests.pl. Also, get rid of $SERVER2IN which was not
used.
Ref: #10818
Log messages generated with logmsg can now be buffered and returned from
the runner as a return value. This will be needed with parallel testing
to allow all messages for one test to be displayed together instead of
interspersed with messages of multiple tests. Buffering can be disabled
by setting a logging callback function with setlogfunc, which is
currently being done to preserve existing logging behaviour for now.
Some additional output is generated in verbose and debugprotocol modes,
which don't always use logmsg. These modes also impact some servers
which generate extra messages. No attempt is made to buffer everything
if these modes are enabled.
Ref: #10818Closes#11016
This is closer to the place where logs are displayed on test failure.
Also, only display these logs if -p is given, which is the same flag
that controls display of test failure logs. Some server log files
need to be deleted later so that they stay around long enough to be
displayed on failure.
Ref: #10818
The test loop now has an initial loop that first runs through all
possible tests to build a set of those to attempt on this run based on
features and keywords and only then goes through that new list to run
them. This actually makes it three loops through all tests cases, as
there is an existing loop that gathers possible test numbers from the
test files on disk.
This has two minor effects on the output: all the tests that will be
skipped are displayed at the start (instead of being interspersed with
other tests) and the -l option no longer shows a count of tests at the
end or a (misleading) statement that tests have run successfully. The
skipped tests are also omitted from the test results sent to AppVeyor
and Azure in CI builds.
Another effect is a reduction in the amount of work considered part of
the "Test definition reading and preparation time" reported with -r
making those figures slightly lower than before.
Ref: #10818
testutil.pm now contains a few miscellaneous functions that are used in
several places but have no better place to live. subvariables moves to
servers.pm since most variables that it substitutes relate to servers,
so this is the most appropriate place. Rename a few functions for better
naming consistency.
Ref: #10818Closes#10995
This is code that is directly responsible for running a single test.
This will eventually run in a separate process as part of the parallel
testing project.
Ref: #10818