| Age | Commit message (Collapse) | Author |
|---|
|
|
|
... instead of relying on those dependencies being pulled in
indirectly.
|
|
|
|
|
|
...that is to be used by FileRoot::ToArtifactDescription.
|
|
|
|
...and move it to the common stage.
|
|
...to create ArtifactDigests.
|
|
|
|
|
|
...with ArtifactDigest.
|
|
Also update the classes documentation accordingly.
|
|
|
|
|
|
...to track changes during refactoring easier.
|
|
...and replace it with instances created early via a builder
pattern.
|
|
As the serve endpoint acts also as a regular client to its
associated remote-execution endpoint, it should employ the same
retry strategy as the regular just client.
Also updates ReadJustServeConfig to store the retry config
arguments instead of calling the RetryConfig singleton setters
directly, thus clearly separating the reading of the arguments from
the creation of any configuration singleton/instance.
|
|
The retry_parameters.hpp header-only library defining the Retry
class now is the retry_config.hpp header-only library defining the
RetryConfig class.
|
|
As it is used by just execute only, instantiate it inside the
ExecutionServer, which reads and writes to the cache map, and pass
a const ref to OperationsServer, which only queries.
|
|
Instead of computing the shard based on the RemoteExecutionConfig
singleton, use the already computed hash stored in the passed
StorageConfig instance, which now needs to be set up separately
if bootstrapping in order to avoid unwanted includes.
Storing the backend description to CAS and corresponding audit
checks now take place in main.
|
|
...such that it will be available to the TargetCache for sharing.
Also, GC does not require remote execution information, so the
logic for this subcommand is moved earlier in main.
|
|
|
|
|
|
|
|
|
|
...to properly fallback to local api if needed.
|
|
...instead of using singleton calls.
|
|
...instead of using singleton calls.
|
|
|
|
Also updates the tests and all relevant documentation accordingly.
|
|
... to simplify reuse.
|
|
... in a structured way to eventually support machine-readable access to
the identifiers of the log files.
|
|
|
|
Trees are first-class objects for justbuild. To allow interoperation
with other tools, it is necessary to provide those objects in a
standard format; for directories, those are archives. Hence procive
a corresponding option.
|
|
|
|
|
|
... and optionally upload them to a remote-execution endpoint.
|
|
...by allowing a Logger instance to be provided. Also adds a flag
in order for failed artifacts from builds orchestrated by the serve
endpoint to be able to be reported as errors instead of warnings.
|
|
...by allowing a Logger instance to be provided.
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
During analysis it is useful to track and report the progress for
all export targets. This is not exclusively linked to a serve
endpoint being present, despite most of the time being expected to
be spent in export targets being served from the remote endpoint.
This commit refactors the current implementation to give proper
feedback to the user on the progress of the analysis phase.
|
|
...with regular instances that have controlled life-times.
This avoids race conditions in tracking and reporting the results
of analysis and build, as the serve endpoint can orchestrate
multiple builds at the same time asynchronously. As a bonus
side-effect this also ensures the correctness of the progress
reporting per orchestrated build.
|
|
The serve endpoint always has to access the correctly sharded
target cache, including during analysis. For this purpose, the
target cache instance interrogated during analysis has to be
explicitly provided.
|
|
|
|
We ensure that for each export target to be written to the target
cache all its implied export targets are written to the target
cache first. This ensures that the target cache maintains its
consistency at all times with respect to export target
dependencies.
|
|
|
|
... of all produced binaries, including the intermediate
ones: protoc and grpc_cpp_plugin.
|
|
|
|
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"
|
|
Three new command line options have been added:
- `--max-attempts`
- `--initial-backoff-seconds`
- `--max-backoff-seconds`
|
