| Age | Commit message (Collapse) | Author |
|---|
|
Often, the simple number, e.g., for failed actions can already give
valuable information. For example, when investigating flakiness,
the count of failed actions already gives a hint whether a change
increased or decreased flakiness which can be valuable before even
investigating if the nature of the failure has changed. As we have
that information available and an additional number in a heading
does not clutter the page too much, let's just show it.
|
|
... to improve readability of target files.
|
|
... and do mark artifacts internally as synchronized. First all all,
we will abort anyway, to the entry won't even be read and, secondly
it is not necessarily true that the artifact is synchronized.
|
|
|
|
|
|
If the main repository is marked absent, warn if during the
dependency closure computation any non-content-fixed repositories
are reached, i.e., any "file"-type repositories that are neither
implicitly nor explicitly marked "to_git". Also warn if the main
repository itself is marked absent but is not content fixed.
Add small test checking that the new warning is produced.
|
|
When backing up target-cache entries we use parallelism at two
dimensions, the independent cache entries and for each entry we
retrieve the artifacts in parallel. If for each dimension we use
the full amount of parallelism allowed, that gives a number of
threads up to the square of the amount of parallelism specified by
the user. Therefore, use in each dimension only the square root
of the allowed parallelism keeping the total parallelism (up to
rounding) within the specified range.
|
|
Add a test testing the serve instance implicit to the "with serve"
rule by asking it to build a target that creates an export target
where the output is a deep tree.
|
|
Add a test asking serve to provide a target where both, the dependency
as well as the action graph has both a wide node (a target with a
large number of direct dependencies) as well as a deep node (a node
where the chain of dependencies is long). That target is requested
serveral times in parallel to verify that such targets can also be
served under load.
The process actually tested is the `just serve` process implicit
to the "with serve" rule.
|
|
Dropping unnecessary "arguments_config" as well as evaluating
trivial computations.
|
|
|
|
As the end of the build can be significantly ahead of the end of
the incvocation, a new time stamp was added to the profile. Use
this new time stamp in the invocation server when determining the
wall-clock time of the build.
|
|
... which might be quite ahead of the end time of the invocation if
writing out of the action graph delays the end of the invocation.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
