GitHub Actions – CI/CD auf kurzem Wege

Mit „Actions“ versucht GitHub in den Markt der CI/CD-Provider einzusteigen und will sich hier ein Stück des Kuchens abgreifen. GitHub Actions sind der nächste logische und vielleicht auch überfällige Schritt des Unternehmens, nicht nur Versionsverwaltung as a Service anzubieten und Code zu hosten, sondern diesen auch direkt im gleichen Ökosystem testen, bauen und releasen lassen zu können. Andere Anbieter wie GitLab oder Bitbucket bieten diese Funktionalität bereits seit längerem an. GitHub-Nutzer mussten bisher auf externe Lösungen wie bspw. CircleCI oder Travis CI ausweichen. Mit den GitHub Actions wird das Rad nicht neu erfunden und daher ist es nicht verwunderlich, dass GitHub auf bereits etablierte Konzepte und Vorgehensweisen anderer Anbieter zurückgreift. So werden die CI/CD-Pipelines, welche bei GitHub als Workflow bezeichnet werden, zum Beispiel auch in YAML geschrieben und als Teil des Quellcodes im Repository abgelegt. Auch ist die Definition einer Laufzeitumgebung (Windows, macOS, Linux) möglich und die Angabe von (mehreren) Versionen einer Laufzeitumgebung kann definiert werden.

Zentrale Konzepte

GitHub verwendet zwar im Kern ähnliche Konzepte wie die bekannten CI/CD-Provider am Markt, jedoch gibt es im Detail kleine Abweichungen. Daher definiert GitHub die gegebenen Konzepte wie folgt:

Workflow – Ein Workflow ist das Aggregat einzelner Teilaufgaben, die für das Bauen, Testen, Packen, Release und/oder Deployen eines Projekts notwendig sind. Um einen Workflow auszuführen, können trigger (bspw. on push) oder cronjobs definiert werden. Die einzelnen Schritte werden bei GitHub „Job“ genannt.

Job – Ein Job setzt sich aus einzelnen Schritten (Steps) zusammen. Jobs können parallel oder nacheinander ausgeführt werden und definieren die Umgebung, in welcher die zugeordneten Schritte ausgeführt werden sollen. Hierfür kann zwischen Linux (ubuntu), Windows oder macOS ausgewählt werden.

Step – Ein Step definiert eine einzelne Aufgabe, die in der vom Job vorgegebenen Umgebung ausgeführt wird. Eine Aufgabe kann hierbei ein Command (bspw. npm install) oder eine Action sein.

Action – Actions sind aggregierte (meist komplexe) Step-Implementierungen, die wiederverwendet werden können. Statt beispielsweise für den Checkout immer wieder „git clone“ als Command zu implementieren, kann die Action „actions/checkout@v1“ verwendet werden.

Ein Beispiel anhand von Node.JS

Um es frei nach Goethe zu sagen: Genug der Worte, Taten warten! – Folgende GitHub-Action-Definition zeigt, wie ein Node-Projekt in drei verschiedenen Node-Versionen gebaut werden kann. Der Workflow wird bei jedem „push“-Event getriggert und startet anschließend für jede angegebene Node-Version einen virtuellen Runner, welcher ein Ubuntu bereitstellt. Auf diesen Runner werden anschließend alle Steps ausgeführt: Auschecken der Sourcen, Installation der Node-Version, Logik, um das Node-Projekt zu bauen, testen und zu releasen. Eine genaue Beschreibung der einzelnen Syntaxelemente ist ebenfalls von GitHub dokumentiert und kann hier eingesehen werden.

name: Node.JS CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [8.x, 10.x, 12.x]

    steps:
    - uses: actions/checkout@v1
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - name: npm install, build, and test
      run: |
        npm install
        npm run prepare:release
      env:
        CI: true
        RUN_SLOW_TESTS: true

Wird diese Workflow-Definition unter „.github/workflows/nodejs.yml“ im Repository abgelegt, kann unter dem Reiter „Actions“ eine Übersicht der einzelnen „Workflow runs“ (sofern bereits einer gestartet wurde) und Workflow-Definitionen abgerufen werden.

Auch eine Detailansicht der einzelnen Runs wird, wie von anderen Providern gewohnt, angeboten und im folgenden Bild deutlich. Jeder Teilschritt wird hierbei als Kopfzeile dargestellt, hinter welcher initial die entsprechenden Logausgaben versteckt werden. Durch einen Klick auf einen Workflow-Schritt können entsprechend weitere Logausgaben abgerufen werden. Im linken Bereich der Seite werden – sofern konfiguriert – die verschiedenen parametrisierten Workflows angezeigt. In dem vorliegenden Beispiel sind es die drei Node-Versionen 8, 10 und 12.

Einschränkungen

In einigen Fällen können Workflows Ressourcen-hungrig oder komplex sein. Daher sieht GitHub ein paar wenige Einschränkungen für die Verwendung von GitHub Actions vor. Diese Limits gelten jeweils pro Repository und sind als „harte“ Limits zu berücksichtigen:

• Maximal 20 gleichzeitige Workflows
• Maximal insgesamt 1000 API-Requests pro Stunde
• Maximale Laufzeit eines Workflows: 6 Stunden
• Maximal 20 parallele Jobs

Fazit

Dieser Beitrag umreißt, welche neuen Möglichkeiten GitHub mit dem bald öffentlich verfügbaren Feature „Actions“ anbieten wird. Aktuell scheinen die Möglichkeiten noch recht rudimentär zu sein, doch der Vorteil eine CI/CD-Pipeline direkt beim Git-Provider selbst definieren zu können bietet zumindest für kleine und vor allem neue Projekte einen gewissen Mehrwert. Inwiefern sich GitHub Actions gegen die verbreiteten üblichen Verdächtigen im Bereich CI/CD durchsetzen kann, wird sich zeigen.