Ævar Arnfjörð Bjarmason [off-list ref] 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...".
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)?".
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.
The job that is now called "linux-leaks" used to be "regular
(linux-leaks, gcc, ubu...", and there definitely is an improvement,
so "regular (\(.*\))" -> "\1" could help if the original was named
properly. It is easier to spot what the job is about for that
particular one.
I find this of mixed value, ranging from "Meh" to "Hmm...nice?".
On Fri, Nov 19 2021, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
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.