Age | Commit message (Collapse) | Author |
|
...whenever it is given access to a Git repository.
The referenced storage config needs to outlive the repository
config instance.
|
|
|
|
To properly use `just serve`, both the client and the serve instance
must talk to the very same execution endpoint. Typically, both the
client and serve can reach out to the execution endpoint via the same
IP address. However, it might be possible that the client and a serve
instance know the same execution endpoint by means of differnet IP
addresses. For example, the client knows the execution endpoint
address through an _external_ IP address, while the serve instance,
deployed within the same network infrastructure, only knows the
_internal_ IP address.
This patch adds the subkey `"client address"` -- of the key
`"execution endpoint"` -- in the serve configuration file, to specify
the alternative pair `address:port` used by the client.
|
|
Although references give an additional information about ownership, they introduce additional design difficulties.
|
|
|
|
...to remove the unnecessary link between folder name and the logic
of resolve_symlinks_map.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... instead of relying on those dependencies being pulled in
indirectly.
|
|
...instead of passing just the Git hash, which imposes the remote
to always be native.
The serve service proto file is updated accordingly.
|
|
...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.
|
|
|
|
|
|
|
|
|
|
...to prevent additional conversions to ArtifactDigest from plain strings.
|
|
|
|
...to simplify further refactoring.
|
|
|
|
! => 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.
|
|
...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
|