ci: add a Windows job to the Azure Pipelines definition
commit2e90484eb4ad0eb4334a94ba5ae401a293870e3a
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Tue, 29 Jan 2019 14:19:30 +0000 (29 06:19 -0800)
committerJunio C Hamano <gitster@pobox.com>
Tue, 29 Jan 2019 17:26:46 +0000 (29 09:26 -0800)
tree6bce810622a0f24d5e11ea72f99db5d8ffdcdf5e
parent27be78173da3b11011f55061571d81ae006b8915
ci: add a Windows job to the Azure Pipelines definition

Previously, we did not have robust support for Windows in our CI
definition, simply because Travis cannot accommodate our needs (even
after Travis added experimental Windows support very recently, it takes
longer than Travis' 50 minute timeout to build Git and run the test
suite on Windows). Instead, we used a hack that started a dedicated
Azure Pipeline from Travis and waited for the output, often timing out
(which is quite fragile, as we found out).

With this commit, we finally have first-class support for Windows in our
CI definition (in the Azure Pipelines one, that is).

Due to our reliance on Unix shell scripting in the test suite, combined
with the challenges on executing such scripts on Windows, the Windows
job currently takes a whopping ~1h20m to complete. Which is *far* longer
than the next-longest job takes (linux-gcc, ~35m).

Now, Azure Pipelines's free tier for open source projects (such as Git)
offers up to 10 concurrent jobs for free, meaning that the overall run
time will be dominated by the slowest job(s).

Therefore, it makes sense to start the Windows job first, to minimize
the time the entire build takes from start to end (which is now pretty
safely the run time of the Windows job).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
azure-pipelines.yml