Wie automatisiert GitHub Actions Entwicklungsaufgaben?

  • 10 Minuten

Hier stellen wir GitHub-Aktionen und -Workflows vor. Sie lernen die Arten von Aktionen kennen, die Sie verwenden können und wo Sie sie finden können. Außerdem sehen Sie sich Beispiele für diese Arten von Aktionen und deren Anpassung in einen Workflow an.

Verkürzte Zeit von der Idee zur Bereitstellung durch GitHub

GitHub ist dazu konzipiert, Entwicklerteams und DevOps-Engineers bei der schnellen Entwicklung und Bereitstellung von Anwendungen zu unterstützen. Es gibt viele Features in GitHub, die diese Effizienz ermöglichen, aber sie fallen in der Regel in eine von zwei Kategorien:

  • Kommunikation: Zu dieser Kategorie gehören alle Möglichkeiten, die GitHub bietet, um die Kommunikation bezüglich Softwareentwicklungsprojekte für Entwicklerteams zu vereinfachen: Code Reviews in Pull Requests, GitHub-Issues, Projektboards, Wikis, Benachrichtigungen und mehr.
  • Automatisierung: GitHub Actions ermöglicht es Ihrem Team, Workflows bei jedem Schritt im Softwareentwicklungsprozess von der Integration bis zur Bereitstellung zu automatisieren. Sie können sogar das Hinzufügen von Bezeichnungen zu Pull Requests und die Überprüfung auf veraltete Issues und Pull Requests automatisieren.

In Kombination haben diese Feature es Tausenden Entwicklerteams ermöglicht, den Zeitaufwand von der ursprünglichen Idee bis zur Bereitstellung effektiv zu verkürzen.

Verwenden der Workflowautomatisierung zum Verkürzen der Entwicklungszeit

In diesem Modul konzentrieren wir uns auf automatisierung. Daher wird im Folgenden veranschaulicht, wie Teams die Automatisierung nutzen können, um den Zeitaufwand für einen üblichen Entwicklungs- und Bereitstellungsworkflow zu reduzieren.

Berücksichtigen Sie dabei alle Aufgaben, die durchgeführt werden müssen, nachdem der Code geschrieben, aber bevor der Code zuverlässig für seinen vorgesehenen Zweck verwendet werden kann. Je nach den Zielen Ihrer Organisation müssen Sie wahrscheinlich eine oder mehrere der folgenden Aufgaben ausführen:

  • Sicherstellen, dass der Code alle Komponententests besteht
  • Durchführen von Überprüfungen der Codequalität und -konformität, um sicherzustellen, dass der Quellcode die Standards der Organisation erfüllt
  • Überprüfen des Codes und dessen Abhängigkeiten auf bekannte Sicherheitsprobleme
  • Erstellen Sie den Code, indem Sie neuen Quellcode aus (potenziell) mehreren Mitwirkenden integrieren.
  • Sicherstellen, dass die Software die Integrationstests besteht
  • Geben Sie die Version des neuen Builds an.
  • Bereitstellen der neuen Binärdateien am entsprechenden Speicherort im Dateisystem
  • Bereitstellen der neuen Binärdateien auf einem oder mehreren Servern
  • Ermitteln Sie, ob eine dieser Aufgaben nicht bestanden haben, und melden Sie das Problem, damit es von der richtigen Person oder dem richtigen Team gelöst wird.

Die Herausforderung besteht darin, diese Aufgaben zuverlässig, konsistent und nachhaltig auszuführen. Dieser Prozess ist ein idealer Auftrag für die Workflowautomatisierung. Wenn Sie bereits auf GitHub vertrauen, möchten Sie wahrscheinlich Ihre Workflowautomatisierung mithilfe von GitHub-Aktionen einrichten.

Was ist GitHub Actions?

GitHub Actions sind Paketskripte, die Aufgaben in einem Workflow zur Softwareentwicklung in GitHub automatisieren. Sie können GitHub Actions so konfigurieren, dass komplexe Workflows ausgelöst werden, die den Anforderungen Ihrer Organisation entsprechen. Der Trigger kann jedes Mal auftreten, wenn Entwickler neuen Quellcode in einen bestimmten Branch einchecken, zu zeitspezifischen Intervallen oder manuell. Das Ergebnis ist ein zuverlässiger und nachhaltiger, automatisierter Workflow, der die Entwicklungszeit deutlich reduziert.

Wo finden Sie GitHub Actions?

Aktionen von GitHub Actions sind Skripts, die ein YML-Datenformat aufweisen. Jedes Repository enthält die Registerkarte Actions (Aktionen), die eine schnelle und einfache Möglichkeit bietet, mit dem Einrichten Ihres ersten Skripts zu beginnen. Wenn Sie einen Workflow sehen, der sich Ihrer Meinung nach als Ausgangspunkt eignet, müssen Sie lediglich auf die Schaltfläche Konfigurieren klicken, um das Skript hinzuzufügen und mit der Bearbeitung der YML-Quelldatei zu beginnen.

Screenshot der Registerkarte *Actions* in GitHub Actions mit einem einfachen Workflow und einer Schaltfläche zum Einrichten des Workflows.

Neben den auf der Registerkarte „Actions“ vorgestellten Aktionen von GitHub Actions stehen Ihnen folgende Möglichkeiten zur Verfügung:

  • Sie können im GitHub-Marketplace nach GitHub Actions suchen. Im GitHub-Marketplace können Sie Tools entdecken und erwerben, die Ihren Workflow erweitern.
  • Sie können nach Open-Source-Projekten suchen. Die GitHub Actions-Organisation enthält beispielsweise viele beliebte Open-Source-Repositorys, die GitHub Actions-Aktionen enthalten, die Sie verwenden können.
  • Sie können Ihre GitHub Actions-Aktionen von Grund auf neu schreiben. Sie können die Aktionen in Open-Source-Inhalte umwandeln oder sie sogar im GitHub Marketplace veröffentlichen.

Verwenden von Open-Source-Aktionen von GitHub Actions

Viele GitHub Actions-Aktionen sind Open Source und für alle Benutzer*innen verfügbar, die sie verwenden möchten. Ebenso wie bei jeder Open-Source-Software müssen Sie diese sorgfältig überprüfen, bevor Sie sie in Ihrem Projekt verwenden können. Ähnlich wie bei den empfohlenen Communitystandards für Open Source-Software, wie das Einschließen einer Infodatei, von Verhaltensregeln, einer „Contributing“-Datei (Mitwirkende) und von Problemvorlagen, sollten Sie bei der Verwendung von GitHub Actions die folgenden Empfehlungen befolgen:

  • Überprüfen Sie die action.yml-Datei der Aktion auf Eingaben, Ausgaben und um sicherzustellen, dass der Code das macht, was er zu tun beansprucht.
  • Überprüfen Sie, ob die Aktion im GitHub Marketplace vorhanden ist. Diese Prüfung lohnt sich, auch wenn eine Aktion nicht auf dem GitHub Marketplace gültig sein muss.
  • Überprüfen Sie, ob die Aktion im GitHub Marketplace überprüft wurde. Die Überprüfung bedeutet, dass GitHub die Verwendung dieser Aktion genehmigt hat. Sie sollten sie dennoch zuerst überprüfen, bevor Sie sie verwenden.
  • Schließen Sie die Version der von Ihnen verwendeten Aktion ein, indem Sie einen Git-Verweis, einen SHA oder ein Tag angeben.

Arten von GitHub-Aktionen

Es gibt drei Typen von GitHub Actions-Aktionen: Containeraktionen, JavaScript-Aktionen und zusammengesetzte Aktionen.

Bei Containeraktionen ist die Umgebung Teil des Aktionscodes. Diese Aktionen können nur in einer Linux-Umgebung ausgeführt werden, die von GitHub gehostet wird. Containeraktionen unterstützen viele verschiedene Sprachen.

JavaScript-Aktionen schließen die Umgebung nicht in den Code ein. Sie müssen die Umgebung angeben, um diese Aktionen auszuführen. Sie können diese Aktionen in einer VM (virtueller Computer) in der Cloud oder lokal ausführen. JavaScript-Aktionen unterstützen Linux-, macOS-und Windows-Umgebungen.

Zusammengesetzte Aktionen ermöglichen Ihnen, mehrere Workflowschritte in einer Aktion zusammenzufassen. Sie können dieses Feature beispielsweise verwenden, um mehrere Ausführungsbefehle in einer Aktion zu bündeln und dann einen Workflow zu haben, der die gebündelten Befehle als einzelner Schritt mit dieser Aktion ausführt.

Anatomie einer GitHub Actions-Aktion

Im Folgenden finden Sie ein Beispiel für eine Aktion, die ein Git-Check-Out eines Repositorys ausführt. Diese Aktion (actions/checkout@v1) ist Teil eines Schritts in einem Workflow. In diesem Schritt wird auch der Node.js-Code erstellt, der ausgecheckt wurde. Im nächsten Abschnitt werden Workflows, Aufträge und Schritte erläutert.

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

Angenommen, Sie möchten eine Containeraktion verwenden, um Containercode auszuführen. Ihre Aktion könnte folgendermaßen aussehen:

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

Beachten Sie den Abschnitt inputs. Hier erhalten Sie den Wert einer Variablen namens MY_NAME. Diese Variable wird im Workflow festgelegt, der diese Aktion ausführt.

Beachten Sie im Abschnitt runs, dass Sie docker im uses-Attribut angeben. Wenn Sie diesen Wert festlegen, müssen Sie den Pfad zur Docker-Imagedatei angeben. In diesem Fall Dockerfile. Wir behandeln hier nicht die Besonderheiten von Docker, aber wenn Sie weitere Informationen wünschen, lesen Sie das Modul "Einführung in Docker-Container" .

Im letzten Abschnitt, Branding, wird Ihre Aktion im GitHub Marketplace personalisiert, wenn Sie sie dort veröffentlichen möchten.

Eine vollständige Liste der Aktionsmetadaten finden Sie unter Metadatensyntax für GitHub Actions.

Was ist ein GitHub Actions-Workflow?

Ein GitHub Actions-Workflow ist ein Prozess, den Sie in Ihrem Repository einrichten, um Aufgaben im Lebenszyklus der Softwareentwicklung zu automatisieren, einschließlich GitHub Actions. Mit einem Workflow können Sie Projekte auf GitHub erstellen, testen, packen, freigeben und bereitstellen.

Um einen Workflow zu erstellen, fügen Sie einer YML-Datei im Verzeichnis .github/workflows in Ihrem GitHub-Repository Aktionen hinzu.

In der bevorstehenden Übung sieht Ihre Workflowdatei main.yml wie im folgenden Beispiel aus:

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

Beachten Sie, dass das Attribut ein on:Auslöser ist, der angibt, wann dieser Workflow ausgeführt wird. Hier wird damit bei einem Push-Ereignis an Ihr Repository eine Ausführung ausgelöst. Sie können einzelne Ereignisse wie on: push, eine Reihe von Ereignissen wie on: [push, pull_request] oder eine Ereigniskonfigurationszuordnung angeben, die einen Workflow plant oder die Ausführung eines Workflows auf bestimmte Dateien, Tags oder Branchänderungen beschränkt. Diese Zuordnung sieht ungefähr so aus:

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration doesn't affect the page_build event above
      - created

Ein Ereignis wird bei allen Aktivitätstypen für das Ereignis ausgelöst, es sei denn, Sie geben den Typ bzw. die Typen an. Eine umfassende Liste der Ereignisse und deren Aktivitätstypen finden Sie unter Ereignisse, die Workflows auslösen in der GitHub-Dokumentation.

Ein Workflow muss mindestens einen Auftrag enthalten. Ein Auftrag ist ein Abschnitt des Workflows, der einem Runner zugeordnet wird. Ein Runner kann in GitHub gehostet werden oder sich selbst hosten, und der Auftrag kann auf einem Computer oder in einem Container ausgeführt werden. Sie geben den Läufer mit dem runs-on: Attribut an. Hier weisen Sie den Workflow an, diesen Auftrag auf ubuntu-latest auszuführen.

Jeder Auftrag hat Schritte, die ausgeführt werden müssen. In unserem Beispiel verwendet der Schritt die Aktion actions/checkout@v1, um das Repository auszuchecken. Der Wert uses: ./action-a ist besonders interessant, denn dieser ist der Pfad zur Containeraktion, die Sie in einer action.yml-Datei erstellen.

Im letzten Teil dieser Workflowdatei wird der Wert der Variablen MY_NAME für diesen Workflow festgelegt. Denken Sie dran, dass für die Containeraktion eine Eingabe mit der Bezeichnung MY_NAME erforderlich war.

Weitere Informationen zur Workflowsyntax finden Sie unter Workflowsyntax für GitHub Actions.

Verweisen auf Aktionen in Workflows

Beim Erstellen von Workflows in GitHub-Aktionen können Sie auf Aktionen aus verschiedenen Quellen verweisen. Diese Aktionen können verwendet werden, um Aufgaben in Ihren Workflows zu automatisieren. Nachfolgend sind die primären Quellen aufgeführt, in denen Workflows auf Aktionen verweisen können:

  1. Ein veröffentlichtes Docker-Containerimage auf Docker Hub
    Workflows können auf Aktionen verweisen, die als Docker-Containerimages auf Docker Hub veröffentlicht werden. Diese Aktionen sind containerisiert und enthalten alle Abhängigkeiten, die zum Ausführen der Aktion erforderlich sind. Um eine solche Aktion zu verwenden, geben Sie das Docker-Image im uses Attribut Ihres Workflowschritts an. Beispiel:

    steps:
  - name: Run a Docker action
    uses: docker://<docker-image-name>:<tag>

  2. Alle öffentlichen Repositorys
    Aktionen, die in öffentlichen Repositorys gehostet werden, können direkt in Ihren Workflows referenziert werden. Diese Aktionen sind für jeden zugänglich und können verwendet werden, indem sie den Repositorynamen und die Version (Git Ref, SHA oder Tag) im uses Attribut angeben. Beispiel:

    steps:
  - name: Use a public action
    uses: actions/checkout@v3

[!WICHTIG]

Verwenden Sie für eine bessere Sicherheit einen vollständigen Commit SHA, wenn Sie auf Aktionen verweisen – nicht nur ein Tag wie @v3.
Dadurch wird sichergestellt, dass Ihr Workflow immer den genauen Code verwendet, auch wenn die Aktion später aktualisiert oder geändert wird.
Beispiel: uses: actions/checkout@c2c1744e079e0dd11c8e0af4a96064ca4f6a2e9e

  1. Dasselbe Repository wie Ihre Workflowdatei
    Sie können auf Aktionen verweisen, die im selben Repository wie Ihre Workflowdatei gespeichert sind. Dieses Feature ist nützlich für benutzerdefinierte Aktionen, die für Ihr Projekt spezifisch sind. Um auf solche Aktionen zu verweisen, verwenden Sie einen relativen Pfad zum Verzeichnis der Aktion. Beispiel: 
    steps:
  - name: Use a local action
    uses: ./path-to-action

Weitere Details finden Sie unter Anleitung zur Sicherheitsoptimierung für GitHub-Aktionen.

  1. Ein Enterprise-Marketplace
    Wenn Ihre Organisation GitHub Enterprise verwendet, können Sie auf Aktionen aus dem privaten Marketplace Ihres Unternehmens verweisen. Diese Aktionen werden von Ihrer Organisation zusammengestellt und verwaltet, um die Einhaltung interner Standards sicherzustellen. Beispiel: 
    steps:
  - name: Use an enterprise marketplace action
    uses: enterprise-org/action-name@v1

Hinweis

  • Aktionen in privaten Repositorys können auch referenziert werden, erfordern jedoch eine ordnungsgemäße Authentifizierung und Berechtigungen.
  • Wenn Sie auf Aktionen verweisen, geben Sie immer eine Version (Git-Referenz, SHA oder Tag) an, um Konsistenz sicherzustellen und unerwartete Änderungen zu vermeiden.

Weitere Informationen finden Sie unter Verweisen auf Aktionen in Workflows.

Vergleich zwischen von GitHub gehosteten und selbstgehosteten Runnern

Wir haben kurz erwähnt, dass Runner einem Auftrag zugeordnet sind. Ein Runner ist einfach ein Server, auf dem die Runneranwendung von GitHub Actions installiert ist. Im vorherigen Workflowbeispiel gab es ein runs-on: ubuntu-latest Attribut innerhalb des Auftragsblocks, das dem Workflow mitteilte, dass der Auftrag mit dem von GitHub gehosteten Runner ausgeführt wird, der in der ubuntu-latest Umgebung ausgeführt wird.

Wenn es um Runner geht, gibt es zwei Optionen, aus denen Sie wählen können: Von GitHub-gehostete Runner oder selbst gehostete Runner. Wenn Sie einen von GitHub gehosteten Runner verwenden, wird jeder Auftrag in einer neuen Instanz einer virtuellen Umgebung ausgeführt. Der von GitHub gehostete Runnertyp, den Sie definieren (runs-on: {operating system-version}), gibt dann diese Umgebung an. Bei selbstgehosteten Runnern müssen Sie die Bezeichnung „selbstgehostet“, das Betriebssystem und die Systemarchitektur anwenden. Beispielsweise würde ein selbst gehosteter Runner mit einem Linux-Betriebssystem und einer ARM32-Architektur wie die folgende Spezifikation aussehen: runs-on: [self-hosted, linux, ARM32]

Jeder Typ von Runner hat seine Vorteile, jedoch bieten von GitHub gehostete Runner eine schnellere und einfachere Möglichkeit zum Ausführen Ihrer Workflows, allerdings mit eingeschränkten Optionen. Selbstgehostete Runner sind eine hochgradig konfigurierbare Methode zum Ausführen von Workflows in ihrer eigenen, benutzerdefinierten lokalen Umgebung. Sie können selbst gehostete Runner lokal oder in der Cloud ausführen. Sie können selbstgehostete Runner auch verwenden, um eine benutzerdefinierte Hardwarekonfiguration mit mehr Verarbeitungsleistung oder Arbeitsspeicher zu erstellen. Diese Art von Konfiguration hilft, größere Aufträge auszuführen, Software zu installieren, die in Ihrem lokalen Netzwerk verfügbar ist, und ein Betriebssystem auszuwählen, das von GitHub-gehosteten Runnern nicht angeboten wird.

GitHub-Aktionen können Nutzungsbeschränkungen aufweisen

GitHub-Aktionen weisen einige Nutzungsbeschränkungen auf, je nach GitHub-Plan und unabhängig davon, ob Ihr Runner GitHub-gehostet oder selbst gehostet ist. Weitere Informationen zu Nutzungslimits finden Sie in der GitHub-Dokumentation unter Nutzungslimits, Abrechnung und Verwaltung.

GitHub hat größere Runner gehostet

GitHub bietet größere Runner für Workflows, die mehr Ressourcen erfordern. Diese Läufer werden von GitHub gehostet und bieten im Vergleich zu Standardläufern einen erhöhten CPU-, Arbeitsspeicher- und Festplattenspeicher. Sie sind darauf ausgelegt, ressourcenintensive Workflows effizient zu verarbeiten und eine optimale Leistung für anspruchsvolle Aufgaben sicherzustellen.

Runnergrößen und -bezeichnungen

Größere Runner sind in mehreren Konfigurationen verfügbar, bieten erweiterte vCPUs, RAM und SSD-Speicher, um verschiedene Workflowanforderungen zu erfüllen. Diese Konfigurationen eignen sich ideal für Szenarien wie:

  • Kompilieren großer Codebasen mit umfangreichen Quelldateien.
  • Ausführen umfassender Testsuiten, einschließlich Integrations- und End-to-End-Tests.
  • Verarbeiten großer Datasets für Datenanalyse- oder Machine Learning-Aufgaben.
  • Erstellen von Anwendungen mit komplexen Abhängigkeiten oder großen binären Ergebnissen.
  • Durchführen leistungsstarker Simulationen oder Rechenmodellierung.
  • Ausführen von Videocodierungs-, Rendering- oder anderen Multimediaverarbeitungsworkflows.

Wenn Sie einen größeren Runner verwenden möchten, spezifizieren Sie die gewünschte Runner-Bezeichnung im runs-on Attribut Ihrer Workflow-Datei. Wenn Sie beispielsweise einen Läufer mit 16 vCPUs und 64 GB RAM verwenden möchten, würden Sie festlegen runs-on: ubuntu-latest-16core.

jobs:
  build:
    runs-on: ubuntu-latest-16core
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: make build

Diese größeren Runner wahren die Kompatibilität mit vorhandenen Arbeitsabläufen, indem dieselben vorinstallierten Tools wie bei Standard-Runnern ubuntu-latest enthalten sind.

Weitere Informationen zu Läufergrößen für größere Läufer finden Sie in der GitHub-Dokumentation

Verwalten größerer Läufer

GitHub bietet Tools zum effektiven Verwalten größerer Runner und sorgt für eine optimale Ressourcennutzung und Kostenverwaltung. Hier sind einige wichtige Aspekte der Betreuung größerer Läufer:

Überwachen der Nutzung

Sie können die Verwendung größerer Runner über die Verwendungsseite von GitHub Actions in Ihren Repository- oder Organisationseinstellungen überwachen. Diese Seite bietet Einblicke in die Anzahl der ausgeführten Aufträge, die Gesamtlaufzeit und die zugehörigen Kosten.

Verwalten des Zugriffs

Um den Zugriff auf größere Runner zu steuern, können Sie Richtlinien auf Repository- oder Organisationsebene konfigurieren. Diese Konfiguration stellt sicher, dass nur autorisierte Workflows oder Teams diese High-Resource-Läufer verwenden können.

Kostenmanagement

Größere Runner verursachen basierend auf ihrem Verbrauch zusätzliche Kosten. Berücksichtigen Sie die folgenden Vorschläge, um Kosten zu verwalten:

  • Verwenden Sie größere Runner nur für Workflows, die hohe Ressourcen erfordern.
  • Reduzieren Sie die Laufzeit, indem Sie Workflows optimieren.
  • Überwachen Sie die Abrechnungsdetails regelmäßig, um Ausgaben nachzuverfolgen.

Skalieren von Workflows

Wenn Ihre Workflows häufig größere Runner verwenden müssen, sollten Sie Skalierungsstrategien in Betracht ziehen, z. B.:

  • Verwenden von selbst gehosteten Runnern für vorhersagbare Workloads.
  • Aufteilen von Workflows in kleinere Aufträge, um die Last über Standardrunner hinweg zu verteilen.