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