[gdal-dev] Changes in Travis-CI setup + AppVeyor

[Even Rouault]

Hi,

I've refactored a bit the way the multiple test configurations are managed with 
Travis-CI. Previously there was a default single test environment (Precise 
64bit) in .travis.yml in trunk, and I had a cron job that merged trunk into 
custom git branches with different .travis.yml configurations for other test 
environments. 
One major drawback of this is that those alternate configurations were not 
tested for pull requests, or when developing a custom branch.
I've now changed that to use the possibility of doing matrices in .travis.yml. 
The various scripts are now in gdal/ci/travis/${BUILD_NAME}

I've also enabled ccache builds in most setups, which speed up builds.

One of the only advantage of having different git branches for different 
environments was to be able to have different badges. But I just found 
https://github.com/exogen/badge-matrix which offer a way of having badges per 
matrix item, so this is now used in 
https://github.com/OSGeo/gdal/blob/trunk/README.md

There are a few custom builds that are still managed the old way :
- the one that creates the test coverage. Could potentially be merged into the 
main one, but as we upload coverage results in the result repository only for 
changes, that's not useful for PR / feature branches. Plus there is an 
encrypted variable that should be re-encrypted for the OSGeo/gdal repository
- the one that runs the clang static analyzer checks. Its length is very close 
to the timeout limit of Travis-CI jobs, so it regularly fails, and given its 
length, it wouldn't be very valuable for quick feedback. Currently it runs at 
most 1 time per hour.

For AppVeyor, I've migrated the appveyor.yml for the vc12_full branch into 
trunk (which is the one with the most dependencies), so it is now available 
for pull requests. A matrix based approach could likely be done too to test 
different versions (current setup test x86 and x64 builds), but I didn't pursue 
that. So the vc9 and vc13 branches are still using the old merge-from-trunk 
approach.


Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com