[Board] Travis-CI & OSGeo

Tue May 1 00:39:38 PDT 2018

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 :)

Thanks,

Regina

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/board/attachments/20180501/be814583/attachment.htm>