| Age | Commit message (Collapse) | Author |
|---|
|
...that checks if symlinks are treated the same as in just-mr.
|
|
|
|
... allowing to print the unique artifact built (if any). This
allows convenient inspection of the build result of targets that
define precisely one artifact.
|
|
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.
|
|
|
|
|
|
|
|
Also add empty directory in test script to ensure we don't regress
in the future. While there, fix some typos.
|
|
... so that linting information gets propagated properly.
|
|
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.
|
|
...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.
|
|
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).
|
|
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.
|
|
|
|
|
|
|
|
For a user `just install-cas` will show an entry without revealing
where it found it---as it is content-addressable, it does not matter.
Therefore, verify that accessing paths of a tree object also works
regardless of where the tree is stored.
|
|
... 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.
|
|
... regardless of the names chosen during packaging.
|
|
|
|
|
|
|
|
... also verifying that we can look into tree outputs
|
|
Verify that install and install-cas do not overwrite and instead
replace existing files. This behaviour is less surprising for the
user in the presence of hard links.
|
|
|
|
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>
|
|
... also when determining default module or target.
|
