libdivecomputer server migration

[Jef Driesen]

On 19-01-18 16:59, Anton Lundin wrote:
> On 19 January, 2018 - Jef Driesen wrote:
> 
>> On 19-01-18 11:58, Anton Lundin wrote:
>>> On 19 January, 2018 - Jef Driesen wrote:
>>>> The libdivecomputer infrastructure is being migrated to another
>>>> server. This will affect the following services:
>>>>
>>>> * Website and mailinglist
>>>>
>>>> These services have already been migrated. This is supposed to be fully
>>>> transparent, although you might experience a little downtime today.
>>>
>>> I'd even suggest you migrate the website to github too, and host it with
>>> github pages: https://pages.github.com/
>>>
>>> The pages looks like static html, and then they're prefect for hosting
>>> in github's infrastructure.
>>
>> That idea crossed my mind as well. But I'm afraid it doesn't work
>> for the entire site. Especially the "doc", "builds" and "releases"
>> directories are a bit problematic. I use ssh/sftp to upload files
>> there. And having to store all those binary files in a git
>> repository would be a bad idea.
> 
> Releases is preferably served out of the github project directly:
> https://github.com/libdivecomputer/libdivecomputer/releases

Yes and no. The tarball from the github website are simply a snapshot from the 
git repository. The release tarballs, generated with "make distcheck" contain a 
lot more. Hence you don't need a full autotools setup installed to build the 
code from those tarballs.

> Pre built binaries can be served the same way, both continuous builds
> and release builds.

For release builds, that should indeed work. And if we can setup continuous 
integration builds, that would even be better. Because then I don't have to 
build and upload manually. So that's no doubt something I want to look into.

But that's not going to work for the experimental builds. That's random stuff I 
build for testing something by end-users. Those get build from code that is not 
checked in anywhere. Thus always manually build and uploaded to the server.

> It would quite simple to generate the doc html to, and just
> automatically check that into a git branch and push it out. I don't
> think they change often enough that it matters.

I was thinking of generating the documentation fully automatically. With a cron 
job on the server or something similar.

Jef