| Age | Commit message (Collapse) | Author |
|---|
|
While our presentation shows the details of only up to 30
non-cached actions, the count reported in the heading should
still be the total count of all non-cached actions. Fix this.
|
|
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.
|
|
As the end of the build can be significantly ahead of the end of
the incvocation, a new time stamp was added to the profile. Use
this new time stamp in the invocation server when determining the
wall-clock time of the build.
|
|
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 include only the basename of the requested artifact.
|
|
|
|
... 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.
|
|
Currently the support hashes are SHA-1 (for git hashes), which has 160 bits and
SHA-256 which has 256 bits. Therefore, we expect either 40 or 64 hex digits.
|
|
|
|
|
|
|
|
While there, sort filter URLs
|
|
to 100
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
... 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.
|
|
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.
|
