| Age | Commit message (Collapse) | Author |
|---|
|
... which might be quite ahead of the end time of the invocation if
writing out of the action graph delays the end of the invocation.
|
|
When using a serve end point, the analysis phase might take quite
long if serve has to actually build a delegated target or, at
least, has to synchronize artifacts with the remote end point.
Therefore, also record the time the build phase started (if building
is requested) as an additional time stamp in the profile.
|
|
|
|
... by ignoring it rather than trying to dereference a nullptr.
|
|
Include in the profile also the effective remote-execution endpoint,
properties, and dispatch list. Software projects are often tested
in a variety of environments or hardware configurations; as,
obviously, the performance might differ significantly (especially
depending on the used hardware) a proper analysis therefore requires
the possibility to distinguish the various backends. Adding the
effective configuration adds this posibility.
|
|
|
|
During execution, paths are relative to the working directory of the
action; however, in our representation, all paths are always relative
to the action root. Commit d65d711f844224dcf9215c52be8f69fd2885adfc
tried to change the reporing to our usual standard, however got
the direction wrong; fix this.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
... so far, which actions where considered, and which of those
were cached.
|
|
... so far only keeping track basic properties of the invocation.
Still, the code is already organized to support future extensions;
in particular, we do not have to rely on the Profile class
being copyable.
|
