d70-t
commented
3 years ago 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-pagesbranch 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?
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?