Publish the book on Github pages?

[RobertPincus]

We are currently using a Gitlab workflow to publish the compiled book on GWDG, and using a separate Github workflow as continuous integration to ensure the book compiles.

It seems that we could publish the pages on Github relatively easily. Should we do this too, or instead or, publishing on GWDG via Gitlab?

[d70-t]

I like the way gitlab handles pages a lot more than github does because:

• pushing compiled things back into the own repository seems to be very weird
• cloning the repository will result in cloning the gh-pages branch as well per default. For some tools, this create quite a messy view

The gitlab solution is much cleaner to my eyes. You'll create a CI Job called pages, which creates an asset called public and that's your page. This by the way also allows for simple preview of non-master branches, as the CI assets on gitlab are browsable by default.

That said, it is a bit more complex to manage those two CIs. Initially I thought we can get along with only gitlab ci, but as the mirrored repository doesn't see the contents of a fork, it can't run on pull requests.

So there are pros and cons for both solutions and I am still undecided.

---

Apart from that, there's another more generic and maybe more important thing: we should find a way to point to the book and its chapters in a future-proof way. Currently there's http://doi.org/21.11101/0000-0007-EBF5-C which (obviously 😁) is not a DOI. That thing points to the Book in its current version and can be adjusted to point to new locations (currently only by me, but that's supposed to change). However, the handle-system doesn't provide facilities to do deep links. So we can't universally reference to i.e. the dropsondes via http://doi.org/21.11101/0000-0007-EBF5-C/dropsondes.html, while https://eurec4a.pages.gwdg.de/how_to_eurec4a/dropsondes.html is perfectly fine.

Until we have a good way to handle this, I am reluctant to move the book to anywhere which is even more out of out control then GWDG already is. And I'd definitely consider Github to be more out of our control. I think the most feasible way to do these kinds of things would be to use the eurec4a.eu DNS entry and refer to the book as https://howto.eurec4a.eu .

This problem generalizes in principle also to the flight phase files as well as to the intake catalog, but we've sidestepped the issue a bit through the use of the eurec4a Python package.

What are your opinions here?

[d70-t]

I am experimenting with github pages at d70-t:github_publish. It should be possible to just download the built artifact after a successful test-build and re-publish it to gh-pages. Custom domains can be set up on gh-pages in principle an I think redirecting howto.eurec4a.eu to that place should be simple enough and would give us (hopefully) more stable links to the book, even if we should move it again in the future.

For now, I just have to wait for the opendap server to come up again though...

[d70-t]

I've now created a test-setup for the book on github-pages with custom domain and HTTPS: https://eurec4a-howto.die70.de . This should be simple to transfer to howto.eurec4a.eu and then we'd probably be fine to run it either on GWDG or on github-pages.

[d70-t]

The book is now available on https://howto.eurec4a.eu