[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: Proposal: Recommend meson for glib 2.58.0
From: Emmanuele Bassi <ebassi () gmail ! com>
Date: 2018-06-15 16:41:50
Message-ID: CALnHYQHfYy4Xf+wSOXAmhSOzx5odwKMyF21AEKbnSvu05smvPQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, 15 Jun 2018 at 16:34, <xclaesse@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
coverage/".
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.
Ciao,
Emmanuele.
--
https://www.bassi.io
[@] ebassi [@gmail.com]
[Attachment #5 (text/html)]
<div dir="ltr">On Fri, 15 Jun 2018 at 16:34, <<a \
href="mailto:xclaesse@gmail.com">xclaesse@gmail.com</a>> wrote:<br><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Le vendredi 08 juin 2018 Ã 20:25 \
+0100, Tim-Philipp Müller a écrit :<br> > Just to make sure everyone is aware of \
this, this also means distros<br> > will always need to always build the \
documentation with gtk-doc,<br> > since<br>
> "ninja dist" won't include generated html files in the tarball. \
It<br> > just<br>
> includes whatever is checked into git (they could be checked into git<br>
> of course if that was a deal-breaker for some reason).<br>
<br>
Note that the doc is built and uploaded as part of glib's CI for each<br>
tag, so it can be taken from artifacts. I don't know if it gets<br>
published from there, but we could do something. Emmanuele Bassi<br>
probably knows more about this mechanism.<br></blockquote><div><br></div><div>It \
doesn't get published, only built and stored as artefacts – though it's \
mostly a demonstration of what could be done.</div><div><br></div><div>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 coverage/".</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Ideally, \
this would also serve as the replacement for <a \
href="http://developer.gnome.org">developer.gnome.org</a>.<br></div><div><br></div><div>Ciao,</div><div> \
Emmanuele.<br></div><div><br></div></div>-- <br><div dir="ltr" \
class="gmail_signature" data-smartmail="gmail_signature"><a \
href="https://www.bassi.io" target="_blank">https://www.bassi.io</a><br>[@] ebassi \
[@<a href="http://gmail.com" target="_blank">gmail.com</a>]</div></div>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic