| Age | Commit message (Collapse) | Author |
|---|
|
|
|
! => not; && => and, || => or
|
|
Also switch to using the fields from RemoteContext instances
instead of those from ApiBundle.
|
|
...and replace it with passed instances created early via a builder
pattern.
Tests are also updated accordingly.
|
|
...wherever an ApiBundle is already being passed.
|
|
...instead of using singleton calls.
|
|
...with a default implementation.
Although it is not used directly, it will be needed for instantiation of std::optional.
|
|
|
|
...to track changes during refactoring easier.
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
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.
|
|
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.
|
|
|
|
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>
|
