So führen Sie Ihre GitHub Actions lokal mit Act aus

GitHub Actions haben die Art und Weise, wie Entwickler Workflows in ihren Repositories automatisieren, revolutioniert. Von Continuous Integration und Continuous Deployment (CI/CD) Pipelines bis hin zur Automatisierung der Issue-Kennzeichnung und der Generierung von Release Notes bieten Actions eine leistungsstarke, integrierte Möglichkeit, den Software Development Lifecycle direkt in GitHub zu verwalten.

Die Entwicklung und das Testen dieser Workflows kann sich jedoch manchmal umständlich anfühlen. Der traditionelle Zyklus beinhaltet:

Änderungen an Ihren Workflow-Dateien vornehmen (normalerweise in .github/workflows/).
Diese Änderungen committen.
Sie in Ihr GitHub-Repository pushen.
Warten, bis die GitHub-Runner den Job übernehmen und ausführen.
Die Protokolle auf der GitHub-Website analysieren, um zu sehen, ob Ihre Änderungen funktioniert haben oder ob sie Fehler verursacht haben.

Dieser Prozess, insbesondere das Warten und der Kontextwechsel zwischen Ihrem lokalen Editor und der GitHub-Benutzeroberfläche, kann die Entwicklung erheblich verlangsamen, insbesondere wenn Sie an komplexen Workflows iterieren oder knifflige Probleme debuggen. Was wäre, wenn Sie Ihre Actions testen könnten, bevor Sie sie pushen?

Genau hier kommt act ins Spiel. Wie sein Slogan schon sagt: "Think globally, act locally". act ist ein Open-Source-Befehlszeilen-Tool, das entwickelt wurde, um Ihre GitHub Actions Workflows lokal mit Docker-Containern auszuführen. Es simuliert die von GitHub Actions bereitgestellte Umgebung und ermöglicht es Ihnen, Ihre Workflows schnell zu testen und zu iterieren, ohne jede kleine Änderung committen und pushen zu müssen.

💡

Möchten Sie ein großartiges API-Testtool, das wunderschöne API-Dokumentation generiert?

Möchten Sie eine integrierte All-in-One-Plattform für Ihr Entwicklerteam, um mit maximaler Produktivität zusammenzuarbeiten?

Apidog liefert alle Ihre Anforderungen und ersetzt Postman zu einem viel günstigeren Preis!

button

Warum GitHub Actions lokal mit `act` ausführen?

Die Vorteile der Integration von act in Ihren Entwicklungs-Workflow sind erheblich:

Schnelles Feedback: Dies ist der Hauptvorteil. Anstelle des Commit-Push-Warte-Debug-Zyklus können Sie Ihren Workflow sofort nach einer lokalen Änderung ausführen. Erhalten Sie Feedback in Sekunden oder Minuten, nicht in Minuten oder Zehnern von Minuten. Dies beschleunigt den Entwicklungs- und Debugging-Prozess für Ihre .github/workflows/-Dateien drastisch.
Lokaler Task-Runner: Viele Projekte verwenden Tools wie make, npm scripts oder benutzerdefinierte Shell-Skripte, um gängige Entwicklungsaufgaben zu definieren (Bauen, Testen, Linting usw.). act ermöglicht es Ihnen, diese Aufgaben zu konsolidieren. Sie können Ihre Build-, Test- und andere Prozesse als GitHub Actions-Jobs definieren und dann act verwenden, um diese gleichen Jobs lokal für Entwicklungszwecke auszuführen. Dies reduziert Duplizierungen und gewährleistet Konsistenz zwischen Ihrer lokalen Entwicklungsumgebung und Ihrer CI/CD-Pipeline. Sie definieren die Aufgaben einmal in Ihren Workflow-Dateien, und sie werden überall identisch (oder sehr ähnlich) ausgeführt.
Offline-Entwicklung: Testen Sie die grundlegende Workflow-Syntax und -Logik auch ohne ständige Internetverbindung (obwohl anfängliche Image-Downloads und bestimmte Aktionen möglicherweise Konnektivität erfordern).
Kosteneinsparungen: Während GitHub eine großzügige kostenlose Stufe für öffentliche Repositories und eine angemessene Preisgestaltung für private Repositories bietet, kann die wiederholte Ausführung komplexer oder langer Workflows während der Entwicklung Runner-Minuten verbrauchen. Lokales Testen vermeidet diese Nutzung.
Debugging-Leistung: Das Debuggen fehlgeschlagener Actions auf GitHub beinhaltet oft das Hinzufügen zusätzlicher Protokollierung, das Pushen und Warten. Mit act können Sie die lokale Umgebung untersuchen, Volumes einbinden und möglicherweise fortschrittlichere Debugging-Techniken innerhalb der Docker-Container verwenden, die es startet.

Wie funktioniert `act`?

Das Verständnis des Mechanismus hinter act hilft bei der effektiven Verwendung und der Fehlerbehebung potenzieller Probleme. Hier ist eine Aufschlüsselung seiner Funktionsweise:

Workflow-Parsing: Wenn Sie den Befehl act im Stammverzeichnis Ihres Repositorys ausführen, scannt er das Verzeichnis .github/workflows/ nach Ihren Workflow-YAML-Dateien.
Event-Trigger-Simulation: Standardmäßig simuliert act ein push-Event, aber Sie können auch andere Events wie pull_request, workflow_dispatch usw. angeben. Es bestimmt, welche Workflows und Jobs ausgeführt werden sollen, basierend auf dem angegebenen Event und den in Ihren Workflow-Dateien definierten on:-Triggern.
Abhängigkeitsanalyse: act analysiert die Abhängigkeiten zwischen Jobs innerhalb eines Workflows (unter Verwendung des Schlüsselworts needs:), um die richtige Ausführungsreihenfolge zu bestimmen.
Docker-Image-Verwaltung: Für jeden Job identifiziert act die angegebene Runner-Umgebung (z. B. runs-on: ubuntu-latest). Anschließend ordnet es diese einem bestimmten Docker-Image zu. act verwendet die Docker-API, um:

Images abzurufen: Laden Sie die erforderlichen Runner-Images und alle Docker-Images herunter, die von Container-Aktionen verwendet werden (uses: docker://...). Standardmäßig werden Images bei jeder Ausführung abgerufen, sofern nicht anders konfiguriert.
Images erstellen (falls erforderlich): Wenn eine Aktion auf ein lokales Dockerfile verweist (uses: ./path/to/action), kann act das Docker-Image lokal erstellen.

Container-Ausführung: act verwendet die Docker-API, um Container für jeden Schritt innerhalb eines Jobs zu erstellen und auszuführen. Es konfiguriert diese Container so, dass sie die GitHub Actions-Umgebung so genau wie möglich nachahmen:

Umgebungsvariablen: Standardmäßige GitHub Actions-Umgebungsvariablen (wie GITHUB_SHA, GITHUB_REF, GITHUB_REPOSITORY, CI usw.) werden injiziert.
Dateisystem: Der Repository-Code wird in das Arbeitsverzeichnis des Containers (/github/workspace) eingebunden. Dateien, die von Schritten generiert werden, werden innerhalb des Containers für nachfolgende Schritte beibehalten.
Netzwerk: Container werden typischerweise in einem Docker-Bridge-Netzwerk ausgeführt, wodurch die Kommunikation bei Bedarf ermöglicht wird (obwohl sich die Netzwerkspezifika von der GitHub-Umgebung unterscheiden können).

Log-Streaming: act streamt die Protokolle von den laufenden Containern direkt in Ihr Terminal und liefert so Echtzeit-Feedback zum Ausführungsfortschritt und zu etwaigen Fehlern.

Im Wesentlichen orchestriert act lokale Docker-Container, um den Ausführungsablauf und die Umgebung Ihrer GitHub Actions Workflows zu replizieren.

Voraussetzungen: Docker-Installation

Die Kernabhängigkeit für act ist Docker. act nutzt die Docker-Engine, um die isolierten Umgebungen zu erstellen, die zum Ausführen Ihrer Workflow-Schritte benötigt werden. Bevor Sie act installieren, müssen Sie eine funktionierende Docker-Installation auf Ihrem System haben.

Docker installieren: Befolgen Sie die offiziellen Anweisungen für Ihr Betriebssystem:
macOS: Docker Desktop für Mac
Windows: Docker Desktop für Windows (Benötigt WSL 2 oder Hyper-V)
Linux: Befolgen Sie die spezifischen Anweisungen für Ihre Distribution (z. B. Ubuntu, Fedora, Debian usw.). Stellen Sie sicher, dass Sie Ihren Benutzer der docker-Gruppe hinzufügen, um Docker-Befehle ohne sudo auszuführen.
Docker überprüfen: Öffnen Sie nach der Installation Ihr Terminal und führen Sie docker run hello-world aus. Dieser Befehl lädt ein kleines Test-Image herunter und führt es in einem Container aus. Wenn es erfolgreich ausgeführt wird, ist Ihr Docker-Setup bereit.

`act` installieren

Sobald Docker läuft, können Sie act installieren. Es gibt verschiedene Möglichkeiten, dies zu tun, abhängig von Ihrem Betriebssystem und Ihren Präferenzen.

1. Homebrew (macOS und Linux)

Wenn Sie den Homebrew-Paketmanager verwenden, ist die Installation unkompliziert:

brew install act

Dies installiert die neueste stabile Version. Wenn Sie die absolut neueste Entwicklungsversion (die möglicherweise einen Compiler erfordert) wünschen, können Sie Folgendes verwenden:

brew install act --HEAD

2. GitHub CLI-Erweiterung (macOS, Windows, Linux)

Wenn Sie bereits die GitHub CLI (gh) verwenden, können Sie act als Erweiterung installieren:

gh extension install nektos/gh-act

Nach der Installation rufen Sie act über den Befehl gh auf:

gh act          # Anstelle von nur 'act'
gh act -l
gh act pull_request

3. Chocolatey (Windows)

Für Benutzer des Chocolatey-Paketmanagers unter Windows:

choco install act-cli

(Hinweis: Einige Quellen listen möglicherweise act anstelle von act-cli auf. Überprüfen Sie den neuesten Paketnamen im Chocolatey-Community-Repository, wenn Probleme auftreten.)

4. Scoop (Windows)

Für Benutzer des Scoop-Paketmanagers unter Windows:

scoop install act

5. WinGet (Windows)

Für Benutzer des Windows Package Managers (winget):

winget install nektos.act

6. Linux-Skript-Installer

Für Linux-Distributionen ohne einfachen Zugriff über Paketmanager steht ein praktisches Skript zur Verfügung:

curl -s https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

(Hinweis: Gehen Sie immer mit Vorsicht vor, wenn Sie Skripte direkt in sudo weiterleiten. Überprüfen Sie zuerst den Skriptinhalt, wenn Sie Sicherheitsbedenken haben.)

7. Andere Methoden (Arch, COPR, MacPorts, Nix)

Installationsanweisungen für andere Paketmanager wie pacman (Arch), COPR (Fedora), MacPorts und Nix finden Sie in der offiziellen act-Dokumentation:

Überprüfung:

Öffnen Sie nach der Installation ein neues Terminalfenster und führen Sie Folgendes aus:

act --version
# oder wenn Sie die gh-Erweiterung verwenden:
gh act --version

Dadurch sollte die installierte Version von act ausgegeben werden, wodurch die erfolgreiche Installation bestätigt wird.

Erste Konfiguration: Runner-Images

Wenn Sie act zum ersten Mal in einem Projektverzeichnis ausführen, werden Sie möglicherweise aufgefordert, eine Standard-Runner-Image-Größe auszuwählen. GitHub Actions bietet Runner mit unterschiedlichen Ressourcen und vorinstallierter Software. act versucht, dies durch die Verwendung verschiedener Basis-Docker-Images nachzuahmen.

Normalerweise wird Ihnen eine Auswahl wie diese angezeigt:

? Bitte wählen Sie das Standard-Image aus, das Sie mit act verwenden möchten:

  - Micro: Minimales Image mit Nodejs-Unterstützung (~200MB) docker.io/node:16-buster-slim
  - Medium: Act-Image mit grundlegenden Tools (~500MB) ghcr.io/catthehacker/ubuntu:act-latest
  - Large: Github Actions Runner-Image (~17GB) ghcr.io/catthehacker/ubuntu:full-latest

Standard-Image? [Medium]:

Micro: Basierend auf offiziellen Node.js Slim-Images (wie node:16-buster-slim oder node:16-bullseye-slim). Sehr klein und schnell herunterzuladen, enthält aber nur Node.js und minimale Systembibliotheken. Geeignet, wenn Ihre Aktionen nur Node.js benötigen oder alle ihre Abhängigkeiten selbst installieren.
Medium: Bereitgestellt vom Benutzer catthehacker (z. B. catthehacker/ubuntu:act-latest, catthehacker/ubuntu:act-22.04). Diese Images enthalten häufigere Tools, die auf GitHub-Runnern zu finden sind, sind aber immer noch relativ leichtgewichtig (ca. 500 MB). Dies ist oft die empfohlene Standardeinstellung, da sie Funktionen und Größe ausgleicht.
Large: Ebenfalls von catthehacker (z. B. catthehacker/ubuntu:full-latest, catthehacker/ubuntu:full-22.04). Diese werden aus Dateisystem-Dumps der tatsächlichen von GitHub gehosteten Runner erstellt und enthalten fast die gesamte vorinstallierte Software. Sie bieten die höchste Kompatibilität, sind aber sehr groß (oft >17 GB), was zu langen anfänglichen Downloadzeiten und erheblichem Festplattenspeicherverbrauch führt.

Empfehlung: Beginnen Sie mit dem Medium-Image. Es bietet eine gute Balance und funktioniert für viele gängige Anwendungsfälle. Wenn Probleme aufgrund fehlender Software auftreten, können Sie die Software entweder innerhalb Ihrer Workflow-Schritte installieren oder zu dem Large-Image für diesen bestimmten Runner wechseln (mehr dazu später).

act speichert Ihre Auswahl in einer Konfigurationsdatei (~/.actrc). Sie können die Standardeinstellung später ändern, indem Sie diese Datei bearbeiten oder act in einem Verzeichnis erneut ausführen, in dem es konfiguriert werden muss.

Kern `act`-Verwendung: Ausführen Ihrer Workflows

Sobald act installiert und konfiguriert ist, ist die Verwendung relativ einfach. Navigieren Sie in Ihrem Terminal zum Stammverzeichnis Ihres Projekts (dem, das den Ordner .github enthält).

1. Standard-Event ausführen (push)

Der einfachste Befehl führt die Workflows aus, die durch das Standard-push-Event ausgelöst werden:

act
# oder
gh act

act analysiert Ihre Workflows, identifiziert Jobs, die on: push ausgelöst werden, ruft die erforderlichen Docker-Images ab (falls noch nicht zwischengespeichert) und führt die Jobs aus.

2. Verfügbare Workflows und Jobs auflisten

Um zu sehen, welche Workflows und Jobs act erkennt und für das Standard-Event ausführen würde:

act -l
# oder
gh act -l

Dies gibt eine Liste wie diese aus:

Stage  Job ID        Job name      Workflow name  Workflow file  Events
0      build         Build         CI Pipeline    ci.yaml        push
1      test          Test          CI Pipeline    ci.yaml        push
1      lint          Lint          Code Quality   codeql.yaml    push,pull_request

3. Einen bestimmten Job ausführen

Wenn Sie nur einen einzelnen Job aus einem Workflow testen möchten, verwenden Sie das Flag -j gefolgt von der Job-ID (aus der Ausgabe von act -l):

act -j build
# oder
gh act -j build

4. Ein bestimmtes Event auslösen

Workflows werden oft durch andere Events als push ausgelöst. Sie können diese Events simulieren, indem Sie den Event-Namen als Argument an act übergeben:

# Ein Pull-Request-Event simulieren
act pull_request

# Ein workflow_dispatch-Event simulieren (manuelles Triggern)
act workflow_dispatch

# Ein schedule-Event simulieren
act schedule

# Ein Release-Event simulieren
act release -e event.json # Geben Sie bei Bedarf Event-Payload-Details an

act führt nur Workflows und Jobs aus, die so konfiguriert sind, dass sie on: dem angegebenen Event ausgeführt werden.

5. Eingaben für workflow_dispatch übergeben

Workflows, die durch workflow_dispatch ausgelöst werden, können Eingaben akzeptieren. Sie können diese mit dem Flag --input oder -i bereitstellen:

# Unter der Annahme, dass Ihr Workflow eine Eingabe namens 'environment' hat
act workflow_dispatch --input environment=staging

6. Umgang mit Secrets

GitHub Actions Workflows basieren oft auf Secrets (wie API-Schlüsseln oder Tokens). act greift nicht automatisch auf Ihre GitHub-Secrets zu. Sie müssen sie lokal bereitstellen.

Interaktive Eingabeaufforderung: Verwenden Sie das Flag -s. act fordert Sie auf, den Wert für jedes in Ihrem Workflow definierte Secret einzugeben:

act -s MY_SECRET_TOKEN -s ANOTHER_SECRET

Alternativ fordert nur act -s nach allen Secrets auf.

Umgebungsvariablen: Secrets werden oft als Umgebungsvariablen mit dem Präfix SECRET_ übergeben. Sie können sie in Ihrer Shell definieren, bevor Sie act ausführen:

export SECRET_MY_SECRET_TOKEN="your_value"
act

Secrets-Datei: Erstellen Sie eine Datei (z. B. .secrets) mit KEY=VALUE-Paaren:

MY_SECRET_TOKEN=your_value
ANOTHER_SECRET=another_value

Führen Sie dann act mit dem Flag --secret-file aus:

act --secret-file .secrets

(Stellen Sie sicher, dass diese Datei zu Ihrer .gitignore hinzugefügt wird, um zu vermeiden, dass Secrets committet werden!)

7. Umgang mit Variablen und Umgebungsvariablen

Workflow-Variablen: Sie können Werte für Variablen bereitstellen, die auf Workflow-Ebene definiert sind (vars:-Kontext, obwohl die vollständige vars-Kontextunterstützung in act möglicherweise begrenzt ist) mit dem Flag --var oder einer --var-file, ähnlich wie bei Secrets.
Umgebungsvariablen: Um benutzerdefinierte Umgebungsvariablen für die Workflow-Ausführung festzulegen, verwenden Sie das Flag --env oder eine --env-file.

act --env NODE_ENV=development --env CUSTOM_FLAG=true
act --env-file .env_vars

Verwalten von Runner-Umgebungen und -Images

Während die Standard-Runner-Images (Micro, Medium, Large) viele Szenarien abdecken, benötigen Sie oft mehr Kontrolle.

1. Einschränkungen der Standard-Images

Denken Sie daran, dass die Standard-act-Runner-Images (insbesondere Micro und Medium) nicht mit den von GitHub bereitgestellten Umgebungen identisch sind. Ihnen fehlen möglicherweise bestimmte Tools, Bibliotheken oder Systemdienste (wie systemd), die Ihr Workflow erwartet. Die Large-Images bieten eine höhere Wiedergabetreue, haben aber den erheblichen Größenachteil.

2. Alternative Images mit -P angeben

Wenn ein Job eine bestimmte Umgebung oder ein bestimmtes Toolset benötigt, das im Standard-Image nicht vorhanden ist, können Sie act anweisen, ein anderes Docker-Image für eine bestimmte Plattform mit dem Flag -P (Plattform) zu verwenden.

Das Format lautet -P <platform>=<docker-image>.

<platform>: Die Bezeichnung, die in der runs-on:-Direktive Ihres Workflows verwendet wird (z. B. ubuntu-latest, ubuntu-22.04, ubuntu-20.04).
<docker-image>: Der vollständige Name des zu verwendenden Docker-Images (z. B. node:18, python:3.10-slim, mcr.microsoft.com/devcontainers/base:ubuntu).

Beispiele:

# Verwenden Sie das Large-Image speziell für Jobs, die auf ubuntu-22.04 ausgeführt werden
act -P ubuntu-22.04=ghcr.io/catthehacker/ubuntu:full-22.04

# Verwenden Sie eine bestimmte Node.js-Version für ubuntu-latest-Jobs
act -P ubuntu-latest=node:18-bullseye

# Verwenden Sie ein umfassenderes Image von nektos/act-environments (sehr groß!)
# WARNUNG: nektos/act-environments-ubuntu:18.04 ist >18GB
act -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04

# Geben Sie mehrere Plattformen an, wenn Ihr Workflow sie verwendet
act -P ubuntu-20.04=node:16-buster -P ubuntu-22.04=node:18-bullseye

3. Lokale Runner-Images verwenden (--pull=false)

Standardmäßig versucht act, bei jeder Ausführung die neueste Version des angegebenen Docker-Images abzurufen. Wenn Sie ein benutzerdefiniertes Runner-Image lokal erstellt haben oder sicherstellen möchten, dass Sie genau die Version verwenden, die Sie zwischengespeichert haben, können Sie dieses Verhalten deaktivieren:

act --pull=false
# oder möglicherweise den Offline-Modus verwenden
act --action-offline-mode

Dies weist act an, das lokal verfügbare Image zu verwenden, falls vorhanden, und nur zu versuchen, es abzurufen, wenn es fehlt.

4. Nativ auf dem Host ausführen (-self-hosted)

Für Workflows, die auf macOS oder Windows abzielen (runs-on: macos-latest oder runs-on: windows-latest), können Sie, wenn Sie act auf demselben Host-Betriebssystem ausführen, act anweisen, keinen Docker-Container für den Runner selbst zu verwenden. Stattdessen werden die Schritte direkt auf Ihrem Host-Computer ausgeführt. Dies kann nützlich sein, wenn die Docker-Kompatibilität ein Problem darstellt oder wenn Sie direkten Zugriff auf Host-Ressourcen benötigen.

# Führen Sie macos-latest-Jobs direkt auf Ihrem Mac-Host aus
act -P macos-latest=-self-hosted

# Führen Sie windows-latest-Jobs direkt auf Ihrem Windows-Host aus
act -P windows-latest=-self-hosted

Vorsicht: Die direkte Ausführung auf dem Host umgeht die durch Docker bereitgestellte Isolation. Workflow-Schritte haben Zugriff auf Ihr Dateisystem und können möglicherweise Ihre Host-Umgebung ändern. Verwenden Sie diese Option mit Vorsicht. Schritte innerhalb des Jobs, die explizit Docker-Container verwenden (z. B. Service-Container oder Container-Aktionen), verwenden weiterhin Docker.

Einschränkungen und Überlegungen

Obwohl act unglaublich nützlich ist, ist es wichtig, sich seiner Einschränkungen bewusst zu sein:

Kein perfektes Replikat: act simuliert die GitHub Actions-Umgebung, ist aber nicht identisch. Es gibt Unterschiede in der Vernetzung, den verfügbaren Systemdiensten (z. B. kein systemd in Docker-Containern), bestimmten Hardwareressourcen und der genauen Menge der vorinstallierten Tools (es sei denn, Sie verwenden die sehr großen Runner-Images). Einige Workflows, insbesondere komplexe, die stark mit dem zugrunde liegenden Betriebssystem oder bestimmten GitHub-Funktionen interagieren, verhalten sich möglicherweise in act anders als auf GitHub.
Kontextunterschiede: Einige Teile des github-Kontexts sind möglicherweise unvollständig oder enthalten Standard-/Mock-Werte, wenn sie lokal ausgeführt werden. Der secrets-Kontext benötigt immer eine explizite Eingabe. Die vars-Kontextunterstützung kann im Vergleich zur Live-GitHub-Umgebung ebenfalls Einschränkungen aufweisen.
Gleichzeitigkeit: act führt Jobs typischerweise sequenziell basierend auf ihren needs-Abhängigkeiten aus. Es repliziert nicht vollständig die Fähigkeit von GitHub, unabhängige Jobs gleichzeitig mit Matrixstrategien über mehrere Runner auszuführen (obwohl act die Ausführung von Matrix-Jobs unterstützt, werden diese lokal normalerweise sequenziell ausgeführt).
Gehostete Dienste: Funktionen wie Caching (actions/cache) funktionieren möglicherweise anders oder erfordern eine bestimmte lokale Konfiguration im Vergleich zum integrierten Caching-Dienst von GitHub. Service-Container, die in Workflows definiert sind, sollten funktionieren, da act auch Docker dafür verwendet.
Plattformverfügbarkeit: Sie können nur Linux-basierte Jobs innerhalb von Docker auf jedem von Docker unterstützten Host (Mac, Windows, Linux) ausführen. Um macos-latest-Jobs auszuführen, benötigen Sie idealerweise act auf macOS (oder verwenden Sie das Flag -self-hosted auf macOS). In ähnlicher Weise erfordern windows-latest-Jobs typischerweise act auf Windows (oder -self-hosted auf Windows). Während Docker kann Windows-Container unter Windows ausführen, konzentriert sich act hauptsächlich auf Linux-Container und bietet die stabilste Unterstützung dafür.

Empfehlung: Verwenden Sie act für die schnelle Entwicklung, die Syntaxprüfung, das Testen der grundlegenden Logik und die Iteration einzelner Jobs oder Schritte. Führen Sie immer eine endgültige Validierung durch, indem Sie Ihre Workflows auf GitHub selbst ausführen, bevor Sie wichtige Änderungen zusammenführen, insbesondere für Bereitstellungspipelines. Konsultieren Sie die offizielle act-Dokumentation für die detaillierte Supportmatrix und bekannte Probleme.

Fazit

Das lokale Testen von GitHub Actions ist ein erheblicher Produktivitätsbooster, der den potenziell langsamen und mühsamen Debug-Zyklus in einen schnellen, iterativen Prozess verwandelt. Das act-CLI-Tool bietet eine robuste und flexible Möglichkeit, dies zu erreichen, indem es Docker verwendet, um die GitHub Actions Runner-Umgebung auf Ihrem lokalen Computer zu simulieren.

Durch die Integration von act in Ihren Workflow erhalten Sie:

Schnellere Feedbackschleifen.
Geringere Abhängigkeit vom Pushen auf GitHub zum Testen.
Die Möglichkeit, Ihre Actions-Definitionen als lokalen Task-Runner zu verwenden.
Verbesserte Debugging-Funktionen.

Obwohl es Einschränkungen hat und kein perfekter 1:1-Ersatz für die Live-GitHub-Umgebung ist, deckt act eine Vielzahl von Anwendungsfällen ab und verringert die Reibung bei der Entwicklung zuverlässiger und effektiver GitHub Actions Workflows erheblich. Installieren Sie es, versuchen Sie, Ihre vorhandenen Workflows lokal auszuführen, und erleben Sie die Vorteile des globalen Denkens bei lokalem Handeln.

💡