Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.
Introduction
Ce guide explique comment générer, tester et publier un package .NET.
Les exécuteurs hébergés dans GitHub ont un cache d’outils où sont préinstallés des logiciels, notamment le kit SDK .NET Core. Pour obtenir la liste complète des logiciels à jour et des versions préinstallées du SDK .NET Core, consultez Logiciels installés sur les exécuteurs hébergés dans GitHub.
Prérequis
Vous devez déjà être familiarisé avec la syntaxe YAML et savoir comment elle s’utilise avec GitHub Actions. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Il est recommandé de connaître les bases du SDK .NET Core. Pour plus d’informations, consultez Bien démarrer avec .NET.
Utilisation d’un workflow de démarrage pour .NET
Pour commencer rapidement, ajoutez le workflow de démarrage à l’annuaire .github/workflows
de votre référentiel.
GitHub fournit un workflow de démarrage pour .NET qui devrait fonctionner pour la plupart des projets .NET. Les sections suivantes de ce guide donnent des exemples de la façon dont vous pouvez personnaliser ce workflow de démarrage.
-
Dans votre instance GitHub Enterprise Server, accédez à la page principale du dépôt.
-
Sous le nom de votre dépôt, cliquez sur Actions.
-
Si vous disposez déjà d’un workflow dans votre dépôt, cliquez sur Nouveau workflow.
-
La page « Choisir un workflow » présente une sélection de workflows de démarrage recommandés. Recherchez « dotnet ».
-
Dans le workflow « .NET », cliquez sur Configurer.
Si vous ne trouvez pas le workflow de démarrage « .NET », copiez le code de workflow suivant dans un nouveau fichier appelé
dotnet.yml
dans l’annuaire.github/workflows
de votre référentiel.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
-
Modifiez le workflow en fonction des besoins. Par exemple, modifiez la version de .NET.
-
Cliquez sur Valider les changements.
Spécification d’une version .NET
Pour utiliser une version préinstallée du SDK .NET Core sur un exécuteur hébergé dans GitHub, utilisez l’action setup-dotnet
. Cette action recherche une version spécifique de .NET à partir du cache d’outils de chaque exécuteur, et ajoute les fichiers binaires nécessaires à PATH
. Ces modifications seront conservées pendant toute la durée du travail.
L’action setup-dotnet
est recommandée pour l’utilisation de .NET avec GitHub Actions, car cela garantit un comportement cohérent sur tous les exécuteurs et toutes les versions de .NET. Si vous utilisez un exécuteur auto-hébergé, vous devez installer .NET et l’ajouter à PATH
. Pour plus d’informations, consultez l’action setup-dotnet
.
Utilisation de plusieurs versions de .NET
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
Utilisation d’une version spécifique de .NET
Vous pouvez configurer votre travail pour qu’il utilise une version spécifique de .NET, comme 6.0.22
. Vous pouvez également utiliser la syntaxe de versioning sémantique pour obtenir la dernière version mineure. Cet exemple utilise la dernière version mineure de .NET 6.
- 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'
Installer les dépendances
Le gestionnaire de package NuGet est installé sur les exécuteurs hébergés dans GitHub. Vous pouvez utiliser l’interface CLI dotnet pour installer des dépendances à partir du registre de package NuGet avant de générer et de tester votre code. Par exemple, le YAML ci-dessous installe le package Newtonsoft
.
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
Mise en cache des dépendances
Vous pouvez mettre en cache les dépendances NuGet à l’aide d’une clé unique, ce qui vous permet de restaurer les dépendances pour les prochains workflows avec l’action cache
. Par exemple, le YAML ci-dessous installe le package Newtonsoft
.
Pour plus d’informations, consultez « Mise en cache des dépendances pour accélérer les workflows ».
steps:
- uses: actions/checkout@v4
- name: Setup dotnet
uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.0.x'
- uses: actions/cache@v3
with:
path: ~/.nuget/packages
# Look to see if there is a cache hit for the corresponding requirements file
key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}
restore-keys: |
${{ runner.os }}-nuget
- name: Install dependencies
run: dotnet add package Newtonsoft.Json --version 12.0.1
Remarque : Selon le nombre de dépendances, il peut être plus rapide d’utiliser le cache des dépendances. Les projets qui ont de nombreuses dépendances doivent voir une amélioration des performances, car cela réduit le temps nécessaire au téléchargement. Les projets qui ont moins de dépendances peuvent ne pas constater d’amélioration significative des performances, et peuvent même voir une légère diminution de celles-ci en raison de la façon dont NuGet installe les dépendances mises en cache. Les performances varient d’un projet à l’autre.
Génération et test de votre code
Vous pouvez utiliser les mêmes commandes que celles que vous utilisez localement pour générer et tester votre code. Cet exemple montre comment utiliser dotnet build
et dotnet test
dans un travail :
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
Empaquetage des données de workflow en tant qu’artefacts
Une fois le workflow terminé, vous pouvez charger les artefacts résultants à des fins d’analyse. Par exemple, vous devrez peut-être enregistrer des fichiers journaux, des vidages principaux, des résultats de test ou des captures d’écran. L’exemple suivant montre comment utiliser l’action upload-artifact
pour charger les résultats de test.
Pour plus d’informations, consultez « Stockage des données de workflow en tant qu’artefacts ».
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() }}
Publication dans des registres de package
Vous pouvez configurer votre workflow pour publier votre package .NET dans un registre de package une fois vos tests CI réussis. Vous pouvez utiliser des secrets de dépôt pour stocker n’importe quels jetons ou informations d’identification nécessaires à la publication de votre fichier binaire. L’exemple suivant crée et publie un package dans GitHub Packages à l’aide de dotnet core cli
.
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