Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
