Schnellstart: Erstellen eines GitHub-Workflows für eine Testüberprüfung

Artikel
05/09/2023

In diesem Schnellstart erfahren Sie, wie Sie einen GitHub-Workflow erstellen, um Ihren .NET-Quellcode zu testen. Das automatische Testen Ihres .NET-Codes innerhalb von GitHub wird als Continuous Integration (CI) bezeichnet, bei der Pull-Requests oder Änderungen am Quellcode die Ausführung von Workflows auslösen. Neben dem Erstellen des Quellcodes stellt das Testen sicher, dass der kompilierte Quellcode wie vom Autor beabsichtigt funktioniert. In den meisten Fällen dienen Komponententests als sofortige Feedbackschleife, um die Gültigkeit von Änderungen am Quellcode sicherzustellen.

Voraussetzungen

Ein GitHub-Konto.
Ein .NET-Quellcoderepository.

Erstellen einer Workflowdatei

Fügen Sie im GitHub-Repository dem Verzeichnis .github/workflows eine neue YAML-Datei hinzu. Wählen Sie einen aussagekräftigen Dateinamen aus, der deutlich angibt, welche Aufgabe der Workflow ausführen soll. Weitere Informationen finden Sie unter Workflowdatei.

Wichtig

GitHub erfordert, dass Workflowkompositionsdateien im Verzeichnis .github/workflows platziert werden.

Workflowdateien definieren in der Regel eine Komposition aus einem oder mehreren GitHub Actions-Vorgängen über jobs.<job_id>/steps[*]. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions.

Erstellen Sie eine neue Datei namens build-ans-test.yml, kopieren Sie die folgenden YML-Inhalte, und fügen Sie sie ein:

name: build and test

on:
  push:
  pull_request:
    branches: [ main ]
    paths:
    - '**.cs'
    - '**.csproj'

env:
  DOTNET_VERSION: '6.0.401' # The .NET SDK version to use

jobs:
  build-and-test:

    name: build-and-test-${{matrix.os}}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macOS-latest]

    steps:
    - uses: actions/checkout@v3
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ env.DOTNET_VERSION }}

    - name: Install dependencies
      run: dotnet restore
      
    - name: Build
      run: dotnet build --configuration Release --no-restore
    
    - name: Test
      run: dotnet test --no-restore --verbosity normal

Für die vorherige Workflowkomposition gilt:

name: build and test definiert den Namen. „build and test“ wird in Workflowstatusbadges angezeigt.
```
name: build and test
```
Der on-Knoten gibt die Ereignisse an, die den Workflow auslösen:
```
on:
  push:
  pull_request:
    branches: [ main ]
    paths:
    - '**.cs'
    - '**.csproj'
```
- Wird ausgelöst, wenn ein push- oder pull_request-Vorgang im main-Branch auftritt, bei dem Dateien geändert wurden, auf die Dateierweiterungen .cs oder .csproj enden.
Der env-Knoten definiert benannte Umgebungsvariablen (env var).
```
env:
  DOTNET_VERSION: '6.0.401' # The .NET SDK version to use
```
- Der Umgebungsvariablen DOTNET_VERSION wird der Wert '6.0.401' zugewiesen. Auf die Umgebungsvariable wird später verwiesen, um die dotnet-version der GitHub-Aktion actions/setup-dotnet@v3 anzugeben.
Der jobs-Knoten erstellt die Schritte, die für den Workflow ausgeführt werden sollen.
```
jobs:
  build-and-test:

    name: build-and-test-${{matrix.os}}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macOS-latest]

    steps:
    - uses: actions/checkout@v3
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ env.DOTNET_VERSION }}

    - name: Install dependencies
      run: dotnet restore
      
    - name: Build
      run: dotnet build --configuration Release --no-restore
    
    - name: Test
      run: dotnet test --no-restore --verbosity normal
```
- Es gibt einen einzelnen Auftrag mit dem Namen build-<os>, wobei <os> der Name des Betriebssystems aus strategy/matrix ist. Die name- und runs-on-Elemente sind für jeden Wert in matrix/os dynamisch. Dies kann unter den neuesten Versionen von Ubuntu, Windows und macOS ausgeführt werden.
- Die GitHub-Aktion actions/setup-dotnet@v3 wird verwendet, um das .NET SDK mit der angegebenen Version aus der Umgebungsvariablen DOTNET_VERSION einzurichten.
- Der Befehl dotnet restore wird aufgerufen.
- Der Befehl dotnet build wird aufgerufen.
- Der Befehl dotnet test wird aufgerufen.

Erstellen eines Badges für den Workflowstatus

Es ist üblich, dass GitHub-Repositorys im Stammverzeichnis des Repositoryverzeichnisses über eine Datei README.md verfügen. Ebenso ist es sinnvoll, den aktuellen Status für verschiedene Workflows zu melden. Alle Workflows können einen Statusbadge generieren, der innerhalb der Datei README.md visuell ansprechend ist. So fügen Sie den Badge für den Workflowstatus hinzu:

Wählen Sie im GitHub-Repository die Navigationsoption Aktionen aus.
Alle Repositoryworkflows werden auf der linken Seite angezeigt. Wählen Sie den gewünschten Workflow und die Schaltfläche mit den Auslassungspunkten (...) aus.
- Die Schaltfläche mit den Auslassungspunkten (...) erweitert die Menüoptionen für den ausgewählten Workflow.
Wählen Sie die Menüoption Statusbadge erstellen aus.
Wählen Sie die Schaltfläche Statusbadgemarkdown kopieren aus.
Fügen Sie das Markdown in die Datei README.md ein, speichern Sie die Datei, und committen und pushen Sie die Änderungen.