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

[thomas bonfort]

psc,

mapserver.org is now serving a website built by travis-ci. The built
static website is itself versionned and hosted on github, our osgeo vm
just needs to update its local copy of its clone in order to stay
updated. We also have a fallback in case the projects vm falls again,
at http://mapserver.github.io/ (that could become the master for
www.mapserver.org if we pointed the mapserver.org DNS to it).

I still need to work on hosting the pdf files, hosting the development
(master) version of the docs, and automatically updating the
projectsvm when a commit is pushed to the git repository.

The docs themselves (along with their build scripts) have been
slightly modified:
- english docs are not built in the en/ subdirectory anymore but are
placed in the root of the build directory (to avoid having to setup
redirects)
- there is no need for a mapservorg target anymore
- the cron jobs and the en/ redirects on mapserver.org have been
disabled to account for these changes

let me know if you see anything strange...

regards,
thomas


On 4 April 2014 22:55, thomas bonfort <thomas.bonfort at gmail.com> 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/1d178ab6e6d0765adfbb0fea40404a6a1803a969
> (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