Johannes Schindelin [off-list ref] writes:
So I merged my branch into `seen` and pushed it. The corresponding run can
be seen here:
https://github.com/dscho/git/actions/runs/1892982393
I visited this page (while logged in to GItHub---I am saying this
for others who may not know the output is shown differently for
visitors that are logged-in, and and logged-in users).
On that page, you see the following:
Annotations
50 errors and 1 warning
ⓧ win test (3)
failed: t7527.1 explicit daemon start and stop
...
⚠ CI: .github#L1
windows-latest workflows now use windows-2022. For more details, see https://github.com/actions/virtual-environments/issues/4856
In my mind, this is already an improvement. (Even if this is a _lot_ of
output, and a lot of individual errors, given that all of them are fixed
with a single, small patch to adjust an option usage string, but that's
not the fault of my patch series, but of the suggestion to put the check
for the option usage string linting into the `parse_options()` machinery
instead of into the static analysis job.)
It is not obvious what aspect in the new output _you_ found "an
improvement" to your readers, because you didn't spell it out. That
makes "in my mind, this is already an improvement" a claim that is
unnecessarily weaker than it really is.
Let me tell my experience:
- Clicking on macos+clang in the map-looking thing, it did show and
scroll down automatically to show the last failure link ready to
be clicked after a few seconds, which was nice, but made me
scroll back to see the first failure, which could have been
better.
- Clicking on win+VS test (2), the failed <test> part was
automatically opened, and a circle spinned for several dozens of
seconds to make me wait, but after that, nothing happened. It
was somewhat hard to know if I were expected to do something to
view the first error and when the UI is ready to let me do so, or
if I were just expected to wait a bit longer for it to all happen
automatically.
Either case, the presentation to fold all the pieces that finished
successfully made it usable, as that saved human time to scan to
where failures are shown.
I personally do not care about the initial latency when viewing the
output from CI run that may have happened a few dozens of minutes
ago (I do not sit in front of GitHub CI UI and wait until it
finishes). As long as it is made clear when I can start interacting
with it, I can just open the page and let it load while I am working
on something else.
Thanks.