| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
... while keeping our .clang-format file.
|
|
|
|
|
|
|
|
...and move the storing logic to Execute directly. There is no need to pass additional parameters to the method to just perform a check inside, and after this removal there is no need to preserve a one-line method.
|
|
|
|
The context is passed by not_null const pointer in order to avoid
binding to temporaries, and it or parts of it get stored by const
ref where needed.
|
|
As it is used by just execute only, instantiate it inside the
ExecutionServer, which reads and writes to the cache map, and pass
a const ref to OperationsServer, which only queries.
|
|
|
|
...instead of not_null const ptr.
|
|
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
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>
|
