| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
... in the summary, so that the user knows what to expect when
looking into the details-environment.
|
|
|
|
With the introduction of new exit codes, the presentation of
an invocation was changed to refrain from showing actions in
abnormal case failure already during analysis phase. However
ca8fd841736ca65fa4292887052c78243512962a did not include the case of
a successful build into the cases of normal circumstances. Fix this.
|
|
|
|
... if available. This can be useful, when presenting builds
that are mainly there to have artifacts available for manual
use.
|
|
When showing a tree, we have for each entry already a designated
file name. Use this, to offer direct dowload links for blobs with
the intended name.
|
|
With just-mr supporting a custom prefix to be shown at the beginning
of a logged invocation, users might be pointed to the web server very
early. Therefore, properly indicate if the invocation data is not yet
complete.
|
|
For many text files it is useful to read them directly in the browser.
However, many files that are better analysed by machines (like large
repository configurations) also come as plain-text files. Therefore,
always offer to download a file currently being viewed. Use the URL
scheme in such a way that the name to download the file as can be
specified; in this way, we are prepared if we decide to also log
the artifacts to be built and offer those to be downloaded.
|
|
|
|
Being able to browse through past invocations of the build tool can
actually be useful and doing so in the browser is a way many users
prefer. Therefore, add a small WSGI application (written in python,
using werkzeug and jinja) serving a directory of invocation logs
via http.
|
|
|
|
In preparation for the rule changes, to avoid introducing false
positives during future bisections.
|
|
|
|
... under the advanced chapter of our tutorial.
|
|
... and ensure that pandoc processes them correctly. In particular,
add an empty line around itemize environments.
|
|
|
|
|
|
|
|
- For the rule functions TREE_OVERLAY and DISJOINT_TREE_OVERLAY
call the argument "$1", to align with the argument name for
BLOB and TREE.
- For the built-in functions `"tree_overlay"` and `"disjoint_tree_overlay"`,
align this the built-in function `"tree"` and allow staging of
the resulting tree.
|
|
|
|
... and remove it from the future design, as it is already implemented.
|
|
Clarify the handling and extent of proposed debug-related
configuration fields in the CC defaults.
|
|
|
|
|
|
... as it turns out that the synchronous writing is fast enough and
hence we can avoid all the problems of background processes.
|
|
Also update the README.
|
|
...instead of using the master branch.
|
|
Reduce interference of invocation logging with regular logging
operations; in particular, restrict just-mr passing the --async-profile
option only to build commands and thus avoiding race conditions with
calls to `analyse` that rely on having a graph available immediate
after invocation.
|
|
|
|
- specify that what is cloned is the workspace root of the target
repository
- disambiguate what is referred to as the 'start' and 'target'
repository
|
|
|
|
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.
|
|
Add the artifacts and outputs of the updated rules, as well as
some explanatory remarks.
|
|
- As we build a binary hello, make it an extension of the hello
we had before.
- Make the passing of time more explicit.
- Add actual output of rerunning the tutorial.
|
|
As our defaults rule supports flags common for C and C++ use
them, especially as our example only uses common flags.
|
|
|
|
|
|
... in particular in the case of targets producing precisely one
artifact; this better emphasizes the idea that we talk to the tool
in terms of targets. While there, also add some clarifying comments.
|
|
|
|
|
|
|
|
The "generic" rules deliberately resolves conflicts on identical
paths in a latest-wins fashion (seeing all artifacts as later than
all runfiles) to allow an easy way to define actions. However, the
inputs stage obtained by this resolution can still contain conflicts
and those are an error. Properly detect those. Also clarify in the
documentation, that only conflicts on identical paths are resolved
in the described priority, not semantic overlap.
|
|
... rather than as future design. While there, also add target-level
caching as a service to the list of documentation pages.
|
|
The 'type' field is optional and informs both the way to unpack
the archive and which type imported file repositories should be
rewritten as in the output configuration. Mirrors the 'just-mr'
types, with options for tarballs and zip-like archives, defaulting
to tarballs if missing.
The 'mirrors' field is treated the same as for 'git' sources.
The 'subdir' field is optional and accounts for the fact that the
actual root of the source repository might be a subpath in the
unpacked archive, as opposed to Git repositories where it is
reasonable to expect that the sources root is the top-level
directory.
|
|
...to refer to repositories as a chain of bindings to be followed
starting from one of the known repositories (existing or imported).
Both the initial and the target repositories are to be kept during
deduplication.
|
|
|
