| Age | Commit message (Collapse) | Author |
|---|
|
|
|
properly
|
|
... and verify that
- spurious conflicts do not cause failure but instead are handled
correctly, and
- real conflicts are detected and reported properly.
|
|
|
|
While our tool promises to generate a reproducible order of the
action origins, we should not insist on a particular one. Therefore
sort before comparing.
|
|
... 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.
|
|
|
|
|
|
...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.
|
|
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.
|
|
... as this is the only thing the user cares about when trying
to investigate why that action failed.
|
|
Add an end-to-end test verifying that we report enough useful
information in case of an action failing.
|
|
... and only let test do the check on the final resulting boolean,
where the string representation is canonical. In this way, we avoid
having to rely on the string representation of numbers, where, e.g.,
1 and 1.0 are equally valid representations of the same number.
|
|
... 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.
|
|
... on next invocation, instead of being taken from cache.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Signed-off-by: Goetz Brasche <goetz.brasche@huawei.com>
|
|
|
|
Not only trees, but also regular files can disallow paths reaching
into them. If we have a file at a/b then another file at a/b/c
is a staging conflict as well. Make our tool recognize this.
|
|
Our maps serve two purposes: on the one hand, they can be a generic
key-value association with arbitrary strings as keys. On the other
hand, we use them to describe arrangements of files (inputs to actions,
artifacts or runfiles generated). In this function, certain keys refer
to the same path and hence have to be identifed. Therefore, at places
where the keys clearly have to be paths in the file system, implicitly
normalize them and check for conflicts.
|
|
|
|
|
|
|
|
Use the log functionality instead of relying on stderr being
precisely the log. Also check for the number of processed
actions instead of any number of actions that might be
reported in the log. While there, redirect stderr to stdout
to have a unified cronological log.
|
|
This test also demonstrates the notion of equality used in our
action graph: actions are considered equal, if they are defined in
the same way (regardless of where they are defined); when looking up
actions in cache, however, the inputs are considered extensionally.
The test also verifies that if one dumps the action graph, the
origins of an action (as the same action can be defined in many
places) are reported correctly.
|
