| Age | Commit message (Collapse) | Author |
|---|
|
In general, in the log produced by `just serve`, we want at most one
entry at INFO level or higher per successfull request. Therefore,
downgrade the log level of all operations that are carried out in
a loop over all repositories that just serve takes care of.
|
|
|
|
This test tries to demonstrate that even if the remote-execution
has forgotten the action, the target-level cache of just serve
will allow a successful build without repeating the action. It
does it by cleaning the local build root of the remote-execution
service. If, however, serve and execute are the same process, they
also use the same local build root, so the target-level cache entry
needs to be kept alive separately.
|
|
... i.e., support testing the use case that the serve instance simultaneously
acts as remote-execution endpoint.
|
|
As just serve can simultaneously act as remote-execution endpoint,
it has to accept in its configuration all the necessary information,
in particular, the local launcher. Add it.
|
|
The base functionality is already implemented. Also, the default has
changed with respect to the design to make reading symlinks the default
and only follow symlinks if the optin --follow-symlinks is given.
|
|
|
|
|
|
... and optionally upload them to a remote-execution endpoint.
|
|
|
|
|
|
When running in single node, serve endpoint should not even
consider sharding. Additionally, garbage collection uplinking
should also take the shard into account. For this purpose, a
TargetCache instance now remembers if it was explicitly sharded and
passed that information to the GarbageCollector for uplinking.
|
|
|
|
|
|
...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.
|
|
When the serve endpoint has all the information to analyse a
target, any analysis or build errors should be made available to
the client. This way the user can receive a relevant error report.
|
|
|
|
...by allowing a Logger instance to be provided. Also adds a flag
in order for failed artifacts from builds orchestrated by the serve
endpoint to be able to be reported as errors instead of warnings.
|
|
|
|
...by allowing a Logger instance to be provided.
|
|
...by allowing a Logger instance to be provided.
|
|
This allows to be explicit and thus have better control on where
messages get logged.
|
|
|
|
...as it is redundant here and exception prone.
|
|
...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
|
|
... simultaneously, in order to find race conditions during
the build.
|
|
As a library, that target depends implicitly on the toolchain,
hence the already present export of "TOOLCHAIN_CONFIG", but also
the environment for using that toolchain. So, export "ENV" as well.
|
|
... so that they can be served and hence the corresponding
dependency can be absent.
|
|
... so that any updates of the local-build-root layout are correctly
taken into account. In particular, this change also moves the temporary
directory under the emphemeral root, allowing more quick clean up.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
Commit 2ebf355989eb92ac9967eceee0af14d39477afe0 moved the tmpdir
creation for various tasks into the task itself. In doing so, TmpDir
was called with a relative path; that was, however, is interpreted
relative to the working directory, violating the property that
our tool never write anything outside the local build root unless
explicitly asked to do so (by specifying the output path in an
install or install-cas invocation). Fix this, by calling the the
tmp-dir function that is storage-layout aware.
|
|
... as the fs_utils have a lot more dependencies making them usable
in less places. Moreover, this function also serves to shape the
layout of the local build root and hence is more appropriately
placed in the config anyway.
|
|
Some of our C-tests under catch2 may rely on the local build root
to get a proper tmp directory; ensure this is set properly to avoid
falling back to the user's home directory.
|
|
|
|
... as it is already encoded to be meaningfully printable.
|
|
... with effective config instead of the actual cache key, which
is simply a blob identifier that is probably not so meaningful for
the user watching the build.
|
|
... instead of blindly assuming the evaluation succeeds.
Co-authord-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
During analysis it is useful to track and report the progress for
all export targets. This is not exclusively linked to a serve
endpoint being present, despite most of the time being expected to
be spent in export targets being served from the remote endpoint.
This commit refactors the current implementation to give proper
feedback to the user on the progress of the analysis phase.
|
|
...when orchestrating a build.
|
|
|
|
...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.
|
|
This is needed in order to pass the correctly instantiated
TargetCache to AnalyseTarget even when bootstrapping 'just'.
|
|
... verifying that
- emphemeral directories are removed,
- left-over remove-me directories are removed, and
- the available content of CAS and cache are not affected.
|
|
... to clean up what can be done without losing cache information.
|
|
... and make rotation of generations optional, as with the removal
of ephemeral data there is now a useful collection even without
rotating generations.
|
|
... under a common root in the youngest generation. This will allow
a simple way of cleaning them up during garbage collection.
|
|
|
|
|
|
|
