On Fri, 15 Jun 2018 at 16:34, <xclae...@gmail.com> wrote:

> Le vendredi 08 juin 2018 à 20:25 +0100, Tim-Philipp Müller a écrit :
> > Just to make sure everyone is aware of this, this also means distros
> > will always need to always build the documentation with gtk-doc,
> > since
> > "ninja dist" won't include generated html files in the tarball. It
> > just
> > includes whatever is checked into git (they could be checked into git
> > of course if that was a deal-breaker for some reason).
> Note that the doc is built and uploaded as part of glib's CI for each
> tag, so it can be taken from artifacts. I don't know if it gets
> published from there, but we could do something. Emmanuele Bassi
> probably knows more about this mechanism.

It doesn't get published, only built and stored as artefacts – though it's
mostly a demonstration of what could be done.

The main issue with using GitLab pages is that publishing wipes out the
deployment every time, so we cannot have things like "publish the API
reference for master under unstable/ and the API reference for for each
branch under branchname/ and then publish the test suite coverage under

The only way to achieve this would be to build the API reference then push
it to some other repository, and have a CI hook that deploys everything.
This would allow building different versions of the API reference, and
additionally have things like coverage (per branch) and a simple website.
I've started looking into this, but it's kind of complicated, as it
requires creating a new `glib-docs` user and repo; generate SSH keys for
it; and then have the CI infrastructure store the SSH keys as secrets and
use them during the CI build.

Alternatively, we'd need a place accessible from the CI infra to copy our
files into, that would get published automatically on our web servers.

Ideally, this would also serve as the replacement for developer.gnome.org.


[@] ebassi [@gmail.com]
gtk-devel-list mailing list

Reply via email to