| Age | Commit message (Collapse) | Author |
|---|
|
...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.
|
|
|
|
|
|
operations
This test creates a "file" repository with pragma "to_git". Move to a
subdirectory to avoid including all the tools in that created root.
|
|
For historic reasons (as quite some tests date back till before the
public name of the build tools was decided), the end-to-end tests
assume generic names for the tools. This used to be done by simple
staging the artifacts. As soon as we started to support dynamic
linking, we also have to allow the runtime dependnecies, as provided
by our install-with-deps rule. ae2e515ab84ea3ab08764685f84441c0741f8039
attempted to add those dependencies by replacing the staging by
a generic action doing a copy. This, however, made the "lib" dir
containing the dependencies an opaque tree
- defined by different actions, and, more importantly,
- containing only the run-time dependencies of one of the tools.
This causes staging conflicts between those two lib dirs (currently
hidden by a bug in the computation of the disjoint union) and things
only worked because in the canonical configuration used for testing
both "lib" dirs are empty anyway.
The correct way of adding dependencies while renaming the tool is
still staging; fix this.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
... i.e., support testing the use case that the serve instance simultaneously
acts as remote-execution endpoint.
|
|
|
|
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
... simultaneously, in order to find race conditions during
the build.
|
|
... verifying that
- emphemeral directories are removed,
- left-over remove-me directories are removed, and
- the available content of CAS and cache are not affected.
|
|
|
|
... instead of replacing the host name of each mirror, it
should only reorder the list of given mirrors.
|
|
... explaining, in particular, which environment variables are provided
by the test-runner framework.
|
|
|
|
... in particular, verify that no error is reported on successfull
command completion.
|
|
|
|
... 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.
|
|
... to generic actions, in order to not rely on "standard paths"
being pulled in.
|
|
As this test takes significantly more time than the other end-to-end tests,
set a suitable default value for the configuration variable TIMEOUT_SCALE.
|
|
Especially the end-to-end tests that use "remote" end points can grow
large; therefore, honor the configuration variable TIMEOUT_SCALE, to
allow the author to specify that this test takes more time.
|
|
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.
|
