Age | Commit message (Collapse) | Author |
|
|
|
The expected size of the list that defines the target was not checked
consistently. So, in case a target expected a list with 4 elements,
but got just 3, a segfault would happen.
This patch resolves this issue.
|
|
|
|
With the reformating of the analyse result we accepted longer
output lines anyway. Allowing them in the report of a detected
flaky action immediately gets the log and console output more
useful, as the source can often be identified without looking
at the full definition of the action in the action graph.
|
|
A complete documentation of a rule should not only include how to
use it (i.e., which fields are present and what is their meaning)
but also what the result is. This is particularly true, as the result
is structured and can contain some complex logic or conventions in
the provided information.
|
|
DirectoryEntries must be constructed explicitly either via a GitTree*
or an unordered_map<string,ObjectType>. So, the case of an empty
directory, is represented by an empty map. Before this patch, empty
directories were represented by std::monostate and missing checks
on that led to a seg-fault.
|
|
For a user, an important information is to know which actions
are currently running and, more importantly, the target that
caused them. To do so, we need a bit of infrastructure.
- We have to keep track of begin and end of running actions,
as well as the order in which they were started. That has
to happen efficiently and in a thread-safe way.
- We have to compute and keep the origin map for actions,
even if we don't serialize the action graph.
|
|
So far, `just describe` reported only the list of keys for runfiles
and artifacts while reporting full information for the provided
data, including the artifacts contained therein. Change this to
always reporting the full information, as for runfiles and artifacts
the detailed information is valuable as well.
|
|
|
|
... allowing to provide additional information in case of conflict
during flat staging.
|
|
The fact that we happen to use the same protocol as bazel does,
does not mean we are bazel. After all, the remote-build-execution
protocol is meant as a generic protocol. Hence change the names in
logs to avoid confusions.
|
|
|
|
To concatenate lists (the only ability the "+" operator had),
use "++".
|
|
|
|
|
|
... to allow for overwriting
|
|
For historic reasons, we considerd special strings as false values.
Drop that behavior in favor of a clean LISP-like semantics: everything
is true that is not empty.
|
|
|
|
|
|
... to foster the implementation of the built-in target "TREE"
|
|
|
|
... so remove it from the list of expected keys.
|
|
Reporting, with exponentially backing off intervals, the number of
cache hits found so far, the number of actions that have ben run,
and the number of actions currently under consideration.
|
|
|
|
|
|
|
|
|
|
While on the console, we want multi-line logs nicely aligned, when
logging to a file, unique readability is enough. So we can fix the
continuation prefix to a fixed string (with non-overlapping initial
segment). This makes log files easier to scan and also avoids
very long lines, given that the more complete message prefixes
are very long.
|
|
|
|
This patch introduces a templated ParseEntityName which can accept a
json or ExpressionPtr. Internally, performs a proper dispatch on these
cases
- isString
- isList
- size == 2
- size >= 3
A test is added for checking the proper handling of an empty list
|
|
EntityName now clearly expresses its double identity:
- NamedTarget
- AnonymousTarget
The usage of std::variant<NamedTarget,AnonymousTarget> guarantees that
EntityName, internally, is not a mix of the two - like could happen
before this patch.
NamedTarget features an enum ReferenceType to express the type of the
target, namely, "normal target" or an "explicit file reference".
Thanks to this refactoring, the introduction of new targets type
should be easier, since the design is more modular.
NamedTarget
|
|
|
|
|
|
|
|
... which was accessing the wrong artifacts in the list if the
artifact list contains a mixture of files and trees.
|
|
If we do not use a target directly, we also should not include
it. It's be build tool's job to track indirect dependencies.
|
|
I this way, also resulting trees can cleanly be printed on the command
line via the -P option.
|
|
|
|
|
|
... to be consistent with the remote execution protocol.
|
|
... as wrongfully only sub-tree entries were added to
locally cached trees, although they should also store
entries for files and executables.
|
|
... as wrongfully only sub-tree entries were added to
locally cached trees, although they should also store
entries for files and executables.
|
|
... and refactor static constant to proper format `kFdLess`.
|
|
|
|
... and therefore split the common `AtomicAdd()` into two functions
for adding from bytes or file path. The procedure for adding from
bytes remains the same. For adding from file path, we can link the
file directly and skip the rename, if the file did not exist and we
have ownership.
|
|
|
|
|
|
|
|
|
|
|