Mein erster Workflow mit GitHub Actions

Ich habe heute zum ersten Mal einen »Workflow« mit »GitHub Actions« erstellt, um eine Travis-CI-Integration zu ersetzen. Erfreulicherweise ging das recht schnell von der Hand. Hier möchte ich den Prozess als kleinen Einstieg in das Thema beschreiben.

Bei dem Workflow geht es darum, das DEWP-Planet-Feed-Plugin nach Erstellen eines GitHub-Releases in einer direkt nutzbaren Form an den Release anzuhängen, damit Nutzerinnen und Nutzer nicht lokal NPM anwerfen und dann Webpack ausführen müssen, bevor sie es nutzen können.

Was sind GitHub Actions?

Bevor wir einsteigen, gehen wir kurz einen Schritt zurück und klären, was GitHub Actions sind. Mit GitHub Actions können Abläufe/Workflows erstellt werden, die an alle möglichen Ereignisse in einem GitHub-Repository gehängt werden können. Sobald das auslösende Ereignis auftritt, etwa das Erstellen eines Releases, wird die Action ausgeführt.

Denkbar sind damit dann beispielsweise Dinge wie

• Prüfung von Coding-Standards
• Deployment eines Projekts
• To-Do-Kommentare im Code automatisch in Issues umwandeln
• vieles mehr mit fertigen Actions und/oder eigenen.

Eigenen Workflow erstellen

In der Navigationsleiste eines GitHub-Repositorys (wo unter anderem »Code«, »Issues« und »Pull requests« stehen) gibt es den Punkt »Actions«. Nach einem Klick darauf seht ihr bei einem eigenen Repository die Möglichkeit, einen neuen Workflow zu erstellen.

Hier könnt ihr aus unterschiedlichen Vorlagen wählen oder »Set up a workflow yourself« wählen. Bei dem Planet-Feed-Plugin müssen NPM-Pakete installiert werden, ich habe als Startpunkt also das Node.js-Template ausgewählt und dann angepasst.

Egal was ihr wählt, als Nächstes landet ihr in der Bearbeitungsansicht einer YAML-Datei, in der der Workflow definiert wird. Wenn ihr bereits mit anderen Lösungen wie Travis gearbeitet habt, dürfte das vom Prinzip bekannt sein.

Der Code

Hier kommt erst mal der komplette Code meines ersten Workflows, darunter folgt die Erklärung:

name: Deployment

on:
  release:
    types:
      - created

env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-node@v1
      with:
        node-version: '12'
    - name: Install dependencies and run webpack
      run: |
        npm install --silent
        npm run build:production
    - name: Create deployment ZIP
      run: |
        mkdir -p dewp-planet-feed
        rsync -rav --exclude-from='.rsync-exclude' --delete-excluded ./ dewp-planet-feed
        zip -r dewp-planet-feed.zip dewp-planet-feed/
        rm -rf dewp-planet-feed
    - name: Get Release
      id: get_release
      uses: bruceadams/get-release@v1.2.0
    - name: Upload ZIP to release.
      uses: actions/upload-release-asset@v1
      with:
        upload_url: ${{ steps.get_release.outputs.upload_url }}
        asset_path: ./dewp-planet-feed.zip
        asset_name: dewp-planet-feed.zip
        asset_content_type: application/zip
Code-Sprache: YAML (yaml)

Dem Workflow einen Namen und Trigger geben

Am Anfang legen wir den Namen des Workflows auf »Deployment« fest und definieren, dass er beim Erstellen von Releases ausgeführt werden soll. Hier sind viele weitere Events möglich, die in der GitHub-Hilfe auf der Seite »Events that trigger workflows« beschrieben sind.

Wir brauchen später zur Authentifizierung den GITHUB_TOKEN aus dem secrets-Objekt und fügen ihn daher als Umgebungsvariable hinzu.

Aufgaben definieren

Im Bereich jobs werden die konkreten Aufgaben ausgeführt – in unserem Fall ist das nur der deploy-Job, hier wären aber mehrere möglich, die auch aufeinander aufbauen können. Innerhalb des Jobs geben wir den Namen an und die Umgebung, in der der Job ausgeführt werden soll: die neueste Ubuntu-Version.

steps sind die Schritte, aus denen der Job besteht. Bevor eine Aktion mit dem Repo-Code ausgeführt wird, definieren wir über uses zwei GitHub Actions, die genutzt werden sollen:

• actions/checkout@v2 checkt das Repo aus, für das die Action ausgeführt wird, sodass auf dessen Dateien zugegriffen und mit ihnen gearbeitet werden kann.
• actions/setup-node@v1 setzt eine Node-Umgebung mit der definierten Node-Version auf.

Mit einer Build-Matrix ist es auch möglich, den Workflow auf unterschiedlichen Systemen und mit unterschiedlichen Versionen von Sprachen auszuführen.

NPM-Abhängigkeiten installieren und Webpack ausführen

Nachdem diese Aktionen durchgeführt sind, werden die NPM-Abhängigkeiten installiert. Dafür werden im Schritt »Install dependencies and run webpack« als Wert von run die zwei Befehle npm install --silent zur Installation der Abhängigkeiten und npm run build:production zum Ausführen von Webpack ausgeführt.

Zu diesem Zeitpunkt haben wir die Voraussetzungen dafür geschaffen, dass die Dateien einfach zu einer WordPress-Installation hochgeladen werden könnten. Jetzt müssen wir aus diesem Ergebnis noch ein ZIP erstellen und es an den Release hängen.

ZIP erstellen und zum Release hochladen

Zur ZIP-Erstellung wird im »Create deployment ZIP«-Schritt ein Verzeichnis dewp-planet-feed angelegt, in das wir mit rsync alle Dateien und Verzeichnisse kopieren, außer denen, die in einer .rsync-exclude-Datei aufgelistet sind (darunter ist beispielsweise das node_modules-Verzeichnis und alles, was mit einem . beginnt, wie das .git-Verzeichnis oder die .gitignore-Datei.

Nachdem das geschafft ist, erstellt der zip-Befehl aus dem Verzeichnis eine dewp-planet-feed.zip und wir löschen das Verzeichnis (den letzten Schritt können wir uns eigentlich auch sparen, da das Verzeichnis nicht weiter stört).

Für den Upload zum Release nutzen wir eine fertige Action, die allerdings Informationen zu dem Release benötigt, die wir nicht ohne weiteres vorliegen haben. Deshalb schieben wir zunächst einen Schritt »Get Release« ein und geben ihm die ID get_release, die wir gleich noch brauchen. Der Schritt nutzt die Action bruceadams/get-release@v1.2.0, die uns unterschiedliche Informationen zu dem Release zurückgibt, der den Workflow ausgelöst hat, unter anderem die upload_url, die zum Upload von Release-Assets gebraucht wird.

Damit haben wir alle Informationen, um unser erstelltes ZIP-Archiv zum Release hochzuladen. Dafür verwenden wir in »Upload ZIP to release« die Action actions/upload-release-asset und übergeben als Parameter in with die Upload-URL aus dem vorherigen Schritt, den Pfad zu der Datei, den Namen den das Asset haben soll, sowie den Content-Typ.

Wenn wir jetzt einen Release erstellen und unter dem Punkt »Actions« schauen, sollten wir dort unseren Deployment-Workflow werkeln sehen und nach erfolgreichem Abschluss das ZIP-Archiv beim Release 🎉