On Thu, Mar 03 2022, Junio C Hamano wrote: > GitHub CI seems to fail due to lack of "paste" for win+VS job. This > was somewhat unexpected, as our test scripts seem to make liberal > use of "cut" that goes together with it. > > https://github.com/git/git/runs/5415486631?check_suite_focus=true#step:5:6199 > > The particular failure at the URL comes from the use of "paste" in > 5ea4f3a5 (name-rev: use generation numbers if available, > 2022-02-28), but it hardly is the first use of the command. There > is one use of it in t/aggregate-results.sh in 'master/main' already. I think it's the first use, the t/aggregate-results.sh is run on "DEFAULT_TEST_TARGET=test make -C t", but we use "DEFAULT_TEST_TARGET=prove". Re your upthread: > 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). I think this URL is a good example of what I noted in [1]. Your link loads relatively quickly, but I then saw a "linux-TEST-vars" failure and clicked on it, wanting to see why that fails. It opens relatively quickly, but no failure can be seen. It stalls with a spinner next to "t/run-build-and-test.sh", and stalled like that for 75[2] seconds before finally loading past line ~3.5k to line ~70k showing the relevant failure in t6120*.sh. I really don't think it's a reasonable claim to say that only "veterans" of git development[3] are likely to find the workflow of seeing a CI failure right away useful, or wanting to browse through the N different "job" failures without having to pre-open them, go find something else to do, then come back to it etc. I also noted in [1] that it takes a lot more CPU now, so even if that is your workflow for looking at CI you'll need a fairly performant machine if you have a few job failures (which isn't a typical), as each tab will be pegging a CPU core at ~100% for a while. I have fairly normally spec'd quad-core laptop that I almost never hear, and this new CI UI is pretty reliable in making it sound as though it's about to take flight. 1. https://lore.kernel.org/git/220222.86tucr6kz5.gmgdl@xxxxxxxxxxxxxxxxxxx/ 2. I reported large N seconds, but nothing so bad before. For some reason this one's particularly bad, but in [1] it was the same CPU use with ~20s etc (but that one was 1/2 the amount of lines) 3. https://lore.kernel.org/git/nycvar.QRO.7.76.6.2203011111150.11118@xxxxxxxxxxxxxxxxx/
