Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
... and, in this way, avoid duplication of these constants that
might lead to inconsistencies between those two tools later.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
commit update
Uses the SSL certification utility method to correctly set the
certification check options for the remote URL libgit2 calls.
Due to the fact that remote operations are done via a temporary
repository to allow concurrent work, the correct repository
configuration needs to be interrogated. Thankfully, libgit2
provides a thread safe config snapshot object to be used in
such scenarios.
Also updates the existing GitRepoRemote tests accordingly.
|
|
|
|
... instead of only honoring the latest argument. In this way,
standard overlays coming from the launcher configuration can be
amended in individual invocations.
|
|
|
|
|
|
... by providing the fully-qualified name of an expression
that could not be found.
|
|
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.
|
|
|
|
...in order to not include unwanted dependencies in just proper.
The new class extends the GitRepo class used for just's Git tree
operations and gets used in all of just-mr's async maps.
|
|
..., i.e., the requirement that the positional arguments form a
syntactically valid target name. An explicit error message (created
by the target-name parsing) is preferrable over tacitly dropping all
but the last up to two arguments (which is the meaning of CLI11's
expected(2)).
While there, drop duplicate full stop in error message.
|
|
|
|
|
|
|
|
|
|
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>
|
|
|
|
|
|
While compilers are allowed to drop unused functions in anonymous
name spaces, and in this way also the open linker symbols referenced
there, they are not obliged to do so. Not optimizing away such
unused functions when compiled with -DBOOTSTRAP_BUILD_TOOL causes
the linking fail in the initial phase of the boostrap process where
libgit2 is not yet available (nor really needed). Therefore, ensure
that those dead functions are absent in the initial bootstrap phase
using appropriate preprocessor directives.
Signed-off-by: Klaus T. Aehlig <aehlig@linta.de>
|
|
|
|
... and ensure that cascades of checks are performed with
only a single filesystem stat per method.
|
|
|
|
As now all remote Git operations in GitRepo require at most just
the branch name, there is no more need to inquire the repository
about branch refspecs.
|