Re: [PATCH 1/2] CI: use shorter names that fit in UX tooltips

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Nov 19 2021, Johannes Schindelin wrote:

> On Fri, 19 Nov 2021, Ævar Arnfjörð Bjarmason wrote:
>
>> Change the names used for the GitHub CI workflows to be short enough
>> to (mostly) fit in the pop-up tool-tips that GitHub shows in the
>> commit view. I.e. when mouse-clicking on the passing or failing
>> check-mark next to the commit subject.
>>
>> That description is truncated to 24 characters, with the 3 at the end
>> being placed by "...".
>>
>> E.g. the full job name (visible at [1]):
>>
>>     "regular (linux-gcc-default, gcc, ubuntu-latest)"
>>
>> Will, when shown in the tool-tip be truncated to:
>>
>>     "CI/PR / regular (linu..."
>>
>> There's then a further limit in the expanded view where the job names
>> are observably truncated to 44 characters (including "..."). I.e.:
>>
>>     "regular (linux-gcc-default, gcc, ubuntu-l..."
>>
>> With this change we shorten both the job names, and change the
>> top-level "name" from "CI/PR" to "CI", since it will be used as a
>> prefix in the tooltips. We also remove redundant or superfluous
>> information from the name, e.g. "ubuntu-latest" isn't really needed
>> for "linux-leaks", it'll suffice to say linux. For discovering what
>> image runs that specifically we can consult main.yml itself.
>>
>> The above "regular (linux-gcc-default, gcc, ubuntu-latest)" job name
>> then becomes a 1=1 match to the "$jobname" used in
>> "ci/run-build-and-tests.sh". A "( push" or " (pull_request" is then
>> added implicitly as before (from the top-level "on" parameter in
>> "main.yml"). In the tooltip we'll now show:
>>
>>     "CI / linux-leaks (pu..."
>>
>> We then have no truncation in the expanded view. See [2] for a
>> currently visible CI run using this commit, and [3] for the GitHub
>> workflow syntax involved being changed here.
>>
>> We could avoid even more truncation with more compact names,
>> e.g. changing "linux" to "lin" or "lnx", but I didn't do that since
>> any additional shortening seemed counterproductive, i.e. "w32" is a
>> well-known way of referring to "Windows", but "lin" isn't). We could
>> also shorten e.g. "::build" and "::test" to "+bld" and "+tst", but
>> those seem similarly to be overly obtuse.
>>
>> 1. https://github.com/git/git/tree/master/
>> 2. https://github.com/avar/git/tree/avar/ci-shorter-names
>> 3. https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>
> My vote is to drop this patch: it does a lot of things, but I do not see
> any benefit. Names that are too long in one person's setup are not too
> long in another one's.

What person's setup are we talking about here? Satya Nadella's? :)

This isn't a terminal I resized, it's your employer's website.

From the browsers I've tried (Firefox, Chrome, logged in & out) it's the
same for everyone. 

Do you not see the existing labels truncated in the same way?

> Also, it drops the "PR" as if we would not do PR builds at all anymore
> ("CI" is for "Continuous Integration", i.e. the testing of the current
> `main` branch).

I think "CI" is commonly understood to not mean that these days. It's
just "the test thing that runs on push" to most people. Is anyone
confused that CI is running in their topic branch without a merge back
to mainline?

What's the potential for confusion here? Do you really need to see "CI /
PR" there to be assured that the thing you're looking at running is
actually running?

I dropped it because omitting the " / PR" is worth it not truncate the
actual meaningful info that comes after, e.g. showing both of
"linux-gcc"and "linux-leaks" as "linu..." or whatever.

> And `w32`? Really? *Really*?

I didn't know what to pick there, "win" was suggested in a side-thread.

FWIW I just ran "find" on some repos that I've got checked out locally
of various software, many of which had something-w32.c, or a w32
directory, even if that software is obviously targeting Windows 64 bit
these days.

I thought it was like how my kernel says I'm running an "amd64", even
though it's an Intel :)