git-pages für statische Websites

stb commented

2026-07-18 21:23:06 +02:00

Owner

Mit Forgejo 16 gehen jetzt zusammen mit git-pages auch PR-Preview-Deployments. Das ist super-cool, nicht nur für unsere Haupt-Geschichten, sondern ggf. auch für weitere User/Projekte.

Wir brauchen eine Domain (z. B ccchh.space oder ccchh.site), unter der die Sites gehostet werden können (damit wir keine Probleme mit CSRF oder Cookies bekommen).

Dann können wir git-pages so aufsetzen, dass man mit der Action einfach eine statische Site oder eine PR-Preview deployen kann. Man kann auch auf separate Domains deployen.

Hier eine Zusammenfassung für User, die ich für Hanse geschrieben habe.

Git Pages https://codeberg.org/git-pages/git-pages ist das Forgejo-Äquivalent zu Github Pages: man kann auf einfache Art und Weise Webseiten deployen, ohne lange mit Webserverconfigs etc. fummeln zu müssen.

"Statische Website" bedeutet, der Webserver liefert ausschließlich statische Seiten, also kein PHP, kein CGI, etc. Man kann solche Seiten von Hand als HTML bauen, oder man benutzt einen Static Site Generator wie z. B. Hugo https://gohugo.io/ oder Astro https://astro.build/. Aber es gibt noch viel viel mehr.

Das Generieren des HTMLs übernimmt eine Forgejo Action (wie Github Actions).

Konkret gibt es diese Möglichkeiten:

Website für euren User: https://user.hanse-page.de: legt ein Repo git.hanse.de/user/pages an und steckt da die entsprechenden Workflow rein. Beispiel: https://git.hanse.de/hanse/pages für die Organisation "hanse".
Website für ein Projekt: https://user.hanse-page.de/project: legt ein Repo git.hanse.de/user/project an und steckt da die entsprechenden Workflow rein. Beispiel: https://git.hanse.de/hanse/git-pages-example
Deployment auf eigene Domain: Legt euch ein Repo an, tragt die richtigen DNS-Records ein, und sagt der Action, dass das Deployment für diese URL ist. Beispiel: https://git.hanse.de/hanse/www.hanse.de

Zusätzlich kann man über Git Pages auch Pull Requests deployen, und so Änderungen vor dem Deployment auf der eigentlichen Website checken. Dazu wird dann user.preview.hanse-page.de/project@pr verwendet; ihr könnt die entsprechenden Actions in den Beispielen sehen.

DNS-Records für eigene Domain:

example.com A 212.12.50.232
example.com AAAA 2a00:14b0:f001:100::e8
_git-pages-forge-allowlist.example.com TXT "https://git.hanse.de/user/repo"

Mit Forgejo 16 gehen jetzt zusammen mit git-pages auch PR-Preview-Deployments. Das ist super-cool, nicht nur für unsere Haupt-Geschichten, sondern ggf. auch für weitere User/Projekte. Wir brauchen eine Domain (z. B ccchh.space oder ccchh.site), unter der die Sites gehostet werden können (damit wir keine Probleme mit CSRF oder Cookies bekommen). Dann können wir git-pages so aufsetzen, dass man mit der Action einfach eine statische Site oder eine PR-Preview deployen kann. Man kann auch auf separate Domains deployen. Hier eine Zusammenfassung für User, die ich für Hanse geschrieben habe. --- Git Pages https://codeberg.org/git-pages/git-pages ist das Forgejo-Äquivalent zu Github Pages: man kann auf einfache Art und Weise Webseiten deployen, ohne lange mit Webserverconfigs etc. fummeln zu müssen. "Statische Website" bedeutet, der Webserver liefert ausschließlich statische Seiten, also kein PHP, kein CGI, etc. Man kann solche Seiten von Hand als HTML bauen, oder man benutzt einen Static Site Generator wie z. B. Hugo https://gohugo.io/ oder Astro https://astro.build/. Aber es gibt noch viel viel mehr. Das Generieren des HTMLs übernimmt eine Forgejo Action (wie Github Actions). Konkret gibt es diese Möglichkeiten: * Website für euren User: https://user.hanse-page.de: legt ein Repo git.hanse.de/user/pages an und steckt da die entsprechenden Workflow rein. Beispiel: https://git.hanse.de/hanse/pages für die Organisation "hanse". * Website für ein Projekt: https://user.hanse-page.de/project: legt ein Repo git.hanse.de/user/project an und steckt da die entsprechenden Workflow rein. Beispiel: https://git.hanse.de/hanse/git-pages-example * Deployment auf eigene Domain: Legt euch ein Repo an, tragt die richtigen DNS-Records ein, und sagt der Action, dass das Deployment für diese URL ist. Beispiel: https://git.hanse.de/hanse/www.hanse.de Zusätzlich kann man über Git Pages auch Pull Requests deployen, und so Änderungen vor dem Deployment auf der eigentlichen Website checken. Dazu wird dann user.preview.hanse-page.de/project@pr verwendet; ihr könnt die entsprechenden Actions in den Beispielen sehen. DNS-Records für eigene Domain: * `example.com A 212.12.50.232` * `example.com AAAA 2a00:14b0:f001:100::e8` * `_git-pages-forge-allowlist.example.com TXT "https://git.hanse.de/`*user*`/`*repo*`"`

stb self-assigned this

2026-07-18 21:23:08 +02:00

stb commented

2026-07-18 21:24:18 +02:00

Author

Owner

Es wäre cool, wenn wir den Host direkt exposen können, weil git-pages gleich caddy mit drin hat, und man sich um nichts sonst mehr kümmern muss (also Rev Proxy, Certs, etc.)

stb commented

2026-07-18 22:02:36 +02:00

Author

Owner

ccchh.page ist bestellt.

Rows
Columns

git-pages für statische Websites #128