Schnellstart: Erstellen eines GitHub-Workflows für die Buildüberprüfung

Artikel
05/10/2023

In diesem Schnellstart erfahren Sie, wie Sie einen GitHub-Workflow erstellen, um die Kompilierung Ihres .NET-Quellcodes in GitHub zu überprüfen. Das Kompilieren Ihres .NET-Codes ist einer der grundlegendsten Überprüfungsschritte, die Sie ausführen können, um die Qualität von Updates für Ihren Code sicherzustellen. Wenn sich der Code nicht kompilieren (oder erstellen) lässt, schreckt das leicht ab und sollte ein klares Zeichen dafür sein, dass der Code korrigiert werden muss.

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-validation.yml, kopieren Sie die folgenden YML-Inhalte, und fügen Sie sie ein:

name: build

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

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

jobs:
  build:

    name: build-${{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

Für die vorherige Workflowkomposition gilt:

name: build definiert den Namen. „build“ wird in Workflowstatusbadges angezeigt.
```
name: build
```
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:

    name: build-${{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
```
- 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 ist erforderlich, um das .NET SDK mit der angegebenen Version aus der Umgebungsvariablen DOTNET_VERSION einzurichten.
- (Optional) Abhängig von Ihrer .NET-Workload sind möglicherweise zusätzliche Schritte erforderlich. Sie werden in diesem Beispiel ausgelassen, aber Sie müssen möglicherweise zusätzliche Tools installieren, um Ihre Apps erstellen zu können.
  - Wenn Sie beispielsweise eine ASP.NET Core Blazor-WebAssembly-Anwendung mit AoT-Kompilierung (Ahead-of-Time) erstellen, installieren Sie die entsprechende Workload vor dem Ausführen von Wiederherstellungs-/Build-/Veröffentlichungsvorgängen.
```
- name: Install WASM Tools Workload
  run: dotnet workload install wasm-tools
```
  Weitere Informationen zu .NET-Workloads finden Sie unter dotnet workload install.
- Der Befehl dotnet restore wird aufgerufen.
- Der Befehl dotnet build wird aufgerufen.

Stellen Sie sich eine Workflowdatei in diesem Fall als eine Komposition vor, die die verschiedenen Schritte zum Erstellen einer Anwendung darstellt. Es sind viele .NET CLI-Befehle verfügbar, von denen die meisten im Kontext einer GitHub-Aktion verwendet werden können.

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.