[Board] Travis-CI & OSGeo

Tue May 1 02:57:14 PDT 2018

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)

just my opinion

J
út 1. 5. 2018 v 9:39 odesílatel Regina Obe <lr at pcorp.us> napsal:

> I see this conversation is stalled so, let me summarize it a bit to see
how to approach it:

>   > * There is a need for more CI (Travis) threads on the OSGeo
organization of Github

> I'll leave this to Even to discuss how pressing this need is.  I think it
depends on how pressing it is. As  I understand it there are GDAL and Proj
(and one more other), I can't remember that use  the travis-ci OSGeo org
resources heavily.  All the other projects I can think of pgRouting, GRASS,
QGIS, MapServer, and PostGIS all have their own org so are not suffering
from not having enough workers.  GEOS is on OSGeo Org – but we'd be happy
to move GEOS off of OSGeo org, cause it's just a mirror anyway. Then again
GEOS is not as busy as GDAL so probably not hogging any workers.

> I think Sandro and Even have already started taking steps to setup a GDAL
gitlab repo so that GitLab-CI tests can be done on gitlab for GDAL.

> Sandro/Even correct me if I misspoke.

>   * Some of us are not keen to give money to private infrastructure if
there is an open source solution (Gitlab CI, Jenkins) and prefer to support
open source even outside OSGeo

> Correct.  I'd be willing to put in a fair amount of sweat labor to make
this happen, because for my needs I find travis is not enough and too
limiting in what I can do with it.

>   * Moving from Github to Gitlab will be a drawback to the projects (part
of the community will be left behind and lost). So, not an option ¿¿for
short term??.

> That is not true.  Mirroring from Github/Gitlab is trivial.  PostGIS
already does it and enjoys travis, gitlab ci, dronie, and Jenkins.

> So the only difficult part is setting up an image and a gitlab-ci.yml
file which is a little different from travis ci.

> For reference you can look at the ones PostGIS has

https://git.osgeo.org/gitea/postgis/postgis/src/branch/svn-trunk/.gitlab-ci.yml

https://git.osgeo.org/gitea/postgis/postgis/src/branch/svn-trunk/.travis.yml

> Jenkins is probably a little harder to get going but it too has a yml
like script a Jenkins – ci can listen for and use.

>   * We could add a Jenkins from OSGeo that can take care of what Travis is
doing right now. Advantage: we will have no restrictions. Disadvantage:
¿¿Integration on github??

> Jenkins can integrate with github fine as it's pretty agnostic and has a
ton of plugins for github integration, such as the github issues plugin

> https://wiki.jenkins.io/display/JENKINS/GitHub+Issues+Plugin

> I haven't explored all those features yet, on the Jenkins side I just use
scripts stored in the repo of PostGIS / pgRouting

> https://git.osgeo.org/gitea/postgis/postgis/src/branch/svn-trunk/ci

> https://github.com/pgRouting/pgrouting/tree/master/ci

> which for example for windows,

> does experimental builds for windows users to test and for the debian
tests against the head of all the PostgreSQL versions.

> And also has slaves for testing freebsd and so forth -

> So much of the frustration with bots (travis included) is just dealing
with them when they wet their pants  or someone spills water on them.

> Like those inconvenient times when travis decides to up the OS or you or
the repo you are relying on is broken.

> Did I miss something here?

> So, our best options look like:

>   > * Having the Jenkins that replaces Travis

> I think people will still want to have Travis around since it's free
machines and the easiest to set up.  With Jenkins we'd be using our own
hardware or have to have people slave their machines.

> But it would be easier to configure to push things to Project websites.

> Think OSGeoLive having docs built and pushed to OSGeoLive website at any
change.

> That's one job Jenkins does for us on PostGIS side, updating the docs at
every commit and pushing them to the website.

> >  * Pay Travis more

> And to decide we need to know:
>   * Is having a Jenkins really an option here? Or something will be
missing?

> Again I don't think it should be an either / or. Each has their strengths
and weaknesses.

> E.g. appveyor tests windows, Travis doesn't.  Jenkins can test any OS you
add as a slave or be in standalone mode.

> Only thing that is not clear to me if having one Jenkins is sufficient.
I don't think it will be. But we can at the very least have a formulaic
setup

> And images ready should people want to use it and configure for their own
needs.

> Travis CI and Gitlab CI are probably the most interchangeable with Gitlab
you can pay or host your own, but there is a bit of work translating your
travis script to gitlab.

> Travis is the free-tier or pay of which both are closed source solutions.

>   > * Will it be cheaper?

> It will definitely not be cheaper in terms of labor , but will provide
more flexibility, I would focus on where that flexibility is needed first.

> I think you can coax travis to do things like pushing artifacts to
websites like binary builds but not as straightforward as it is with
Jenkins.  I could be mistaken since I know a bit more about Jenkins than
Travis.

> I'm sure Hobu will correct my ignorance and rave about all the goodness
of Travis J

> Thanks,

> Regina

-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp