| Age | Commit message (Collapse) | Author |
|---|
|
Ignore-special git-tree-based roots are still content defined, so
one should use the correct marker in the JSON description of the
root that will be stored in the repository description of target
cache keys. This commit fixes the issue and improves documentation.
|
|
|
|
... as it is part of just-mr, which is an essential part of
the build system installation by now.
|
|
|
|
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.
|
|
The traverser instantiation consumes the arguments.build struct,
therefore one must not access that struct later in the code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This end-to-end test, of course, depends on the tools, provided
inside the test's working directory. The test, being end to end,
constructs a workspace with multi-repository configuration with
the main repo a file repsoitory at the root of the constructed
work space; to be able to test exporting this repository has pragma
"to_git". Move the constructed work space to sub directory to not
include the tools to be tested in the work space that is gitified;
one the one hand, the tested tools should not be part of the test
workspace and on the other hand, this shaves off a large fraction
of the test's run time.
|
|
|
|
Before trying to fetch an archive content from other non-local
sources, check first the just serve endpoint.
|
|
|
|
|
|
|
|
Whenever a just-serve endpoint is given, fetching archives or Git
commits from there is preferrable to fetching them from other
sources. Verify in the tests that this actually happens.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
...before going to the network, if 'just serve' endpoint given.
ContentCASMap was reworked to provide a cleaner logic for handling
pure fetches, which also reduced code duplication in ContentGitMap.
|
|
...before going to the network, if 'just serve' endpoint given.
|
|
Log levels on the server-side should reflect the meaning of the
status codes in the response messages. As such, anything that
leads directly to an error-type status code has been bumped up to
log level Error, the rest to log level Info.
|
|
... which should accumulate values from all base targets
unless the flag type (CFLAGS, CXXFLAGS, or LDFLAGS) is
explicity overwritten by the inheritor.
|
|
The man page for open(2) says the following to the O_SYNC flag: 'O_SYNC
provides synchronized I/O file integrity completion, meaning write operations
will flush data and all associated metadata to the underlying hardware.' This
flag results in a high delay when files are stored in casx, e.g., several
seconds for medium-sized files such as 23 MB. Since just does not care about
persistency, this strong synchronization mechanism is not required and is
deactivated.
|
|
The install target, like any other target, has to have artifacts
and runfiles being proper stages, i.e., in such a way that the
keys can be interpreted as names in the file system without causing
conflicts. This property used to be unchecked, thus allowing users
to define mal-formed targets that, when used as inputs to actions,
would result in unspecified layout of the action directory. Fix
this by adding an appropriate check enforcing well-formedness of
the resulting stage.
|
|
Added compatibility envariable to the with_serve rule, guarded
tests using --fetch-absent such that they run only in native mode,
and made all serve-service tests aware of the compatibility flag.
|
|
|
|
The `just serve` command defaults to also provide the remote-execution
endpoint if none is specified. The `just build` implicitly uses the
serve endpoint as remote-execution endpoint if no other endpoint is
specified. In this way, the serve endpoint has become the universal
endpoint for simple set ups. Simplify that usage further by providing
a short command-line option.
|
|
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.
|
|
...the client and serve use two different remote execution endpoints
fixup test
|
|
serve_target_remote_build.sh should be updated once just-serve can
orchestrate the remote build
|
|
This will allow end-to-end tests to pre-populate the serve build
root if needed.
|
|
|
|
|
|
|
|
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
"Configuration" services.
The RPC ServeTarget has not implemented the orchestration of remote
build yet. If the TargetCacheKey is not found in the target cache, the
response contains status == grpc::StatusCode::UNIMPLEMENTED.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
...a remote execution end-point for just-serve.
|
|
This service allows to query the configuration of the just-serve
instance. In particular, it is used to double-check that the
associated remote end point is the same used by the interrogating
client.
|
|
It defines two RPC:
- ServeTarget: Given a target-level caching key, returns the computed
value.
- ServeTargetVariables: Given the target-level root tree and the name
of an export target, returns the list of flexible variables from
that target's description.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
|
|
|
|
Absent roots are characterised only by a Git tree hash, so a new
variant of the underlying stored information was added in the form
of a plain string.
In order to avoid unwanted implicit conversions when instantiating
via literal strings, we force callers of the constructors to
explicitly differentiate between plain strings and filesystem
paths. Existing tests were updated to reflect this.
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
|
|
|
|
TargetCache...
...backed by the same CAS, but the FileStorage uses the given
shard. This is particularly useful for the just-serve server
implementation, since the sharding must be performed according to the
client's request and not following the server configuration.
|
|
This constructor is used by TargetService::ServeTarget
|
