Verwenden von Skripts zum Testen deines Codes auf einem Runner

Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.

Übersicht über das Beispiel

In diesem Artikel werden anhand eines Beispielworkflows einige der wichtigsten CI-Features von GitHub Actions vorgestellt. Wenn dieser Workflow ausgelöst wird, wird automatisch ein Skript ausgeführt, das überprüft, ob die GitHub-Docs-Website fehlerhafte Links aufweist.

Das folgende Diagramm zeigt die allgemeinen Schritte im Workflow und wie sie im Auftrag ausgeführt werden:

Übersichtsdiagramm der Workflowschritte

In diesem Beispiel verwendete Features

Der Beispielworkflow veranschaulicht die folgenden Möglichkeiten von GitHub Actions:

Feature	Implementierung
Auslösen eines Workflows, der automatisch ausgeführt werden soll:	`push`

Beispielworkflow

Der folgende Workflow wurde von dem Docs Engineering-Team für GitHub erstellt. Um die neueste Version dieser Datei im Repository github/docs zu überprüfen, siehe check-broken-links-github-github.yml.

Hinweis: Jede Zeile dieses Workflows wird im nächsten Abschnitt unter Grundlegendes zum Beispiel erläutert.

YAML

name: 'Link Checker: All English'

# **What it does**: Renders the content of every page and check all internal links.
# **Why we have it**: To make sure all links connect correctly.
# **Who does it impact**: Docs content.

on:
  workflow_dispatch:
  push:
    branches:
      - main
  pull_request:

permissions:
  contents: read
  # Needed for the 'trilom/file-changes-action' action
  pull-requests: read

# This allows a subsequently queued workflow run to interrupt previous runs
concurrency:
  group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
  cancel-in-progress: true

jobs:
  check-links:
    runs-on: ${{ fromJSON('["ubuntu-latest", "self-hosted"]')[github.repository == 'github/docs-internal'] }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup node
        uses: actions/setup-node@v3
        with:
          node-version: 16.13.x
          cache: npm

      - name: Install
        run: npm ci

      # Creates file "$/files.json", among others
      - name: Gather files changed
        uses: trilom/file-changes-action@a6ca26c14274c33b15e6499323aac178af06ad4b
        with:
          fileOutput: 'json'

      # For verification
      - name: Show files changed
        run: cat $HOME/files.json

      - name: Link check (warnings, changed files)
        run: |
          ./script/rendered-content-link-checker.mjs \
            --language en \
            --max 100 \
            --check-anchors \
            --check-images \
            --verbose \
            --list $HOME/files.json

      - name: Link check (critical, all files)
        run: |
          ./script/rendered-content-link-checker.mjs \
            --language en \
            --exit \
            --verbose \
            --check-images \
            --level critical

Grundlegendes zum Beispiel

In der folgenden Tabelle wird erläutert, wie jedes dieser Features beim Erstellen eines GitHub Actions-Workflows verwendet wird.

Code	Erklärung
YAML `name: 'Link Checker: All English'`	Der Name des Workflows, der auf der Registerkarte „Aktionen“ im GitHub-Repository angezeigt wird.
YAML `on:`	Mit dem `on`-Schlüsselwort kannst du die bei Ausführung des Workflows ausgelösten Ereignisse definieren. Du kannst hier mehrere Ereignisse definieren. Weitere Informationen findest du unter Auslösen eines Workflows.
YAML `workflow_dispatch:`	Füge das `workflow_dispatch`-Ereignis hinzu, wenn du diesen Workflow manuell auf der Benutzeroberfläche ausführen möchtest. Weitere Informationen findest du unter `workflow_dispatch`.
YAML `push: branches: - main`	Füge das `push`-Ereignis hinzu, sodass der Workflow jedes Mal automatisch ausgeführt wird, wenn ein Commit an einen Branch mit dem Namen `main` gepusht wird. Weitere Informationen findest du unter `push`.
YAML `pull_request:`	Füge das `pull_request`-Ereignis hinzu, sodass der Workflow jedes Mal automatisch ausgeführt wird, wenn ein Pull Request erstellt oder aktualisiert wird. Weitere Informationen findest du unter `pull_request`.
YAML `permissions: contents: read pull-requests: read`	Ändert die für `GITHUB_TOKEN` gewährten Standardberechtigungen. Dies variiert je nach den Anforderungen deines Workflows. Weitere Informationen findest du unter Zuweisen von Berechtigungen zu Aufträgen.
YAML `concurrency: group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label \|\| github.head_ref \|\| github.ref }}'`	Erstellt eine Parallelitätsgruppe für bestimmte Ereignisse und verwendet den `\|\|`-Operator zum Definieren von Fallbackwerten. Weitere Informationen findest du unter Verwenden von Parallelität.
YAML `cancel-in-progress: true`	Bricht alle derzeit ausgeführten Aufträge oder Workflows in derselben Parallelitätsgruppe ab.
YAML `jobs:`	Gruppiert alle in der Workflowdatei ausgeführten Aufträge.
YAML `check-links:`	Definiert einen Auftrag mit der ID `check-links`, die innerhalb des `jobs`-Schlüssels gespeichert ist.
YAML `runs-on: ${{ fromJSON('["ubuntu-latest", "self-hosted"]')[github.repository == 'github/docs-internal'] }}`	Konfiguriert den Auftrag abhängig von dem Repository, das den Workflow ausführt, zur Ausführung auf einem von GitHub gehosteten oder selbstgehosteten Runner. In diesem Beispiel wird der Auftrag auf einem selbstgehosteten Runner ausgeführt, wenn das Repository mit `docs-internal` benannt ist und sich innerhalb der `github`-Organisation befindet. Wenn das Repository nicht mit diesem Pfad übereinstimmt, wird er auf einem von GitHub gehosteten `ubuntu-latest`-Runner ausgeführt. Weitere Informationen zu diesen Optionen findest du unter Auswählen des Runners für einen Auftrag.
YAML `steps:`	Gruppiert alle Schritte, die als Teil des `check-links`-Auftrags ausgeführt werden. Jeder Auftrag in einem Workflow verfügt über einen eigenen `steps`-Abschnitt.
YAML `- name: Checkout uses: actions/checkout@v3`	Das `uses`-Schlüsselwort weist den Auftrag an, die Aktion mit dem Namen `actions/checkout` abzurufen. Mit dieser Aktion wird dein Repository ausgecheckt und in den Runner heruntergeladen. Dadurch kannst du Aktionen für deinen Code ausführen (z. B. Testtools). Du musst die Auscheckaktion jedes Mal verwenden, wenn dein Workflow mit dem Code des Repositorys ausgeführt wird, oder du eine im Repository definierte Aktion verwendest.
YAML `- name: Setup node uses: actions/setup-node@v3 with: node-version: 16.13.x cache: npm`	In diesem Schritt wird mit der `actions/setup-node`-Aktion die angegebene Version des Node.js-Softwarepakets auf dem Runner installiert. Dadurch erhältst du Zugriff auf den `npm`-Befehl.
YAML `- name: Install run: npm ci`	Mit dem `run`-Schlüsselwort wird der Auftrag angewiesen, einen Befehl im Runner auszuführen. In diesem Fall werden mit `npm ci` die npm-Softwarepakete für das Projekt installiert.
YAML `- name: Gather files changed uses: trilom/file-changes-action@a6ca26c14274c33b15e6499323aac178af06ad4b with: fileOutput: 'json'`	Sammelt mit der `trilom/file-changes-action`-Aktion alle geänderten Dateien. Dieses Beispiel wird mit `a6ca26c14274c33b15e6499323aac178af06ad4b`-SHA einer bestimmten Version der Aktion angeheftet.
YAML `- name: Show files changed run: cat $HOME/files.json`	Listet den Inhalt von `files.json` auf. Dies ist im Protokoll der Workflowausführung sichtbar und kann für das Debuggen nützlich sein.
YAML `- name: Link check (warnings, changed files) run: \| ./script/rendered-content-link-checker.mjs \ --language en \ --max 100 \ --check-anchors \ --check-images \ --verbose \ --list $HOME/files.json`	In diesem Schritt wird mit dem `run`-Befehl ein Skript ausgeführt, das im Repository unter `script/rendered-content-link-checker.mjs` gespeichert ist, und alle zur Ausführung erforderlichen Parameter werden übergeben.
YAML `- name: Link check (critical, all files) run: \| ./script/rendered-content-link-checker.mjs \ --language en \ --exit \ --verbose \ --check-images \ --level critical`	In diesem Schritt wird auch mit dem `run`-Befehl ein Skript ausgeführt, das im Repository unter `script/rendered-content-link-checker.mjs` gespeichert ist, und ein anderer Satz von Parametern übergeben.

Nächste Schritte

Informationen zu GitHub Actions-Konzepten findest du unter Grundlegendes zu GitHub Actions.
Weitere schrittweise Anleitungen zum Erstellen eines einfachen Workflows findest du unter Schnellstart für GitHub Actions.
Wenn du mit den Grundlagen von GitHub Actions vertraut bist, erfahre unter Informationen zu Workflows mehr über Workflows und deren Features.