| Age | Commit message (Collapse) | Author |
|---|
|
...and adjust interfaces.
|
|
...instead of using singleton calls.
|
|
...instead of using singleton calls.
|
|
...instead of using singleton calls.
|
|
...instead of using singleton calls.
|
|
|
|
...to track changes during refactoring easier.
|
|
... for failures instead of the binary strict_logging. In this
way, we can log at log level Error in the serve instance, and for
the client at level Warning or Info, depending on whether failure
is expected (i.e., if targets are potentially taken from a serve
endpoint) or not.
|
|
Once a RepositoryConfig instance gets populated, it must never be
changed again. Therefore, all functions accepting these instances
should only take them as pointers to const.
|
|
... to simplify reuse.
|
|
... so that they are available in machine-readable form. In this
way, all logs can automatically be collected without the need of
parsing human-targeted error messages.
|
|
|
|
|
|
... so also report at info level if we got export targets served.
|
|
|
|
|
|
...in the tool proper, i.e., excepting tests.
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
...with regular instances that have controlled life-times.
This avoids race conditions in tracking and reporting the results
of analysis and build, as the serve endpoint can orchestrate
multiple builds at the same time asynchronously. As a bonus
side-effect this also ensures the correctness of the progress
reporting per orchestrated build.
|
|
The serve endpoint always has to access the correctly sharded
target cache, including during analysis. For this purpose, the
target cache instance interrogated during analysis has to be
explicitly provided.
|
|
... to clean up what can be done without losing cache information.
|
|
|
|
In order for the serve endpoint to correctly dispatch a build to
the correct remote-execution endpoint, the platform properties and
dispatch list for a build need to be passed explicitly to the
executor (via the graph traverser instance) instead of always being
taken from the RemoteExecutionConfig struct.
This commit implements these changes, including updating existing
tests accordingly.
|
|
|
|
Three new command line options have been added:
- `--max-attempts`
- `--initial-backoff-seconds`
- `--max-backoff-seconds`
|
|
Only the client needs to make sure that the remote execution
endpoint is set in the case 'just serve' acts also as
'just execute', i.e., when a remote execution endpoint is not
specified, while for setting up the serve server a missing
execution endpoint should remain unset.
|
|
|
|
|
|
|
|
|
|
Similarly to the jobs common argument, we can simply only pass the
needed single element from the analysis arguments struct. This will
allow for a clearer understanding of what target analysis requires
and reduce the overhead when reutilizing this method in just serve.
|
|
...to make it available also for setting up 'just serve' builds.
|
|
|
|
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.
|
|
|
|
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.
|
|
...a remote execution end-point for just-serve.
|
|
|
|
|
|
Use parallelism if provided by the build API when synchronizing
artifacts of export targets and when synchronizing artifacts due
to the --remember option. Do so at build parallelism as this the
parallelism suitable for the build API.
|
|
Typically, the number of export targets is small compared to the
size of the respective export targets. Moreover, export targets are
often chained, resulting in overlapping artifacts that we want to
fetch only once. Therefore, fetch export targets sequentially, giving
room to introduce parallelism in the individual fetch steps later.
While there, also log the beginning of the artifact synchronisation
for the export targets.
|
|
|
|
Initial version, to be extended later with other RPCs.
|
|
|
|
... by moving the diagnose and cli related code into to separate
libraries. In this way, we hopefully improve maintainability of
the code base.
|
|
...that std::filesystem::* calls produce. This is because existence
and type checks use almost exclusively std::filesystem::status,
which follows symbolic links, when being called with path arguments.
Instead, one should instead use these methods with the value
returned by a call of std::filesystem::symlink_status.
This commit also streamlines the FileSystemManager tests, as well
as replace bare calls to std::filesystem with their FileSystemManager
counterparts (where suitable).
|
|
In this way, the user can specify which execution endpoint
to use depending on the execution properties.
|
|
... and hence should be declared as such.
|
|
|
