GitHub als CMS (2/2): Statische Webseiten mit Travis CI bauen

Im ersten Teil dieser Artikelserie ist erläutert, wie man Web-Autoren das Editieren von Inhalten mittels GitHub erleichtern kann.

Dieser Artikel beschreibt das automatische Generieren und Veröffentlichen der Webseiten.

Grundkonzept

Grundsätzlich sind folgende Schritte erforderlich:

  1. Quellcode beziehen
  2. Statische Webseite bauen
  3. Statische Webseite veröffentlichen

Im Rahmen dieses Artikels werden dafür folgende Dienste genutzt:

  1. Der Quellcode wird auf GitHub verwaltet.
  2. Die statische Webseite wird mittels Travis CI gebaut.
  3. Die resultierende Statische Webseite wird auf GitHub Pages veröffentlicht.

Demnach gelten die jeweiligen Nutzungsrichtlinien von GitHub und Travis CI.

Außerdem ist wichtig, sich bewusst zu sein, dass in beide Dienste im Standardangebot sämtliche Inhalte als Open Source behandeln und somit für jedermann einsehbar sind.

Quellcode von GitHub beziehen

Sobald man sich mit dem entsprechenden GitHub-Konto bei Travis CI angemeldet hat, können einzelne Repositories zur Verarbeitung gewählt werden.

Der Leser sollte dies ohne Schwierigkeiten handhaben können. Details sind in der Travis CI Dokumentation erläutert.

Mittels Travis CI bauen und auf GitHub Pages veröffentlichen

Um von Travis CI in ein Git-Repository schreiben zu können, muss sichergestellt werden, dass sich die Applikation authentifizieren kann.

Anstatt umständlich mit SSH-Schlüsseln zu arbeiten, bietet es sich an, Benutzername und Passwort direkt in der Git-Remote URL fest zu halten.

Access Token generieren

Für diese HTTPS-Authentifizierung wird ein Zugriffskürzel benötigt, welches laut der Beschreibung auf GitHub generiert werden kann.

# Token zur weiteren Verarbeitung speichern
GITHUB_TOKEN=e2643f7d431b071c58729474daaa6d805b336596

Access Token verschlüsseln

Würde man das Token im Klartext in die Konfigurationsdatei schreiben, könnte dieses leicht kompromittiert werden.

Travis CI bietet daher eine einfache Möglichkeit, derartige Daten zu verschlüsseln und im Rahmen des Build-Prozesses wieder zur Verfügung zu stellen.

# Travis Gem installieren
gem install travis travis-lint

# Token verschlüsseln und in .travis.yml schreiben
travis encrypt GITHUB_TOKEN=${GITHUB_TOKEN} --add env.global

# Gültigkeit von .travis.yml sicherstellen
travis-lint

Damit werden Kommandos im späteren Travis CI Build-Prozess den ursprünglichen Wert von ${GITHUB_TOKEN} auslesen können.

Skript zur Veröffentlichung in .travis.yml hinterlegen

Dies ist ein vollständiges Beispiel für die Datei .travis.yml.

Nachdem die Abhängigkeiten installiert sind, wird die Seite gebaut (middleman build). Anschließend wird das Ergebnis als eigenes Git-Repository initialisiert, konfiguriert und in das Ziel-Repository veröffentlicht.

Man beachte den Zugriff auf ${GITHUB_TOKEN} im Rahmen des git remote Kommandos. Wichtig ist auch die Verwendung von --quiet um zu verhindern, dass das Token auf der Travis CI Website im Klartext aufscheint.

Achtung: In diesem Beispiel werden die Inhalte des Ziel-Repository gänzlich gelöscht und neu angelegt.

language: ruby
rvm: 2.0.0
env:
  global:
    secure: I3lfngRydxAJzdZQ7lVf2h8EqymIH8OyR71miD1NDN5ioOfXSaVPzB6+OX2KGI9x4TXs4QKZdBpu5zEJDfLqbLbbmn4X8AayGgzEmcEkubAOc8/epdELlYRxBL4x5v5R/wRDEl+0mr9G+cYZ+UKhvFnXnUX1V9JvsHS1P+xbfHk=
before_install:
- sudo apt-get update -qq
- sudo apt-get install -qq jpegoptim libjpeg-turbo-progs pngcrush optipng advancecomp
script: |
  bundle exec middleman build &&
  cd ./build && site_url=`cat CNAME` && [ ${site_url} != '' ] &&
  git init && git remote add origin https://BENUTZERNAME:${GITHUB_TOKEN}@github.com/BENUTZERNAME/${site_url}-build.git &&
  git config user.email \"`date '+%Y'`@example.org\" && git config user.name \"Travis\ CI `date '+%Y'`\" &&
  git add . && git status --porcelain | git commit --quiet --file=- &&
  git checkout -b gh-pages && git push --quiet --force --set-upstream origin gh-pages

Im gegebenen Anwendungsfall kann ein Build nur dann als erfolgreich betrachtet werden, wenn die Webseite auch korrekt veröffentlicht wurde. Demnach ist in diesem Beispiel die gesamte Logik Teil des Abschnitts script, während in anderen Beispielen entsprechende Hooks wie etwa after_success angebrachter sind.