Re: [PATCH] ci: run `make sparse` as a GitHub workflow

Hi Junio,

On Wed, 14 Jul 2021, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

On Wed, 14 Jul 2021, Junio C Hamano wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

Which means that the likelihood of a run to fail increases with the number
of jobs in said run (even innocuous problems such as transient failures to
download an Ubuntu package), and it also makes it much more painful to
re-run the entire thing because you may well end up wasting a grand total
of ~370 minutes even if only a 30-second-job would need to be re-run.

Having said that, I think you're right and the upside of keeping things
together may outweigh that downside.

I wasn't make a request or a demand to change or not to change
anything, so in this particular exchange there was no point where I
was right (or wrong, for that matter ;-).  I was asking if there was
a solid reasoning behind the split, and if there is, I am perfectly
happy to see it done as a separate workflow with the log message
that explains why it is separate.  I am also perfectly fine with
this rolled into the primary one, with clear reasoning behind the
choice recorded in the log message.

I do not think that it would be an improvement to defend the default
choice (i.e. to add this new job to `.github/workflows/main.yml`) in the
commit message. It is the default for new CI stuff to go, after all, and
we do not need to clutter the message by stating the obvious.

It wasn't quite obvious why we justify spending 370 minutes one more
time only to rerun 30-second job, though.

True.

And this is not a new problem. Every time anything happens in those
`osx-gcc` or `osx-clang` jobs (e.g. that transient problem with the broken
pipes in t5516 [*1*], that's a fun one), a full re-run is necessary, or
else the commit and/or PR will remain marked as broken.

In other words, while it is totally appropriate for me to explain this to
you in this here thread because it came up as a tangent, it would be
inappropriate to stick that explanation into this patch's commit message.
We do not make a habit of adding tangents that came up during patch
reviews into commit messages, and I do not intend to start such a habit
here, either.

Ciao,
Dscho

Footnote *1*: See
https://lore.kernel.org/git/20190829143805.GB1746@sigill.intra.peff.net/ (local)
(I don't think this is fixed as of now)