Gewusst wie: Verwenden von GitHub Actions zum Erstellen von Workflows für CI
Hier erfahren Sie mehr über GitHub Actions und Workflows für CI.
Folgendes wird vermittelt:
- Erstellen eines Workflows anhand einer Vorlage
- Grundlegendes zu GitHub Actions-Protokollen
- Durchführen von Tests für mehrere Ziele
- Trennen von Build- und Testaufträgen
- Speichern von Buildartefakten und Zugreifen auf diese Artefakte
- Automatisiertes Hinzufügen von Bezeichnungen für PRs bei der Überprüfung
Erstellen eines Workflows anhand einer Vorlage
Sie beginnen den Vorgang zum Erstellen eines Workflows mit einer Vorlage. Eine Vorlage enthält allgemeine Aufgaben und Schritte, die für die jeweilige Art der Automatisierung, die Sie implementieren, vorkonfiguriert sind. Wenn Sie nicht mit Workflows, Aufträgen und den Schritten vertraut sind, sollten Sie zunächst das Modul Automatisieren von Entwicklungsaufgaben mit GitHub Actions bearbeiten.
Wählen Sie auf der Hauptseite Ihres Repositorys die Registerkarte Aktionen aus, un wählen Sie dann Neuer Workflow.
Auf der Seite Workflow auswählen können Sie aus vielen verschiedenen Vorlagen wählen. Ein Beispiel ist die Node.js-Vorlage, die eine Neuinstallation von Knotenabhängigkeiten durchführt, den Quellcode erstellt und Tests für verschiedene Versionen von Node ausführt. Ein weiteres Beispiel ist die Python-Paket-Vorlage, die Python-Abhängigkeiten installiert und Tests, einschließlich lint, für verschiedene Python-Versionen durchführt.
Geben Sie im Suchfeld Node.js ein.
Wählen Sie in den Suchergebnissen im Bereich „Node.js“ die Option Konfigurieren aus.
Sie sehen diesen Standard-Workflow für Node.js-Vorlagen in der neu erstellten Datei node.js.yml.
name: Node.js CI
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [14.x, 16.x, 18.x]
steps:
- uses: actions/checkout@v3
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm ci
- run: npm run build --if-present
- run: npm test
Beachten Sie das on:-Attribut. Dieser Workflow wird ausgelöst, wenn das Repository gepusht wird und wenn ein Pull Request für den Mainbranch gestellt wird.
Es gibt ein job in diesem Workflow. Sehen Sie sich an, was der Auftrag bewirkt.
Das Attribut runs-on: gibt das Betriebssystem für den Workflow an (ubuntu-latest). Das node-version:-Attribut gibt an, dass es drei Builds gibt, jeweils einen für Node Version 14.x, 16.x und 18.x. Wir beschreiben den matrix-Teil später ausführlich, wenn wir den Workflow anpassen.
Die steps im Auftrag verwenden die GitHub-Aktionen actions/checkout@v3, um den Code aus Ihrem Repository in die VM zu holen, und actions/setup-node@v3, um die richtige Version von Node.js einzurichten. Mit dem Attribut ${{ matrix.node-version }} legen wir fest, dass wir drei Versionen von Node.js testen werden. Dieses Attribut verweist auf die Matrix, die wir zuvor definiert haben. Das Attribut cache gibt einen Paket-Manager für die Zwischenspeicherung im Standardverzeichnis an.
Im letzten Teil dieses Schritts werden Befehle ausgeführt, die von Node.js-Projekten verwendet werden. Der Befehl npm ci installiert Abhängigkeiten aus der Datei package-lock.json, npm run build --if-present führt ein Buildskript aus (sofern vorhanden) und npm test führt das Testframework aus. Beachten Sie, dass diese Vorlage den Build- und den Testschritt innerhalb des gleichen Auftrags enthält.
Weitere Informationen zu npm finden Sie in der entsprechenden Dokumentation:
Aktionsprotokolle für den Build
Wenn ein Workflow ausgeführt wird, wird ein Protokoll erstellt, das Details zu den Vorgängen und Fehlern enthält, die gegebenenfalls während der Ausführung aufgetreten sind.
Wenn ein Fehler auftritt oder ein Test fehlschlägt, sehen Sie in den Protokollen ein rotes ✖ statt eines grünen Häkchens ✔. Sie können die Details des Fehlers oder der Störung untersuchen, um herauszufinden, was passiert ist.
In der Übung untersuchen Sie Protokolldetails, um Tests mit Fehlern zu ermitteln. Sie können über die Registerkarte Aktionen auf die Protokolle zugreifen.
Anpassen von Workflowvorlagen
Zu Beginn dieses Moduls haben wir ein Szenario beschrieben, in dem Sie CI für Ihr Team einrichten müssen. Die Node.js-Vorlage eignet sich hervorragend für den Einstieg in die erforderlichen Schritte, sie sollte jedoch an die individuellen Anforderungen Ihres Teams angepasst werden. So sollen z. B. verschiedene Node-Versionen und Betriebssysteme als Ziel festgelegt werden. Sie möchten auch, dass die Build- und Testschritte separate Aufträge sind.
Nachfolgend wird gezeigt, wie Sie einen Workflow anpassen können.
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [16.x, 18.x]
Hier wurde eine Buildmatrix konfiguriert, um Tests für mehrere Betriebssysteme und mit unterschiedlichen Sprachversionen auszuführen. Diese Matrix erzeugt vier Builds, einen für jedes Betriebssystem, das mit jeder Version von Node gepaart ist.
Vier Builds und alle dazugehörigen Tests erzeugen eine ganze Reihe von Protokolldaten. Es kann schwierig sein, all diese Informationen durchzusehen. Im folgenden Beispiel zeigen wir Ihnen, wie Sie den Testschritt in einen dedizierten Testauftrag verschieben. Mit diesem Auftrag werden Tests für verschiedene Ziele ausgeführt. Die Trennung von Build- und Testschritten erleichtert das Verständnis des Protokolls.
test:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [16.x, 18.x]
steps:
- uses: actions/checkout@v3
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
- name: npm install, and test
run: |
npm install
npm test
env:
CI: true
Was sind Artefakte?
Wenn ein Workflow etwas anderes als einen Protokolleintrag erzeugt, wird das Produkt als Artefakt bezeichnet. Der Node.js-Build erzeugt zum Beispiel einen Docker-Container, der bereitgestellt werden kann. Dieses Artefakt, der Container, kann mit der Aktion actions/upload-artifact in den Speicher hochgeladen und später mit der Aktion actions/download-artifact aus dem Speicher heruntergeladen werden.
Durch das Speichern eines Artefakts wird es zwischen Aufträgen aufbewahrt. Jeder Auftrag verwendet eine neue Instanz einer VM, so dass Sie das Artefakt nicht wiederverwenden können, indem Sie es auf der VM speichern. Wenn Sie Ihr Artefakt in einem anderen Auftrag verwenden müssen, können Sie das Artefakt aus einem Auftrag in Speicher hochladen und für den anderen Auftrag herunterladen.
Artefaktspeicher
Artefakte werden auf GitHub gespeichert. Der dazu verwendete Speicherplatz ist bei öffentlichen Repositorys kostenlos. Bei privaten Repositorys steht abhängig vom Konto ebenfalls eine bestimmte Speichergröße kostenfrei zur Verfügung. Ihre Artefakte verbleiben für 90 Tage im Speicher auf GitHub.
Im folgenden Workflow-Codeschnipsel sehen Sie, dass es in der actions/upload-artifact@main-Aktion ein path:-Attribut gibt. Der Wert dieses Attributs ist der Pfad zum Speichern des Artefakts. In diesem Beispiel geben wir public/ an, um sämtliche Daten in ein Verzeichnis hochzuladen. Wenn wir nur eine einzelne Datei hochladen möchten, verwenden wir etwas wie public/mytext.txt.
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@main
with:
name: webpack artifacts
path: public/
Um das Artefakt zum Testen herunterzuladen, muss der Build erfolgreich abgeschlossen und das Artefakt hochgeladen worden sein. Im folgenden Code geben Sie an, dass der Testauftrag vom Buildauftrag abhängig ist.
test:
needs: build
runs-on: ubuntu-latest
Im Workflowausschnitt unten wird gezeigt, dass das Artefakt heruntergeladen wird. Das Artefakt kann nun zu Testzwecken im Testauftrag verwendet werden.
steps:
- uses: actions/checkout@v3
- uses: actions/download-artifact@main
with:
name: webpack artifacts
path: public
Weitere Informationen zur Verwendung von Artefakten in Workflows finden Sie unter Speichern von Workflowdaten als Artefakte in der GitHub-Dokumentation.
Automatisieren von Überprüfungen in GitHub mithilfe von Workflows
Bisher haben wir beschrieben, wie Workflows mit GitHub-Ereignissen wie einem Push oder Pull Request gestartet werden. Wir könnten einen Workflow auch nach einem Zeitplan oder bei einem Ereignis außerhalb von GitHub ausführen.
Manchmal möchten wir den Workflow erst dann ausführen, wenn eine Person eine Aktion durchgeführt hat. So kann es beispielsweise sein, dass wir einen Workflow erst dann ausführen möchten, wenn ein Prüfer den Pull Request genehmigt hat. In diesem Szenario kann pull-request-review als Auslöser für den Workflow verwendet werden.
Alternativ könnte dem Pull Request eine Bezeichnung hinzugefügt werden. In diesem Fall verwenden wir die Aktion pullreminders/label-when-approved-action.
steps:
- name: Label when approved
uses: pullreminders/label-when-approved-action@main
env:
APPROVALS: "1"
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ADD_LABEL: "approved"
Beachten Sie den Block env:. In diesem Block können Sie die Umgebungsvariablen für diese Aktion festlegen. So können Sie z. B. die erforderliche Anzahl von genehmigenden Personen festlegen. In diesem Fall ist eine genehmigende Person festgelegt. Die Authentifizierungsvariable secrets.GITHUB_TOKEN ist erforderlich, weil die Aktion Änderungen an Ihrem Repository vornehmen muss, indem eine Bezeichnung hinzugefügt wird. Als letzten Schritt geben Sie den Namen der Bezeichnung an, die hinzugefügt werden soll.
Beim Hinzufügen einer Bezeichnung können Sie z. B. ein Ereignis angeben, das einen weiteren Workflow startet (beispielsweise einen Mergevorgang). Wir behandeln dieses Ereignis im nächsten Modul über kontinuierliche Bereitstellung mit GitHub Actions.