| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When presenting a build, the output artifacts are hidden behind a
"details" environment to not overload the user with long list of,
e.g., test results (especially if generated by a test matrix). If,
however, only a single artifact is built, there is no reason to
hide it; so simply show it.
|
|
Given the just added json-file formatter, we can generate a diff
formatting properly all json files, i.e., all target, rules, and
expression files, by applying that formatter to every target file
and combining the patches. A target description doing precisely
this can easily be obtained as computed root. In this way, we also
make good use of caching. To avoid doing recomputing the target
description unnecessarily, we factor through the tree structure of
the repository tree; the latter, we obtain from the to-git view of
the top-level directory, whereas for computing the diff we use the
actual (not necessarily committed) files.
|
|
... that is aware of the order-independent fields in our C++ rules.
Co-authored-by: Maksim Denisov <denisov.maksim@huawei.com>
Co-authored-by: Oliver Reiche <oliver.reiche@huawei.com>
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
Our lint target already provides a target for the diff obtained
from clang format. Add a convenience script computing and applying
that patch.
|
|
|
|
|
|
To quickly understand where the problems found by the linter are,
an overall report can be useful, so that
just-mr --main lint build -P REPORT
immediately shows the problems found in the code. For convenience,
also include the patch to be applied to fix formating in the default
target.
|
|
Add a test verifying that no header files are picked up from an
indirect dependency.
|
|
Co-authored-by: Maksim Denisov <denisov.maksim@huawei.com>
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
Remove the test tainting of the distfiles target used in the large
tests and instead make an export target, as it is purely a source
tree. In this way, the distfiles tree can be truly absent and the
large tests can now also be delegated to the serve endpoint.
|
|
- in sequence containers, use operator[] instead of .at() when
accessing indices guaranteed to be in bound;
- in associative containers, prefer .find() and reusing the
returned const iterator to using .contains() and .at(); while
there, make any so obtained iterators const if they are read-only.
|
|
A typical compiler implicitly adds some search directories for system headers; those
might not be obvious for the bootstrapped clang-tidy. Therefore, use the bundled
headers of the clang toolchain. This has the additional advantage, that everyone
uses the same system headers for linting.
|
|
... by explicitly catching any possible exception. Mainly to make clang-tidy
happy.
...
|
|
Due to a random nature of the LargeObjectUtils generator, it may generate 2 identical files in a row. To prevent the test from failing, check that a newly generated file doesn't collide with any already added to the CAS.
|
|
Environment variables can be used to provide some context, why a
particular invocation was run, and hence allow additional sharding.
Also, remind that setting up a cronjob for log rotation might me
a good idea.
|
|
... mentioning that now etc/repos.in.json is used for bootstrapping.
This is relevant for both, determining the precise list of dependencies
needed as well as for patching the repository configuration, e.g.,
in a package build.
|
|
To allow everyone to lint in the same way with minimal manual
setup effort.
|
|
|
|
... using the already-committed configuration file and the
version of clang-tidy that was imported from the toolchain.
|
|
... as repository configuration. We know that everything imported is
not needed for the bootstrap process. Hence, by taking the description
before import, we can avoid fetching unnecessary archives.
|
|
... and make it available to a new "lint" repository. In this way,
there is no dependency of the main or test repository on the newly
importet toolchain, while the "lint" repository has access to a
well-defined version of clang-tidy.
|
|
|
|
|
|
|
|
...that ignores compactification.
|
|
|
|
Linting is a natural example where actions are discovered that are
not neded for the artifact that is requested to be built. Use this
opportunity to explain the difference between discovering an action
and processing it.
|
|
This test uses a file repository at "." with the "to_git" pragma.
Now, if we build the tool to be tested in debug mode, the sources
end up in the test's action directory. If we take the work dir
of the simulated use case top level, all these sources end up
unnecessarily in the workspace root of the test repo. Avoid this
overhead by moving to a subdirectory.
|
|
|
|
|
|
...also on failure or warning.
|
|
...in creating Git tree from filesystem directory.
|
|
|
|
|
|
...in methods that should not report at error level themselves,
but let this be handled by its callers.
While there, remove an unneeded path manipulation in a defferent
set of log messages.
|
|
...while also removing some unneeded one.
Do not implicitly trust that the third-party code called in these
methods is non-throwing and instead properly handle any exception
that might arise. Also remove the specifiers from some anonymous
namespace methods where a try-catch would be overkill and let
their callers handle any exceptions instead.
|
|
...and fix inconsistent capitalisation.
|
|
Do not implicitly trust that the third-party code called in these
methods is non-throwing and instead properly handle any exception
that might arise.
|
|
|
|
... to include at least all pages referenced throughout the man page.
|
|
|
|
|
|
... which should not do any symlink checks in compatible
mode.
|
|
|
|
This ensures that any entries that the standard remote execution
protocol accepts but are invalid in justbuild, i.e., upwards
symlinks, are rejected.
For this purpose, do not fail in the action response instances,
just perform the check there, as all required information is
available, and set a flag that the executor can check as needed.
|
|
While in practice a failure to populate the fields of a response
happens once per invocation, as it will trigger a failure of the
execution, from an algorithmic standpoint the flag to mark a
successful population of the response fields should only be set on
actual success.
Fix this.
|
|
...and remove specifiers from methods that might throw in
unexpected ways. By doing this, balance the need to avoid wrongly
silencing exception sources during execution with reducing the
amount of try-catch blocks.
|
|
This will check if directories contain upwards symlinks.
|
|
The execution server itself should not consider anything special in
setting the response message to the client, instead let the
underlying API fail or not during collection.
|
