| Age | Commit message (Collapse) | Author |
|---|
|
|
|
...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.
|
|
Compared to the command line, the environment usually is quite
short. So including it in messages reporting about commands does
not introduce a lot of additional noise. However, knowing the
environment can help understanding an error message. Therefore, it
seems a good trade off to include it. Do so.
|
|
...instead of using absolute values.
This was the desidered outcome all along and now it can be done
right thanks to the recently added multiplication expression.
|
|
... in particular that of the absent pragma which is addressed both,
in imports as well as in deduplication.
|
|
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.
|
|
Also updates the tests and all relevant documentation accordingly.
|
|
|
|
The result of the analysis is a JSON object containing the keys
`"artifacts"`, `"runfiles"`, and `"provides"`. This JSON object, by
default, is logged. However, it might be useful to process the data
contained in it, while, for example, developing new rules.
This patch adds a new command line option (`--dump-result`), reserved
to the subcommand `analyse`, to dump the analysis result to the given
file or stdout (if `-` is given).
|
|
|
|
... and nothing reconstructed for simple (i.e., non-export) targets.
|
|
|
|
Configured targets, by design, cannot distinguish between a value
not occuring in the configuration and occuring there with value
null. Therefore, to understand the conflict, we can as well drop
all the null values of the target configuration when reporting it.
|
|
... as this is the only thing the user cares about when trying
to investigate why that action failed.
|
|
|
|
Often outputs are only referenced as blobs but not downloaded to the
working directory of the test. This can make it hard to understand
errors, as the respective artifacts are not available for inspection.
This is even more important in case of tests with a provided serve
endpoint as then even the error message of a failed serve build is
only referenced as blob. Solve this by keeping the local build root
of the remote-execution service using the fact that all objects are
transferred between the serve endpoint and the client go through
the remote-execution endpoint.
|
|
|
|
|
