Hi Junio, On Wed, 14 Jul 2021, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Wed, 14 Jul 2021, Junio C Hamano wrote: > > > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. > > > > 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@xxxxxxxxxxxxxxxxxxxxx/ (I don't think this is fixed as of now)
