Démarrage rapide : Créer un flux de travail GitHub de validation

Dans ce guide de démarrage rapide, vous allez apprendre à créer un flux de travail GitHub pour valider la compilation de votre code source .NET dans GitHub. La compilation de votre code .NET est l’une des étapes de validation les plus simples que vous pouvez effectuer pour garantir la qualité des mises à jour de votre code. Si le code ne se compile pas (ou ne génère pas), il s’agit d’un moyen de dissuasion facile qui doit être un signe clair que le code doit être corrigé.

Prérequis

Créer un fichier de flux de travail

Dans le référentiel GitHub, ajoutez un nouveau fichier YAML au répertoire .github/workflows. Choisissez un nom de fichier explicite, qui indiquera clairement ce que le workflow est censé faire. Pour plus d’informations, consultez Fichier de flux de travail.

Important

GitHub exige que les fichiers de composition de flux de travail soient placés dans le répertoire .github/workflows .

Les fichiers de flux de travail définissent généralement une composition d’une ou plusieurs actions GitHub via jobs.<job_id>/steps[*]. Pour plus d’informations, consultez Workflow syntax for GitHub Actions.

Créez un nouveau fichier nommé build-validation.yml, copiez et collez-y le contenu YML suivant :

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

Dans la composition du flux de travail précédent :

  • name: build définit le nom, «build» s’affiche dans les badges d’état du flux de travail.

    name: build
    
  • Le nœud on désigne les événements qui déclenchent le flux de travail :

    on:
      push:
      pull_request:
        branches: [ main ]
        paths:
        - '**.cs'
        - '**.csproj'
    
    • Déclenchée lorsqu’un push ou pull_request se produit sur la branche main où les fichiers modifiés se terminent par les extensions de fichier .cs ou .csproj.
  • Le nœud env définit des variables d’environnement nommées (env var).

    env:
      DOTNET_VERSION: '6.0.401' # The .NET SDK version to use
    
    • La variable d'environnement DOTNET_VERSION est attribuée à la valeur '6.0.401'. La variable d’environnement est référencée ultérieurement pour spécifier le dotnet-version de l’action GitHub actions/setup-dotnet@v3.
  • Le nœud jobs génère les étapes à suivre pour le workflow.

    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
    
    • Il existe un seul travail, nommé build-<os><os> est le nom du système d’exploitation de strategy/matrix. Les éléments name et runs-on sont dynamiques pour chaque valeur dans matrix/os. Cette opération s’exécute sur les dernières versions d’Ubuntu, Windows et macOS.

    • L’action GitHub actions/setup-dotnet@v3 est requise pour configurer le SDK .NET avec la version spécifiée à partir de la variable d’environnement DOTNET_VERSION.

    • (Facultatif) Des étapes supplémentaires peuvent être nécessaires, en fonction de votre charge de travail .NET. Ils sont omis dans cet exemple, mais vous devrez peut-être installer des outils supplémentaires pour générer vos applications.

      • Par exemple, lors de la génération d’une application Blazor WebAssembly ASP.NET Core avec une compilation AoT (Ahead-of-Time), vous devez installer la charge de travail correspondante avant d’exécuter des opérations de restauration/génération/publication.
      - name: Install WASM Tools Workload
        run: dotnet workload install wasm-tools
      

      Pour plus d’informations sur les charges de travail .NET, consultez dotnet workload install.

    • La commande dotnet restore est appelée.

    • La commande dotnet build est appelée.

Dans ce cas, réfléchissez à un fichier de flux de travail comme une composition qui représente les différentes étapes de génération d’une application. De nombreuses commandes CLI .NET sont disponibles, dont la plupart peuvent être utilisées dans le contexte d’une action GitHub.

Créer un badge d’état de flux de travail

Il est courant que les référentiels GitHub aient un fichier README.md à la racine du répertoire du référentiel. De même, il est agréable de signaler l’état le plus récent pour différents flux de travail. Tous les flux de travail peuvent générer un badge d’état, qui est visuellement attrayant dans le fichier README.md. Pour ajouter le badge d’état du flux de travail :

  1. Dans le référentiel GitHub, sélectionnez l’option de navigation Actions.

  2. Tous les flux de travail du référentiel s’affichent sur le côté gauche, sélectionnez le flux de travail souhaité et le bouton points de suspension (...).

    • Le bouton points de suspension (...) développe les options de menu pour le flux de travail sélectionné.
  3. Sélectionnez l’option de menu Créer un badge d’état.

    GitHub: Create status badge

  4. Sélectionnez le bouton Copier le Markdown du badge d’état.

    GitHub: Copy status badge Markdown

  5. Collez le Markdown dans le fichier README.md, enregistrez le fichier, validez et envoyez (push) les modifications.

Pour plus d’informations, consultez Adding a workflow status badge.

Exemple de badges d’état du flux de travail de génération

Passage Échec de Aucun état
GitHub: build passing badge GitHub: build failing badge GitHub: build no-status badge

Voir aussi

Étapes suivantes