| Age | Commit message (Collapse) | Author |
|---|
|
The context is passed by not_null const pointer in order to avoid
binding to temporaries, and it or parts of it get stored by const
ref where needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...to calculate the empty compatible hash.
|
|
...to track changes during refactoring easier.
|
|
...and replace it with instances created early via a builder
pattern.
|
|
Also store a const ref for usage in setting up a fresh ApiBundle
during target serve.
|
|
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.
|
|
As 'just execute' does not actually use the remote api, the
configuration instances created for it can be streamlined or moved
out of its scope.
|
|
...and replace it with passed instances created early via a builder
pattern.
Tests are also updated accordingly.
|
|
...wherever an ApiBundle is already being passed.
|
|
...and store it as a const ref for subsequent use wherever the apis
are already passed.
|
|
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.
|
|
...and replace it with passed instances created early via a builder
pattern.
|
|
|
|
|
|
As the storage instance also instantiates the target cache, we need
to ensure that each such instance has at that point all the correct
remote endpoint information to ensure the target cache sharding
works as expected.
In particular, the server-side and client-side operations of just
have a slightly different setup for the remote endpoint address,
therefore they require the storage instantiation to be done
separately.
|
|
|
|
|
|
|
|
...and adjust AnalyseContext.
|
|
|
|
|
|
|
|
|
|
|
|
...to track changes during refactoring easier.
|
|
|
|
Use a builder pattern for creation and validation, in a manner that
allows also other authentication methods to be added in the future
besides the current TLS/SSL.
The main Auth instances are built early and then passed by not_null
const pointers, to avoid passing temporaries, replacing the previous
Auth::TLS instances passed by simple nullable const pointers. Where
needed, these passed Auth instances are also stored, by const ref.
Tests also build Auth instances as needed, either with the default
'no certification' or from the test environment arguments.
|
|
|
|
...to more easily keep track of changes during refactoring.
|
|
|
|
|
|
|
|
|
|
...instead of std::optional<gsl::not_null<RepositoryConfig const*>>.
|
|
The build tool prints status messages at the end of each of the
major stages that sequentially follow each other. This allows,
in particular when using log files (that contain time stamps) to
quickly identify which phase was the resource consuming one. All
these message mention the (same!) configured target that is process
by this invocation of the build tool. In the presence of toolchains,
the configuration can, however, get quite large (containing lots of
paths to various tools). Therefore, shorted the configuration in the
repeated menions if it is very long (currenlty 320 characters); as
we do not change the first mentinoing ("Requested target is ..."),
even with that shortening the log contains the same information.
|
|
Most built-in rules are just described by their name, assuming they
are known to the user anyway. One exception, however, are "export"
targets, as those serve as interfaces to (logical) repositories and
hence is supposed to have a documentation of the target itself. Over
time, however, "configure" targets have evolved to become internal
interfaces (maybe even for an external target), e.g., to provide
default values and hence make better use of the actual export target.
Therefore it is desirable to provide a bit more information when
asked to describe a "configure" target.
- As "configure" targets have a fixed set of keys, adding a "doc"
field is a conservative extension; this can be useful to give an
overview what the target is about.
- An important information of a "configure" target is the target
that is configured. While this, in general, is an expression, in
the typical cases, the description is very short (a literal target
name, or a variable). So we can afford to show the definition.
|
|
...instead of not_null const ptr.
|
|
...instead of not_null const ptr.
|
|
|
|
|
|
|
