[gdal-dev] Streamlining GDAL CI builds?

Even Rouault even.rouault at spatialys.com
Fri Sep 7 13:16:57 PDT 2018


Hi Sean,

> I'd love to help speed up the GDAL CI builds.> I think that between removing
> or streamlining some targets and getting more resources on Travis and
> AppVeyor, we could possibly get green lights on pull requests in 25 minutes.

Would be good, but probably hard to get to that point with the same coverage. 
They are subtle differences in all those configs.

The slowness of ubuntu_1604 is mostly due to running scripts/cppcheck.sh (that 
one could potentially be parallelized)

> 
> I'm not familiar with the Clang static analyzer. Are there any constraints
> to how finely its work can be split into parts? If these are the longest
> running jobs, can they be split so that they are not the longest running
> jobs?

Each file is analyzed separately, so could be split as much as wanted, but 
that might require adding subtargets in makefiles to group subdirectories of 
frmts or ogr/ogrsf_frmts. See ci/travis/csa_part_1/install.sh and ci/travis/
csa_part_2/install.sh for the current splitting

> 
> Ubuntu precise is past EOL. Can the relatively slow builds running on
> Ubuntu precise instances be deleted?

The 2 configs that still rely on precise could probably be upgraded to trusty. 
They are not really testing precise, more an historical artifact. But with my 
experience with maintaining the CI stuff, hell is in the details...
The big_endian one uses a cross-compiler and must not depend that much on 
precise since it doesn't rely on third-party libraries
The gcc52_stdcpp14_sanitize uses a custom gcc (with newer toolchains, the 
sanitizer option would be available), but uses all the libs available on 
precise, so I can anticipate that some updates will be needed. The slowness is 
due to running the test suite under the sanitize

> 
> I'm mostly ignorant when it comes to Windows – would caching the OBJDIR
> for  builds on AppVeyor help?

My fear would be that the makefile.vc do not capture well header dependencies, 
and thus if a .h is changed only, the cpp files that use it are not properly 
recompiled.

Even

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


More information about the gdal-dev mailing list