| Age | Commit message (Collapse) | Author |
|---|
|
...and replace it with passed instances created early via a builder
pattern.
Tests are also updated accordingly.
|
|
...wherever an ApiBundle is already being passed.
|
|
...by making the respective Build methods const. It should be
perfectly valid for multiple Build calls to happen for the same
builder instance, so its internal state should never be invalidated
by, e.g., moving from internal fields.
|
|
|
|
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.
|
|
|
|
|
|
...instead of not_null const ptr.
|
|
|
|
|
|
...to properly fallback to local api if needed.
|
|
...and adjust interfaces.
|
|
...instead of initialization of the singleton.
Use builder for creation and validity check.
|
|
...and adjust interfaces.
|
|
...instead of using singleton calls.
|
|
...with a default implementation.
Although it is not used directly, it will be needed for instantiation of std::optional.
|
|
* No stackoverflow is possible: there is just one instance of ServeApi and services are relatively 'light';
* Services are not optional and cannot be changed during their use;
* operator-> is not free.
|
|
|
|
...to track changes during refactoring easier.
|
|
...to track changes during refactoring easier.
|
|
If the serve endpoint reports an internal error, local builds
should not continue and the error message should be provided.
Similarly, if the serve endpoint promises the target cache value to
be in remote CAS, but the client cannot find or process it as
needed, then a local build again should not continue and the reason
be provided as an error message.
|
|
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>
|
|
...by increasing granularity in client-side reporting. This allows
to correctly continue with builds of local targets if the serve
endpoint does not have the requested target, as well as improve
the reporting for users on failure.
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
|
|
|
|
As serve and just-mr share their caching of description-tree
association, we also have to change this cache. Thanks to json
encoding before hashing, we know that the old and new hash keys
do not overlap, so the change is save. As distdirs also keep the
respective files in the git root, no new downlaoding will happen
either, hence no warning in the CHANGELOG is needed.
|
|
The just serve client-side and API methods, as well as just-mr
utilities should use the noexcept specifier.
|
|
This request is needed by just-mr in order to verify that it can
use a provided serve endpoint when setting up the repository roots.
|
|
Also cleans up the logging when parsing the serve service
configuration file.
|
|
The requests to retrieve the tree of a commit, archive, or distdir
also set up those trees in a way that the serve endpoint can later
build against them, besides allowing just-mr to set up roots
locally. Therefore, if the witnessing entity (Git commit, content
blob, or distdir, respectively) is known to the serve endpoint,
then failing to set up the root tree there should result in a
failure also of the just-mr setup on the client side.
|
|
pragma-related RPCs
|
|
|
|
|
|
The error log level should be reserved for events that inevitably
lead to a failed build. A failure to receive a target from the serve
endpoint, however, is not such a case; for performance reasons,
and also to have the same artifacts as everyone else in the case
of non-reproducible dependencies, just inquires the serve end point
for every export target whenever a serve end point is given. In
this case, the build just continues even if the serve end point
is, e.g., lacking a certain root.
|
|
|
|
request
|
|
In the scenario when 'just serve' acts as 'just execute', the
remote execution endpoint returned by the serve service should be
allowed to be empty.
In this case, from the server's perspective, there is nothing to be
checked, however a client might still want to ensure that its own
configured serve and execution endpoints match.
|
|
|
|
|
|
|
|
|
|
|
|
With the introduction of 'just serve', export targets can now be
built also independently from one another based on their
corresponding minimal repository configuration, as stored in the
target cache key.
In this context, this commit changes the RepositoryConfig usage
from one global (static) instance to pointers passed as necessary
throughout the code.
|
|
|
|
If only the `--remote-serve-endpoint` option is specified on the
command line, the `--remote-execution-endpoint` is also set to the
given value.
This makes the spawning and usage of just-execute consistent. When
just-serve is started, if no remote execution endpoint is provided,
the same process will also act as a just-execute instance. With the
current patch, the client can thus only write, on command line, the
remote serve address, avoiding the repetition of the same address for
two different options.
|
|
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
|
|
|
|
- add missing serve_api TARGETS file
- rename service client to align with server naming scheme
- fix inconsistencies in comments between implementation and protocol
|
