Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Cette version de GitHub Enterprise a été abandonnée le 2023-01-18. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Création et test de code .NET

Vous pouvez créer un workflow CI (intégration continue) pour générer et tester votre projet .NET.

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.

GitHub ont un cache d’outils où sont préinstallés des logiciels, notamment le 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 « Syntaxe de workflow pour 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 du workflow de démarrage .NET

GitHub fournit un workflow de démarrage .NET qui doit fonctionner pour la plupart des projets .NET. Ce guide inclut des exemples qui montrent comment personnaliser ce workflow de démarrage. Pour plus d’informations, consultez Workflow de démarrage .NET.

Pour commencer rapidement, ajoutez le workflow de démarrage au répertoire .github/workflows de votre dépôt.

name: dotnet package

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest
    strategy:
      matrix:
        dotnet-version: ['3.0', '3.1.x', '5.0.x' ]

    steps:
      - uses: actions/checkout@v2
      - name: Setup .NET Core SDK ${{ matrix.dotnet-version }}
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: ${{ matrix.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

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.0', '3.1.x', '5.0.x' ]

    steps:
      - uses: actions/checkout@v2
      - name: Setup dotnet ${{ matrix.dotnet-version }}
        uses: actions/setup-dotnet@v1
        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 3.1.3. 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 3.

    - name: Setup .NET 3.x
      uses: actions/setup-dotnet@v1
      with:
        # Semantic version range syntax or exact version of a dotnet version
        dotnet-version: '3.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@v2
- name: Setup dotnet
  uses: actions/setup-dotnet@v1
  with:
    dotnet-version: '3.1.x'
- name: Install dependencies
  run: dotnet add package Newtonsoft.Json --version 12.0.1

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@v2
- name: Setup dotnet
  uses: actions/setup-dotnet@v1
  with:
    dotnet-version: '3.1.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 « Rendre persistantes des données de workflow à l’aide d’artefacts ».

name: dotnet package

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest
    strategy:
      matrix:
        dotnet-version: [ '3.0', '3.1.x', '5.0.x' ]

      steps:
        - uses: actions/checkout@v2
        - name: Setup dotnet
          uses: actions/setup-dotnet@v1
          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@v2
          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@v2
      - uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '3.1.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