Hi Even,
Bravo! Well done!
Best regards,
Dmitry
02.11.16 17:38, 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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
