| Age | Commit message (Collapse) | Author |
|---|
|
...with a default implementation.
Although it is not used directly, it will be needed for instantiation of std::optional.
|
|
|
|
* No stackoverflow is possible: there is just one instance of ServeApi and services are relatively 'light';
* Services are not optional and cannot be changed during their use;
* operator-> is not free.
|
|
|
|
...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.
|
|
|
|
|
|
... but not all. Also in this case, if an target-level cache
entry is written, the dependencies have to be written as well.
|
|
... 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.
|
|
For libraries the headers of private dependencies were wrongly
skipped from staging. For binaries, no headers were passed at all
in the provides map. To fix these issues, an additional field is
added in the provides map to ensure we collect, and then properly
stage, all needed headers for both libraries and binaries.
|
|
...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.
|
|
|
|
This is useful when we want to install targets built in debug mode,
but do not want to stage all the additional source and header files
if no debugging is being performed, e.g., in tests.
|
|
...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.
|
|
... instead of defaulting to "". In this way, an empty default target can
be used as toolchain defaults for systems with default names.
|
|
|
|
This reduces the code duplication between the local and bazel APIs
and improves code maintainability.
|
|
|
