| Age | Commit message (Collapse) | Author |
|---|
|
When presenting a build, the output artifacts are hidden behind a
"details" environment to not overload the user with long list of,
e.g., test results (especially if generated by a test matrix). If,
however, only a single artifact is built, there is no reason to
hide it; so simply show it.
|
|
Often, the simple number, e.g., for failed actions can already give
valuable information. For example, when investigating flakiness,
the count of failed actions already gives a hint whether a change
increased or decreased flakiness which can be valuable before even
investigating if the nature of the failure has changed. As we have
that information available and an additional number in a heading
does not clutter the page too much, let's just show it.
|
|
|
|
Also show only the build time in the invocations overview, as only
for the build phase detailled timing information will be available
in the log of a particular information.
|
|
|
|
|
|
... to allow reuse.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
