| Age | Commit message (Collapse) | Author |
|---|
|
...to track changes during refactoring easier.
|
|
...to track changes during refactoring easier.
|
|
|
|
... about processes producing both, stdout and stderr. By supporting
unique readability of the output, we facilitate the understanding
of the messages provided by actions.
|
|
... and thus allowing proper quoting of command output.
|
|
...to use corresponding Storage for storing auxiliary information.
|
|
...to enable validation of received blobs.
|
|
|
|
...bypassing BazelNetwork layer.
|
|
|
|
|
|
IExecutionApi::UploadFile was introduced to handle adding of a temporary file to the storage. The call was redirected to LocalCAS internal methods that do the similar thing, so this virtual method can be removed.
|
|
... for failures instead of the binary strict_logging. In this
way, we can log at log level Error in the serve instance, and for
the client at level Warning or Info, depending on whether failure
is expected (i.e., if targets are potentially taken from a serve
endpoint) or not.
|
|
After successful build of an export target target a cache entry is
written. As those export targets have a dependency structure, care
is taken to write them in correct order.
Writing a cache entry for an export target requires knowledge of
the analysis result of that target. Originally, all targets used
to be analysed locally, so that information was available for
every target that was not read from the local target cache already.
However, with the introduction of serve endpoints, it can happen
that a target was analyzed locally, but it depends on targets
obtained from serve. In this case, we have to refrain from writing
a target-level cache entry to keep the the consistency invariants
of the target-level cache.
|
|
Update logic populating containers to use the new method which
is aware of the maximum transfer limit.
|
|
...by proactively calling the Upload method for large blobs and
containers as soon as the transfer limit is reached.
|
|
This unifies the signature of all uploader functions consuming a
BlobContainer type.
|
|
As the ContentBlobContainer is used to store actual content needed
to be transferred, it is useful to automatically keep track of the
running (bytes) size of the data being stored.
|
|
... to allow generating symlinks as part of a rule, as it is already described
in our documentation.
|
|
...to reduce the "price" of copying.
|
|
...instead of BazelBlobContainer to not bring bazel_re::Digest to IExecutionApi.
|
|
|
|
|
|
|
|
...where the template parameter is the type of a digest.
|
|
...instead of various iterators.
|
|
|
|
...fixing potentially dangerous code (evaluation order is unspecified).
|
|
|
|
|
|
...in LocalApi and BazelApi.
|
|
...in LocalApi and BazelApi.
|
|
This reduces the code duplication between the local and bazel APIs
and improves code maintainability.
|
|
|
|
We can avoid doing extra work in converting between bazel digests
and artifact digests by actually using the API interface.
|
|
|
|
|
|
|
|
|
|
When populating the GitTree instance stored in a Git tree-type
FileRoot with the ignore-special flag set, the GitTree instance
would be created with an empty raw_id_ field, signaling that some
of the entries might have been skipped and thus the root tree id
is not anymore in a one-to-one correspondence with the stored list
of entries.
This however caused FileRoot instances with missing tree id
information. This commit fixes the issue by always storing the
raw_id_ field as the root id of the Git tree, as well as clarifying
the relationship between this field and the ignore_special_ flag,
including refactoring the tree id getters.
|
|
Once a RepositoryConfig instance gets populated, it must never be
changed again. Therefore, all functions accepting these instances
should only take them as pointers to const.
|
|
If the serve endpoint reports an internal error, local builds
should not continue and the error message should be provided.
Similarly, if the serve endpoint promises the target cache value to
be in remote CAS, but the client cannot find or process it as
needed, then a local build again should not continue and the reason
be provided as an error message.
|
|
The Emit method of the Logger class, when called with a string as
second argument, expects it to be a format string. It should be
considered a programming error to pass a string variable as that
argument without knowing for certain that it does not contain any
format escape character ('{', '}'); instead, one should be
conservative and use the blind format string "{}" as second
argument and pass the unknown string variable as third argument.
|
|
... to 320 chars for the configuration to keep error messages managable
in case of heavy configurations (e.g., generated internally by a complex
configure target).
|
|
... to keep error messages more readable.
|
|
Possibly empty directory path should be escaped.
|
|
|
|
|
|
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.
|
|
|
