| Age | Commit message (Collapse) | Author |
|---|
|
... so that tagging in the associated git root can be synchronized
with other services provided by just serve.
|
|
|
|
...instead of adding it preliminarily.
|
|
|
|
...to let it be stored as an independent instance.
|
|
|
|
|
|
... given that a proper reporting of the return code if
repo_config.SetGitCAS is contained in main anyway. Therefore, log
the details trying to set the git cas to a level less than that of
the final reporting.
|
|
... as the base repository of a computed root might be absent.
|
|
|
|
...and use expected to replace it.
|
|
To avoid unnecessary staging and git imports of computed roots for
build in compatible mode, use the rehashing functionality to allow
us to compute the git tree of that root in memory.
|
|
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.
|
|
|
|
|
|
... 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.
|
|
|
|
The origins of actions are useful for understanding the action
graph; if, however, the action graph is only to be used for further
computaiton, this is unnecessary information. Therefore, add an
option to dump the action graph without origins.
|
|
|
|
|
|
|
|
...and move it to the common stage.
|
|
|
|
! => not; && => and, || => or
|
|
... right after having successfully finished analysing the target.
As a side effect, we also get the statistics of the export targets
reported on analysis requests. As cached export targets project
artifacts to known ones, that information is highly relevant there.
|
|
Also update the classes documentation accordingly.
|
|
This will allow for ApiBundle to be used together with the TestApi
implementation of IExecutionApi in tests.
Also rename CreateRemote method to MakeRemote in order to remove
any semantical confusion.
|
|
|
|
It is passed as a not_null const pointer, to avoid binding to
temporaries, and stored as a const reference to be later passed
also to Executor/Rebuilder.
|
|
|
|
Also switch to using the fields from RemoteContext instances
instead of those from ApiBundle.
|
|
Also switch to using the fields from RemoteContext instances
instead of those from ApiBundle.
|
|
The CreateRemote method is also updated to receive all
remote-related information as arguments, such that it does not have
to rely on the ApiBundle internal fields which will eventually be
removed.
|
|
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 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.
|
|
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.
|
|
...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.
|
