| Age | Commit message (Collapse) | Author |
|---|
|
|
|
From a git CAS crate an execution API unable to execute
actions or to store anything. This implementaiton of the
common interface is still useful as the execution API
is the interface used for tranfering artifacts.
|
|
As those functions indicate success, it is up to the caller to
decide if the error was fatal or not. Reporting an error nevertheless
might result in error messages on successful operaitons, which is
confusing for the user.
|
|
- deduplicate dependencies
- remove unused dependency
|
|
|
|
|
|
|
|
...bazel_types.hpp just requires the messages, not the grpc related
services and classes
|
|
...both buildbarn and just execute do not allow a direct upload to the
action cache. Moreover, our tool does not support it, anyway, meaning
it was dead code.
|
|
The improved GC implementation uses refactored storage
classes instead of directly accessing "unknown" file paths.
The required storage class refactoring is quite substantial
and outlined in the following paragraphs.
The module `buildtool/file_system` was extended by:
- `ObjectCAS`: a plain CAS implementation for
reading/writing blobs and computing digests for a given
`ObjectType`. Depending on that type, files written to the
file system may have different properties (e.g., the x-bit
set) or the digest may be computed differently (e.g., tree
digests in non-compatible mode).
A new module `buildtool/storage` was introduced containing:
- `LocalCAS`: provides a common interface for the "logical
CAS", which internally combines three `ObjectCAS`s, one
for each `ObjectType` (file, executable, tree).
- `LocalAC`: implements the action cache, which needs the
`LocalCAS` for storing cache values.
- `TargetCache`: implements the high-level target cache,
which also needs the `LocalCAS` for storing cache values.
- `LocalStorage`: combines the storage classes `LocalCAS`,
`LocalAC`, and `TargetCache`. Those are initialized with
settings from `StorageConfig`, such as the build root base
path or number of generations for the garbage collector.
`LocalStorage` is templated with a Boolean parameter
`kDoGlobalUplink`, which indicates that, on every
read/write access, the garbage collector should be used
for uplinking across all generations (global).
- `GarbageCollector`: responsible for garbage collection and
the global uplinking across all generations. To do so, it
employs instances of `LocalStorage` with `kDoGlobalUplink`
set to false, in order to avoid endless recursion. The
actual (local) uplinking within two single generations is
performed by the corresponding storage class (e.g.,
`TargetCache` implements uplinking of target cache entries
between two target cache generations etc.). Thereby, the
actual knowledge how data should be uplinked is
implemented by the instance that is responsible for
creating the data in the first place.
|
|
... as internally we do not do the Tree-dance. Instead, we
directly store the root Directory digest for ActionResult's
OutputDirectories.
|
|
in the tree CAS.
Before this patch, after the checking in the tree cas, also the blob
cas was checked leading to a NOT-FOUND error.
|
|
google::longrunning::Operations::GetOperation
For each action that is executed, an entry is added to a shared thread
safe cache. Once the number of operations stored exceeds twice 2^n,
where n is given by the option --log-operations-threshold, at most 2^n
operations will be removed, in a FIFO scheme.
|
|
|
|
|
|
|
|
Co-authored-by: Sascha Roloff <sascha.roloff@huawei.com>
|
|
|
|
... by keeping track of each blob being a file or executable
and storing it to the correct local physical CAS directory.
The new flag is merely a hint and only used by the local
execution API. Leaving it out will still correctly transfer
the blob but may cause unnecessary duplicates in file CAS.
|
|
|
|
|
|
|
|
|
|
so that they can also be reported on the client side
|
|
|
|
|
|
This subcommand starts a single node remote execution service honoring
the just native remote protocol.
If the flag --compatible is provided, the execution service will honor
the original remote build execution protocol.
New command line args supported by this subcommand:
-p,--port INT: Execution service will listen to this port. If unset,
the service will listen to the first available one.
--info-file TEXT: Write the used port, interface, and pid to this file
in JSON format. If the file exists, it will be overwritten.
-i,--interface TEXT: Interface to use. If unset, the loopback device
is used.
--pid-file TEXT Write pid to this file in plain txt. If the file
exists, it will be overwritten.
--tls-server-cert TEXT: Path to the TLS server certificate.
--tls-server-key TEXT: Path to the TLS server key.
Co-authored by: Klaus Aehlig <klaus.aehlig@huawei.com>
|
|
|
|
client
|
|
|
|
|
|
Co-authored-by: Michael Thies <mail@mhthies.de>
|
|
|
|
... and ensure that cascades of checks are performed with
only a single filesystem stat per method.
|
|
|
|
This code movement is required to break a cyclic dependency coming with the
introduction of the garbage collector. target_cache depends on
garbage_collector and garbage_collector would depend on target_cache to
determine the target-level-cache directory. After moving this calculation to a
more general location, the cycle is broken.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While there, also add all direct dependencies explicitly; using
directly dependencies that are pulled in only indireclty causes
problems from a maintainability point of view.
|
|
|
|
This commit also introduces an incompatible change, since it modifies the way
how files are stored in the just cache directory. This modification reduces the
number of files per directory and only introduces a maximum number new
directories to avoid possible performance bottlenecks.
|
|
This change is introduced to be prepared for future changes such as garbage
collection. It is an incompatible change compared to earlier just versions
since it modifies the local path to the just cache directory, where among
others the CASes, action cache, target-level cache are located.
|
|
This enforces the explicit specification, which object type, either file or
tree, should be used to create an artifact digest. This also avoids subtile
errors at locations as in the previous commit, where files as well as trees are
supposed to be handled, but digest creation mistakenly defaults to file object
type.
|
|
The initial assumption before introducing the native remote execution protocol
was that only blobs were transmitted over the wire and put in a blob store.
With the native remote execution protocol, also trees can be transmitted over
the wire and they are put in a different store than blobs. Different hashing
functions are used for blobs and trees and need to be calculated accordingly
for data to be put in the correct store. This distinction of blobs and trees is
now implemented. Additionally, a warning is added that checks equality
between the requested digest and the digest computed by the received
content. This check makes sense to detect, e.g., corrupted messages,
unexpected transmission termination, or remote server failure.
|
|
Signed-off-by: Goetz Brasche <goetz.brasche@huawei.com>
|
