Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
... to include at least all pages referenced throughout the man page.
|
|
... 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.
|
|
|
|
|
|
It is already supported to ask just-mr (via the rc file) to log for
each invocation the artifacts that were built. Add a similar option
for the artifacts that were to be built, i.e., for dumping the
intensional description of the output artifacts. That information
can be used, e.g., to compute the critical path.
|
|
It allows to specify a list of environment variables, which are captured at
invocation time and stored as key-value pairs in the metadata file. This allows
to get some information about the invocation context such as username,
merge-request ID or source branch (on a CI runner), or others.
|
|
|
|
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.
|
|
|
|
|
|
|
|
Allow to specify a custom string that is extended by the basename
of the logging directory, in case invocation logging is activated.
This can be used, e.g., to point to the user to service doing
something useful with the logged data (or simply presenting it in
a nicer form).
|
|
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.
|
|
Document the conservative extension of our graph-file format due
to the addition of tree overlays.
|
|
|
|
|
|
Support passing on an invocation-specific --profile option
when launching just. This allows routine profiling of builds.
|
|
... 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.
|
|
|
|
|
|
|
|
To properly use `just serve`, both the client and the serve instance
must talk to the very same execution endpoint. Typically, both the
client and serve can reach out to the execution endpoint via the same
IP address. However, it might be possible that the client and a serve
instance know the same execution endpoint by means of differnet IP
addresses. For example, the client knows the execution endpoint
address through an _external_ IP address, while the serve instance,
deployed within the same network infrastructure, only knows the
_internal_ IP address.
This patch adds the subkey `"client address"` -- of the key
`"execution endpoint"` -- in the serve configuration file, to specify
the alternative pair `address:port` used by the client.
|
|
|
|
|
|
|
|
Marking a source repository 'as plain' means that the whole source
repository tree will get imported as a repository type
corresponding to the source type. In this case, additional pragmas
than those supported by the inndividual imports might need to be
set.
Solve this by supporting the just-mr-style 'pragma' field also in
the source description, for all sources also accepting the
'as plain' field. Currently support only the 'special' pragma.
Document change and add test for plain imports that checks this
feature.
|
|
In particular, any transitive 'file'-type repository will inherit
any given '{to_git: true}' pragma in the import description
objects. Note that this technically can only happen for transitive
'file' repositories imported from a 'file' source, so in all other
cases such a pragma would not have any effect.
Document change and extend the import from 'file' source test to
check this feature.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... allowing to print the unique artifact built (if any). This
allows convenient inspection of the build result of targets that
define precisely one artifact.
|
|
|
|
|
|
|
|
|