Hi Junio, On Wed, 23 Jan 2019, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > > > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > > > The Windows job currently takes a whopping ~1h20m to complete. Which is > > *far* longer than the next-longest job takes (linux-gcc, ~35m). As such, > > it makes sense to start the Windows job first, to minimize the overall > > run time (which is now pretty safely the run time of the Windows job). > > Is the reason why Windows job gets started first is to make sure > that it, which is known to take the longest time, never has to wait > before starting while other jobs run, in case there is limited > parallelism? Yes, in order to optimize the overall run time. Like, if you have N jobs, and you know that one of them takes longer than the other combined, it really only makes sense to start that one as first one. > The last part of this sentence is what readers of this > step will need in order to be convinced by the justification given, > because (1) if the jobs run totally serially, the order does not > matter much---if anything, running shorter jobs first would give > results from more jobs sooner, and (2) if the jobs run totally in > parallel, the order does not matter as long as we have enough > parallelism. Right, I think I totally forgot to mention that Azure Pipelines offers 10 parallel jobs to open source projects for free. Which means that we will run up to 10 jobs in parallel, as long as no other build is running, of course. Will adjust the commit message. > > This commit is best viewed with `--color-moved`. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > > --- > > azure-pipelines.yml | 172 ++++++++++++++++++++++---------------------- > > 1 file changed, 86 insertions(+), 86 deletions(-) > > For those who are seeing this azure-pipelines series for the first > time, it would probably be unclear what the point of adding an > entire file in 09/21 and them moving lines around in 10/21 is. If > somebody asked me why, I wouldn't be able to explain why it is a > good idea. > > Would it hurt readability if these two steps are combined? The thing is, I tried (of course) to replicate the Travis configuration as closely as possible. And the Windows job was in a specific location there. However, I just realized that I *added* the Windows job to the Pipelines right from the start, and that is definitely not on par with Travis, as the Travis configuration did not define a Windows job (instead it has code to trigger a dedicated Azure Pipeline). So what I will do instead is to - *not* add the Windows-specific part in the commit that adds the initial Azure Pipelines support, and - explain in the commit message of that commit that the idea is to imitate our existing Travis configuration as closely as possible. Ciao, Dscho
