GitHub Actions gibt es bereits seit 2018, aber wirklich lieben gelernt habe ich die GitHub Actions eigentlich erst dieses Jahr durch die Weiterentwicklung an HelloCoding.
Die GitHub Actions sind nützlich für Continuous Integration und Continuous Deployment, um es etwas umgangssprachlicher auszudrücken, für das Automatisieren von Prozessen im Entwicklungsprozess oder für das anschließende automatisierte Deployment. Die GitHub Actions leben in den Repositorys. Sie können nicht unabhängig von einem Repository genutzt werden, da sie immer mit dem Repository interagieren, basierend auf den Events zum Beispiel. Um es etwas vereinfachter zum Einstieg auszudrücken: Die GitHub Actions sind dazu da, Scripte jeglicher Programmiersprachen automatisiert an bestimmten Events in einer geschlossenen Umgebung auszuführen.
Um die Welt der GitHub Actions zu stürmen, sollten wir einen Überblick über die Begrifflichkeiten gewinnen, die uns in diesem Zusammenhang immer wieder begegnen werden. Von Workflows, Jobs, Actions, Events und Runners wirst du noch viel hören, sobald du dich mit dem Thema "GitHub Actions" beschäftigst!
Ein Workflow ist ein automatisierter Ablauf, der aus einem oder mehreren Jobs besteht. Die Workflows werden durch entsprechende Events ausgelöst. Diese Workflows werden in einer YAML-Syntax geschrieben und sind elementar zur Verwendung der GitHub Actions.
Ein Job ist die Aufgabe, die innerhalb eines Workflows ausgeführt wird. Dabei kann ein Job selbst Logik ausführen oder in den einzelnen Schritten auch auf die sogenannten Actions zurückgreifen. Ein Job kann in verschiedenen Runner ausgeführt werden und so auch parallel auf verschiedenen Systemen getestet werden.
Innerhalb von Jobs gibt es auch Actions, diese sind dazu da, Logik von einzelnen Schritten in einem Job auszulagern, sodass nicht in jedem Workflow Logik wieder definiert werden muss, die schon in Hunderten Repositorys verwendet wurde. Dazu stellt GitHub auch den Marketplace bereit, in diesem findest du Actions von der Community und GitHub. Es gibt einige, die wir regelmäßig benötigen, in unseren Workflow-Dateien. Diese stelle ich dir später noch mal vor!
Innerhalb einer Repository kann es verschiedene Events geben, die genutzt werden können, um Workflows auszulösen. Diese Events gibt es zum Beispiel, wenn ein Pull Request oder ein Issue erzeugt wird, oder wenn ein Push in einem Branch passiert. Die Möglichkeiten, auf bestimmte Events zu hören, sind sehr umfassend bei Github findest du eine passende Dokumentation. Zusätzlich gibt es auch noch die Möglichkeit, ein schedule Event zu verwenden, das ist ähnlich zu einem klassischen Cronjob. Ich habe diesen für mein Readme Repository verwendet, das meine Artikel im Readme File immer einmal die Woche aufgrund meines RSS-Feeds aktualisiert. Das fertige Workflow File kannst du hier sehen.
Ein Runner ist eine in sich geschlossene Instanz (vergleichbar mit einem Docker Container in etwa), die dazu da ist, einen Job auszuführen. Es gibt verschiedene Typen von Runner dabei muss als erste zwischen den GitHub-hosted Runners und den Self-hosted Runners unterschieden werden. Für die Runner bei GitHub hast du ein unbegrenztes Kontinent an Minuten, solang es sich um eine öffentliche Repository handelt, für Private Repositorys hat GitHub das Ganze für freie Accounts auf 2000 Minuten pro Monat beschränkt, wenn wir von 30 Tagen ausgehen sind das 60 Minuten pro Tag. Eine Alternative dazu sind Self-hosted Runners für private Profile müssen diese je Repository konfiguriert werden, was etwas nervig ist, aber verständlich, GitHub hat auch ein Interesse daran, Geld zu verdienen. Die Self-hosted Runners können auf vielen Geräten betrieben werden: vom MacBook, Windows-Gerät über einen Raspberry Pi oder dem Server in der Cloud ist alles möglich. Innerhalb eines Repositorys unter "Security" > "Actions" > "Runners" und dann der Button "New self-hosted runner" gibts eine Anleitung, wie man einen neuen Self-hosted Runner einrichten kann für das jeweilige Repository.
Persönlich habe ich hervorragende Erfahrungen mit dem Docker Image von Marc gemacht, diese ist einfach über Docker Compose auf jedem Server an den Start zu bringen, wenn man einen Self-hosted Runner benötigt.
Wenn ihr anfangt, mit GitHub Actions zu experimentieren und Private Repositorys verwenden wollt, kann ich euch empfehlen, ein "Limit Spending" unter "Billing & Plans/Monthly spending limits" von 0. $ einzustellen, um sicherzugehen, dass ihr nicht aus Versehen Geld ausgebt.
Es gibt einige Actions, die man schon als sehr elementar ansehen kann, wenn man mit den Workflows arbeiten möchte. Denn alles von null zu starten, ist definitiv zu zeitintensiv in den meisten Fällen. Weshalb GitHub in der Organisation "Actions" einige Actions bereitstellt, die grundlegend genutzt werden können. Die wichtigste wird die Checkout Action sein, diese ist dazu da, eine Repository auszuchecken. Der Checkout ist notwendig, wenn man mit dem Code seiner Repository interagieren möchte. Dort kommt sicherlich der Gedanke auf, ich will doch in meiner Automatisierung immer mit meinem Quellcode interagieren, oder nicht? Es gibt Fälle wie das automatische Hinzufügen von Labels zu Issues, bei denen wir den Quellcode nicht benötigen, weshalb der Checkout nicht immer automatisch gemacht wird. Neben unserem Quelltext brauchen wir auch die jeweilige Programmiersprache, die wir verwenden wollen, um etwa die Unit-Tests unserer Anwendung auszuführen oder bestimmte Analysetools auszuführen, die auf einer bestimmten Sprache basieren. Dafür gibt es auch von GitHub entsprechende Setup Actions für die Programmiersprachen Java, Python, Node/JS, .NET, Go und viele weitere Setup Actions gibt es dann auch noch von Dritten. Für weitere Actions kann ich dir auch das Repository Awesome Actions als Überblick empfehlen und natürlich den offiziellen Marktplatz.
Zwei Tipps möchte ich dir hier mitgeben für deine Workflows. Es gibt leider keinen guten Weg, um GitHub Actions zu debuggen. Gerade wenn man neue Workflows entwickelt, kann es oft ein kleiner Schmerzpunkt sein, deshalb kann ich dir empfehlen, das manuelle Auslösen von Actions zu aktivieren.
Um deine Actions Manuell auszuführen, kannst du einfach workflow_dispatch als Key innerhalb des on Keys verwenden dadurch entsteht eine zusätzliche UI Element in der GitHub Übersicht eines Workflows, worüber du diese Manuell starten kannst, so kannst du bei einer Veränderung unabhängig vom Event auch mal deine Workflows Testen.
on:
workflow_dispatch:Zusätzlich kann man hier auch noch einen Branch auswählen, auf dem der Workflow laufen soll. Außerdem kannst du mittels Inputs weitere Felder in diesem Interface hinzufügen. Gibt es Jobs, die nicht immer ausgeführt werden sollen? Wie wäre es mit einer Checkbox "Skip Linter".
Ein weiterer Wert, den ich nicht vermissen möchte, ist der schedule Key. Mit diesen können zum Beispiel CronJobs konfiguriert werden, damit ein Job zum Beispiel immer alle 7 Tage ausgeführt wird. Dieser eignet sich zum Beispiel dafür, wenn jeden Sonntag einmal die neusten Sicherheitsupdates geladen werden sollen und dann auf die Server gespielt werden.
on:
schedule:
- cron: '0 0 */7 * *'Um unser Wissen aus diesem Artikel noch etwas zu verfestigen, möchte ich dir noch ein kleines Beispiel geben für ein automatisiertes Unit-Testing in Python. Dabei wollen wir immer, wenn ein Pull Request geöffnet wird, dass die Unit-Tests ausgeführt werden. Dafür werden wir verschiedene Elemente benötigen, die ich bis hier beschrieben habe. Das gesamte Ergebnis findest du in der Demo-Repository. Wenn du keine Erfahrung mit Unit-Tests in Python hast und dich das Thema interessiert, kannst du es im Artikel „Wie Unit-Testing in Python funktioniert?“ nachlesen.
Wir werden verschiedene Aspekte in unserem Workflow File abdecken:
Beginnen wir mit dem passenden Event, diese ist pull_request für unseren Fall reicht dieses ganz simple, es gibt hier aber auch noch weiter Optionen, um die Typen bei Bedarf zu verfeinern. Zusätzlich definieren wir noch einen Namen, unter diesem wird unser Workflow später in der UI von GitHub sichtbar.
name: Python Unit Test on PR
on:
pull_request:Nun können wir mit der Definition unserer jobs starten, wir benötigen hier nur einen Job mit mehreren Schritten. Wir werden den Standard Linux ubuntu-latest Runner verwenden von GitHub. Unser Job wird "Python Unit Test" heißen, da diese seine Aufgabe ist.
jobs:
tests:
name: Python Unit Test
runs-on: ubuntu-latest
steps: ... <folgt>Nachdem wir nun unseren Job "tests" mit dem Namen "Python Unit Test" angelegt haben, können wir die einzelnen Schritte steps definieren, die wir benötigen, um unseren Unit-Tests ausführen zu können.
- name: Checkout
uses: actions/checkout@v2Als Erstes müssen wir sozusagen unsere Repository in die virtuelle Umgebung laden, dafür verwenden wir die Checkout Action, die ich oben bereits einmal vorgestellt habe. Anschließend können wir die setup-python Action verwenden, um Python mit der Version 3.11 einzurichten, um unsere Tests dann ausführen zu können. Wie du siehst, können wir mit with zusätzliche Parameter an die Action übergeben, in unserem Fall die korrekte Python-Version, die wir verwenden möchten.
- name: Set up Python 3.11
uses: actions/setup-python@v5
with:
python-version: 3.11Nachdem wir unseren Quelltext zur Verfügung haben und unsere Python Version eingerichtet haben, fehlt uns nur noch das ausführen der Test, eine Besonderheit hier ist noch das | Pipe Symbol diese steht dort um zu definieren, dass es sich nachfolgende um einen mehrzeiligen Textblock handelt, diese ist nützlich, falls du mehr als nur ein Kommando ausführen willst.
- name: Unit Test
run: |
python -m unittest discoverAnschließend hast du eine komplette Datei, aber wo legst du diese jetzt ab? Unter .github/workflows/ein-name.yml kannst du diese jetzt ablegen. Ich habe diese Datei bei mir test_pr.yml benannt.
hellocodingDE/demo-github-actions
Ein Beispiel für Automatisiertes Unit Testing, innerhalb von Github Actions
Zusätzlich habe ich hier noch mal drei wichtige Links, unter diesen kannst du einsehen, wie es aussieht bei einem erfolgreichen Pull Request oder fehlgeschlagenen Pull Request.
Die GitHub Actions sind eine mächtige Funktion für Entwickler:innen und DevOps in der Optimierung ihrer Abläufe. Die Actions können hervorragend genutzt werden, um die Codequalität zu erhalten. Grade in Open-Source-Projekten kann das Maintainer die Arbeit erleichtern, in dem vieles schon automatisiert getestet wird. Oder aber auch für das schnelle Veröffentlichen von neuen Versionen, sei es das Deployment auf Servern oder das Erstellen von Releases, können GitHub Actions verwendet werden. Zum Beispiel hatte ich nun in meinem Projekt GoWordlytics automatische Releases beim Erstellen von Tags eingerichtet, um die Builds für Golang nicht manuell erzeugen zu müssen.
Hinterlasse mir gerne einen Kommentar zum Artikel und wie er dir weitergeholfen hat beziehungsweise, was dir helfen würde das Thema besser zu verstehen. Oder hast du einen Fehler entdeckt, den ich korrigieren sollte? Schreibe mir auch dazu gerne ein Feedback!
Es sind noch keine Kommentare vorhanden? Sei der/die Erste und verfasse einen Kommentar zum Artikel "GitHub Actions: Beherrsche die Welt der Piplines!"!
