Age | Commit message (Collapse) | Author |
|
... so that at this level, the full activity of the serve service can
be monitored.
|
|
|
|
|
|
|
|
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.
|
|
|
|
...to remove the unnecessary link between folder name and the logic
of resolve_symlinks_map.
|
|
|
|
|
|
|
|
...and use expected to replace it.
|
|
|
|
|
|
|
|
... instead of relying on those dependencies being pulled in
indirectly.
|
|
...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.
|
|
When returning digests in responses, ensure they are of the type
the remote would know. Compatible digests can be found vis the
stored mappings from Git digests to bazel objects.
|
|
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.
|
|
...native and compatible, even if currently only native is active.
While there, be more explicit in which storage instance is being
used.
|
|
|
|
|
|
...to get the protocol type.
|
|
...and move it to the common stage.
|
|
...to create ArtifactDigests.
|
|
...to create ArtifactDigests.
|
|
|
|
Also update the classes documentation accordingly.
|
|
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.
|
|
...for orchestrated builds.
As the dispatch list and execution properties need to be parsed,
place them in a proper RemoteExecutionConfig, to be passed to the
created ApiBundle instance.
|
|
The context is passed by not_null const pointer in order to avoid
binding to temporaries, and it or parts of it get stored by const
ref where needed.
|
|
The context is passed by not_null const pointer to avoid binding to
temporaries. The LocalApi also stores the context as const ref for
further access and passing it to LocalAction.
|
|
|
|
...to track changes during refactoring easier.
|
|
|
|
Also store a const ref for usage in setting up a fresh ApiBundle
during target serve.
|
|
As it is used by just execute only, instantiate it inside the
ExecutionServer, which reads and writes to the cache map, and pass
a const ref to OperationsServer, which only queries.
|
|
...wherever an ApiBundle is already being passed.
|
|
...by using the new DescribeBackend method instead. This ensures
that the TC shard computation is indeed consistent between local
and serve endpoint.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...to properly fallback to local api if needed.
|
|
...instead of using singleton calls.
|