| 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.
|
|
...and use it in fetch and repos_to_setup_map to remove code duplication.
|
|
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.
|
|
Main culprits:
- std::size_t, std::nullptr_t, and NULL require <cstddef>
- std::move and std::forward require <utility>
- unordered maps and sets require respective includes
- std::for_each and std::all_of require <algorithm>
|
|
|
|
|
|
... as this is the only part this map depends on, and not the
information on what to do with the archive, like style of unpacking,
etc. In this way, this map will also be reusable for fetching
foreign files.
|
|
|
|
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.
|
|
This is to uphold the coding style guide we employ.
|
|
|
|
... instead of some hard-coded strings, as that can be confusing
when the tool is packaged under a different name.
|
|
... which were only honored when doing fetch and setup.
|
