[mapserver-dev] Rethinking our doc site build workflow (+vote)

[Thomas Gratier]

Hi,

Readthedocs suppose to duplicate your source content for each language.
It does no deal with i18n support. You can see at
https://github.com/rtfd/readthedocs.org/issues/139.
To illustrate,for exemple, opendatamanual mentionned in the issue is always
not working with i18n
https://readthedocs.org/search/project/?q=opendatamanual
Moreover, the docs seems to confirm too
https://read-the-docs.readthedocs.org/en/latest/localization.html
So I don't think it's the best although I think it's perfect for "one
language" project.
I would prefer Travis if possible by using Github hooks.

Cheers

Thomas Gratier


2014-04-07 17:49 GMT+02:00 Daniel Morissette <dmorissette at mapgears.com>:

> +1
>
> Daniel
>
>
> On 14-04-04 4:55 PM, thomas bonfort wrote:
>
>> PSC,
>>
>> In light of the recent projectsvm downtime and the (increasing, given
>> the new translations) load we are putting on that server while
>> building our docs, I would like to propose that we transition our
>> build process to use travis-ci for the compilation part.
>>
>> In clear, docs would be automatically built on travis-ci.org once a
>> commit is pushed on the stable or master branch, and would then be
>> scp'd/rsync'd to the public projectvm directory on success.
>>
>> Advantages:
>> - no need to maintain build scripts on the projectsvm
>> - the actual travis config files are simple and minimal:
>> https://github.com/tbonfort/docs/commit/1d178ab6e6d0765adfbb0fea40404a
>> 6a1803a969
>> (without the logic to publish to mapserver.org yet, though)
>>
>> Inconveniences:
>> - we rely on an external service we have no control on. we can always
>> switch back to the current solution if needed (no www.mapserver.org
>> downtime, the docs would just not be in sync while we transitioned).
>> - building the PDFs has a non-negligeable impact on build times and
>> apt packages needed to be installed on the travis instances. They
>> would therefore be disabled by default, but might be enabled on a
>> case-by-case basis if the commit message contains a magic keyword.
>> - it might seem we are loosing control as to what is published on the
>> mapserver.org website (given the resulting website is automatically
>> published). In practice this is more or less already the case with the
>> automatic builds happening on the projectsvm.
>>
>> I've had confirmation from the travis team that we are not abusing
>> their system by implementing this:
>>
>> ===================================================================
>> Hey Thomas,
>>
>> Thanks for getting in touch and checking with us!
>>
>> We absolutely don't mind you using our service to build and push your
>> documentation site, quite the opposite.
>>
>> We're always happy to see people adopt Travis CI in unexpected and new
>> ways, so by all means, ship it!
>>
>> Cheers, Mathias
>>
>> --
>> Mathias Meyer
>> =====================================================================
>>
>> Before investing more time on this, I will need a go from the PSC. I'm
>> going to be offline next week and unable to respond, but will start
>> the transition at my return if no -1s are casted.
>>
>> +1 Use Travis-ci platform to build and publish mapserver website
>>
>> best regards,
>> thomas
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>
>
> --
> Daniel Morissette
> T: +1 418-696-5056 #201
> http://www.mapgears.com/
> Provider of Professional MapServer Support since 2000
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20140407/fc580d90/attachment.html>