| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Normally, actions are supposed to work silently, i.e., without writing
to stdout/stderr. So, if an action produces console output, it is
definitely worth looking at, even for cached actions. Therefore,
add a section after the failed actions showing those actions (if
not in the previous action). Also, always show duration (if known)
and if an action is cached (which can happen for the ones producing
console output).
|
|
When using a serve endpoint, analysis errors my contain a reference to
a build failure on serve, shown as 'blob <hash>'. For each such blob
reference add a link offering to read this blob.
|
|
|
|
|
|
|
|
|
|
When looking at an invocation, it can be helpful to quickly get
all other invocation that coincide with a specific remote-execution
property (like the build image). Support this use case by adding
appropriate filtering and links.
|
|
|
|
... 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.
|
|
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.
|
|
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.
|
