[Qgis-psc] Continuous Deployment for OSGeo4W

[Matthias Kuhn]

Hi

Thanks for the information Hugo !

On 06/12/2018 05:17 PM, Hugo Mercier wrote:
> Hi !
> 
> Thanks for your interest Matthias ! My few comments below.
> 
> On 12/06/2018 13:11, Matthias Kuhn wrote:
>>>> I just stumbled upon a repository from Oslandia [2] that streamlines the
>>>> packaging and integrates it with continuous deployment apparently.
>>> Odd that you had to stumbled upon it - this was also presented and discussed at
>>> the Madeira hackfest and it's one of the benifits of moving from github to
>>> gitlab.
>>
>> Then this must be caused by my absence in Madeira ;)
>> If required a gitlab mirror of the current github repo to trigger
>> gitlab-ci builds should be the smallest part to setup within this
>> infrastructure ;)
>>
> 
> The discussion we had in Madeira has been recorded and is available here:
> https://www.youtube.com/watch?v=s1UtwdMep3w

Nice, thanks to the video recording team :)


> 
>>> But it currently also depends on internal build servers (at oslandia).  It
>>> doesn't upload to the osgeo4w repository, but integrates the repository and has
>>> utility scripts to invoke the build, harvest the packages and add them to taht
>>> repository.  So the current packaging scripts would have to be adapted.
> 
> Indeed.
> The build server is still shared internally with some other customer
> projects. However I would be happy to give access to a few people with
> enough motivation to test and enhance what we already have.
That sounds interesting indeed. So you are the point of contact for this?

> 
> We still plan to dedicate this server to OSGeo4W builds, once we are
> done with the current customer project and would like to give access to
> a wider audience among OSGeo4W packagers little by little (and maybe
> also to PostGIS folks ?).
> 
> We tried to be "close enough" to current conventions that are used by
> compilation scripts so that the effort of adaptation is not that high.
> But I think adaptation of scripts to a new infrastructure is inevitable.

That sounds good, also I can't really see an issue with sharing things
with PostGIS folks. In contrary, that will avoid situations as seen in
the past on Ubuntu with ubuntugis repository where installing qgis and
postgis on the same platform was sometimes hard because they depended on
different gdal libs.
Is there any mid-term plan to integrate this with the main OSGeo4W
repository? And to move those servers under the osgeo or qgis umbrella?


> 
>> Reading this and the above paragraph, I think it's a quite good approach
>> here, proxying to the existing pre-built packages and building a
>> scripted repo on top that eventually can obsolete packages one-by-one.
>>
> 
> That was the initial plan. We currently have an "Oslandia" repository
> that is still unmerged with the "historical" OSGeo4W main repository,
> which is not an ideal situation. Some of our packages are probably not
> stable / complete enough to be merged, and we probably just did not take
> the time to ask for an upload for the rest of them ...

I see. That's exactly where an integrated continuous deployment
infrastructure would help :)

> 
> 
>>> If we wouldn't need (to spend funds on) windows licenses to get this to fly, we
>>> might already have public build machines.  And those seems to be the current
>>> missing bits.
>> I read between the lines that there have been previous (PSC) discussions
>> about this before. And I assume the bottom line was that donations
>> should not be used to feed MS. So I think it might be an opportunity of
>> user groups or organizations to jump in and fill the gap here. If that's
>> the case, I will see if I can do something to get that fixed.
>>
> 
> Good point. However I think the license costs would be negligible
> compared to the hosting / maintenance cost.

That is more than likely, yes.
I'd count the hosting costs on the same budget than the license costs.
For the maintenance costs it's a question if it should be volunteer, if
one company should be contracted to do that and/or if maintenance is
also something that can be put in the community hands (e.g. travis right
now is 99% maintained through scripts in the repo).

Matthias