| Age | Commit message (Collapse) | Author |
|---|
|
End-to-end tests should, like all tests, be independent of any
non-project files the user has in their home directory. This also
applies when running the tests locally. In particular, end-to-end
tests should not read the user's ~/.just-mrrc. Therefore, properly
set --norc in all end-to-end tests (where this is not already
the case).
|
|
...when calling std::filesystem::weakly_canonical, since the latter converts the argument path to an absolute path internally.
|
|
|
|
|
|
|
|
In all presentations of actions to the user, we use output paths
relative to the root of the action directory. Therefore, we should
do the same in the profile. However, when noting the completion of
an action, we get paths as in the wire protocol, i.e., relative to
the working directory of the action. Therefore, rebase appropriately.
|
|
|
|
and while there, replace `auto` with explicit signatures.
|
|
|
|
|
|
|
|
We use a pointer to the actual Profile object to handle profiling,
if requested. For this to work, actual object needs to stay in
scope. However, we handle most of the operations, including parsing
of arguments, in a global try-catch block. In order to be able to
also correctly write a profile file outside this block, move the
scope of the Profile object to top-level in main.
While there, also improve the signature of the Profile class. That
class is only meaningful, if a profile should eventually be writting
to disk. So reflect this in the constructur. Also, once we know the
file name to write the profile to (if any), we have already parsed
the command line; so the making available of the command line to the
profile can be enforced by adding this to the constructor as well.
Co-authored-by: Denisov Maksim <denisov.maksim@huawei.com>
|
|
As parsing the the command-line is non-trivial, we include all the
relevant information about the command line in the profile. This
should also include the subcommand. For sake of completeness, we
also include the non-option arguments of the subcommand.
|
|
|
|
|
|
Extend the profile by including non-zero exit codes of individual
actions. When looking at an individual build invocation, the actions
with non-zero exit code are often the interesting ones, like root
cause of a build failure, or failing tests. Therefore, it is useful
information to include this information; by leaving out the exit
code if it is zero, we do not significantly increase the profile.
|
|
... under the advanced chapter of our tutorial.
|
|
While it is useful to have an end-to-end example also for advanced
topics, they should not be mixed with the basic tutorial showing
how to use the tool to build a typical project (here in C/C++).
|
|
... and ensure that pandoc processes them correctly. In particular,
add an empty line around itemize environments.
|
|
|
|
|
|
The BazelNetworkReader contains an optimization for reading directories
in case the remote execution (in compatible mode) supports the GetTree
request. This is, however not the case for many remote exeuciton
services, including our own single-node execution service. So the
code is basically untested and rarely used, if at all. Moreover,
justbuild is usually used in native mode and using compatibility
mode is expected to handle tree operations less efficient.
Therefore, remove this basically dead code and decrease complexity
this way.
|
|
|
|
... instead of at debug. We expect actions to be not in cache, so the fact
that we experience cache misses is not surprising. Given the information
available at this point, a useful logging indicating (in terms meaningful
to the user) is not possible. Therefore, keep the debug-level log clean.
|
|
At various places in the build tool, we try to read files from various
CASes and caches. The absence of a file there is normal; therefore,
reduce log level in order to not overload the debug-level log.
|
|
Those are the sha256sum of the serialisation of an artifact and that
serialisation does not end up in the compatible CAS. In other words,
they do not refer to anything the user can access. Therefore, drop
this message that is not helpful.
|
|
|
|
While for included libraries, it makes sense to have them with debug
symbols (after all, they are linked into a binary depending on it),
the toolchain binaries are just called, so there is no point in
building debug versions thereof.
|
|
|
|
|
|
|
|
... instead of only the file name. Having the full path into the
tree makes it more easy for the user to understand the root cause
of a conflict.
|
|
... as that failure does not necessarily abort the build.
|
|
Those operations require fetching objects through the network. The
fetch is already restricted to only the tree-objects where a merge
is necessary, leaving out unchanged trees as well as all blobs.
Still, some time may be required, especially over slow networks.
Therefore report this activity in the progress.
|
|
properly
|
|
Now that we generate tree-overlay action identifiers that are disjoint
from identifiers of regular actions, having a joint origin map
does not cause any confusion. Concerning the numbering of subtasks,
we always see tree-overlay actions following the regular actions,
even if defined in a different order. In this way, the identifiers
for the regular actions don't change. Including tree-overlay
actions in the origin map also has the advantage that the origin
is properly reported in case of failure (e.g., non-disjointness of
the obtained trees).
|
|
While our traverser correctly keeps separate identifier spaces for
those entities, having disjoint identifiers allows easier reading
of log messages and more simple reporting of origins of actions.
|
|
... and verify that
- spurious conflicts do not cause failure but instead are handled
correctly, and
- real conflicts are detected and reported properly.
|
|
... calling them as such, and not trying to report command and
environment.
|
|
- break lines at logicial point, following the layout of our other
error messages
- fix a typo
- properly quote the path of the conflict
|
|
Similarly to other third-party binaries, we should not care if they
are built in release or debug mode and as such we explicitly clear
the DEBUG flag.
|
|
Similarly to the proto compiler, this target is a third-party
binary and as such we do not care if it is built in release or
debug mode, so always clear the DEBUG flag.
|
|
As we only care about the result of proto targets, we do not care
if the proto compiler is built in release or debug mode, so always
clear the DEBUG flag for this binary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
