Wie man in diesem Blog einen Beitrag veröffentlicht

Dieses Blog ist eine statische Website, die mit Hugo generiert und auf GitLab Pages bereitgestellt wird. Jeder Beitrag ist eine Markdown-Datei in einem eigenen Ordner, und Veröffentlichen bedeutet, diese Datei in den Branch main zu mergen. Bei Gaia Lab haben wir hier die vollständigen Schritte zusammengestellt, damit jedes Teammitglied schreiben und veröffentlichen kann, ohne auf jemanden angewiesen zu sein.

Den Beitrag anlegen #

Klone das Repository und lege den Beitrag mit hugo new content an. Hugo wendet den Archetyp archetypes/posts.md auf alles an, was unter posts/ liegt, sodass die Datei bereits mit vorbereitetem Front Matter und mit draft: true entsteht.

git clone <url-del-repositorio> gaia-blog
cd gaia-blog
hugo new content posts/mi-entrada/index.md

Das Ergebnis ist ein Ordner content/posts/mi-entrada/ mit einer index.md darin. Hugo nennt das ein page bundle: Die Fotos und Videos des Beitrags werden in denselben Ordner kopiert und über ihren Namen referenziert, ohne Pfade. Der Ordnername ist die endgültige URL des Beitrags, daher sollte er kurz sein, in Kleinbuchstaben und ohne Akzente.

Das Front Matter #

Der YAML-Block zwischen den beiden --- beschreibt den Beitrag. Alle Schlüssel müssen vorhanden sein, auch wenn sie leer bleiben.

Dieser Beitrag selbst wurde absichtlich ohne Titelbild veröffentlicht, um zu prüfen, wie eine Karte ohne Bild aussieht.

Nützliches Markdown #

Der Textkörper wird in Standard-Markdown geschrieben. Was wir am häufigsten verwenden:

## Encabezado de sección
### Subsección

- Elemento de lista
- Otro elemento

| Parámetro | Valor |
|---|---|
| Red | 5G SA |

> Cita o resultado destacado.

```python
print("código con resaltado por lenguaje")
```

![Texto alternativo descriptivo](foto.jpg "Pie de foto")

Das Bild steht in einem eigenen Absatz, und der Text in Anführungszeichen wird zur Bildunterschrift. So sieht ein echtes Foto aus, das in den Ordner dieses Beitrags kopiert wurde:

Zusätzlich zum Markdown bietet die Vorlage drei Hugo-Shortcodes:

{{< note title="Nota" >}}
Aviso lateral. Admite Markdown y `type="warning"`.
{{< /note >}}

{{< video src="clip.mp4" poster="clip.jpg" caption="Pie del vídeo" >}}

{{< youtube ID_DEL_VIDEO >}}

Und so sieht der erste davon im Einsatz aus:

Die Website lokal ansehen #

hugo server -D

Die Website ist dann unter http://localhost:1313/ erreichbar. Da die baseURL in hugo.toml einen Pfad enthält (/blog/), behält Hugo ihn auch lokal bei, und die tatsächliche Adresse lautet http://localhost:1313/blog/. Die Option -D zeigt auch die Entwürfe an; ohne sie – und im Deployment – existiert ein Beitrag mit draft: true nicht. Änderungen am Markdown werden im Browser automatisch neu geladen.

Veröffentlichen #

Wir veröffentlichen immer aus einem Branch und über einen Merge Request:

git checkout -b post/mi-entrada
git add content/posts/mi-entrada/
git commit -m "Entrada: mi entrada"
git push -u origin post/mi-entrada

Beim Öffnen des Merge Requests in GitLab führt die Pipeline den Job build aus, der prüft, dass die Website kompiliert, und das Ergebnis als Artefakt speichert. Wenn der Merge Request in main gemergt wird, baut der Job pages die Website mit der endgültigen URL erneut und stellt sie auf GitLab Pages bereit; der Beitrag erscheint nach ein bis zwei Minuten.

Fotos und Videos #

Fotos werden als JPG mit 1.400 bis 2.000 px Breite hochgeladen, korrekt ausgerichtet und ohne Metadaten. Mit ImageMagick:

magick foto.JPG -auto-orient -strip -resize 1600x -quality 80 salida.jpg

Videos kommen als MP4 in H.264 mit dem Index am Anfang der Datei (faststart), damit die Wiedergabe beginnt, bevor sie vollständig heruntergeladen sind. Der erste Befehl kodiert ein beliebiges Video nach H.264 um; der zweite genügt, wenn es bereits H.264 ist und nur der Index verschoben werden muss, ohne Neukodierung:

ffmpeg -i original.mp4 -c:v libx264 -crf 28 -movflags +faststart clip.mp4
ffmpeg -i clip.mp4 -c copy -movflags +faststart salida.mp4

Lade keine schweren Originale, keine RAW-Dateien und keine kompletten Videos ins Repository: Unverarbeitetes Material wird außerhalb des Repositorys aufbewahrt, und in den Ordner des Beitrags gelangt nur die optimierte Version.