| Age | Commit message (Collapse) | Author |
|---|
|
As it is common to use ArtifactDigest objects with a default value
of 0, the std::hash implementation should not take the size into
account. The is_tree member however should be kept in as it always
needs to have a value and has no sensible default.
|
|
|
|
|
|
|
|
|
|
Three new command line options have been added:
- `--max-attempts`
- `--initial-backoff-seconds`
- `--max-backoff-seconds`
|
|
...the provided function until either the function succeeds, maximum
number of attempts is reached or the function returns an error
indicating that we cannot simply retry.
It is meant to be used with rpc calls, but the logic can be applied to
other scenarios.
|
|
|
|
The ToJson method of RemoteAddress was wrongly creating a list
instead of a simple string, thus a wrongly formatted backend
description was being used to shard the target cache. This however
does not affect the correctness of the build.
Changelog also updated accordingly.
|
|
...options from the generated help messages, as these are not used
for the install-cas subcommand.
This also updates the man page accordingly, where the dispatch file
was marked as supported, as well as update any test affected by
these changes.
|
|
|
|
|
|
With the introduction of 'just serve', export targets can now be
built also independently from one another based on their
corresponding minimal repository configuration, as stored in the
target cache key.
In this context, this commit changes the RepositoryConfig usage
from one global (static) instance to pointers passed as necessary
throughout the code.
|
|
The `just serve` command defaults to also provide the remote-execution
endpoint if none is specified. The `just build` implicitly uses the
serve endpoint as remote-execution endpoint if no other endpoint is
specified. In this way, the serve endpoint has become the universal
endpoint for simple set ups. Simplify that usage further by providing
a short command-line option.
|
|
The function ToJson used `file_type` key to express the type of the
artifact, on the other hand, FromJson was expecting `type`.
This patch makes the two functions consistent, prefering `file_type`
for historical reasons.
|
|
This is required in order to make them available to 'just serve'
in a minimal just installation.
|
|
This was causing the remote serve address to overwrite the one set
for remote execution.
Also, to keep things clean, some common remote server-related
methods and definitions were moved into their own library.
|
|
|
|
|
|
|
|
|
|
... to allow selecting a sub object of a specified tree.
|
|
In this way, the user can specify which execution endpoint
to use depending on the execution properties.
|
|
|
|
This feature has been introduced with C++20.
|
|
... also, gracefully handle the case of a missing working
directory when determining the current module, falling back
to the top-level module.
|
|
|
|
... with two minor code base changes compared to previous
use of gsl-lite:
- dag.hpp: ActionNode::Ptr and ArtifactNode::Ptr are not
wrapped in gsl::not_null<> anymore, due to lack of support
for wrapping std::unique_ptr<>. More specifically, the
move constructor is missing, rendering it impossible to
use std::vector<>::emplace_back().
- utils/cpp/gsl.hpp: New header file added to implement the
macros ExpectsAudit() and EnsureAudit(), asserts running
only in debug builds, which were available in gsl-lite but
are missing in MS GSL.
|
|
- deduplicate dependencies
- remove unused dependency
|
|
... asking just to transfer everyting installed to the local CAS first.
|
|
|
|
...bazel_types.hpp just requires the messages, not the grpc related
services and classes
|
|
|
|
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.
|
|
|
|
... and, in this way, avoid duplication of these constants that
might lead to inconsistencies between those two tools later.
|
|
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.
|
|
... instead of only honoring the latest argument. In this way,
standard overlays coming from the launcher configuration can be
amended in individual invocations.
|
|
|
|
|
|
..., 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.
|
|
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>
|
|
Co-authored-by: Michael Thies <mail@mhthies.de>
|
|
|
|
|
|
|
|
... dumping only the configured targets that are export targets.
Those targets are of particular interest as those are the targets,
as they are the high-level caching points and also often serve
as interface between projects.
|
|
|
|
|
|
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.
|
