| Age | Commit message (Collapse) | Author |
|---|
|
...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.
|
|
|
|
|
|
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.
|
|
|
|
In particular, ensure that Git roots check for, e.g., upwards
symlinks, before returning blobs and trees. To ensure that only the
bear minimum extra work is performed for this purpose, Git roots
now keep also the root's GitTreeEntry as a field, allowing the
validity check of root source trees to take place only once and
only if required.
|
|
|
|
|
|
...with respect to rejecting invalid entries such as upwards
symlinks. Also ensure that valid trees are only checked once by
remebering known valid tress though marker files in local storage.
|
|
...whenever it is given access to a Git repository.
The referenced storage config needs to outlive the repository
config instance.
|
|
...through marker files kept in storage under generation regime.
These can be used to allow valid source trees, i.e., those free of
upwards symlinks, to be cached in a persistent manner over multiple
builds.
|
|
This is useful when the caller already knows that the tree to look
up is valid, and thus the extra check step can be safely skipped.
|
|
This removes a scenario where otherwise successful (exit code 0)
calls to just and just-mr would result in an error-level log
message.
|
|
|
|
Match behaviour of reading trees, which always checks for invalid
entries, also for reading blobs.
|
|
This allows individual blobs read to be checked, e.g., for upwards
symlinks, also when not part of a tree, which performs such a
validation for its entries during its parsing into a GitTree.
|
|
|
|
|
|
... and do mark artifacts internally as synchronized. First all all,
we will abort anyway, to the entry won't even be read and, secondly
it is not necessarily true that the artifact is synchronized.
|
|
If the main repository is marked absent, warn if during the
dependency closure computation any non-content-fixed repositories
are reached, i.e., any "file"-type repositories that are neither
implicitly nor explicitly marked "to_git". Also warn if the main
repository itself is marked absent but is not content fixed.
Add small test checking that the new warning is produced.
|
|
When backing up target-cache entries we use parallelism at two
dimensions, the independent cache entries and for each entry we
retrieve the artifacts in parallel. If for each dimension we use
the full amount of parallelism allowed, that gives a number of
threads up to the square of the amount of parallelism specified by
the user. Therefore, use in each dimension only the square root
of the allowed parallelism keeping the total parallelism (up to
rounding) within the specified range.
|
|
... 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.
|
|
...in all return paths, including in reporting caught exceptions.
In this way give the opportunity for any calling AsyncMap to
receive an expected fatal logger call on failure and thus be able
to shut down gracefully. This is in line with the AsyncMap design,
where the loggers are assumed to be safe to call by a consumer.
|
|
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.
|
|
|
|
This fixes a bug in which the setup root was falsely being changed
by unconditionally searching early for a default configuration
files, despite one being explicitly provided at the command line.
|
|
... so that at this level, the full activity of the serve service can
be monitored.
|
|
|
|
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.
|
|
|
|
|
|
... which requires all entries to be sorted in
lexicographical order.
|
|
... by ignoring it rather than trying to dereference a nullptr.
|
|
The directory name is designed to allow an easy rough sorting by
time. This can also be used to identify the latest build for a
specific user. However, users often run several builds in a single
minute; therefore, increase time-stamp precission to include
seconds as well. While still lexicographic and chronological order
will disagree, at least for a single user it will be correct most
of the times.
|
|
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.
|
|
|
|
|
|
|
|
... by the requested subcommand. In particular, do not set it for
pure analyse requests.
|
|
For a generic rule, it is an error if map union of various
inputs (overlayed in correct order) does not form a proper stage. To
implement this check properly, we first have to construct the map of
all inputs and only then perform the staging check and not do the check
with only the runfiles, as 5e104a526cf76fe75312d2fd288a3c88f506fb0a
accidentally did. Fix this.
|
|
|
|
instead of ArtifactDigest
|
