Kapitel 4. Arbeiten mit Workflows
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Wie du sicher schon gemerkt hast, sind Workflows das Herzstück von GitHub Actions. Ich habe bereits einige Grundlagen zum Verständnis von Workflows erläutert. Aber du musst auch in der Lage sein, sie einfach zu erstellen, auszuführen und auf Erfolg oder Misserfolg zu überprüfen. In diesem Kapitel geht es um diese Art von Aktivitäten.
Zunächst gebe ich dir einen Überblick über einige der Funktionen, die GitHub für die Erstellung von Workflows bietet. Dann zeige ich dir, wie du Workflows in der GitHub-Benutzeroberfläche bearbeitest und wie du dort Änderungen mit Operationen wie Commits und Pull Requests durchführst. Nebenbei lernst du, wie du durch die Ergebnisse von Workflow-Läufen navigierst und wie du die Ausführung eines Workflows überwachen kannst.
Schließlich zeige ich dir, wie du mit den aktualisierten GitHub Actions VS Code-Erweiterungen Workflows erstellst und bearbeitest und wie du deine Läufe in Visual Studio Code (VS Code) verwaltest und überwachst.
Der erste Schritt ist eine Anleitung zum Erstellen eines ersten Workflows in einem Repository.
Den ersten Workflow in einem Repository erstellen
Angenommen, du hast ein Repository, für das du noch keine GitHub-Aktionen verwendet hast, und du möchtest damit anfangen. Wie fängst du an? Schauen wir uns zunächst ein einfaches Projektbeispiel in GitHub an. Abbildung 4-1 zeigt ein einfaches Repository mit ein paar Dateien.
Abbildung 4-1. Einfaches Projekt in GitHub
Wenn du in einem Repository ohne bestehende Workflows im oberen Menü auf die Registerkarte Aktionen anklickst, wird dir eine Einstiegsseite für Aktionen angezeigt. (Falls gewünscht, kannst du diese Seite auch über https:<Ihr github Repo-Pfad>/actions/new aufrufen).
Wenn du ein Repository hast, das bereits eine bestimmte Art von Code enthält (Go, Java usw.), werden die von GitHub vorgeschlagenen Arbeitsabläufe dies berücksichtigen. Abbildung 4-2 zeigt die Einstiegsseite für ein Repository mit Go-Code. GitHub hat für dieses Repository unter Vorgeschlagene Go-Aktionen anstelle einer allgemeinen Aktion vorgeschlagen.
Abbildung 4-2. Einstiegsseite für ein Go-Repository
Es gibt vier Möglichkeiten, mit einem neuen Workflow in einem Repository zu beginnen, wenn es noch keine gibt:
- Klicke auf den Link " Workflow selbst einrichten" direkt über der Aktion " Workflows suchen".
- Klicke auf die Schaltfläche Konfigurieren für den vorgeschlagenen Workflow unter dem Titel Vorgeschlagen für dieses Repository.
- Scrolle und wähle einen der anderen vorgeschlagenen Workflows aus und klicke auf die Schaltfläche "Konfigurieren" für den entsprechenden Workflow.
- Erstelle eine Workflow-Datei außerhalb von GitHub und füge sie in ein Unterverzeichnis .github/workflows im Repository ein.
Wenn du eine der ersten beiden Optionen auswählst, wird der Code für einen einfachen Workflow in den Editor der Weboberfläche eingefügt. Der Name der Workflow-Datei beginnt mit einem Pfad, der .github/workflows enthält, und einem Namensfeld, das den vorgeschlagenen Workflow wiedergibt. Dieses Feld kann so bearbeitet werden, dass es den von dir gewünschten Namen erhält. Du kannst die Rücktaste drücken und den Pfad bearbeiten. Aber wie in Kapitel 1 beschrieben, müssen Workflows im Unterverzeichnis .github/workflows innerhalb eines Projekts liegen.
Verschieben einer Datei innerhalb eines Repositorys
Ein allgemeiner Tipp: Wenn du eine Datei in der GitHub-Benutzeroberfläche bearbeitest und dann den Verzeichnispfad im Namensbereich änderst (durch Zurücksetzen und Eintippen), kannst du den Speicherort einfach ändern und die Datei innerhalb des Repositorys verschieben.
Im rechten Teil des Fensters werden die ausgewählten Aktionen angezeigt. Wenn dein Repository Code eines bestimmten Typs enthält, werden in diesem Fenster eine Reihe von Aktionen angezeigt. (Du kannst aber auch jederzeit über das Suchfeld in diesem Fenster nach anderen Aktionen suchen). Abbildung 4-3 zeigt einen Beispiel-Workflow, der im Editor nach der Auswahl der Vorlage Einfacher Workflow und einem Klick auf die Schaltfläche Konfigurieren ausgefüllt wurde.
Abbildung 4-3. Ein grundlegender Start-Workflow im GitHub-Editor
Der vollständige Code für diesen Start-Workflow ist hier zu sehen. Als Nächstes erkläre ich dir, was dieser Code macht:
1 # This is a basic workflow to help you get started with Actions 2 3 name: CI 4 5 # Controls when the workflow will run 6 7 on: 8 # Triggers the workflow on push or pull request events for main 9 push: 10 branches: [ main ] 11 pull_request: 12 branches: [ main ] 13 14 # Allows you to run this workflow manually from the Actions tab 15 workflow_dispatch: 16 17 # A workflow run is made up of one or more jobs 18 jobs: 19 # This workflow contains a single job called "build" 20 build: 21 # The type of runner that the job will run on 22 runs-on: ubuntu-latest 23 24 # Steps are a sequence of tasks executed as part of a job 25 steps: 26 # Checks-out your repository under $GITHUB_WORKSPACE 27 - uses: actions/checkout@v3 28 29 # Runs a single command using the runners shell 30 - name: Run a one-line script 31 run: echo Hello, world! 32 33 # Runs a set of commands using the runners shell 34 - name: Run a multi-line script 35 run: | 36 echo Add other actions to build, 37 echo test, and deploy your project.
Wenn du dir die Liste ansiehst, erkennst du die Komponenten eines Workflows, die in den Kapiteln 2 und 3 besprochen wurden.
Ab Zeile 7 wird im Abschnitt on festgelegt, wann der Workflow aufgerufen wird. In diesem Fall wird der Workflow durch einen Push- oder Pull-Antrag an den Hauptzweig ausgelöst. Dieser Workflow enthält auch eine workflow_dispatch-Klausel in Zeile 15. Sobald der Code in den Standardzweig übertragen wurde, fügt GitHub eine Schaltfläche auf dem Aktionen-Bildschirm hinzu, mit der du diesen Workflow manuell ausführen kannst. (Die Verwendung des Auslösers workflow_dispatch wird weiter unten in diesem Kapitel und ausführlich in Kapitel 12 beschrieben).
workflow_dispatch und Zweige
Wenn ein Workflow die Klausel workflow_dispatch enthält, muss eine Instanz der Workflow-Datei mit der Klausel im Standardzweig (normalerweise main) vorhanden sein, damit die Schaltfläche in der Benutzeroberfläche angezeigt wird.
Der Abschnitt Aufträge beginnt in Zeile 18. In diesem Workflow gibt es nur einen Auftrag - den Erstellungsauftrag. Am Anfang des Auftrags steht die " runs-on "-Klausel (Zeile 22), die beschreibt, auf welchem System dieser Workflow ausgeführt wird/werden kann. In diesem Fall läuft er auf einem System mit der Linux-Distribution Ubuntu.
Dann gibt es den Abschnitt Schritte im Bauauftrag (ab Zeile 25). Wie bereits erwähnt, können Schritte entweder vordefinierte Aktionen aufrufen oder Betriebssystembefehle über die Shell ausführen. In diesem Einstiegsworkflow gibt es beide Arten von Schritten. In Zeile 27 verwendet der erste Schritt die GitHub-Aktion checkout@v3, um den Inhalt dieses Repositorys auszuchecken, wenn der Workflow läuft. Die folgenden Schritte in den Zeilen 29-37 führen einfache Shell-Befehle aus, die einen Text über die run Klausel ausgeben.
Nachdem du einen Workflow erstellt oder bearbeitet hast, musst du ihn an das Repository zurückgeben. Im nächsten Abschnitt wird gezeigt, wie du das tun kannst, ohne die GitHub-Weboberfläche zu verlassen.
Festlegen des ersten Workflows
Wenn du einen Workflow im GitHub Webeditor programmierst, ist er noch nicht Teil der Codebasis. Als würdest du eine neue Datei lokal bearbeiten, musst du sie in das Repository übertragen. Bevor du das tust, kannst du den Namen des Workflows ändern, indem du die Zeile in der Datei bearbeitest, die mit name: beginnt (Zeile 3 in diesem Beispiel).
Wenn du mit der Bearbeitung fertig bist, klickst du einfach auf die Schaltfläche Änderungen übernehmen oben rechts im Editor-Bildschirm. Abbildung 4-4 zeigt die Schaltfläche. In diesem Fall habe ich den Start-Workflow CI genannt, aber die Workflow-Datei selbst in basic.yml umbenannt.
Abbildung 4-4. Position des Benennungsbereichs und der Schaltfläche zum Starten des Festschreibungsprozesses
Den Pfad der Workflow-Datei bearbeiten
Wie bereits erwähnt, könntest du unter im Pfadbereich die Rücktaste drücken und das Verzeichnis ändern, in dem der Workflow gespeichert ist. Tu das aber nicht. Workflows müssen sich im Verzeichnis .github/workflows eines Repositorys befinden, damit sie mit dem Actions Framework funktionieren.
Nachdem du auf die Schaltfläche Änderungen festschreiben geklickt hast, wird ein Pop-up-Dialog angezeigt, in dem du weitere Informationen über die Änderung erhältst(Abbildung 4-5). Dazu gehören die Beschreibung und die Wahl, ob du die Änderung durch ein einfaches Commit in den aktuellen Zweig oder durch das Erstellen eines neuen Zweigs und die Änderung durch eine Pull-Anfrage vornehmen willst. Ich übertrage hier direkt in den aktuellen Zweig, werde aber später im Kapitel das Beispiel mit der Pull-Anfrage zeigen. In diesem Fall kannst du Kommentare hinzufügen, wenn du möchtest, und die Standardeinstellung " Direkt in den <aktuellen> Zweig übertragen" beibehalten.
Abbildung 4-5. Bestätigen-Dialog
Nachdem die Übergabe erfolgt ist, wird die Datei der Codebasis im Repository hinzugefügt. Wenn du jetzt im oberen Menü auf die Registerkarte Aktionen wechselst, wird der Workflow ausgeführt (oder wurde ausgeführt). Warum das so ist? Als die Übergabe an main erfolgte, erfüllte sie die Kriterien, die im Abschnitt on des Workflows festgelegt wurden:
# Triggers the workflow on push or pull request events but # only for the main branch push: branches: [ main ] pull request: branches: [ main ]
Abbildung 4-6 zeigt den ersten Durchlauf dieses Workflows.
Abbildung 4-6. Erster Durchlauf des Workflows
Dies ist eine gute Gelegenheit, um herauszufinden, was auf dem Bildschirm angezeigt wird und wie du dich dort zurechtfindest.
Auf der linken Seite beginnt eine Liste der Workflows, die mit diesem Repository verbunden sind. Je nachdem, welches Element du in dieser Liste auswählst, werden die Arbeitsabläufe auf der rechten Seite angezeigt. Standardmäßig ist der Eintrag Alle Workflows ausgewählt, und die Läufe aller Workflows werden in der Liste angezeigt. Wenn du in der Liste auf der linken Seite einen bestimmten Workflow auswählst, wird die Liste auf der rechten Seite so gefiltert, dass nur Informationen über den ausgewählten Workflow angezeigt werden. (Die Oberfläche ist in Abbildung 4-7 dargestellt.)
Abbildung 4-7. Anzeige der Läufe eines bestimmten Workflows
Da es nur einen Workflow mit nur einem Durchlauf gibt, ist das nicht besonders interessant. Das einzige zusätzliche Element, das jetzt angezeigt wird, wenn der spezielle Workflow ausgewählt ist, ist das Feld mit der Zeile "Dieser Workflow hat einen workflow_dispatch Ereignisauslöser" und die Schaltfläche Workflow ausführen. Der Grund dafür, dass ich das jetzt sehe, ist, dass ich diesen Workflow auf der linken Seite ausgewählt habe (statt der Auswahl " Alle Workflows" ). Und dieser Workflow enthält den folgenden Code im Abschnitt on der Workflow-Datei in der Standardverzweigung:
on: ... # Allows you to run this workflow manually from the Actions tab workflow_dispatch:
Dies ist eine Instanz des Auslösertyps workflow_dispatch. Er zeigt eine Schaltfläche an, mit der du einen weiteren Durchlauf des Workflows manuell auslösen kannst. Wenn du darauf drückst, wird ein kleines Dialogfeld angezeigt, in dem du einen Zweig auswählen kannst, von dem aus er ausgeführt werden soll, sowie zusätzliche Optionen, falls definiert (siehe Kapitel 8). Wenn du ihn aufrufst, wird der Workflow ausgeführt und ein weiterer Durchlauf wird der Liste hinzugefügt, wie in Abbildung 4-8 dargestellt. Dieser direkte Aufruf eines Workflows kann für das Prototyping, das Debugging und andere Fälle nützlich sein, in denen du nicht immer ein Ereignis in GitHub auslösen möchtest, um den Lauf auszulösen.
Abbildung 4-8. Ein zweiter Workflow-Lauf
Wenn du dir die Beschreibungen dieser Läufe genau ansiehst (unter der Zeile mit dem Häkchen in einem Kreis auf der linken Seite), kannst du Informationen darüber lesen, welches Ereignis jeden Lauf ausgelöst hat. Sie sind nach dem Zeitpunkt ihrer Ausführung sortiert, beginnend mit dem neuesten Lauf ganz oben.
Nach einem Durchlauf möchtest du vielleicht zurückgehen und einige Änderungen am Workflow vornehmen, um etwas zu korrigieren oder hinzuzufügen. Du kannst das Repository klonen und die Datei lokal bearbeiten. Oder du gehst zurück in den Code-Bereich des Repositorys auf GitHub, wählst eine Datei aus und bearbeitest sie von dort aus.
Die Aktionen-Oberfläche auf dieser Seite bietet einen weiteren Shortcut, um direkt zum Workflow-Code zu gelangen: Klicke auf den kleinen YAML-Dateinamen unter dem Titel des Workflows oben. Abbildung 4-9 zeigt das Element, von dem ich spreche. In diesem Fall lautet der Link/Name basic.yml.
Abbildung 4-9. Dateinamen-Verknüpfung zur Bearbeitung der Workflow-Datei
Wenn du auf diesen Link klickst, wird die Datei im Webeditor angezeigt. Oben rechts in der grauen Leiste über der Datei findest du eine kleine Reihe von Symbolen. Achte auf das Symbol, das wie ein Bleistift aussieht. Du kannst auf dieses Symbol klicken, um die Datei direkt im Browser zu bearbeiten(Abbildung 4-10).
Wenn du auf das Bleistiftsymbol klickst, wird eine einfache Bearbeitungsoberfläche für die Datei angezeigt. Neben der Möglichkeit, den Namen und den Pfad der Datei zu ändern (über das Eingabefeld mit dem Dateipfad oberhalb des Codes), gibt es auch Optionen zum Ändern der Einrückung und des Umbruchstils (oben rechts im Bearbeitungsbereich), eine Registerkarte, auf der du eine Vorschau der Änderungen sehen kannst, und Schaltflächen zum Bestätigen oder Abbrechen der Änderungen. All das ist in Abbildung 4-11 dargestellt.
Abbildung 4-10. Starten einer Bearbeitungssitzung in der Weboberfläche
Abbildung 4-11. Der vollständige Bearbeitungsbildschirm
Um zu zeigen, wie die Bearbeitung funktioniert, kann ich einige einfache Änderungen vornehmen, um diesen Workflow so zu ändern, dass er zwei Aufträge statt einem hat. Zuerst ändere ich die Beschreibung und den Namen des bestehenden Auftrags. Das ist nicht unbedingt notwendig, passt aber besser zu den anderen Änderungen, die ich vornehme:
# This workflow contains a single job called "build" build:
zu:
# This job checks out code from the repo checkout:
Weiter unten, vor dem ersten run Schritt, füge ich ein paar Zeilen ein, um die restlichen Schritte zu eigenen Aufträgen zu machen. Für muss Folgendes hinzugefügt werden:
- Ein Name für den Auftrag
- Eine
runs-onKlausel, die angibt, welche Art von System für die Ausführung verwendet werden soll - Eine
stepsKlausel, die angibt, wo die Schritte für den neuen Auftrag beginnen
Diese Zeilen werden (mit einem Kommentar) ab der ursprünglichen Zeile 28 eingefügt. Wenn du das tust, musst du sehr darauf achten, dass du den erwarteten Einrückungsstil einhältst, da es sich um YAML handelt:
# This job does the core processing process: # The type of runner that the job will run on runs-on: ubuntu-latest steps:
Der Abschnitt Aufträge des Arbeitsablaufs sieht jetzt wie folgt aus:
jobs:
# This job checks out code from the repo
checkout:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of
the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can
access it
- uses: actions/checkout@v3
process:
# The type of runner that the job will run on
runs-on: ubuntu-latest
steps:
# Runs a single command using the runners shell
- name: Run a one-line script
run: echo Hello, world!
# Runs a set of commands using the runners shell
- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.
Auf der Registerkarte Vorschau kannst du dir bequem ansehen, was in dieser Datei geändert hat, bevor sie übertragen wird. Abbildung 4-13 zeigt die Anzeige des Codes nach Auswahl dieser Registerkarte.
Abbildung 4-13. Vorschau der Änderungen
Jetzt sind die Änderungen bereit, um übertragen zu werden. Dazu klicke ich einfach auf die Schaltfläche Änderungen festschreiben. Es öffnet sich das gleiche Dialogfeld wie zuvor. Diesmal wähle ich die Option, den Commit per Pull Request durchzuführen. Und ich gebe dem neuen Zweig den Namen patch-1. Abbildung 4-14 zeigt das fertige Dialogfeld.
Abbildung 4-14. Dialogfeld für Pull Request
Nachdem du auf die Schaltfläche Änderungen vorschlagen geklickt hast, erhältst du den Standarddialog Pull Request öffnen, der in Abbildung 4-15 dargestellt ist. In der oberen grauen Leiste ist bereits eingestellt, dass der Patch-1-Zweig mit Main verglichen wird. Und er kann die Änderungen ohne Konflikte zusammenführen. Wenn du bereit bist, klickst du im nächsten Schritt einfach auf die Schaltfläche Pull Request erstellen.
Abbildung 4-15. Pull Request-Dialog für die Änderung
Nachdem der Pull Request erstellt wurde, führt GitHub alle vordefinierten Prüfungen durch, die mit dem Repository und dem Branch verbunden sind. In diesem Fall werden die Aufträge eines Workflows ausgeführt, der durch einen Pull Request in diesem Zweig ausgelöst wird. Das entspricht den Aufträgen zum Auschecken und Verarbeiten, die gerade in der Workflow-Datei basic.yaml definiert wurden. Du kannst sehen, wie sie ausgeführt werden, während die Pull-Anfrage zunächst bearbeitet wird. Und du kannst sie auch sehen, wenn die erste Bearbeitung abgeschlossen ist, indem du auf den Link Alle Prüfungen anzeigen auf der rechten Seite der Zeile Alle Prüfungen wurden bestanden klickst. Abbildung 4-16 zeigt die Prüfungen, nachdem sie ausgeführt worden sind.
Abbildung 4-16. Auflistung durchgeführter Prüfungen
Wenn du auf den Link Details am Ende jeder Zeile von klickst, gelangst du zu einem Bildschirm für diesen Lauf. In Abbildung 4-17 siehst du die Aufträge des Workflows auf der linken Seite und einen Bereich auf der rechten Seite, der alle Schritte auflistet, die für den Auftrag ausgeführt werden mussten, mit der Ausgabe der einzelnen Schritte. Dazu gehören auch implizite Schritte, die von GitHub verwaltet werden und für die Ausführung des Auftrags erforderlich sind, z. B. Auftrag einrichten.
Abbildung 4-17. Detaillierte Schritte, die während eines Laufs ausgeführt werden
Jeder Schritt kann erweitert werden, um mehr Details anzuzeigen. Und einige der in den Schritten aufgeführten Zeilen können auch erweitert werden, um kollabierte Ausgaben oder Ausführungsdetails anzuzeigen. (Mehr über diesen Bildschirm erfährst du, wenn du dich in Kapitel 5 mit Runnern und in Kapitel 10 mit der Fehlersuche und -behebung beschäftigst).
Ein anderer Weg, um an die Details zu kommen
kannst du sehen, wenn du die Registerkarte Pull-Anfragen oben im Repository-Bildschirm auswählst, die offene Pull-Anfrage auswählst und dann die Registerkarte Überprüfungen auswählst. (Siehe Abbildung 4-18.)
Abbildung 4-18. Über das Pull Request-Menü zum Detailbildschirm gelangen
Wenn du zurück zur Hauptregisterkarte Aktionen wechselst, findest du Details zu allen Läufen deines Workflows. Ich habe nur einen Workflow, aber ich wähle ihn einfach aus. Auf der rechten Seite, wie in Abbildung 4-19 dargestellt, siehst du alle Läufe des ausgewählten Workflows.
Abbildung 4-19. Letzte Workflow-Läufe
Der letzte Lauf dieses Workflows steht in der obersten Zeile der Liste. Wenn du auf die Commit-Meldung Update basic.yaml klickst, wird die Liste der Aufträge des Workflows angezeigt, zusammen mit der Zeit, die sie gebraucht haben und ob sie erfolgreich waren oder nicht. In Abbildung 4-20 ist der Erfolg an den Kreisen mit den Häkchen zu erkennen. Wenn du auf den Namen eines Auftrags in diesem Fenster klickst, siehst du die Details des Schritts. Das ist die gleiche Ansicht, die du erhältst, wenn du auf den Link " Details" im Abschnitt " Prüfungen" des Pull Request-Bildschirms klickst.
Oben rechts auf dem in Abbildung 4-20 gezeigten Bildschirm siehst du auch die Schaltfläche Alle Aufträge neu starten. Daneben befindet sich eine Schaltfläche, die erweitert werden kann, um dich durch die Erstellung eines Statusabzeichens zu führen, sowie eine Option zum Löschen von Protokollen. ("Erstellen eines Statusabzeichens" erklärt mehr über das Erstellen eines Statusabzeichens.)
Abbildung 4-20. Gesamtansicht der Aufträge für einen Workflow
Jetzt, da alle Prüfungen vor dem Zusammenführen abgeschlossen sind, kannst du den Code zusammenführen und die Pull-Anfrage abschließen.
Zurückbekommen zum Pull Request
Du kannst ganz einfach zum Pull Request zurückkommen, indem du im Menü auf der obersten Ebene (die Zeile, die mit < > Code beginnt ) Pull Requests auswählst und dann den Pull Request aus der angezeigten Liste auswählst. Du kannst auch einfach die URL deines GitHub-Projekts mit der Endung pull/1 verwenden (vorausgesetzt, dies ist der erste Pull Request in deinem Repository).
Um die Zusammenführung abzuschließen, klickst du auf die Schaltfläche "Pull Request zusammenführen" und dann auf die nächste Schaltfläche "Zusammenführung bestätigen". Du siehst dann den üblichen Dialog, dass der Pull Request zusammengeführt und geschlossen wurde (und du kannst den Zweig löschen, wenn du willst).
Wenn du jetzt oben auf das Menü Aktionen klickst, kannst du den letzten Durchlauf des Workflows sehen, der durch den Pull Request(Abbildung 4-23) mit der automatisch generierten Commit-Nachricht erzeugt wurde.
Abbildung 4-23. Jüngste Läufe des Projekts
Bevor du diesen Bildschirm verlässt, solltest du noch ein paar andere Funktionen kennenlernen. In der Zeile eines beliebigen Laufs kannst du das ... am Ende auswählen, um einen Lauf zu löschen oder direkt zur Workflow-Datei zu gehen(Abbildung 4-24).
Abbildung 4-24. Zusätzliche Optionen für einen Lauf
Außerdem gibt es oben in der Liste der Läufe Filteroptionen. Du kannst eine davon aus der Dropdown-Liste auswählen und so filtern, dass nur Runs angezeigt werden, die deiner Auswahl entsprechen. Abbildung 4-25 zeigt, wie du die Liste der Runs nach dem Patch-1-Zweig filtern kannst, der in dem gerade abgeschlossenen Pull Request verwendet wurde.
Abbildung 4-25. Filtern der Liste der Läufe nach Zweig
Verwendung der VS Code GitHub Actions Extension
Wenn du lieber in einer IDE arbeitest, gibt es eine GitHub Actions-Erweiterung für VS Code, mit der du Workflows erstellen und bearbeiten sowie Läufe verwalten und überwachen kannst. Sie enthält Funktionen wie Linting und Code-Vervollständigung und wird offiziell von GitHub unterstützt. (Die Erweiterung war ursprünglich ein Community-Projekt, das vor allem für die Überwachung genutzt wurde).
Wenn du mit VS Code vertraut bist, kannst du die Erweiterung ganz einfach über die Suche nach Aktionen in der VS Code IDE(Abbildung 4-26) oder über den Link VS Code GitHub Actions Extension installieren.
Abbildung 4-26. Installation der Erweiterung über die IDE
Du kannst dann ein Repository auswählen und es in VS Code klonen. Irgendwann wirst du aufgefordert, dich bei GitHub anzumelden und der Erweiterung den Zugriff auf deine GitHub-Repositories zu erlauben(Abbildung 4-27).
Abbildung 4-27. GitHub für VS Code autorisieren
Nach der Installation und der Autorisierung hast du eine neue Ansicht in VS Code für GitHub-Aktionen. Wenn du bereits Workflows und Workflow-Läufe in deinem Repository hast, werden sie in der Ansicht angezeigt(Abbildung 4-28).
Abbildung 4-28. Neue Ansicht für Aktionen
Wenn du in der WORKFLOWS-Liste einen Workflow-Lauf anhand seiner Nummer auswählst, erscheint auf der rechten Seite ein Globus-Symbol. Wenn du auf das Globus-Symbol klickst, kannst du den Workflow-Lauf im Browser in der Standard-Aktionsoberfläche öffnen. Wenn du einen Auftrag in der Liste auswählst, erscheint auf der rechten Seite ein Listensymbol. Wenn du dieses auswählst, kannst du die Protokolle zu diesem Auftrag einsehen(Abbildung 4-29).
Abbildung 4-29. Icons für Aufträge und Läufe
Wenn du dir ein Protokoll ansiehst, kannst du in der EXPLORER-Ansicht auf den Abschnitt OUTLINE klicken, um bestimmte Punkte im Protokoll leichter anzusteuern(Abbildung 4-30).
Abbildung 4-30. Gliederung für die Navigation in den Protokollen in der Explorer-Ansicht
Die Erweiterung versteht auch das Workflow-Schema und kann bei der Erstellung/Bearbeitung von Workflow-Dateien Hilfestellungen zum Kontext geben. Wenn du zum Beispiel mit dem Mauszeiger über ein Schlüsselwort fährst, kannst du Pop-ups mit hilfreichen Informationen über den Kontext erhalten(Abbildung 4-31).
Abbildung 4-31. Kontextsensitive Hilfe bei der Bearbeitung von Workflows
Die Erweiterung informiert dich über Syntaxprobleme beim Erstellen/Bearbeiten von Workflow-Dateien(Abbildung 4-32).
Abbildung 4-32. Erkennung von Syntaxfehlern
Weitere nette Funktionen von sind die Code-Vervollständigung für Elemente, wenn die Menge der verfügbaren Optionen bestimmt werden kann(Abbildung 4-33) und die Möglichkeit, einen schnellen Link zum Code für eine Aktion zu erhalten, indem du mit dem Mauszeiger über die Verwendungsanweisung im Workflow fährst(Abbildung 4-34).
Abbildung 4-33. Code-Vervollständigung in der Erweiterung
Abbildung 4-34. Abrufen eines Links zur Quelle für eine Aktion
Fazit
In diesem Kapitel habe ich das GitHub-Webinterface für die Arbeit mit Aktionen und Workflows vorgestellt. Damit kannst du ganz einfach Workflows erstellen und bearbeiten, ohne den Browser verlassen zu müssen. Du kannst die Workflows auch ausführen und dir jeden Durchlauf ansehen, während er stattfindet. Frühere Durchläufe werden gespeichert, damit du sie überprüfen kannst.
GitHub Actions bietet eine Reihe von Starter- und Referenz-Workflows, die das Erstellen eines ersten Workflows erleichtern. GitHub schaut sich jeden vorhandenen Code in deinem Repository an und macht, wenn möglich, Vorschläge für einen nützlichen ersten Workflow. Die Starter- und Referenz-Workflows sind ein guter Ausgangspunkt, wenn du einen Workflow für ein neues Repository brauchst.
Die Ausführung von Workflows kann als Reaktion auf standardmäßige GitHub-Ereignisse ausgelöst werden, sie können aber auch manuell ausgelöst werden, wenn sie für Workflow-Dispatching eingerichtet sind. Nach der Ausführung zeichnet GitHub Informationen über den Lauf auf und du kannst die Aufzeichnung des Laufs aufschlüsseln, um zu sehen, was tatsächlich passiert ist, und um die Details zu erfahren, z. B. welche Befehle letztendlich auf dem Runner-System ausgeführt wurden.
Die Bearbeitung von Workflows kann vollständig im Browser oder über die VS Code-Integration erfolgen, wenn du das bevorzugst. Änderungen können entweder direkt in den aktuellen Zweig übertragen oder über Pull Requests zusammengeführt werden. Wenn du eine Pull-Anfrage stellst, werden alle Workflows, die dem Ereignis entsprechen, ausgelöst und als Pre-Checks ausgeführt, um die Änderung vor der Zusammenführung zu überprüfen.
Das nächste Kapitel befasst sich mit den Systemen, auf denen die Workflows ausgeführt werden, auch Runner genannt.
Get GitHub-Aktionen lernen now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
