Age | Commit message (Collapse) | Author |
|
During the analysis of export targets, if there is a local target
cache miss, we should also interrogate the serve endpoint
(if given) for the target cache value before proceeding with the
analysis.
For this test we have extended the "with_serve" runner to expose
also the remote-execution build root to the test env.
|
|
|
|
While in our setting, a missing directory is generally OK, it is
not OK to ask for the content of an absent root. In particular, we
should not assume it to be empty, just because the root is absent.
|
|
|
|
When explaining CC tests, the option --request-action-input is used
to get hold of the actual test binary. This is the first time in
the tutorial where the action graph is larger than the part that
that is traversed during the build. Use this oportunity to explain
the difference between those concpets as, reportedly, some users
got confused about this.
|
|
|
|
Now we look for the tree also in the local CAS, not just in the
local Git cache. If found, we import the tree from local CAS to the
Git cache and continue as usual.
|
|
Now we look for the content blob also in the local Git cache, not
just in local CAS. If found, we store the blob read from Git cache
into local CAS and continue as usual.
|
|
Now we look for the content blob also in the local Git cache, not
just in local CAS. If found, we store the blob read from Git cache
into local CAS and continue as usual.
|
|
This fixes the multiple instances of (mainly) missing or wrong
includes of standard, third-party, and own headers in the
other_tools source folder.
|
|
This way we ensure each repository can be set up on its own and
nothing gets cached from other repositories, as opposed to the
parallel run where some caching is expected to occur.
|
|
|
|
This bug was introduced with the alternative mirrors changes.
|
|
If the option --absent is given in just-mr (either directly or
implicitly via the corresponding entry in the rc file), it rewrites
the "pragma" entries in the internal representation of the mr
repository config. When doing so, however, we have to take into
consideration that a workspace root is not necessarily the definition
of a repository, but can, alternatively, also be a reference to
another root. This was not taken into account; fix this by restricting
the rewriting to only json objects.
|
|
The just-serve config already honors specific fields to obtain the
information on how to authenticate to the remote-execution endpoint.
However, those have not yet been described in the man page yet. Do
this now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As we already have a good enough API call and in order to improve
specificity in log messages, there is no need for one more level of
abstraction. This will also make it easier to drop in the future
this check (if deemed unnecessary anymore), while keeping in place
the mandatory check that a serve endpoint has been configured.
|
|
|
|
... to support building with older GNU libstc++ versions.
|
|
While parsing the configuration file, if the key `"execution
endpoint"` is present, the following three keys are evaluated as well:
- "max-attempts"
- "initial-backoff-seconds"
- "max-backoff-seconds"
|
|
the rpc calls.
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
...by specifying which TargetCache instance to use. This will allow
'just serve' to store target cache entries into the correct sharded
location.
|
|
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.
|
|
|
|
|
|
|