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.
Einführung
In dieser Anleitung erfährst du, wie du ein .NET-Paket erstellst, testest und veröffentlichst.
GitHub-gehostete Runner haben einen Toolcache mit vorinstallierter Software, die .NET Core SDK einschließt. Eine umfassende Liste mit aktueller Software und den vorinstallierten Versionen von .NET Core SDK findest du unter Auf GitHub-gehosteten Runnern installierte Software.
Voraussetzungen
Du solltest bereits mit der YAML-Syntax vertraut sein und wissen, wie sie mit GitHub Actions verwendet wird. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
Du solltest über grundlegende Kenntnisse in Bezug auf das .NET Core SDK verfügen. Weitere Informationen findest du unter Erste Schritte mit .NET.
Verwenden eines .NET-Starterworkflows
Für einen schnellen Einstieg füge einen Starterworkflow zum Verzeichnis .github/workflows
deines Repositorys hinzu.
GitHub enthält einen Starterworkflow für .NET, der die für die meisten .NET-Projekte funktionieren sollte. In den nachfolgenden Abschnitten dieser Anleitung finden Sie Beispiele dafür, wie dieser Starterworkflow angepasst werden kann.
-
Navigiere auf Ihre GitHub Enterprise Server-Instance zur Hauptseite des Repositorys.
-
Klicke unter dem Namen deines Repositorys auf Aktionen.
-
Wenn du bereits über einen Workflow im Repository verfügst, klicke auf Neuer Workflow.
-
Auf der Seite „Workflow auswählen“ wird eine Auswahl empfohlener Starterworkflows angezeigt. Suchen Sie nach "dotnet".
-
Klicken Sie im Workflow „.NET“ auf Konfigurieren.
Wenn Sie den Starterworkflow „.NET“ nicht finden, kopieren Sie den folgenden Workflowcode in eine neue Datei namens
dotnet.yml
im.github/workflows
-Verzeichnis Ihres Repositorys.YAML name: .NET on: push: branches: [ "main" ] pull_request: branches: [ "main" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup .NET uses: actions/setup-dotnet@v3 with: dotnet-version: 6.0.x - name: Restore dependencies run: dotnet restore - name: Build run: dotnet build --no-restore - name: Test run: dotnet test --no-build --verbosity normal
name: .NET on: push: branches: [ "main" ] pull_request: branches: [ "main" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup .NET uses: actions/setup-dotnet@v3 with: dotnet-version: 6.0.x - name: Restore dependencies run: dotnet restore - name: Build run: dotnet build --no-restore - name: Test run: dotnet test --no-build --verbosity normal
-
Bearbeiten Sie den Workflow nach Bedarf. Ändern Sie beispielsweise die .NET-Version.
-
Klicke auf Änderungen committen.
Angeben einer .NET-Version
Verwende die Aktion setup-dotnet
, um eine vorinstallierte Version des .NET Core SDK für einen von GitHub gehosteten Runner zu verwenden. Mit dieser Aktion wird im Toolcache der jeweiligen Runner nach einer bestimmten Version von .NET gesucht, und die erforderlichen Binärdateien werden zu PATH
hinzugefügt. Diese Änderungen bleiben für den Rest des Auftrags beibehalten.
Die Aktion setup-dotnet
wird als Methode zur Verwendung von .NET mit GitHub Actions empfohlen, da damit ein konsistentes Verhalten bei verschiedenen Runnern und verschiedenen Version von .NET gewährleistet wird. Wenn du einen selbst gehosteten Runner verwendest, musst du .NET installieren und zu PATH
hinzufügen. Weitere Informationen findest du unter der Aktion setup-dotnet
.
Verwenden mehrerer .NET-Versionen
name: dotnet package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
dotnet-version: [ '3.1.x', '6.0.x' ]
steps:
- uses: actions/checkout@v4
- name: Setup dotnet ${{ matrix.dotnet-version }}
uses: actions/setup-dotnet@v3
with:
dotnet-version: ${{ matrix.dotnet-version }}
# You can test your matrix by printing the current dotnet version
- name: Display dotnet version
run: dotnet --version
Verwenden einer bestimmten .NET-Version
Du kannst einen Auftrag so konfigurieren, dass eine bestimmte Version von .NET verwendet wird, z. B. 6.0.22
. Alternativ kannst du auch Syntax für semantische Versionierung verwenden, um die neuste Nebenversion abzurufen. In diesem Beispiel wird die neueste Nebenversion von .NET 6 verwendet.
- name: Setup .NET 6.x
uses: actions/setup-dotnet@v3
with:
# Semantic version range syntax or exact version of a dotnet version
dotnet-version: '6.x'
Installieren von Abhängigkeiten
Auf von GitHub gehosteten Runnern ist der Paketmanager NuGet installiert. Du kannst die dotnet-CLI verwenden, um Abhängigkeiten aus der NuGet-Paketregistrierung zu installieren, bevor du deinen Code erstellst und testest. Mit dem folgenden YAML-Code wird beispielsweise das Newtonsoft
-Paket installiert.
steps:
- uses: actions/checkout@v4
- name: Setup dotnet
uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.0.x'
- name: Install dependencies
run: dotnet add package Newtonsoft.Json --version 12.0.1
Abhängigkeiten „cachen“ (zwischenspeichern)
Sie können NuGet-Abhängigkeiten für zukünftige Workflows anhand der optionalen Eingabe cache
zwischenspeichern. So nimmt zum Beispiel das folgende YAML eine Zwischenspeicherung des NuGet-Ordners global-packages
vor und installiert dann das Newtonsoft
-Paket. Mit einer zweiten optionalen Eingabe, cache-dependency-path
, kann der Pfad zu einer Abhängigkeitsdatei angegeben werden: packages.lock.json
.
Weitere Informationen findest du unter Abhängigkeiten zwischenspeichern um Workflows zu beschleunigen.
steps:
- uses: actions/checkout@v4
- name: Setup dotnet
uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.x'
cache: true
- name: Install dependencies
run: dotnet add package Newtonsoft.Json --version 12.0.1
Hinweis: Je nach Anzahl der Abhängigkeiten ist es möglicherweise schneller, den Abhängigkeitscache zu verwenden. Bei Projekten mit vielen umfangreichen Abhängigkeiten sollte sich die Leistung erhöhen, da die zum Herunterladen erforderliche Zeit reduziert wird. Bei Projekten mit weniger Abhängigkeiten ist möglicherweise keine signifikante Leistungssteigerung, sondern aufgrund der Art und Weise, wie zwischengespeicherte Abhängigkeiten von NuGet installiert werden, sogar eine geringfügige Leistungsabnahme zu verzeichnen. Die Leistung variiert je nach Projekt.
Deinen Code bauen und testen
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu bauen und zu testen. In diesem Beispiel wird veranschaulicht, wie die Befehle dotnet build
und dotnet test
in einem Auftrag verwendet werden:
steps:
- uses: actions/checkout@v4
- name: Setup dotnet
uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.0.x'
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build
- name: Test with the dotnet CLI
run: dotnet test
Workflow-Daten als Artefakte paketieren
Nach Abschluss eines Workflows kannst du die resultierenden Artefakte für die Analyse hochladen. Zum Beispiel kann es notwendig sein, Logdateien, Core Dumps, Testergebnisse oder Screenshots zu speichern. Im folgenden Beispiel wird gezeigt, wie die Aktion upload-artifact
zum Hochladen von Testergebnissen verwendet werden kann.
Weitere Informationen findest du unter Speichern von Workflowdaten als Artefakte.
name: dotnet package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
dotnet-version: [ '3.1.x', '6.0.x' ]
steps:
- uses: actions/checkout@v4
- name: Setup dotnet
uses: actions/setup-dotnet@v3
with:
dotnet-version: ${{ matrix.dotnet-version }}
- name: Install dependencies
run: dotnet restore
- name: Test with dotnet
run: dotnet test --logger trx --results-directory "TestResults-${{ matrix.dotnet-version }}"
- name: Upload dotnet test results
uses: actions/upload-artifact@v3
with:
name: dotnet-results-${{ matrix.dotnet-version }}
path: TestResults-${{ matrix.dotnet-version }}
# Use always() to always run this step to publish test results when there are test failures
if: ${{ always() }}
In Paket-Registries veröffentlichen
Du kannst deinen Workflow so konfigurieren, dass das .NET-Paket in einer Paketregistrierung veröffentlicht wird, wenn deine CI-Tests bestanden werden. Du kannst Repositorygeheimnisse verwenden, um alle Token oder Anmeldeinformationen zu speichern, die zum Veröffentlichen deiner Binärdatei erforderlich sind. Im folgenden Beispiel wird ein Paket erstellt und mithilfe von dotnet core cli
in GitHub Packages veröffentlicht.
name: Upload dotnet package
on:
release:
types: [created]
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
packages: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.0.x' # SDK Version to use.
source-url: https://nuget.pkg.github.com/<owner>/index.json
env:
NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
- run: dotnet build --configuration Release <my project>
- name: Create the package
run: dotnet pack --configuration Release <my project>
- name: Publish the package to GPR
run: dotnet nuget push <my project>/bin/Release/*.nupkg