| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 0db6f248a04f5a23102b4208c1f28b3633c6ef8a.
We have our own build description for lzma, hence we are likely not
affected by CVE-2024-3094. Nevertheless, we should not encourage the
use or distribution of an archive that contains a known backdoor.
Reverting this commit also points us to a mirror that is still
fetchable.
|
|
... and not directly used by our tool.
|
|
|
|
|
|
Trees are first-class objects for justbuild. To allow interoperation
with other tools, it is necessary to provide those objects in a
standard format; for directories, those are archives. Hence procive
a corresponding option.
|
|
|
|
|
|
Main culprits:
- std::size_t, std::nullptr_t, and NULL require <cstddef>
- std::move and std::forward require <utility>
- unordered maps and sets require respective includes
- std::for_each and std::all_of require <algorithm>
|
|
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
|
