| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
...that come with installing just. This ensures control on the
subdirectories available to the runner, avoiding any possible
conflicting paths.
|
|
The runners used in tests that rely on execution or serve
endpoints to exist can get stuck waiting for these to become
online if for some reason they cannot be set up. This commit fixes
this issue by setting a reasonable timeout, after which we fail
gracefully.
|
|
... in the local launcher for the execution end point. In this way,
the tests also work on systems where sh does not pull in enough
paths to have all the "usual" tools available.
To also get a correct path on systems relying on sh pulling in
enough paths, take what sh, launched with the default launcher,
would believe the path is.
|
|
For maximum compatibility, we use the uppercase types from the
typing package instead of the built-in types, therefore compliant
with PEP 484 and PEP 526.
|
|
... as those binaries might need run-libs.
|
|
endpoint
This can be useful, for example, to test if justbuild can successfully
communicate with the specified remote execution service.
|
|
... instead of using pipes that are prone to get full. Also
increase log level to Trace.
|
|
... 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.
|
