| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
Some actions are allowed to fail, typically tests. By reporting the
output of failed such actions early, the user can already have a
look at those artifacts, typically a test log, while the build is
still going on.
|
|
... even if remote-execution arguments are given. Also verify
that failure is correctly reflected in the exit code.
|
|
|
|
|
|
|
|
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.
|
|
|
|
While still doing some unnecessary file operations in the local
build root, computed roots work also for remote execution, both
in native and in compatible mode, also for roots with non-trivial
depth. Add a basic test ensuring we do not regress there.
|
|
|
|
... and look up values in cache, if possible.
|
|
|
|
While there, also clean up the analysis result as soon as it
is no longer needed.
|
|
For subcomputations add the log to CAS and only report the blob
identifier. Also, indicate at the beginning, that computed roots are
to be computed. While there, simplify code by using the ToString()
method of computed roots.
|
|
|
|
|
|
...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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also add empty directory in test script to ensure we don't regress
in the future. While there, fix some typos.
|
|
... so that we can run with whatever ambient path is present
rather than relying on standard paths pulled in by env.
|
|
... so that linting information gets propagated properly.
|
|
When switching from a target to the artifacts that are the inputs
of a particular action, the provides map is also switched to provide
additional (besides the inputs) information about the action, in
particular the command. Extend this provides map with the remaining
information, in particular the working directory.
|
|
... also ensuring that the implict empty tree is added as input.
|
|
|
|
older generations
|
|
|
|
|
|
|
|
This test verifies properties of just, hence the precise nature of the
just-mr tool does not matter.
|
|
... ensuring we do not regress on the recently fixed race that allowed
file descriptors to reconstructed executables to be kept alive.
|
|
Our end-to-end tests involve calling just-mr. When run locally, in order to
make then self-contained we need to make sure this test call to just-mr does
not pick up the user's .just-mrrc that might contain different setting not
overridden at the command line.
|
|
|
|
|
|
...between local, remote, and served builds.
|
|
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.
|
|
|
|
|
|
Most built-in rules are just described by their name, assuming they
are known to the user anyway. One exception, however, are "export"
targets, as those serve as interfaces to (logical) repositories and
hence is supposed to have a documentation of the target itself. Over
time, however, "configure" targets have evolved to become internal
interfaces (maybe even for an external target), e.g., to provide
default values and hence make better use of the actual export target.
Therefore it is desirable to provide a bit more information when
asked to describe a "configure" target.
- As "configure" targets have a fixed set of keys, adding a "doc"
field is a conservative extension; this can be useful to give an
overview what the target is about.
- An important information of a "configure" target is the target
that is configured. While this, in general, is an expression, in
the typical cases, the description is very short (a literal target
name, or a variable). So we can afford to show the definition.
|
|
... but not all. Also in this case, if an target-level cache
entry is written, the dependencies have to be written as well.
|
|
...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.
|
|
|
|
...REMOTE_EXECUTION_PROPERTIES env variable.
|
|
...that come with installing just. This ensures control on the
subdirectories available to the runner, avoiding any possible
conflicting paths.
|
