[Board] Travis-CI & OSGeo

Tue May 1 09:20:33 PDT 2018

my understanding is, that having cuatom jenkins instace, would make it
possible to address some of the issues we have with free travis-ci. and
having jenkins at hand, would make it possible to some of the projects
(like pywps and similar small) to make few steps towards CI. combination of
both is possible.

On Tue, 1 May 2018, 17:59 michael terner, <ternergeo at gmail.com> wrote:

> At the risk of chiming in as a non-developer, I'd observe that I'm not
> sure that Maria's final question ("will Jenkins be enough") accurately
> summarizes what I hear as the core take home of this thread. Rather, I
> think there is a legitimate difference of opinion on:
>
>    1. Should all OSGeo projects use the same platform (whether it be
>    Jenkins, or Travis, or other tooling)?
>    2. Or, should projects be free to use the tools that work best from
>    their points-of-view, and in light of the history of those projects?
>    3. And, there's a subtext of what is "more important", having the
>    "purity" of more open solutions; or the practicality of getting work done
>    with tools that the people involved with projects may be familiar with, or
>    simply prefer?
>
> And of course, the overarching question is *what should OSGeo do about
> it?*
>
>    - Should there be a policy about what tools projects may be *required *to
>    use?
>    - Should OSGeo setup an open platform, that it supervises and makes
>    available (on a voluntary basis) to projects?
>    - Should projects be allowed to spend project money on commercial
>    tools (i.e., if they include those expenses in their budgets; and even if
>    some of those moneys come from sources like OSGeo)?
>
> I think these bigger issues are the most important part of this thread,
> and from my reading there is not yet a clear consensus. This seems like an
> important issue (and policy; and direction statement) for OSGeo/the Board
> to address.
>
> Count me squarely in the "practicality is important" camp. Indeed, to me
> producing great, open source software is the end goal. And the people that
> manage those projects should have a large say in what tools are best for
> them; as well as the freedom to spend money on those tools when appropriate
> (and with OSGeo's support). Indeed, there is no such thing as open source
> purity (well, maybe Stallman approaches that?), as significant parts of the
> software development ecosystem ranging from hardware to internet access are
> paid for commercially.
>
> MT
>
> On Tue, May 1, 2018 at 11:05 AM, María Arias de Reyna <delawen at gmail.com>
> wrote:
>
>> Hi,
>>
>> In my experience, I like Jenkins more than Travis and I think that
>> with an owned Jenkins we will be able to do much more than with the
>> Travis service, but I understand that I may be missing something
>> important here. So it is up to each project to comment if Jenkins
>> would be a nice solution or not.
>>
>> At least for GeoNetwork, it's true that we have Travis linked to our
>> github (not inside OSGeo organization but on our own), but, at the
>> same time, what we really use is a Jenkins we have on our own
>> infrastructure. Every time I try to use Travis, it is unstable and
>> weird. We can't trust the testing results, for example. But that may
>> be me, or Java, or GeoNetwork, or who knows, that makes Travis
>> unfriendly with our project.
>>
>> So, going back to the beginning of the thread: Even, will a Jenkins be
>> enough?
>>
>
>>
>> On Tue, May 1, 2018 at 2:59 PM, Regina Obe <lr at pcorp.us> wrote:
>> >
>> >> Hi,
>> >
>> >> afaik, Jenkins can be configured, that it uses several "cores" - so
>> one Jenkins instance can take advantage of more servers, so  it scales up
>> pretty well.
>> >
>> >> Actually, in my previous work, we used jenkins quite extensively,
>> developers and even power users were able to setup their own jobs,
>> >> which were taking fresh code from custom git repo ... it was more or
>> less about writing the shell script, which did all the work
>> >
>> >> so, if there would be jenkins instance available in osgeo
>> infrastructure, I would prefer it over travis (which pywps is using now)
>> >
>> >
>> > Yes Jenkins can scale fairly well especially when we throw slaves into
>> the mix.
>> > I was more thinking about the logistics of delegating administrative
>> rights and configuring slaves in a fashion that power users can configure
>> their own and know what's available on each slave for their tests, cleanup
>> of workspace etc.
>> > And also the interoperability of the projects.
>> >
>> > The main reason I like Jenkins is for PostGIS work we need to follow
>> PostgreSQL developments which means we need to test against the head of not
>> yet released PostgreSQL which is something not easy to do with travis.
>> >
>> > We also need to test against the head of GEOS and GDAL so one of the
>> Jenkins bots we have uses the build output from PostgreSQL, GEOS, GDAL
>> Jenkins jobs and does a matrix job (testing 5 versions of PostgreSQL
>> including dev head) , GEOS head, GDAL head.
>> >
>> > There is a lot of potential for synergy, but also a bit of "If I need
>> to test GDAL for PostGIS purposes and GDAL needs to test GDAL, but I don't
>> necessarily need to run all the tests GDAL needs to run, where is the
>> balance of power there".  So that's my reasoning for why a single Jenkins
>> might not be sufficient.  It's doable but takes a bit of planning.
>> >
>> > As far as authentication we can use OSGeo LDAP and designate
>> administrators from each project.  I think having 10 administrators that
>> have full control of the instance from various projects that we all feel
>> comfortable about working together is a workable solution.
>> >
>> >
>> > Thanks,
>> > Regina
>> >
>> >
>> >
>> >
>> >
>>
> _______________________________________________
>> Board mailing list
>> Board at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/board
>>
>
>
>
> --
> Michael Terner
> ternergeo at gmail.com
> (M) 978-631-6602
> _______________________________________________
> Board mailing list
> Board at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/board
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/board/attachments/20180501/6dfc94c0/attachment.htm>