8. Ausblick: Automatisierung

HinweisÜberblick

Dauer: 15 min als Ausblick (Theorie), ca. 45 min zum Mitmachen

Fragen: Wie kann GitLab Arbeitsschritte automatisch erledigen? Wie veröffentliche ich eine Webseite direkt aus GitLab?

Lernziele:

  • Erklären, was CI/CD, Pipeline, Job und Runner sind
  • Wissen, wofür man GitLab Pages nutzt
  • Optional: eine kleine Pipeline einrichten, die aus Markdown eine Webseite baut

Die Idee

Bis jetzt haben wir alles von Hand erledigt: Dateien schreiben, committen, Merge Requests annehmen. GitLab kann aber bei jeder Änderung automatisch Arbeitsschritte ausführen.

Beispiel: Unser Forschungstagebuch soll als Webseite erscheinen. Jedes Mal, wenn jemand einen neuen Eintrag committet, baut GitLab die Seite neu und veröffentlicht sie, ohne dass jemand etwas klicken muss.

Begriffe

HinweisCI/CD
  • CI, Continuous Integration: Bei jeder Änderung (oder jedem Merge Request) laufen automatisch Prüfungen. In der Softwareentwicklung sind das Tests, bei Texten zum Beispiel ein Linkcheck.
  • CD, Continuous Deployment: Nach bestandener Prüfung wird das Ergebnis automatisch veröffentlicht.
  • Pipeline: eine Kette von Arbeitsschritten, wie ein Fließband: prüfen → umwandeln → veröffentlichen. Schlägt ein Schritt fehl, hält das Band an.
  • Job: ein einzelner Arbeitsschritt.
  • Stage: eine Phase. Jobs derselben Stage laufen zusammen, dann kommt die nächste Stage.
  • Runner: der Rechner, der die Jobs ausführt, meist in einem Container mit genau der Software, die der Job braucht.
  • .gitlab-ci.yml: eine Textdatei im Hauptverzeichnis des Projekts, in der die Pipeline beschrieben ist (Format: YAML).
  • GitLab Pages: GitLab veröffentlicht das Ergebnis einer Pipeline als Webseite.

Status einer Pipeline („Build“ → „Pipelines“): blau = läuft, grün = erfolgreich, rot = fehlgeschlagen, grau = wartet.

Wofür nutzt man das?

  • Webseiten aus Markdown bauen: Dokumentation, Kursmaterial, Projektseiten. Auch diese Seite entsteht so, nur mit Codeberg statt GitLab.
  • Texte prüfen, etwa auf kaputte Links oder Rechtschreibung
  • Aus Markdown automatisch PDF- oder Word-Dateien erzeugen
  • Metadaten validieren, zum Beispiel ob eine Datei einem Schema entspricht
  • Software bei jedem Merge Request automatisch testen

Optional: zum Mitmachen

WarnungVoraussetzung: ein Runner

Auf gitlab.com stellen Runner die Rechenzeit bereit („instance runners“). Sie setzen eine Verifizierung des Accounts voraus, zum Beispiel per Telefon oder Kreditkarte. Ohne sie schlägt jede Pipeline fehl. Auf eigenen Instanzen entscheiden die Admins, ob Runner und Pages zur Verfügung stehen.

  1. Im Forschungstagebuch links „Build“ → „Pipeline editor“ öffnen und die Konfiguration anlegen.
  2. Den Inhalt durch Folgendes ersetzen:
stages:
  - check
  - publish

check-for-mds:
  image: bash:latest
  stage: check
  script:
    - compgen -G '*.md'

pages:
  image:
    name: pandoc/core:latest
    entrypoint: ["/bin/sh", "-c"]
  stage: publish
  script:
    - mkdir public
    - pandoc *.md --standalone --metadata title="Forschungstagebuch" -o public/index.html
  artifacts:
    paths:
      - public
  1. Mit einer Nachricht wie „Pipeline für Webseite eingerichtet“ committen.
  2. Unter „Build“ → „Pipelines“ zuschauen, bis beide Stages grün sind.
  3. Unter „Deploy“ → „Pages“ den Link zur Webseite öffnen.

Was passiert hier?

  • stages: Wir definieren zwei Phasen, check und publish.
  • check-for-mds läuft im Container bash und prüft mit compgen, ob es überhaupt .md-Dateien gibt. Wenn nicht, hat wohl jemand alles gelöscht, und die Pipeline stoppt.
  • pages läuft im Container von Pandoc, einem Programm, das Dokumente zwischen Formaten umwandelt. Es fügt alle Markdown-Dateien zu einer HTML-Seite public/index.html zusammen. Die Zeile entrypoint ist nötig, damit GitLab im Pandoc-Container eine Shell starten kann.
  • Ein Job namens pages, der seine Ergebnisse im Ordner public ablegt, wird von GitLab automatisch als Webseite veröffentlicht. Auf gitlab.com liegt sie unter einer Adresse mit gitlab.io.
  • artifacts legt fest, welche Dateien GitLab nach dem Job aufbewahrt. Man kann sie auch herunterladen.

Ab jetzt baut jeder Commit die Webseite neu. Die Reihenfolge der Einträge ist dabei alphabetisch nach Dateinamen, Tagebucheinträge mit Datum im Namen stehen also automatisch in zeitlicher Reihenfolge.

Mehr Möglichkeiten, etwa Jobs nur für bestimmte Branches: Referenz zur .gitlab-ci.yml.

Kernaussagen

  • GitLab kann bei jeder Änderung automatisch Arbeitsschritte ausführen (CI/CD).
  • Beschrieben wird das in der Datei .gitlab-ci.yml.
  • Mit GitLab Pages lassen sich Ergebnisse direkt als Webseite veröffentlichen.