GitHub Actions in Action

GitHub hat Ende 2018 seine Workflow-Automation Actions vorgestellt, welches sich momentan noch in der Beta-Phase befindet.

Ich hatte bereits die Gelegenheit, Actions auszuprobieren und bei der Arbeit verwenden wir es auch schon fuer kleinere Deployment-Jobs, fuer die ein eigenes CI/CD-Tool wie Jenkins oder CircleCI Overkill waere, wenn man nach einem Push nur ein paar Files aus dem Repo auf einen Cloud Storage Bucket schieben will.

Im Grunde baut man aus einzelnen Actions einen Workflow zusammen, dies geht entweder ueber einen relativ simpel gehaltenen grafischen Editor oder direkt als Code in einer .workflow-Datei.

Der Clou dabei ist, dass Actions nichts weiter sind als Docker Images und man so zusaetzlich zu einer Reihe von GitHub und seinen Partnern angebotenen Actions auch jederzeit komplett eigene erstellen und publizieren kann.

Erstellen eines einfachen Workflows

Es bietet sich natuerlich direkt an, einfache Tasks wie den Upload von Dateien aus dem Repository in eine Action zu packen, im einfachsten Fall sieht das dann so aus:


Workflow erstellen und Action(s) konfigurieren

Zuerst wird natuerlich ein Workflow erstellt, dieser bekommt einen Namen und einen Trigger konfiguriert, bei welchem er loslaufen soll. Hier gibt es einige verschiedene Events, die verwendet werden koennen („push“ ist natuerlich das offensichtlichste).

Als naechstes definieren wir unsere Action. In unserem Fall benutzen wir keine vorgefertige von GitHub, sondern nehmen ein Docker-Image (azure-cli).

Hier gibt es vor allem zwei verschiedene Felder zu konfigurieren:

runs: definiert den entrypoint des Containers (hier sh, weil wir ein kleines Script ausfuehren).

args: definiert CMD des Containers, als ein Array an Parametern. Wir nehmen -c fuer sh und als zweiten Parameter dann unser kleines Script, welches ueber die Azure CLI Dateien in einen Storage-Account hochlaedt.

Zusaetzlich kann man hier noch ENV-Variablen und Secrets definieren. Secrets werden von GitHub verschluesselt im Repository gespeichert und stehen allen Workflows zur Verfuegung (analog zu Secret Variables in GitLab-Repos).

So sieht der gesamte Workflow dann in Textform aus:

workflow "Push to Storage Account" {   
on = "push"
resolves = ["microsoft/azure-cli"]
}

action "microsoft/azure-cli" {
uses = "docker://microsoft/azure-cli"
runs = "sh"
args = ["-c", "az login --service-principal -u $clientID -p $clientSecret --tenant $tenantId; cd ./html; for f in $(find . -type f ! -path \"./fonts/*\"); do echo \"Uploading $f\"; az storage blob upload -c $storageContainer --account-name $storageAccount -f $f -n $f; done"]
secrets = ["clientID", "clientSecret", "storageAccount", "storageContainer", "tenantId"]
}

Workflows werden im Repository unterhalb vom Verzeichnis .github als .workflow-Dateien gespeichert und sind damit wie der gesamte Rest im Repository auch ordentlich mit versioniert.

Ein durchlaufener Workflow produziert natuerlich auch Logs, die ganz einfach im Actions-Tab in der Repository-Ansicht sichtbar sind:

Dies war ein einfaches Beispiel, jedoch lassen sich damit auch wesentlich komplexere Workflows erstellen, einzig was ich in ein Docker-Image packen kann ist das Limit (und die Beschraenkung von max. 58 Minuten Laufzeit pro Workflow-Run).

Schoen ist vor allem aus meiner Sicht aber, dass vor allem kleinere Tasks, die bei einem Push ins Repo anfallen, nun direkt in GitHub definiert werden koennen, ohne dass dazu ein externes CI/CD-System noch extra betrieben und konfiguriert werden muss.

Schreib einen Kommentar