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

[Dmitry Baryshnikov]

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
>