On 4 January 2017 at 07:59, Matthias Kuhn <[email protected]> wrote: > Hi René-Luc, hi all, > > This is something I have been afraid of for a couple of weeks. > > Short story: our builds just grew too big and a full build is taking > more than 50 minutes to complete on the travis infrastructure.
Argh... what a pain! Still, I think in some ways this is a good reflection of the exponential growth in QGIS unit tests since your initial work introducing the CI infrastructure. I certainly would never want to go back to the pre-CI days! Just wondering- is there any chance sending an email to the Travis crew could get an extension to this build time? I can't see anything on their publicised plans, but perhaps they have a cheaper unlimited build time option available for open source projects? I'd like to see us exhaust these "easier" options first before requiring someone to donate time into tweaking/changing the CI infrastructure. Nyall >What > keeps us alive at the moment is the persistent ccache so a full build > actually never happens. If the ccache gets lost, we will need some black > magic to get the builds started again (it's possible to slowly get the > cache warm but not straightforward). > > What we could possibly do: > > - Modularize the build: e.g. astyle could very well be moved to a > separate job along with other static checks like spelling. That would > even have the advantage of a faster feedback for these analyses. > But I'm not sure how much time we can actually get out of that. > > - Move dependencies into separate packages. We have some deps like > qspatialite that are built as part of QGIS which I think could be > installed as dependencies from a .deb. This will require quite a bit > of work: moving travis out of the container based infrastructure to > the sudo-enabled infrastructure, setting up a repo (e.g. ppa) with > all sort of dependencies including qt 5 etc. This would be an option > again since travis enabled caching also on sudo systems recently. > This will be a quite large task to do. > > - Move to another system (managed infrastructure or self-hosted, there > are a couple of services like circle ci, drone.io, jenkins, gitlab > ci ...). > This will be a quite large task to do with the risk that we run into > yet another timeout, other technical issue or run a self-hosted > infrastructure for which nobody really has the resources to maintain. > > Apart from this, there is also the dependency on some pre-compiled > libraries in the osgeo4a repository. Keeping these up to date is not > something we will want in the long term (I was hoping that travis would > ship a more recent distro than trusty but haven't seen many hints in > this direction yet). > > Bottomline: I don't think there's an easy fix but I think it's time to > start thinking about the future. > > Matthias > > On 01/02/2017 03:03 PM, René-Luc Dhont wrote: >> Hi Devs, >> >> I would like to merge a PR https://github.com/qgis/QGIS/pull/3897 but >> Travis cannot ccomplete the tests. >> >> Would it be simple to fix travis ? >> >> Regards, >> René-Luc >> _______________________________________________ >> Qgis-developer mailing list >> [email protected] >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ > Qgis-developer mailing list > [email protected] > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
