| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
The default remote-execution protocol (which is used in compatible mode)
defines symbolic links as embedded fields within a Directory message. No
separate blobs will be stored in CAS, but they are required, e.g., when a tree
is installed. To fix that issue, we upload any symbolic link received from the
remote execution either as explicit output or as part of an output Directory
message as separate blob to the remote CAS, similar how we handle output
Directory messages themselves.
|
|
|
|
|
|
|
|
... and not only the hash of the blob containing the log of the
failed build. In compatible mode, it is necessary to have the full
digest (including the size) to download a blob from the remote CAS.
|
|
|
|
...and amend the error message.
|
|
...which should be downloaded before the execution starts.
|
|
|
|
|
|
When user setting `remote-execution-properties` with commandline, we
assume that input value must have format with `key:val`, in that case,
if `val` includes colon(s), the real value after parsing won't be the
same as user intends to have, for example, considering commandline flag:
`--remote-execution-properties image:test.registry:8080/test`, will be
parsed into a pair `<image, test.registry>` in existing implementation.
Since it's reasonable to allow colon(s) in execution property value, we
should allow this case, and still keep the restriction on key format.
Signed-off-by: Bin Yu <yubin14@huawei.com>
|
|
Now that support for split/splice is part of the official
capabilites announcement, use those to determine if we should try
splitting/splicing. This change is actually mandatory as the new
standard mandates that clients must check before trying to use
the service.
Co-authored-by: Klaus Aehlig <klaus.aehlig@huawei.com>
|
|
So far, blob split/splice was an extension of our build tool; now
it got standardized. Therefore we can, and hence should, use the
official proto file without modifications. As algorithm negociation
is not yet standardized, drop it for now; we will readd it, once
a standard is agreed upon.
|
|
... and while there, add Oxford comma to make the comment clearer.
|
|
|
|
|
|
|
|
|
|
|
|
The google-default-arguments check normally imposes that virtual
methods have no default arguments. For our use-cases, all
implementations of such methods are expected to use the same
default arguments, and thus this check is manually disabled via
NOLINT comments. However, this is not done consistently.
This commit cleans this up and clarifies our intent by:
- removing the default values (and the NOLINT statement) for all
implementations of virtual methods with default argument values,
matching the desired intended behaviour, but
- keeping the clang-tidy check for future cases where derived
classes would want to provide each different defaults.
|
|
|
|
... and prepare local execution for clients
using only RBEv2.1 (setting only output_paths).
|
|
|
|
... as it is only needed for local execution, there is no
need to provide it in the common api interface.
|
|
|
|
... as Justbuild has a strict separation between output
files and output directories, but the RBE protocol does
not necessarily maintain such a separation and therefore
does not perform such a verification.
|
|
|
|
|
|
- in sequence containers, use operator[] instead of .at() when
accessing indices guaranteed to be in bound;
- in associative containers, prefer .find() and reusing the
returned const iterator to using .contains() and .at(); while
there, make any so obtained iterators const if they are read-only.
|
|
... by explicitly catching any possible exception. Mainly to make clang-tidy
happy.
...
|
|
|
|
...that ignores compactification.
|
|
...also on failure or warning.
|
|
...in creating Git tree from filesystem directory.
|
|
|
|
|
|
...in methods that should not report at error level themselves,
but let this be handled by its callers.
While there, remove an unneeded path manipulation in a defferent
set of log messages.
|
|
...while also removing some unneeded one.
Do not implicitly trust that the third-party code called in these
methods is non-throwing and instead properly handle any exception
that might arise. Also remove the specifiers from some anonymous
namespace methods where a try-catch would be overkill and let
their callers handle any exceptions instead.
|
|
...and fix inconsistent capitalisation.
|
|
Do not implicitly trust that the third-party code called in these
methods is non-throwing and instead properly handle any exception
that might arise.
|
|
|
|
|
|
This ensures that any entries that the standard remote execution
protocol accepts but are invalid in justbuild, i.e., upwards
symlinks, are rejected.
For this purpose, do not fail in the action response instances,
just perform the check there, as all required information is
available, and set a flag that the executor can check as needed.
|
|
While in practice a failure to populate the fields of a response
happens once per invocation, as it will trigger a failure of the
execution, from an algorithmic standpoint the flag to mark a
successful population of the response fields should only be set on
actual success.
Fix this.
|
|
...and remove specifiers from methods that might throw in
unexpected ways. By doing this, balance the need to avoid wrongly
silencing exception sources during execution with reducing the
amount of try-catch blocks.
|
|
This will check if directories contain upwards symlinks.
|
|
The execution server itself should not consider anything special in
setting the response message to the client, instead let the
underlying API fail or not during collection.
|
|
|
