| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When serving the tree of an archive, we should check also in the
local CAS for the content blob.
|
|
|
|
... before trying to upload from local storage to the remote CAS.
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
The error log level should be reserved for events that inevitably
lead to a failed build. A failure to receive a target from the serve
endpoint, however, is not such a case; for performance reasons,
and also to have the same artifacts as everyone else in the case
of non-reproducible dependencies, just inquires the serve end point
for every export target whenever a serve end point is given. In
this case, the build just continues even if the serve end point
is, e.g., lacking a certain root.
|
|
|
|
|
|
|
|
|
|
This commit simply defines the logic needed for progress reporting.
|
|
request
|
|
|
|
The request should only be restricted to the minimal information
needed by the remote to answer it. In particular, the execution
endpoint address should not be transmitted.
|
|
Only the client needs to make sure that the remote execution
endpoint is set in the case 'just serve' acts also as
'just execute', i.e., when a remote execution endpoint is not
specified, while for setting up the serve server a missing
execution endpoint should remain unset.
|
|
In the scenario when 'just serve' acts as 'just execute', the
remote execution endpoint returned by the serve service should be
allowed to be empty.
In this case, from the server's perspective, there is nothing to be
checked, however a client might still want to ensure that its own
configured serve and execution endpoints match.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
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>
|
|
|
|
|
|
|
|
Also adds missing TARGETS file in serve_api folder and ensures
code comments are consistent with the proto file.
|
|
- add missing serve_api TARGETS file
- rename service client to align with server naming scheme
- fix inconsistencies in comments between implementation and protocol
|
|
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
|
|
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.
|
|
Just like the remote-execution protocol has several services (Execution,
ActionCache, ContentAddressableStorage, etc), so will the serve
protocol: the actual target-level caching, as well auxilliary
services, like the service to obtain the tree for a given root. Already
follow that scheme, before the protocol gets part of any release.
Also, move the status enum into the respective answer messages. In this
way, we can have different enums for different requests without causing
conflicts on the named enum constants.
|
|
server is started
|
|
The serve service will communicate with this endpoint when needed,
as well as ensure artifacts it provides are synced with the remote
execution CAS, if requested by the client.
If just-mr is given the --fetch-absent option, it Always produce
present roots irrespective of the 'absent' pragma. For Git repositories
marked with the 'absent' pragma, first try to fetch any commit
trees provided by the serve endpoint from the execution endpoint
CAS, before reverting to a network fetch.
Co-authored-by: Klaus Aehlig <klaus.aehlig@huawei.com>
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
