Johannes Schindelin [off-list ref] writes:
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.
Thanks.
Hi Junio,
On Wed, 14 Jul 2021, Junio C Hamano wrote:
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.
Ciao,
Dscho