| Age | Commit message (Collapse) | Author |
|---|
|
For subcomputations add the log to CAS and only report the blob
identifier. Also, indicate at the beginning, that computed roots are
to be computed. While there, simplify code by using the ToString()
method of computed roots.
|
|
|
|
... also to the ToResult method of the result map.
|
|
The way we use our object cas, it is not unsual that a blob asked
for is not present. Therefore, logging this at debug level floods
that level with too many messages irrelevant for debugging. Fix this,
be demoting to trace level.
|
|
Add a basic implementation of computed roots. So far we neither
enforce nor make good use of the fact that the underlying target
of a computed root has to be an export target of a content-fixed
repository; instead, we always install the root to a temporary
directory and pick it up from there. Still, the basic functionality
is there, and it is minimally useful.
|
|
|
|
|
|
|
|
...instead of filling in a map passed from the outside.
|
|
... by using an exclusive lock. A lock of which only ever shared instances
are requested has no synchronisation effect. Fix this.
|
|
|
|
|
|
|
|
Also follow-up changes to ensure build success.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Requires the use of a pragma to avoid wrong removal suggestion for
path_hash.hpp.
Co-authored-by: Maksim Denisov <denisov.maksim@huawei.com>
|
|
|
|
IWYU needs to be explicitly instructed how to handle included .tpp
files in order to not falsely suggest their removal. Conversely,
it also needs to know not to suggest including .tpp files instead
of the corresponding .hpp files.
|
|
|
|
The class RepositoryConfig is mutable, but has a set-once derived
value, the largest bisimulation of the repositories described. This
construction is problematic in that it assumes that all modifications
be done before the first inspection of a value happens that implicitly
triggers the setting of the derived value. Therefore, at the very
least reset this derived value if a repository is modified.
|
|
... regardless of success. If traversing fails, we should just
return failure. In this way, we can also avoid an unnecessary
else-branch. While there, always return normally for tarverse,
avoiding direct exits.
|
|
|
|
|
|
|
|
As we write the first message about the actual upload of a blob,
we should use future rather than past tense. Also, again at trace
level, add a message of successful completion, if we succeeded.
|
|
|
|
The specification for this status code is as follows.
One or more errors occurred in setting up the action requested,
such as a missing input or command or no worker being available.
The client may be able to fix the errors and retry.
We routinely ensure all inputs are available to the remote execution
before we start an action, so all prerequisites will be there on a
compliant server, however might not actually be on a server where
the CAS only has eventual consistency or is incorrect (due to old
cache entries on CAS purge) in its answer to FindMissingBlobs.
While we have no guarantee that a retry will help, we still retry;
at least in the case of an unavailable worker or CAS entries not
yet available due to eventual consistency, this will help. Also,
we log at debug lvel the full response, including the repeated Any
message. In this way, we can find out what useful information (if
any) is sent by popular remote-execution services and implement
more specific mitigations in the future.
|
|
In BatchUploadBlobs we accept short writes and, in case of no progress,
fall back to single blob upload. Therefore, failure to upload blobs
is not fatal and therefore should not be reported at error level.
Decrease the log level accordingly: a protocol failure to upload is
a performance-related event (as the retry needs additional time),
catching an internal exception is something that shouldn't really
happen, so we warn the user.
|
|
In some situations, we use a retry strategy, but in case of complete
failure have another way of attempting that task. In this case, we
should not emmit an error message right away. Add support for this.
|
|
... instead of relying on those dependencies being pulled in
indirectly.
|
|
...by using the new local api that can handle any remote endpoint,
irrespective of protocol.
Also ensure all tests for the serve service are now being run both
in native and compatible modes.
|
|
...irespective of the used protocol.
This api is useful in enabling just-mr and the SourceTree service
of just serve to interact seamlessly with any remote-execution
endpoint.
|
|
When returning digests in responses, ensure they are of the type
the remote would know. Compatible digests can be found vis the
stored mappings from Git digests to bazel objects.
|
|
...instead of passing just the Git hash, which imposes the remote
to always be native.
The serve service proto file is updated accordingly.
|
