On Fri, Nov 19 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> This changes the names used in GitHub CI to be shorter, because the >> current ones are so long that they overflow the pop-up tooltips in the >> GitHub UI. >> >> New pop-up visible at: https://github.com/avar/git/tree/avar/ci-shorter-names >> >> Full CI run at (currently pending, I had a trivial last-minute >> update): >> https://github.com/avar/git/runs/4264929546?check_suite_focus=true > > I have found the labels on "Jobs" on the left hand side pane > irritatingly unhelpful. For example, "regular (linux-gcc-default, > gcc..." does not tell me much about how it is different from > "regular (linux-gcc, gcc, ubunt...". Yeah, I've needed to look it up most times.. > The question I ask most often is "which one of these ones is the job > that runs tests twice, the second time with nonstandard settings?", > or "Only windows-test(4) is failing, but not vs-test(4); what area > did we break? What is in (4)?". Because I had to look: It's a splitting method Johannes came up with, first stat() all the tests, sort by size, then chunk them up, and use the Nth as a way of dividing those chunks. Maybe he feels strongly about it, but I think a better approach is just to hardcode t0xxx, t1xxx or whatever, then if one is unusually slow have a t1[0-4]xx & t1[5-9]xx or whatever, I.e. just manually partition them as a one-off. These jobs take ~30m anyway, so if one is a tad slower than another it doesn't really matter as much as seeing at a glance where in the test suite the failure is. I nicely split these all up in a follow-up, along with removing the travis CI, but anticipated the usual objections about too much of a scatterbrain series. But yeah, I think all of that would be great to have, I can submit that as a v2, sound goood? AFAICT the whole "stick this all into one job" way of doing the GIT_TEST_* CI is a workaround for some Travis-specific thing. Or a micro-optimization for trying to max out our total CPU time, but anyway it doesn't seem worth it. By far most of the time is spent in the tests themselves, not the build. A WIP split I had of this, e.g. there's a linux-sha256 job, linux-TEST-vars for the big GIT_TEST_* accumulation etc: https://github.com/avar/git/runs/4265312207?check_suite_focus=true We could (and I'd like to..., but not now) cache the build directory between runs. Much faster compilations, and if it breaks, well then our Makefile dependencies are broken, which is also nice to spot in CI (and the cachewillexpire) ... > I do not think relabelling "windows" -> "w32" (why not "win", by the > way?), "vs" -> "w32/VS", or "regular (\(.*\))" -> "\1" helps me very > much in these questions. I however think the blame for it lies > mostly on the original naming, not your effort in this series. I'll pick "win" next time, as noted in some other follow-up replies.
