#955 closed defect (fixed)
Reducing number of configurations in appveyor.yml
Reported by: | rouault | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Default | Version: | |
Severity: | Unassigned | Keywords: | |
Cc: |
Description
appveyor.yml currently tests 8 configurations, each one of them taking more than 10 minutes, and not being parallelized. Which makes the turnaround for a pull request super slow
I'll propose a PR to reduce this to 2 configurations:
- "Visual Studio 15 2017 Win64"
- Visual Studio 2015, "NMake Makefiles", x86
That way we test the 2 architectures, the 2 compilers, and the 2 makefile generators. Other combinations are mostly taking CMake generation itself...
Change History (8)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
We've had lots of build errors that were specific to particular MSVC versions and architectures, so I'd be hesitant to remove these in the name of efficiency. (One can always reduce the "turnaround" by deciding to ignore some of the configurations.)
We could remove the NMake configuration though, as I believe we've agreed not to support that.
comment:3 by , 5 years ago
My reduced set conserves all the individual possibilities (2015 vs 2017, x86 vs x64, nmake makefiles vs visual studio projects), but in just 2 configurations instead of 8. I believe this should offer a decent enough coverage . Basically that's what I do for GDAL : https://ci.appveyor.com/project/OSGeo/gdal/builds/22571089
comment:4 by , 5 years ago
Here's an example of recent failure on AppVeyor:
https://ci.appveyor.com/project/dbaston/geos/builds/22032835
(and please ignore my earlier comment about the NMake-only configuration; I see Paul already removed that)
comment:5 by , 5 years ago
Hum, ok, can we drop to just 4 then ?
- VS 2017, 64, VS project makefile
- VS 2017, 32, nmake makefile
- VS 2015, 64, nmake makefile
- VS 2015, 32, VS project makefile
comment:7 by , 5 years ago
I would have said that going to 4 configurations seems reasonable, but it looks like Paul went ahead and merged the drop to just two. Maybe we'll hear about failures like https://ci.appveyor.com/project/dbaston/geos/builds/22032835 from users of the untested platforms, if there are any.
comment:8 by , 5 years ago
For future reference, "Clean up and update AppVeyor configuration", dropped https://github.com/libgeos/geos/pull/182
Implemented per https://git.osgeo.org/gitea/geos/geos/pulls/71 and https://github.com/libgeos/geos/pull/148