So führen Sie GitHub Actions und GitLab CI lokal aus, bevor Sie pushen

Sie können GitHub Actions auf Ihrem eigenen Computer mit `act` und GitLab CI mit gitlab-ci-local ausführen: Beide lesen Ihre Pipeline-Datei und starten jeden Job in einem Docker-Container. Installieren Sie Docker, installieren Sie den Runner und führen Sie dann act -j test oder gitlab-ci-local test aus dem Repository-Ordner aus. Ein fehlgeschlagener Job schlägt jetzt innerhalb von Sekunden auf Ihrem Computer fehl, anstatt nach einem Push und Warten auf einen gehosteten Runner.

Dieser Leitfaden behandelt, was auf macOS, Windows und Linux installiert werden muss, die Befehle für beide Runner, einen Beispielworkflow, den Sie kopieren können, die Grenzen lokaler Läufe und die Fehler, die zuerst auftreten. Die exemplarische Vorgehensweise verwendet GitTree, den Git-Client, den wir erstellen: Seine Seite Lokale Pipelines prüft, was Sie installiert haben, schreibt eine Beispieldatei und bereitet den genauen Befehl für Sie vor. Lokale Pipelines sind Teil des kostenlosen Plans von GitTree und erfordern kein Hosting-Konto.

Warum CI-Pipelines lokal ausführen?

Jede Änderung an einer Workflowdatei ist Code, den Sie erst testen können, wenn er ausgeführt wird. Ohne einen lokalen Läufer lautet die Schleife: YAML bearbeiten, committen, pushen, auf einen Läufer warten, das Protokoll lesen, wiederholen. Jede Runde kostet Minuten und hinterlässt eine Spur von Commits wie „Versuchen Sie es erneut“. Ein lokaler Lauf verkürzt die Schleife auf Sekunden und hält den Verlauf sauber.

Was Sie brauchen: Docker plus einen Läufer

Beide Läufer starten jeden Job in einem Container, daher muss eine Docker-Engine installiert sein und ausgeführt werden: Docker Desktop, OrbStack oder Colima auf macOS, Docker Desktop auf Windows, Docker Engine oder Docker Desktop auf Linux. Installieren Sie dann den Runner für Ihre Datei.

gitlab-ci-local benötigt Node.js 18 oder höher, wenn Sie es mit npm installieren. Überprüfen Sie das Setup mit docker info, act --version und gitlab-ci-local --version: Wenn docker info fehlschlägt, starten Sie die Engine vor allem anderen.

Führen Sie GitHub Actions lokal mit act aus

Führen Sie act aus dem Stammordner des Repositorys aus. Listen Sie zuerst die Jobs auf und führen Sie dann den Job aus, an dem Sie arbeiten. Standardmäßig simuliert act ein push-Ereignis, sodass Jobs, die nur bei anderen Ereignissen ausgeführt werden, den Ereignisnamen benötigen.

# list workflows and jobs
act -l

# run one job from one workflow file
act -W .github/workflows/ci.yml -j test

# simulate a pull request instead of a push
act pull_request -j test

# pass a secret the job needs
act -j deploy -s NPM_TOKEN="$NPM_TOKEN"

# Apple silicon: run x86_64 images
act -j test --container-architecture linux/amd64

Beim ersten Durchlauf wird gefragt, welches Läuferbild verwendet werden soll. Mittel eignet sich für die meisten Projekte; In den kleinen Bildern fehlen die Tools, die gehostete Läufer enthalten, und das Gesamtbild ist sehr groß. Wenn ein Schritt mit „Befehl nicht gefunden“ fehlschlägt, wählen Sie mit -P ubuntu-latest=<image> ein größeres Bild aus oder installieren Sie das Tool in einem Schritt.

Führen Sie GitLab CI lokal mit gitlab-ci-local aus

gitlab-ci-local liest .gitlab-ci.yml aus dem aktuellen Ordner. Ohne Argumente wird die gesamte Pipeline ausgeführt. Geben Sie ihm einen Jobnamen, um einen Job auszuführen. --list zeigt die Jobs an, ohne sie auszuführen. Dies ist eine schnelle Möglichkeit, zu überprüfen, ob die YAML-Analyse erfolgt.

# list jobs and stages
gitlab-ci-local --list

# run one job
gitlab-ci-local test

# pass a CI/CD variable
gitlab-ci-local test --variable API_URL=http://localhost:8080

Ein Beispielworkflow als Ausgangspunkt

Dies ist die Form des GitHub Actions-Beispiels von GitTree: zwei Jobs, erstellen und dann testen, die mit act und auf GitHub gleich funktionieren. Ersetzen Sie die Befehle durch Ihre eigenen.

name: GitTree local check

on:
  push:
  pull_request:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm ci && npm run build

  test:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v4
      - name: Test
        run: npm test

Wie sich eine lokale Ausführung von einer gehosteten CI unterscheidet

• Geheimnisse und Variablen, die auf GitHub oder GitLab konfiguriert sind, sind nicht verfügbar; Übergeben Sie diejenigen, die ein Job benötigt.
• Container, keine virtuellen Maschinen: Dienste, die systemd oder eine vollständige virtuelle Maschine benötigen, werden nicht auf die gleiche Weise ausgeführt.
• Bilder unterscheiden sich von den gehosteten Läufern; Ein fehlendes Tool ist ein fehlendes Paket, kein fehlerhafter Arbeitsablauf.
• Ereignisse werden simuliert: act ist standardmäßig push; Wiederverwendbare Workflows, Includes und Vorlagen werden vom Läufer aufgelöst, nicht von Ihrem Editor.
• Ein vorbeifahrender lokaler Lauf ist kein gehostetes Ergebnis: Er verkürzt die Schleife; Ihr Gastgeber hat immer noch das letzte Wort.

Häufige Fehler und Korrekturen

Bevor Sie pushen: Konflikte vorhersagen, auf Geheimnisse prüfen, Vorschau des Pushs anzeigen

Ein lokaler Pipeline-Lauf beantwortet eine Frage: Werden die Jobs erfolgreich sein? Drei weitere Prüfungen erfassen, was CI verspätet oder gar nicht meldet, und jede von ihnen wird auch auf Ihrem Computer ausgeführt, bevor etwas gesendet wird.

1. Prognostizieren Sie die Zusammenführung. git merge-tree --write-tree --name-only HEAD origin/main führt die Zusammenführung im Speicher durch und listet die Dateien auf, bei denen es zu Konflikten kommen würde, ohne Ihren Arbeitsbaum zu berühren. GitTree führt die gleiche Art von Prüfung durch und warnt vor einer Zusammenführung, die zu Konflikten führen würde; siehe wie man Git-Merge-Konflikte löst.
2. Auf Geheimnisse prüfen. Vor einem Commit oder Push scannt GitTree die Änderung lokal auf mögliche Token, Passwörter und private Schlüssel und stoppt mit einem Dialog, wenn es einen findet. Ein Geheimnis, das das Remote erreicht, muss gedreht werden, daher ist der günstigste Zeitpunkt, es zu fangen, vor dem Push. Eine Warnung ist keine Garantie, also überprüfen Sie dennoch, was Sie senden.
3. Vorschau des Pushs. Ship Preview listet die Commits und Dateien auf, die der Push senden würde, und für jede Workflow-Datei, die gelesen werden kann, ob eine Pipeline bei diesem Push ausgeführt wird, ausgeführt werden kann oder nicht ausgeführt wird, mit Angabe des Grundes.

Führen Sie dann den Job lokal aus und pushen Sie ihn einmal. Der Anleitung zu geheimen Warnungen und der Anleitung zur Schiffsvorschau behandeln beide Dialoge im Detail.

Was ist mit Bitbucket Pipelines und Azure Pipelines?

Es gibt keinen verwalteten lokalen Runner für bitbucket-pipelines.yml oder azure-pipelines.yml, der mit act oder gitlab-ci-local übereinstimmt. Ein praktischer Ansatz besteht darin, Ihre Build- und Testbefehle in Skripten zu belassen, sie von Ihrer gehosteten Pipeline aufzurufen und eine kleine GitHub Actions- oder GitLab CI-Datei nur für lokale Ausführungen hinzuzufügen. GitTree markiert diese Dateien als Kein lokaler Läufer und bietet die Beispiele genau dafür an.

Nächste Schritte: Der Leitfaden „Pipelines lokal ausführen“ dokumentiert jede Schaltfläche, CI/CD-Ausführungen deckt gehostete Ausführungen, erneute Ausführungen und Genehmigungen ab und der Tools-Launcher listet die anderen integrierten Tools von GitTree auf.