| Age | Commit message (Collapse) | Author |
|---|
|
...by using the new local api that can handle any remote endpoint,
irrespective of protocol.
Also ensure all tests for the serve service are now being run both
in native and compatible modes.
|
|
...to be able to interrogate remotes irrespective of protocol.
When serve endpoint is active, it will provide the correct digest
with which to interrogate the remote endpoint. Otherwise, for a
compatible remote check the file mappings for the correct digest.
The serve service proto file is updated accordingly.
|
|
...besides the simple Git hash, if syncing was done. This way one
can know what digest to ask for from the remote. The serve client
also needs to now know what hash function the remote expects.
The serve service proto file is updated accordingly.
|
|
In just-mr: to instantiate the new Git api instance, both storage
configs, as well as the compatible storage, need to be passed to
the maps. While there, use more explicit naming schemes for the
storage and CAS instances used.
In serve: also acquire gc locks for the local storages when needed
to instantiate the new Git api, which now has access to the CAS.
In all these instances we also pass, as needed, the local api, which
currently still operates only in native mode. This makes no
difference currently, but will ensure less changes needed when the
future compatible-aware local api will be used instead.
|
|
...to be later passed to maps that might need them.
This is a preparatory commit. Currently only the native storage is
actively being used.
|
|
As just-mr will always create Git roots, be explicit in the names
of variables to state that the default storage created is native.
|
|
|
|
|
|
|
|
The root async map in a chain of calls should always be checked
for missing value, which can happen if, e.g., a cycle happens or
a thread gets killed by the system.
Properly handle this by checking explicitly if a value has been
posted. If not, check for cycles where it makes sense (for
example, in the resolving of symlinks), otherwise report any
pending map keys not yet processed.
This is done for all just-mr commands working with async maps.
|
|
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.
|
|
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.
|
|
|
|
...and instead use simple instances created in setup, fetch, and
update, respectively. The various maps and the progress reporter
get access to these instances via not_null pointers.
|
|
...instead of using the singleton.
|
|
...instead of using the singleton.
|
|
|
|
...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.
|
|
...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.
|
|
...and replace it with passed instances created early via a builder
pattern.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
...since it is used for capturing in lambdas for AsyncMaps and mustn't be temporary.
|
|
...instead of std::optional<gsl::not_null<RepositoryConfig const*>>.
|
|
...instead of std::optional<gsl::not_null<IExecutionApi const*>>
|
|
|
|
|
|
|
|
...instead of initialization of the singleton.
|
|
...and adjust interfaces.
|
|
...instead of using singleton calls.
|
|
...to track changes during refactoring easier.
|
|
For setup and update subcommands, the consumer lambdas for their
respective async maps are non-trivial (i.e., do more than keeping
the map values) and operate on ungaurded JSON objects, thus it is
better to guard them against any uncaught exceptions.
|
|
When taking over roots from the input repository description, the
JSON value was not properly checked for validity (i.e., if it is of
type string), resulting in an unhandled exception being thrown. The
issue is fixed with a proper type check.
|
|
|
|
|
|
In order to set up roots, just-mr is able to interrogate, if given,
serve and/or remote-execution endpoints. However, just-mr operates
only with Git hashes, i.e., with a native mode CAS.
This commit ensures the correct interactions occur between just-mr
and the provided endpoints not only in native mode, but also in
comaptible mode, where a serve endpoint might be present even if
one cannot make use of its associated remote-exection endpoint.
The user always gets informed if any incompatibilities are
detected.
|
|
For archive repositories we need to ensure that a non-absent root
is backed by an archive content blob in the local CAS, in order to
also keep the proper root tree file associations. This change also
simplifies the content_cas_map logic by removing the previous
separation of implementation logic between fetching and setting up
the workspace root.
|
|
As the serve service always has an associated remote-execution
endpoint, when just-mr gets passed only a serve endpoint address it
will now default to implying a remote-execution endpoint exists too
at that address. Additionally, now the implementation of the
--backup-to-remote option more clearly shows that it can only be
done in native mode.
|
|
To take advantage of absent roots, we need to ensure that a given
serve endpoint can build against the tree of this generated root.
To this end, for a 'git tree' repository we only set the root as
absent only if the given serve endpoint has this root, or the tree
is known locally and can be provided via the remote CAS. While
generating an absent root the fetch command will never be called.
Generating an absent root without being provided a serve endpoint
is still allowed, but results in a warning.
|
|
Marking a file-type repository as 'to_git' results in a Git-tree
type root, which are of course content fixed and can be (and
usually are) used by export targets. Therefore, it is beneficial
for a serve endpoint, if one is provided, to be aware of such a
root and be able to build against it if needed. If the root is
marked as absent, this condition becomes mandatory.
Generating an absent Git-tree root without being provided a serve
endpoint is still allowed, but results in a warning.
|
