Jetzt anfragenIm letzten Artikel dieser Blogserie wurde die Verwendung von Secrets erläutert. Im folgendem Artikel beleuchten wir die Trigger der Workflows und untersuchen das Berechtigungskonzept. Ist es möglich Berechtigungen pro Action zu vergeben? Können GitHub Actions manuell aus der UI getriggert werden?
Die Trigger der Workflows bestehen aus einer Vielzahl von Events, die dem GitHub Repository entspringen. Wichtige Vertreter sind hier die pullrequest und push Gruppe, welche die Basis für die meisten Actions bilden. Diese ermöglichen das Reagieren auf alle Pull Request und Push Events, welche auch auf einen Branch eingeschränkt werden können (siehe Codebeispiel 1).
Codebeispiel 1: Trigger für Pull Requests und Push auf dem Master Branch
Wichtig: Die einzelnen Events werden mit einem ODER verknüpft, nur mindestens eins der definierten Events muss ausgelöst werden, um den Workflow zu triggern. Außerdem ist es möglich die Events noch nach einem Activity Type einzuschränken. Die Zeile in Codebeispiel 2 triggert den Workflow nur auf das Open und Reopen Event von Pull Requests. Außerdem ist interessant, dass ein Pull Request von einem geforktem Repository auf das Basis Repository das Event nur im Basis Repository auslöst.
Codebeispiel 2: Activity Types von Triggern
Manuelle Trigger
Um GitHub Actions manuell zu starten gibt es zwei Events. Das repository_dispatch Event wird über die API ausgelöst und ermöglicht es einen selbstgewählten Event Type mitzugeben. Dieser kann dann im Workflow ausgewertet werden (siehe Codebeispiel 3).
Codebeispiel 3: POST Request für repository_dispatch Event
Wird das workflow_dispatch Event als Trigger angegeben, kann die GitHub Action im UI manuell ausgeführt werden (siehe Abbildung 1).
Abbildung 1: Manuelles Ausführen von GitHub Actions mittels workflow_dispatch
Zeitgesteuerte Trigger
Das Schedule Event ermöglicht das Einrichten einer zeitgesteuerten Action. Der Zeitintervall wird hier als CRON-String angegeben. Codebeispiel 4 zeigt einen Trigger, der alle 15 Minuten den Workflow ausführt.
Codebeispiel 4: Zeitgesteuerter Trigger
Eine vollständige Übersicht aller Events befindet sich in den GitHub Docs.
Berechtigungen
Der Zugriff auf GitHub Actions wird grundsätzlich über die Zugriffsrechte auf das Repository geregelt. Dabei unterscheidet GitHub zwischen Repositories privater Accounts, welche nur Owner- und Contributer-Rollen haben, und Repositories von Organisationen, welche in Read-, Triage-, Write-, Maintain- und Admin-Rolle unterscheiden. Die einzelnen Rollen bestimmen welche Repository Features wie Pull Request, Release oder ähnliche der Nutzer verwenden darf (siehe GitHub Doku). Diese wiederrum erzeugen bei Benutzung die verschiedenen Trigger Events der Workflows.
Die Rollen Contributer und Owner als auch alle Rollen ab Write sind berechtigt, Workflows anzupassen und demnach auch auszuführen. Allerdings ist es je nach Event Trigger auch Personen mit weniger Rechten möglich GitHub Actions zu starten. Beispielsweise reagiert der Trigger in Codebeispiel 5 auf Änderungen am Star Score des Repositories. Stars können von jedem angemeldetem Nutzer vergeben werden und demnach auch der Workflow von jedem GitHub Nutzer, sofern das Repository öffentlich sichtbar ist, ausgeführt werden.
Codebeispiel 5: Trigger auf öffentliches Star-Event
Fazit
Die Trigger der GitHub Actions bieten vielfältige Möglichkeiten auf Änderungen im Repository zu reagieren. Dabei ist es mit workflow_dispatch und repository_dispatch möglich, Workflows manuell zu starten. Die Berechtigungen für das Ausführen ergeben sich aus den Rollen der Nutzer im Repository. Hier ist es bei öffentlichen Repositories gegebenenfalls nötig mittels if-Bedingung auf den ausführenden Nutzer zu testen.
Im nächsten Artikel fassen wir die Unterschiede und Gemeinsamkeiten zwischen GitHub Actions und Azure Pipelines noch einmal zusammen und erstellen eine Checkliste für die Migration von Azure Pipeline zu GitHub Actions.
Sprechen Sie uns an, wenn Sie Fragen haben oder Unterstützung in Ihrem Softwareentwicklungsprozess benötigen: Von der ersten Idee über die Entwicklung mit einer Build- und Release-Pipeline bis hin zur Inbetriebnahme und Wartung. Wir führen Sie gerne ans Ziel.
