Hi Junio,

On Mon, 7 Mar 2022, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I said that the current output is only useful to veterans. The output that
> > hides the detailed log, under a separate job that is marked as
> > non-failing.
> >
> > That's still as true as when I said it. :-)
>
> I think getting rid of the separate "print failures" CI step and
> making it more discoverable how to reveal the details of failing
> test step is a usability improvement.

I'm so glad you're saying that! I was starting to doubt whether my caring
about getting rid of that `print failures` step was maybe misguided.

> I am not Ævar, but I think what was questioned was the improvement
> justifies multi dozens of seconds extra waiting time, which is a
> usability dis-improvement.  I do not have a good answer to that
> question.

It is definitely worrisome that we have to pay such a price. And if there
was a good answer how to improve that (without sacrificing the
discoverability of the command trace corresponding to the test failure), I
would be more than just eager to hear it.

I did consider generating a HTML-formatted report that would then be
attached as a build artifact. But that would hide the relevant information
even worse than a "print failures" step.

Maybe I should just get rid of the grouping? But that _really_ helped me
when I investigated the recent "usage string updates" vs "FSMonitor"
problem, because the test case boundaries were so much clearer.

Plus, as far as I saw, GitHub workflow logs always scroll to the end of
the logs of the failing step, which would not help _at all_ here.

So I dunno.

> I am probably nearing to be a veteran who knows when to brew my tea
> in my work cycle, and waiting for an extra minute or two while
> browsing CI output is not a problem for me.

:-)

> But new "non-veteran" users may not share that.  That is something a
> bit worrying about the new UI.

Indeed. My goal, after all, is to improve the experience of contributors,
not to make it harder.

Still, given that you currently have to click quite a few times until you
get to where you need to be, I have my doubts that what this patch series
does is actually making things slower, measured in terms of the total time
from seeing a failed build to being able to diagnose the cause by
inspecting the command trace.

Ciao,
Dscho