Meine GitHub Actions Workflows werden nicht gestartet

Prüfen Sie den GitHub-Status!

Hin und wieder gibt es einen Ausfall von z.B. GitHub Actions, und ich sehe einen großen Zustrom von Benutzern auf diesen Blogpost. Bevor Sie also anfangen, dies zu lesen, überprüfen Sie die GitHub-Statusseite um zu sehen, ob es einen Ausfall gibt. Wenn dies der Fall ist, können Sie warten, bis das Problem behoben ist. Ist dies nicht der Fall, können Sie diesen Beitrag weiter lesen, um die Ursache für Ihr Problem zu finden. Ausfälle können in jeder SaaS (Software as a Service)-Umgebung immer vorkommen, und es ist keine leichte Aufgabe, eine groß angelegte Umgebung in einem gesunden Zustand zu halten. Wenn Sie also von einem Ausfall betroffen sind, haben Sie Verständnis für die Techniker, die das Problem lösen.

Achtung, einige Auslöser funktionieren nur auf dem Standardzweig

Einige Standardprobleme, auf die neue Benutzer von GitHub Actions stoßen, sind, dass ihre Workflows nicht ausgelöst werden oder dass die entsprechende Benutzeroberfläche fehlt. Zu Beginn beginnt jeder mit der on: push Trigger, aber es wird der Zeitpunkt kommen, an dem Sie nur einige Arbeitsabläufe auf dem Standard-(Haupt-)Zweig ausführen möchten. Also schränken Sie die on: push Auslöser für diesen Zweig:

on:
  push:
    branches:
      - main

Wenn Sie folgen beste Praktiken Sie möchten einen Pull Request-basierten Prozess implementieren, um zu verhindern, dass eine einzelne Person Änderungen an einem Repository vornimmt. Das bedeutet, dass Sie Ihre Änderungen an Arbeitsabläufen in einem Feature-Zweig und nicht in Ihrem Hauptzweig vornehmen.

Wie geht es weiter? Sehen Sie in den unten stehenden Schritten nach. Sie können ganz oben beginnen (geplanter Lauf startet nicht) und sich dann zu den spezifischeren Beispielen vorarbeiten. Dies entspricht auch der Reihenfolge, in der diese Fragen häufig auftreten.

Foto von SoraSagano auf Unsplash

Das Wichtigste zuerst: Speicherort der Datei

Ich habe das selbst erlebt und 15 Minuten lang gesucht, bevor ich den Fehler erkannte: Überprüfen Sie den Speicherort Ihrer Workflow-Datei! Wenn Sie den ersten Workflow in einem Repo erstellen, stellen Sie vielleicht fest, dass Sie das falsche Verzeichnis konfiguriert haben, weil die Benutzeroberfläche die Workflow-Datei nicht anzeigt, wenn sie sich im falschen Ordner befindet. Das kann ein Hinweis sein.

Sie muss in folgendem Ordner gespeichert werden: /.github/workflows/. Und dieser Ordner ist workflows (Plural) und nicht workflow (Singular).

Geplante Läufe starten nicht

Wenn Sie Ihren ersten Zeitplan für einen täglichen Lauf hinzufügen, werden Sie vielleicht überrascht sein, dass er nicht mit dem von Ihnen festgelegten Zeitplan startet. Sie kratzen sich vielleicht am Kopf und warten ein paar Tage, aber nichts passiert.

on:
  schedule:
    - cron:  '30 5,17 * * *'

Die Ursache hierfür ist, dass die geplanten Läufe nur Auslöser aus dem Standardzweig (main). Mehrere Auslöser verhalten sich auf diese Weise, wie z.B. ein Pull Request (+Status) Auslöser, die Issue / Label / Kommentar Auslöser, usw.

Wenn Sie also einen Zeitplan in Ihrem Workflow haben und sich nicht auf dem Standardzweig befinden, wird der Workflow nicht gestartet. Dies ist eine Sicherheitsmaßnahme, um zu verhindern, dass jemand einen Workflow erstellt, der nach einem Zeitplan abläuft, und dann einen Pull Request für ein Repository erstellt, das einen geplanten Workflow hat. Der geplante Workflow würde dann auf die Pull-Anforderung angewendet und der Angreifer könnte etwas Böses tun. Das ist eine gute Sache, kann aber verwirrend sein, wenn Sie gerade erst anfangen. Die Lösung besteht darin, dafür zu sorgen, dass Sie sich auf dem Standardzweig befinden, wenn Sie Ihren geplanten Arbeitsablauf erstellen. Das bedeutet, dass Sie Ihre Änderungen zusammenführen müssen, damit er nach Ihrem Zeitplan startet.

Andere Gründe für nicht ausgelöste Zeitpläne

Es gibt noch andere Gründe, warum ein Zeitplan nicht ausgelöst werden kann:

1. Das Zeitplan-Ereignis kann in Zeiten hoher Last von GitHub Actions Workflow-Läufen verzögert werden. Zu den Zeiten mit hoher Auslastung gehört der Beginn jeder Stunde. Um die Wahrscheinlichkeit einer Verzögerung zu verringern, planen Sie Ihren Workflow zu einer anderen Uhrzeit.
2. Der Workflow wurde möglicherweise deaktiviert. Bei Forks werden alle Arbeitsabläufe deaktiviert und Sie müssen sie manuell aktivieren (was natürlich sinnvoll ist). Außerdem: In einem öffentlichen Repository werden geplante Workflows automatisch deaktiviert, wenn 60 Tage lang keine Aktivität im Repository stattgefunden hat. Das Konto, das den Workflow zuletzt geändert hat, erhält nach etwa 23 Tagen Inaktivität in einem Repository eine E-Mail-Benachrichtigung:

Die Benutzeroberfläche für manuelle Läufe (workflow_dispatch) ist nicht sichtbar

Dies ist der übliche nächste Schritt, wenn der Zeitplan nicht startet: Sie fügen einfach einen Workflow-Versandauslöser zum Workflow hinzu, um ihn manuell auszulösen. Da es sich jedoch um einen neuen Workflow handelt, der noch nicht existiert, ist die Benutzeroberfläche für die Auslösung nicht sichtbar! Dies ist dasselbe wie das Erstellen einer neuen Workflow-Datei mit diesem Auslöser in einem Rutsch.

Für einen manuellen Auslöser, ist die Benutzeroberfläche nur in der Standardverzweigung verfügbar. Sie können wählen, von welcher Verzweigung aus der Lauf ausgelöst werden soll, und die Eingaben von der Standardverzweigung aus verfügbar machen. Aber die Datei und der Auslöser müssen sich in der Standardverzweigung befinden, damit die Benutzeroberfläche sichtbar ist.

Sie haben zwei Optionen, um fortzufahren und den Workflow auszulösen:

1. Gehen Sie zum nächsten Schritt und verwenden Sie 'on: push'.
2. Starten Sie den neuen Workflow von der Zweigstelle aus über die API

Auslösen des Workflows mit der API

Sie können einen Workflow-Versand (wie auch einen Repository-Versand ) über die Benutzeroberfläche auslösen und ihn sogar von einer Verzweigung aus starten.

Sie müssen einen (authentifizierten) Aufruf der URL für Ihren Workflow machen: '{OWNER}/{REPO}/actions/workflows/{WORKFLOW_ID} dispatches' Die Workflows haben eigentlich eine ID unter der Hülle, aber Sie können auch den Dateinamen verwenden, was einfacher zu lesen ist. Wenn der Workflow also den Namen get-action-data.yml und es lebt in der Repo rajbos/actions-marketplace wird sie zu dieser Url: api.github.com/repos/rajbos/actions-marketplace/actions/workflows/get-action-data.yml/dispatches. Fügen Sie einen JSON-Payload mit der Verzweigung, auf die Sie verweisen, in eine "ref"-Eigenschaft ein (siehe Postman-Screenshot unten).

Hinweis: Fügen Sie keinen Schrägstrich am Ende der URL ein. Die APIs von GitHub akzeptieren dies nicht und geben Fehler zurück.

Mein Tool der Wahl für diesen Zweck ist Postman, weil ich darin meine Anfragen speichern kann und es in seinem eigenen Fenster lebt. Das macht es super einfach, dorthin zu navigieren und STRG+ENTER zu drücken, um den Aufruf auszulösen, was bei der Erstellung der Workflows sehr hilfreich ist.

Sie können auch die GitHubCLI verwenden, um den Workflow auszulösen, indem Sie den folgenden Befehl aus dem Repository-Ordner ausführen:

  gh workflow run get-action-data.yml --ref rajbos-patch-1

Vergessen Sie nicht, die ref hier, wenn Sie von einer Verzweigung aus starten möchten. Andernfalls wird es von der Standardverzweigung ausgeführt. Beachten Sie auch, dass dies im Kontext des Repo-Inhalts ausgeführt wird, der 'auf GitHub' ist, also nicht Ihr lokaler Inhalt!

Ein: dann drücken?

Die letzte Option, die Sie haben, ist, den Workflow immer dann auszulösen, wenn jemand Daten in das Repository eingestellt hat. Sie können entscheiden, ob dies bei bestimmten Zweigen geschehen soll, aber der beste Tipp ist hier, einen Pfadfilter einzubauen (siehe die Docs hier).

on:
  push:
    branches:
      - main
      - my-test-branch
    paths:
      - 'src/**'
      - '.github/workflows/my-workflow-file.yml'

Ich lasse den Workflow oft zumindest auf meinem Testzweig laufen, aber dann nur wenn die relevanten Dateien für diesen Workflow bearbeitet wurden. Das ist in der Regel die Workflow-Datei selbst und vielleicht bestimmte Quelldateien in der Repo, die verwendet werden: Wann immer es eine Änderung in diesen Dateien gibt, führen Sie den Workflow aus. Dies ist vor allem während der Entwicklung des Workflows hilfreich: Wenn Sie eine Änderung einschieben, ist es eine gute Änderung, die Sie den Workflow auslösen möchten.

Ein falsches Etikett anvisieren

Wenn Sie einen Läufer anvisieren, auf den Sie keinen Zugriff haben (überprüfen Sie die Berechtigungen der Läufergruppe), oder ein Label, für das kein Läufer existiert, bleibt Ihr Auftrag so lange hängen, bis der Timeout von 24 Stunden abgelaufen ist. Dann wird ein Timeout-Fehler angezeigt und der Auftrag wird abgebrochen. Überprüfen Sie das Label, das Sie verwenden (dieser Tippfehler im Screenshot bringt mich immer auf die Palme!) und korrigieren Sie es, oder überprüfen Sie die Berechtigungen für die Runner-Gruppe.

Abschließende Bemerkung

Beachten Sie, dass dies alles nicht hilft, wenn Sie bestimmte Anwendungsfälle testen möchten, z. B. wenn jemand einen Kommentar oder eine Pull-Anfrage erstellt. Es gibt andere Möglichkeiten, damit umzugehen, aber das ist ein Thema für einen anderen Beitrag.