GitHub Actions & Pages

Veröffentlicht am von

GitHub

GitHub ist eine cloud-basierte Plattform, die es Entwicklern ermöglicht, Code zu hosten, zu teilen und gemeinsam daran zu arbeiten. Es basiert auf dem weltweit verbreiteten Versionskontrollsystem Git und erweitert dessen Funktionalität dadurch, dass es Werkzeuge bereitstellt, welche speziell für die Zusammenarbeit in der Softwareentwicklung geschaffen wurden. Seit der Gründung im Jahr 2008 entwickelte sich GitHub mit über 100 Millionen Entwicklern und über 4 Millionen Organisationen zu einer für Softwareentwickler unverzichtbaren Plattform weltweit entwickelt.

Die Software Dateien werden in einem zentralen Ort, einem Repository, mitsamt der Änderungshistorie auf GitHub gespeichert.  Mithilfe von so genannten Branches können Entwickler parallel eigene Arbeitsstränge erstellen, in denen sie Veränderungen wie Fehler beheben oder neue Funktionen entwickeln können, ohne die Hauptversion des Projekts zu beeinflussen. Über Pull-Requests lassen sie die Änderungen des Branches nach Überprüfung in die Hauptversion integrieren.

GitHub selbst bietet umfassende Zugriffskontrollmechanismen, welche es ermöglichen, unterschiedliche Berechtigungsstufen für Mitglieder zuzuweisen, um festzulegen, wer Änderungen vornehmen, Projekte verwalten oder nur Code einsehen darf. Repositories können entweder öffentlich und für alle zugänglich sein oder privat, sodass nur bestimmte Personen darauf zugreifen können. Neben der Zugriffskontrolle stellt GitHub eine Reihe weiterer Werkzeuge bereit, wie Fehlerverfolgung (Bug-Tracking), Aufgabenverwaltung (Task-Management), kontinuierliche Integration (Continuous Integration) und Wikis für Dokumentationen sowie Funktionen wie Pull-Requests, Code Scanning, GitHub Actions, GitHub Pages, Diskussionen und weiteren. Diese Werkzeuge und Funktionen helfen dabei, die Zusammenarbeit im Team zu verbessern, Entwicklungsprozesse zu automatisieren, Sicherheitslücken zu minimieren und dadurch die Benutzerfreundlichkeit und Qualität von Softwareentwicklung zu steigern.

 

GitHub Actions

Was sind GitHub Actions

GitHub Actions ist eine Automatisierungsplattform, mit der Softwareentwickler Workflows in einem GitHub-Repository erstellen können, welche wiederkehrende Aufgaben wie Tests, Builds und Deployments automatisieren. Diese Workflows werden bei einem bestimmten Trigger wie z.B Code-Änderungen oder Pull-Requests ausgeführt und bestehen aus sogenannten Jobs, welche in einer YAML-Datei konfiguriert werden.

CI/CD mit GitHub Actions

GitHub Actions stellt die integrierte Lösung für Continuous Integration (CI) und Continuous Deployment/Delivery (CD) für GitHub dar. Mit CI werden Codeänderungen automatisch getestet, um sicherzustellen, dass Änderungen eines Branch bestehende Funktionalitäten nicht beeinträchtigen. CD ermöglicht es hingegen, getestete Codeänderungen in eine Staging- oder Produktionsumgebung überführen. GitHub Actions ermöglicht es, beide Prozesse innerhalb eines Repositories zu konfigurieren und durchzuführen, wodurch externe CI/CD-Tools oft überflüssig werden.

Vorteile der nativen GitHub Actions-Integration

Die direkte Integration von GitHub Actions in GitHub bietet einige Vorteile. Zum einen wird für das Entwickeln und Verwalten der Workflows keine externen Tools benötigt, was Zeit spart und den Aufwand für die Einrichtung und Verwaltung zusätzlicher CI/CD-Tools.  Für öffentliche Repositories bietet GitHub kostenloses Nutzungsvolumen für die Ausführung von Workflows, was es attraktiv für Open-Source-Projekte macht. Zudem existiert bereits eine große Bibliothek an Actions, welche Entwickler wiederverwenden können, um häufige Aufgaben wie das Testen von Code, das Erstellen von Docker-Containern oder das Veröffentlichen der Software zu automatisieren.

Bestandteile von GitHub Actions

Workflows

Ein Workflow ist eine YAML-basierte Konfiguration, die den Ablauf einer oder mehrerer Aktionen beschreibt, die durch spezifische Events in einem GitHub-Repository ausgelöst werden. Workflows sind die oberste Einheit, in welcher automatisierte Build-, Test- und Bereitstellungspipelines für ein Repository definiert werden. 

Workflows lassen sich grob in drei Komponenten einteilen. Der Trigger bzw. das  Ereignis definiert, welche Bedingung die Ausführung eines Workflows startet. Der Auftrag beinhaltet die eigentlichen Arbeitsschritte des Workflows. Diese Arbeitsschritte können einzelne Shellbefehle bzw. Shellscripts sein. Ebenso können hier jedoch auch sogenannte Aktionen, also extern definierte Prozesse, im Auftrag enthalten sein. Die dritte Komponente eines Workflows ist der Runner. Diese definiert, auf welchem Server der Workflow ausgeführt wird. GitHub bietet kostenlos virtualisierte Linux-, Windows- und macOS-Computer an, alternativ können jedoch auch selbst gehostete Runner angegeben werden.

Trigger

Es gibt prinzipiell vier Arten von Ereignissen, welche einen Workflow auslösen können:

  • Ereignisse, welche den Ursprung im Repository des Workflows haben
  • Ausführungen basierend auf einem Zeitplan
  • Manuelle Ausführungen
  • Ereignisse, welche den Ursprung außerhalb von GitHub haben

Liste aller Ereignisse

Ereignisse mit Ursprung im Repository sind die gängigsten Trigger, fast alle verfügbaren Ereignisse sind in dieser Kategorie. Typische Beispiele sind Push, Pull Requests oder geöffnete Issues. Viele Ereignisse können mit weiteren optionalen Attributen spezifiziert werden. Im vorherigen Beispiel wurde das Pull Request-Ereignis auf den main-Branch sowie auf alle Branches beginnend mit „releases/“ beschränkt.
Typische Anwendungsfälle sind beispielsweise die Erstellung von Releases oder die Ausführung diverser Tests für Codekompatibilität und -qualität.

Mit dem schedule-Trigger kann mit typischer cron-Syntax definiert werden, dass ein Workflow nach einem Zeitplan ausgeführt wird. Hier ist zu beachten, dass die kleinste Zeiteinheit die Minute ist, und dass dieser Trigger maximal alle 5 Minuten eine Workflowausführung starten kann.

Mithilfe von workflow_dispatch wird erlaubt, dass ein Workflow manuell gestartet werden kann. Dieser Trigger wird häufig verwendet, um im Fehlerfall während der Ausführung leicht eine Neuausführung anzustoßen.

Zuletzt existiert repository_dispatch. Dieses Ereignis erlaubt, dass Ereignisse außerhalb des Repositories mithilfe eines API-Aufrufs akzeptiert werden. Mithilfe eines Tokens, der für Workflowausführungen autorisiert ist, kann ein POST-Request an die GitHub API-URL für das Repository gesendet werden. Dort muss im JSON-Körper ein frei wählbarer Event-Typ (als String) übergeben werden. Wenn in der Workflowdatei kein types: [...] Attribut  definiert ist, wird das Ereignis immer auslösen, ungeachtet des Typs im API-Aufruf. Ansonsten löst es nur aus, wenn der Eventtyp im Request auch hier in der Workflowdatei vorhanden ist.

Konkreter Aufbau des Repository Dispatch API-Aufrufs

Innerhalb einer Workflow-Datei können beliebig viele dieser Trigger innerhalb der on:-Eigenschaft aufgeführt werden.

Auftrag

Innerhalb eines Workflows muss angegeben werden, welche Handlungen durchgeführt werden sollen. Prinzipiell sind diese strukturiert durch zwei Einheiten:

  • Jobs sind die oberste Gliederung dieser Schritte. Ein Workflow kann einen oder mehrere Jobs haben. Sie sind by default unabhängig von einander, laufen also parallel und stoppen sich nicht gegenseitig, wenn ein Job einen Fehler antrifft.
  • Jobs bestehen aus einem oder mehreren Steps, also Handlungsschritten. Diese werden sequentiell ausgeführt, und ein Fehler stoppt by default den gesamten Job (folgende Schritte im Job werden dann also nicht mehr ausgeführt).

Mithilfe des needs: [...]-Feld eines Jobs kann definiert werden, dass dieser auf die Fertigstellung eines anderen Jobs warten muss. Dadurch werden zumindest diese zwei Jobs sequentiell ausgeführt, und ein Fehler im ersten Job verhindert die Ausführung des Zweiten.
Ebenso kann das Fehlerverhalten für Steps überschrieben werden: ein gesamter Job oder ein einzelner Step kann mit continue-on-error: true versehen werden. In Folge wird ein Fehler zwar angezeigt, aber darauffolgende Steps immer ausgeführt.

Arten von Steps

Es gibt zwei Arten von Steps:

  • Shellscripts werden mit run definiert, als Wert kann dann eine einzelne Zeile oder ein mehrzeiliges Shellscript ausgeführt werden. Es kann global oder pro Step definiert werden, welcher Shell-Interpreter und welches Working Directory zu verwenden ist. Standardmäßig wird auf Windows-Runnern PowerShell und auf anderen Runnern Bash oder die Z-Shell verwendet.
  • Actions werden mit uses definiert. Es wird jedoch anstelle von direkten Shellbefehlen eine vordefinierte Sammlung von komplexeren Handlungen aufgerufen. Actions können mithilfe von JavaScript implementiert werden (bspw. die checkout@v4 Action im Beispiel), alternativ können Actions aber auch mithilfe von Docker beliebig implementiert werden. Docker-basierte Actions sind praktisch beliebig mächtig, haben jedoch eine langsamere Startzeit als JS-basierte Actions.
    Zuletzt existieren zusammengesetzte Aktionen, welche praktisch eine separate Workflowdatei ohne Trigger sind. Dort können erneut Jobs und Steps definiert werden, ebenso können Parameter mithilfe des inputs:-Feld übergeben werden.

Github Runner

Runner sind spezialisierte Maschinen, die sowohl virtuell als auch physisch bereitgestellt werden können und eine zentrale Rolle bei der Automatisierung von GitHub-Workflows spielen. Sie sind darauf ausgelegt, verschiedene Aufgaben eines Workflows zu übernehmen, wie beispielsweise das Klonen eines Repositories, das Installieren von Abhängigkeiten, das Ausführen automatisierter Tests und das Erstellen oder Bauen von Anwendungen. Durch diese Automatisierung ermöglichen Runner eine nahtlose Integration und kontinuierliche Bereitstellung (CI/CD), wodurch Entwicklungsprozesse effizienter gestaltet werden.

GitHub bietet Nutzern die Wahl zwischen der Verwendung von Runnern auf eigener Hardware und der Nutzung der von GitHub bereitgestellten Infrastruktur. Die von GitHub zur Verfügung gestellten Runner laufen auf leistungsfähigen virtuellen Maschinen, die speziell für eine Vielzahl von Anwendungsfällen optimiert sind. Diese virtuellen Maschinen sind in verschiedenen Betriebssystem-Umgebungen verfügbar, darunter Ubuntu Linux, Windows und MacOS. Jede dieser Umgebungen ist mit vorinstallierten Tools und Bibliotheken ausgestattet, die häufig in Entwicklungsprojekten benötigt werden, was den Setup-Prozess erheblich vereinfacht.

Ein besonders großer Vorteil der von GitHub bereitgestellten Runner liegt in ihrer Wartungsfreiheit. Die gesamte Pflege, einschließlich der Aktualisierung der Betriebssysteme und der installierten Tools, wird von GitHub übernommen. Dadurch entfällt für die Nutzer der Aufwand, sich um die Instandhaltung oder Aktualisierung der Systeme zu kümmern. Dies macht die Nutzung dieser Runner ideal für Entwicklerteams, die sich vollständig auf ihre Projekte konzentrieren möchten, ohne Zeit und Ressourcen für die Verwaltung der Infrastruktur aufzuwenden. Im Gegensatz dazu erfordert der Einsatz von Runnern auf eigener Hardware eine eigenverantwortliche Wartung und regelmäßige Updates, was zusätzlichen Verwaltungsaufwand mit sich bringt, aber gleichzeitig mehr Kontrolle über die Infrastruktur ermöglicht.

Github Runner Matrix Strategie

Die Matrix-Strategie ist ein leistungsstarkes Konzept, das die automatische Ausführung verschiedener Variationen eines GitHub-Workflow-Jobs ermöglicht. Sie erlaubt es, eine einzige Job Definition zu verwenden, die durch unterschiedliche Variablen angepasst wird, um mehrere Konfigurationen abzudecken. Ein typisches Beispiel ist das Testen oder Ausführen einer Anwendung auf verschiedenen Betriebssystemen wie Linux und Windows. Hierbei wird das Betriebssystem nicht manuell festgelegt, sondern dynamisch durch die Matrix-Strategie gesteuert, sodass GitHub Actions automatisch mehrere Varianten des Jobs parallel ausführt.

Der wesentliche Vorteil dieser Strategie liegt in ihrer Effizienz und Flexibilität. Entwickler können mit minimalem Aufwand verschiedene Anwendungsfälle testen oder ausführen, ohne jeden einzelnen Workflow-Schritt mehrfach definieren zu müssen. So können beispielsweise Kompatibilitätstests, die auf unterschiedlichen Plattformen durchgeführt werden müssen, in einem einzigen Workflow abgedeckt werden. Darüber hinaus spart die parallele Ausführung der Job-Varianten Zeit, da alle definierten Kombinationen gleichzeitig verarbeitet werden, anstatt sie nacheinander auszuführen.

Die Matrix-Strategie eignet sich besonders für Projekte, bei denen Anwendungen plattformübergreifend entwickelt oder getestet werden müssen. Sie ermöglicht eine nahtlose Integration in bestehende Workflows und reduziert den Verwaltungsaufwand erheblich, da GitHub Actions automatisch alle möglichen Kombinationen auf Basis der definierten Variablen erstellt und ausführt. Dies macht die Matrix-Strategie zu einem unverzichtbaren Werkzeug für Teams, die eine breite Testabdeckung erreichen möchten, ohne dabei die Komplexität ihrer Workflow-Konfigurationen zu erhöhen.

Workflow Konfiguration

Dieser GitHub-Workflow definiert einen Build-Job, der mit Hilfe der Matrix-Strategie parallel auf mehreren Betriebssystemen ausgeführt wird. Die unterstützten Plattformen sind Ubuntu, Windows und macOS, jeweils in ihrer neuesten Version. Der Workflow besteht aus zwei zentralen Schritten: Zunächst wird der Quellcode des Repositories mit der GitHub Action actions/checkout@v2 in den Arbeitsbereich geladen. Anschließend werden die Tests der Anwendung mit dem Befehl npm test ausgeführt.

Dank der Matrix-Strategie wird der Job automatisch für jedes der definierten Betriebssysteme parallel gestartet. Dies ermöglicht eine plattformübergreifende Validierung der Anwendung, wodurch sichergestellt wird, dass sie auf allen wichtigen Betriebssystemen einwandfrei funktioniert. Die parallele Ausführung spart dabei Zeit und erhöht die Effizienz des Workflows. Durch die einfache Konfiguration mit einer einzigen Job-Definition wird zudem der Wartungsaufwand reduziert, da keine separate Konfiguration für jedes Betriebssystem erforderlich ist. Dieser Workflow ist besonders nützlich für Node.js-Projekte, die auf zuverlässige Funktionalität über verschiedene Plattformen hinweg angewiesen sind.

 

Github Pages

GitHub Pages ist ein kostenloser Hosting-Dienst von GitHub, der speziell für die Veröffentlichung statischer Websites wie HTML-, CSS- und JavaScript-Dateien konzipiert wurde. Entwickler können damit Projekte, Dokumentationen oder persönliche Webseiten direkt aus einem GitHub-Repository heraus online zugänglich machen. Dazu muss in den Repository-Einstellungen die Option für GitHub Pages aktiviert und der gewünschte Branch ausgewählt werden. Die notwendigen Quelldateien können einfach hochgeladen oder mithilfe von Jekyll (siehe GitHub Docs), einem statischen Webseiten-Generator mit direkter Unterstützung für GitHub Pages, erstellt werden. Nach der Einrichtung ist die veröffentlichte Webseite unter einer automatisch generierten URL erreichbar.

Dabei unterliegt GitHub Pages einigen Einschränkungen, die Nutzer beachten sollten. Der Dienst darf nicht für kommerzielle Zwecke verwendet werden und muss den GitHub-Nutzungsbedingungen (Terms of Service) entsprechen. Außerdem darf die Webseite nicht mehr als 1 GB Speicherplatz belegen und die Bandbreite ist auf 100 GB pro Monat begrenzt. Pro Stunde sind maximal 10 Builds erlaubt, was vor allem bei häufigen Änderungen berücksichtigt werden muss. Zusätzlich gelten allgemeine Rate-Limiting-Regeln, die sicherstellen, dass der Dienst fair und effizient genutzt wird (siehe Einschränkungen von GitHub Pages).

 

Beispiel Konfiguration

Das Repository github-ci-cd-example dient als Beispiel zur Implementierung von Continuous Integration (CI) und Continuous Deployment (CD) Workflows mit GitHub Actions. Es demonstriert, wie Projekte automatisiert gebaut, getestet und bereitgestellt werden können.

Wichtige Merkmale des GitHub Workflows:

  • Trigger: Der Workflow wird durch ein Push-Event oder einen Pull-Request auf den Branch main ausgelöst.
  • Build- und Test-Schritt: Ein zentraler Schritt des Workflows ist das Installieren von Abhängigkeiten und Ausführen von Tests, um sicherzustellen, dass der Code korrekt funktioniert.
  • Deployment: Nach erfolgreichem Abschluss der Tests wird der Code automatisch auf Github Pages deployed.

Der Workflow ist klar strukturiert und nutzt bewährte Praktiken zur Automatisierung von Softwareentwicklungsprozessen.
Weitere Informationen und der vollständige Code sind verfügbar unter: https://github.com/jokresner/github-ci-cd-example

 

Alternativen

Gitlab CI/CD (Gitlab CI/CD Dokumentation)

  • integrierte Lösung innerhalb von GitLab
  • Konfiguration über .gitlab-ci.yml im Repository
  • Self-Hosted oder Cloud möglich

Jenkins (Jenkins Dokumentation)

  • Automatisierungsserver
  • erfordert eine manuelle Konfiguration und Wartung
  • Flexibilität durch Vielzahl von Plugins
  • ist unabhängig von Version Control Systemen und kann in verschiedenen Umgebungen eingesetzt werden

Microsoft Azure Pipeline (Azure Pipelines Dokumentation)

  • CI/CD-Lösung von Microsoft Azure mit starker Bindung ans Microsoft-Ökosystem
  • kann mit Azure-Diensten sowie anderen Plattformen integriert werden
  • Definition in YAML oder über eine grafische Benutzeroberfläche
  • unterstützt beliebige Git-Repositories

Fazit

GitHub Actions ist ein vielseitiges und leistungsstarkes Tool zur Automatisierung von Softwareentwicklungsprozessen direkt in GitHub. Es ermöglicht die nahtlose Integration von Continuous Integration (CI) und Continuous Deployment (CD), wodurch Codeänderungen effizient getestet und bereitgestellt werden können. Die intuitive Konfiguration über YAML-Dateien und die breite Auswahl an vorgefertigten Actions machen es sowohl für kleine Open-Source-Projekte als auch für große Entwicklungsteams attraktiv.

Die Vorteile der nativen Integration, wie die Nutzung GitHub-gehosteter Runner und die Unterstützung durch eine umfangreiche Community, sparen Zeit und reduzieren Komplexität. Funktionen wie die Matrix-Strategie und die einfache Anpassung an unterschiedliche Workflows bieten zudem eine hohe Flexibilität. Für Entwicklerteams, die eine robuste, einfach zu bedienende und kosteneffiziente CI/CD-Lösung suchen, stellt GitHub Actions eine erstklassige Wahl dar.

Trotzdem gibt es Alternativen wie GitLab CI/CD, Jenkins oder Azure Pipelines, die je nach spezifischen Anforderungen ebenfalls in Betracht gezogen werden können. GitHub Actions punktet jedoch besonders durch die enge Integration in GitHub und die einfache Handhabung, was es zu einem bevorzugten Werkzeug für viele Entwickler macht.

 

Quellen