| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
... overriding the default implementation. In this way, files can
be added directly to the local CAS without having to completely
reside in memory.
|
|
When using blob splitting, we expect to create a potentially large
file. Therefore reconstruct it from its parts on disk rather than
keeping the whole file in memory.
|
|
Allow implementations to have a specialized way of uploading a file
owned by the build process to the applicable cas, both as file, as
well as as tree object (in native mode).
If no implementation is provided, the default is to read the file
into memory and use the Upload method.
|
|
|
|
Extend our internal hash-function abstraction to support hashing
of files. In this way, we can provide a way to compute the hash of
a potentially large file without having to fully read it to memory
first, while still keeping the details of the used hash function
abstracted away.
|
|
|
|
Ignore-special git-tree-based roots are still content defined, so
one should use the correct marker in the JSON description of the
root that will be stored in the repository description of target
cache keys. This commit fixes the issue and improves documentation.
|
|
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 traverser instantiation consumes the arguments.build struct,
therefore one must not access that struct later in the code.
|
|
|
|
|
|
|
|
Before trying to fetch an archive content from other non-local
sources, check first the just serve endpoint.
|
|
|
|
|
|
|
|
...before going to the network, if 'just serve' endpoint given.
ContentCASMap was reworked to provide a cleaner logic for handling
pure fetches, which also reduced code duplication in ContentGitMap.
|
|
...before going to the network, if 'just serve' endpoint given.
|
|
Log levels on the server-side should reflect the meaning of the
status codes in the response messages. As such, anything that
leads directly to an error-type status code has been bumped up to
log level Error, the rest to log level Info.
|
|
The man page for open(2) says the following to the O_SYNC flag: 'O_SYNC
provides synchronized I/O file integrity completion, meaning write operations
will flush data and all associated metadata to the underlying hardware.' This
flag results in a high delay when files are stored in casx, e.g., several
seconds for medium-sized files such as 23 MB. Since just does not care about
persistency, this strong synchronization mechanism is not required and is
deactivated.
|
|
The install target, like any other target, has to have artifacts
and runfiles being proper stages, i.e., in such a way that the
keys can be interpreted as names in the file system without causing
conflicts. This property used to be unchecked, thus allowing users
to define mal-formed targets that, when used as inputs to actions,
would result in unspecified layout of the action directory. Fix
this by adding an appropriate check enforcing well-formedness of
the resulting stage.
|
|
|
|
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.
|
|
If only the `--remote-serve-endpoint` option is specified on the
command line, the `--remote-execution-endpoint` is also set to the
given value.
This makes the spawning and usage of just-execute consistent. When
just-serve is started, if no remote execution endpoint is provided,
the same process will also act as a just-execute instance. With the
current patch, the client can thus only write, on command line, the
remote serve address, avoiding the repetition of the same address for
two different options.
|
|
|
|
|
|
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
"Configuration" services.
The RPC ServeTarget has not implemented the orchestration of remote
build yet. If the TargetCacheKey is not found in the target cache, the
response contains status == grpc::StatusCode::UNIMPLEMENTED.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
...a remote execution end-point for just-serve.
|
|
This service allows to query the configuration of the just-serve
instance. In particular, it is used to double-check that the
associated remote end point is the same used by the interrogating
client.
|
|
It defines two RPC:
- ServeTarget: Given a target-level caching key, returns the computed
value.
- ServeTargetVariables: Given the target-level root tree and the name
of an export target, returns the list of flexible variables from
that target's description.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
|
|
|
|
Absent roots are characterised only by a Git tree hash, so a new
variant of the underlying stored information was added in the form
of a plain string.
In order to avoid unwanted implicit conversions when instantiating
via literal strings, we force callers of the constructors to
explicitly differentiate between plain strings and filesystem
paths. Existing tests were updated to reflect this.
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
|
|
|
|
TargetCache...
...backed by the same CAS, but the FileStorage uses the given
shard. This is particularly useful for the just-serve server
implementation, since the sharding must be performed according to the
client's request and not following the server configuration.
|
|
This constructor is used by TargetService::ServeTarget
|
|
|
|
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.
|
|
Also extended absent-roots test with this scenario.
|
|
|
|
This function is mainly used to check that the hash of a Digest
received over the wire is a real hash, to prevent a malicious attack.
|
|
... which was accidentially a list of (a single) object,
instead of only a single JSON object.
|
|
|
