Re: [gdal-dev] Changes in Travis-CI setup + AppVeyor
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
[gdal-dev] Changes in Travis-CI setup + AppVeyor
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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev