| Age | Commit message (Collapse) | Author |
|---|
|
As there is no guarantee that "out_dirs" are generated on action set
up, do so manually (being OK with the files already being present).
|
|
Add a test testing the serve instance implicit to the "with serve"
rule by asking it to build a target that creates an export target
where the output is a deep tree.
|
|
Add a test asking serve to provide a target where both, the dependency
as well as the action graph has both a wide node (a target with a
large number of direct dependencies) as well as a deep node (a node
where the chain of dependencies is long). That target is requested
serveral times in parallel to verify that such targets can also be
served under load.
The process actually tested is the `just serve` process implicit
to the "with serve" rule.
|
|
Dropping unnecessary "arguments_config" as well as evaluating
trivial computations.
|
|
This test actually tests the serve process brought in by
the ["end-to-end", "with serve"] rule. It starts several requests to
serve and, while serve is still building those, stops the clients.
The serve service should handle those aborted requests gracefully
and afterwards still be ready to take on a new requests.
|
|
... instead of manually configuring and staging the various test branches.
|
|
|
|
One of the analysis commands marked as expected to fail fails from
wrongly passing the launcher instead of the stated reasons. As the
behaviour between standalone and separate serve endpoint versions
would become inconsistent after fixing the command line, remove
this check completely. This does not negatively influence the scope
of the test script.
|
|
...by using the new local api that can handle any remote endpoint,
irrespective of protocol.
Also ensure all tests for the serve service are now being run both
in native and compatible modes.
|
|
|
|
... so that linting information gets propagated properly.
|
|
...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.
|
|
Also updates the tests and all relevant documentation accordingly.
|
|
|
|
|
|
|
|
|
|
This test tries to demonstrate that even if the remote-execution
has forgotten the action, the target-level cache of just serve
will allow a successful build without repeating the action. It
does it by cleaning the local build root of the remote-execution
service. If, however, serve and execute are the same process, they
also use the same local build root, so the target-level cache entry
needs to be kept alive separately.
|
|
|
|
... simultaneously, in order to find race conditions during
the build.
|
|
|
|
... where the files are known to serve, but not the resulting
directory. We achieve this, by adding an unrealted file to the
repository exposed to the serve server.
|
|
... by using the distdir request of the serve API.
|
|
...to help with debugging.
|
|
Extends test coverage for the interaction between 'just-mr setup'
and the serve endpoint for distdir repositories.
|
|
Extends test coverage for the interaction between 'just-mr setup'
and the serve endpoint for git-tree repositories.
|
|
Extends test coverage for the interaction between 'just-mr setup'
and the serve endpoint for file repositories with to_git pragma.
|
|
Extends test coverage for the interaction between 'just-mr setup'
and the serve endpoint for git repositories.
|
|
Extends test coverage for the interaction between 'just-mr setup'
and the serve endpoint for archive repositories.
|
|
... for test actions, by setting an appropriate local launcher. In
this way, the tests can also be run on systems where sh does not
pull in enough paths to have all the "usual" tools available.
|
|
|
|
|
|
|
|
Certain end-to-end tests require custom services. While normally
they come up in quickly (less than 2 seconds), on heavily overloaded
machines it might take longer. So increase the amount of time
these tests are willing to wait for the binary to start up to avoid
flakyness in our CI runs.
|
|
|
|
|
|
During the analysis of export targets, if there is a local target
cache miss, we should also interrogate the serve endpoint
(if given) for the target cache value before proceeding with the
analysis.
For this test we have extended the "with_serve" runner to expose
also the remote-execution build root to the test env.
|
|
|
|
|
|
|
|
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.
|
|
If only the `--remote-serve-endpoint` option is specified on the
command line, the `--remote-execution-endpoint` is also set to the
given value.
This makes the spawning and usage of just-execute consistent. When
just-serve is started, if no remote execution endpoint is provided,
the same process will also act as a just-execute instance. With the
current patch, the client can thus only write, on command line, the
remote serve address, avoiding the repetition of the same address for
two different options.
|
|
...the client and serve use two different remote execution endpoints
fixup test
|
|
serve_target_remote_build.sh should be updated once just-serve can
orchestrate the remote build
|
