Task #3537
closedCreate playground for Hugo site
90%
Description
The idea is to host a preview of the new libreoffice.org Hugo site and allow any Gerrit user to push changes to it. It would be a branch in the main repo.
For Hugo, Salt and webhooks for auto-rendering, I found this recent article, which might provide some inspiration: https://www.linode.com/docs/guides/automate-a-static-site-deployment-with-salt/ (interesting bits start from the section Deploy the Hugo Site).
Rather than what Debian offers, it would be necessary to run Hugo 0.82.0 at a minimum. Might as well run 0.87.0, the current version.
No special switches for Hugo are needed, it is enough to use hugo --destination=...
I guess we are not interested in rebasing the playground branch with any possible changes to the master branch. This is supposed to be a short-lived experiment anyway.
Updated by Guilhem Moulin over 2 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 90
Done: https://newdesign2.libreoffice.org.
Each changeset resp. commit resp. branch is built at /changes/$CHANGE_NUMBER resp. /commits/$COMMIT_ID resp. /refs/heads/$BRANCH. This is a poor man's CI/CD as it's not triggered on change but refreshed by cronjob every 5 minutes. There is also no cleanup. But that should be good enough for now.
I see the inclusion of pictures from OSM in the clear. These should at minimum be upgraded to HTTPS (did that to test the pipeline). Also AFAICT OSM isn't included in https://www.libreoffice.org/privacy; I added the relevant (HTTPS) resources for testing, but I guess a new version of the policy needs to be pushed before switching to production.
One minor thing, AFAICT /index.json is accessed using its absolute path, which breaks that form of CI preview. It's currently mapped to the index.json of the master branch.
It's also not impossible that the CSP needs some tweaking (haven't checked every page).
Updated by Beluga Beluga over 2 years ago
Guilhem Moulin wrote in #note-1:
Done: https://newdesign2.libreoffice.org.
Each changeset resp. commit resp. branch is built at /changes/$CHANGE_NUMBER resp. /commits/$COMMIT_ID resp. /refs/heads/$BRANCH. This is a poor man's CI/CD as it's not triggered on change but refreshed by cronjob every 5 minutes. There is also no cleanup. But that should be good enough for now.
Thanks a lot!
I see the inclusion of pictures from OSM in the clear. These should at minimum be upgraded to HTTPS (did that to test the pipeline). Also AFAICT OSM isn't included in https://www.libreoffice.org/privacy; I added the relevant (HTTPS) resources for testing, but I guess a new version of the policy needs to be pushed before switching to production.
Good catch. The community map was copied as-is from the old site, so in itself the omission from the policy is nothing new :)
One minor thing, AFAICT /index.json is accessed using its absolute path, which breaks that form of CI preview. It's currently mapped to the index.json of the master branch.
Right. I just pushed an update that introduces a global JS var for Hugo's .Site.BaseURL. As I leave baseURL blank in the Hugo config, it should always pick up the root of the site.
Updated by Beluga Beluga over 2 years ago
Beluga Beluga wrote in #note-2:
Guilhem Moulin wrote in #note-1:
One minor thing, AFAICT /index.json is accessed using its absolute path, which breaks that form of CI preview. It's currently mapped to the index.json of the master branch.
Right. I just pushed an update that introduces a global JS var for Hugo's .Site.BaseURL. As I leave baseURL blank in the Hugo config, it should always pick up the root of the site.
Um, actually not matching my local experience (newdesign2 is getting a blank var) :)
So the robust way would be (and I think this would be best going into production anyway) to run hugo with
hugo --baseURL urlstring
urlstring being the absolute url for /changes/$CHANGE_NUMBER, /commits/$COMMIT_ID, /refs/heads/$BRANCH
Updated by Guilhem Moulin over 2 years ago
Beluga Beluga wrote in #note-3:
Right. I just pushed an update that introduces a global JS var for Hugo's .Site.BaseURL. As I leave baseURL blank in the Hugo config, it should always pick up the root of the site.
Um, actually not matching my local experience (newdesign2 is getting a blank var) :)
The CSP blocks execution of <script>var BaseURL ="";</script>; that should work if you remove the inline <script/> and use js/….js instead, no?
So the robust way would be (and I think this would be best going into production anyway) to run hugo with
hugo --baseURL urlstringurlstring being the absolute url for /changes/$CHANGE_NUMBER, /commits/$COMMIT_ID, /refs/heads/$BRANCH
That would break the symlink dance used internally by the CI.
Updated by Beluga Beluga over 2 years ago
Guilhem Moulin wrote in #note-4:
Beluga Beluga wrote in #note-3:
Right. I just pushed an update that introduces a global JS var for Hugo's .Site.BaseURL. As I leave baseURL blank in the Hugo config, it should always pick up the root of the site.
Um, actually not matching my local experience (newdesign2 is getting a blank var) :)
The CSP blocks execution of
<script>var BaseURL ="";</script>; that should work if you remove the inline<script/>and use js/….js instead, no?
One problem was that for some reason the .Site.BaseURL was rendered as blank in newdesign2. If it would have rendered as I wanted, I could also have injected it into some html element and read it from the .js file. But now I used window.location.origin, which hopefully should be robust enough: https://git.libreoffice.org/infra/libreofficeorg/commit/2bc56dec92cad92187bbbc9340cf802588add200
Updated by Guilhem Moulin over 2 years ago
- Status changed from Feedback to Closed