| Age | Commit message (Collapse) | Author |
|---|
|
Also show only the build time in the invocations overview, as only
for the build phase detailled timing information will be available
in the log of a particular information.
|
|
...in all return paths, including in reporting caught exceptions.
In this way give the opportunity for any calling AsyncMap to
receive an expected fatal logger call on failure and thus be able
to shut down gracefully. This is in line with the AsyncMap design,
where the loggers are assumed to be safe to call by a consumer.
|
|
|
|
|
|
When using a serve end point, the analysis phase might take quite
long if serve has to actually build a delegated target or, at
least, has to synchronize artifacts with the remote end point.
Therefore, also record the time the build phase started (if building
is requested) as an additional time stamp in the profile.
|
|
...to match the ones produces by latest binaries and rules.
|
|
While there, update outputs to what is expected with current
released binaries and rules.
Co-authored-by: Klaus Aehlig <klaus.aehlig@huawei.com>
|
|
...to example export targets and defaults.
|
|
...instead of replacing CFLAGS and CXXFLAGS, thus also fixing a
mismatch introduced in c008c07656fff528c80add260397c7c7702aa2a8.
|
|
|
|
|
|
|
|
This fixes a bug in which the setup root was falsely being changed
by unconditionally searching early for a default configuration
files, despite one being explicitly provided at the command line.
|
|
... to a value that is a non-existent directory. Too many tools try
search for rc-files in the user's home directory. To make things
worth, the shell as well as many tools take an unset HOME variable
as instruction to look up the the user's home directory in the system
configuration. While it is good practise to write tests in such
a way that they explcitly do not depend on such machine-specific
defaults, still be on the safe side by explictly setting HOME to a
directory in the action directory we know our rules will no create.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
Co-authored-by: Sascha Roloff <sascha.roloff@huawei.com>
|
|
While there, remove tray cat whitesapce and redetermine the working
directory instead of relying on the environment.
|
|
... to include only the basename of the requested artifact.
|
|
|
|
... to allow reuse.
|
|
... to allow reuse.
|
|
|
|
This test actually tests the serve process brought in by
the ["end-to-end", "with serve"] rule. It starts several requests to
serve and, while serve is still building those, stops the clients.
The serve service should handle those aborted requests gracefully
and afterwards still be ready to take on a new requests.
|
|
... if serve is used and remote-execution is a separate service.
|
|
... instead of manually configuring and staging the various test branches.
|
|
... so that at this level, the full activity of the serve service can
be monitored.
|
|
|
|
|
|
|
|
|
|
|
|
... as this contains a bug fix with respect to the currently-used version
1.70.1, see release notes https://github.com/grpc/grpc/releases/tag/v1.70.2
|
|
Verify more keys in the profile file and also verify basic properties
of the other invocation-specific files that can be requested.
|
|
It is already supported to ask just-mr (via the rc file) to log for
each invocation the artifacts that were built. Add a similar option
for the artifacts that were to be built, i.e., for dumping the
intensional description of the output artifacts. That information
can be used, e.g., to compute the critical path.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A typical invocation logging would also include a value
for "--dump-artifacts". Mention this in the tutorial.
|
|
... as this also works together with, e.g., linting. While there,
also rerun the examples to get the latest output messages.
|
|
|
|
|
|
|
|
|
|
|
|
Normally, actions are supposed to work silently, i.e., without writing
to stdout/stderr. So, if an action produces console output, it is
definitely worth looking at, even for cached actions. Therefore,
add a section after the failed actions showing those actions (if
not in the previous action). Also, always show duration (if known)
and if an action is cached (which can happen for the ones producing
console output).
|
|
By supporting test matrix top-level of our test, which
affects both the ALL and the UNIT_TESTS target, it is
easy to run all tests for different tool chains, flags,
or CC_TEST_LAUNCHER values.
|
