| Age | Commit message (Collapse) | Author |
|---|
|
... if serve is used and remote-execution is a separate service.
|
|
|
|
For tests where we bring our own remote-execution end point, support
a directory where executables can be placed that are picked up
early in PATH by remote actions. In this way, a test can be designed
verifying that a particular action actually was run remotely.
|
|
|
|
|
|
Also for tests that provide infrastructure, it can be desirable
to run those tests a large number of times. Therefore, support
additional remote-execution properties for the summary action so
that a suitable remote-execution endpoint can be chosen.
|
|
...which do not stage also the debug source and header files (while
in debug mode), as this is unnecessary bloat in the tests.
As the tool-under-test and mr-tool-under-test targets should be
used instead of the regular install targets also in the various
extra rules in end-to-end and utils, move their definition in the
outmost test TARGETS file.
|
|
|
|
... i.e., support testing the use case that the serve instance simultaneously
acts as remote-execution endpoint.
|
|
... explaining, in particular, which environment variables are provided
by the test-runner framework.
|
|
Especially the end-to-end tests that use "remote" end points can grow
large; therefore, honor the configuration variable TIMEOUT_SCALE, to
allow the author to specify that this test takes more time.
|
|
|
|
Added compatibility envariable to the with_serve rule, guarded
tests using --fetch-absent such that they run only in native mode,
and made all serve-service tests aware of the compatibility flag.
|
|
This will allow end-to-end tests to pre-populate the serve build
root if needed.
|
|
|
|
... and document at the appropriate places what can be overwritten
by setting those targets.
|
|
Besides stdout and stderr of the test, the output of the remote-execution
server are also artifacts of that rule.
|
|
... as those binaries might need run-libs.
|
|
This allows better separation and, in particular, repositories
needed only for tests do not have to be provided for building the
tools. This also better documents which dependencies are only needed
for testing.
|
|
endpoint
This can be useful, for example, to test if justbuild can successfully
communicate with the specified remote execution service.
|
|
... similar to ["@", "rules", "shell/test", "script"], but implicitly
starting a remote execution in the background, passing the information
about that endpoint to the test via an environment variable.
|
