| Age | Commit message (Collapse) | Author |
|---|
|
...to more easily keep track of changes during refactoring.
|
|
|
|
|
|
|
|
...instead of std::optional<gsl::not_null<RepositoryConfig const*>>.
|
|
The build tool prints status messages at the end of each of the
major stages that sequentially follow each other. This allows,
in particular when using log files (that contain time stamps) to
quickly identify which phase was the resource consuming one. All
these message mention the (same!) configured target that is process
by this invocation of the build tool. In the presence of toolchains,
the configuration can, however, get quite large (containing lots of
paths to various tools). Therefore, shorted the configuration in the
repeated menions if it is very long (currenlty 320 characters); as
we do not change the first mentinoing ("Requested target is ..."),
even with that shortening the log contains the same information.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...and adjust interfaces.
|
|
...instead of initialization of the singleton.
Use builder for creation and validity check.
|
|
...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.
|
|
|
