Thread (2 messages) flat view 2 messages, 2 authors, 2021-07-14

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

From: Junio C Hamano <hidden>
Date: 2021-07-14 20:56:26

Johannes Schindelin [off-list ref] writes:
Hi Junio,

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help