| Age | Commit message (Collapse) | Author |
|---|
|
Now the curl URL API always fails to parse the empty string, so
our test was changed to reflect this.
|
|
|
|
|
|
|
|
Also updated the remote fetch repository, as the previous upstream
repository has since been archived.
|
|
Also updates the test-mixed-bootstrap script which must use the
explicit library version.
|
|
|
|
|
|
Numerical values are used at some places in justbuild: as value for
timeout scaling, as well as by the "range" expression that is used,
e.g., to define repreated test runs. Therefore, improve support
for numerical values by adding basic operations.
|
|
For an absent export target, the first step of analysis is to ask
serve for the flexible variables. The answer to this request is,
however, independent of the configuration for this target. So we
can avoid calls by caching the answer in an additional map.
|
|
|
|
For export targets, we know ahead of time the effective configuration;
so, if the current configuration is not the effective anyway, we
can simply analyse the effective configuration and take that result.
In this way, we can avoid calls to serve if a target is analysed
in two configurations that coincide on the flexible variables.
|
|
|
|
For export targets, we know ahead of time the effective configuration;
so, if the current configuration is not the effective anyway, we
can simply analyse the effective configuration and take that result.
As a side effect, we also count the number of observed export
targets correctly.
|
|
... so also report at info level if we got export targets served.
|
|
|
|
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.
|
|
|
