[Qgis-developer] CI testing: the straight truth

Matthias Kuhn matthias at opengis.ch
Wed Jan 11 02:37:45 PST 2017


Hi,

I have just received the confirmation from travis that they boosted our
build times to 90 minutes.
I think that should keep us alive for the foreseeable future.

Please let me use this opportunity to highlight the excellent support
from their side!

Matthias

On 04/01/17 10:31, Matthias Kuhn wrote:
> Hi Andreas, Nyall
>
> I would also prefer this, I just sent them a mail and will get back to
> you as soon as I get a response.
>
> Mid-term we will still need to launch a project to update the system and
> get away from the pre-built dependencies in osgeo4travis to a system
> that is easier to maintain collectively but I'm happy if we can wait
> with this a bit.
>
> @Tom Chadwin:
> agreed, that's a risk indeed
>
> Best regards
> Matthias
>
> On 01/04/2017 08:21 AM, Neumann, Andreas wrote:
>> Hi all,
>>
>> I agree with Nyall. We should try contracting the travis ci team and ask
>> them if we could switch to unlimited build time. Even if this means
>> paying a certain amount for the services (if it is a reasonable price).
>>
>> Matthias - could you please take a lead in contacting them?
>>
>> Thanks,
>> Andreas
>>
>> On 2017-01-03 23:40, Nyall Dawson wrote:
>>
>>> On 4 January 2017 at 07:59, Matthias Kuhn <matthias at opengis.ch
>>> <mailto:matthias at opengis.ch>> 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
>>>>> Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>>>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>> _______________________________________________
>>>> Qgis-developer mailing list
>>>> Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>  
>>
>>  
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer



More information about the Qgis-developer mailing list