Partager via


GitHub Actions et .NET

Dans cette vue d’ensemble, vous allez découvrir quel rôle GitHub Actions jouer dans le développement d’applications .NET. GitHub Actions permet à vos référentiels de code source d’automatiser l’intégration continue (CI) et la livraison continue (CD). Au-delà de cela, GitHub Actions expose des scénarios plus avancés , fournissant des hooks pour l’automatisation avec des révisions de code, la gestion des branches et le triage des problèmes. Avec votre code source .NET dans GitHub, vous pouvez tirer parti de GitHub Actions de plusieurs façons.

Actions GitHub

GitHub Actions représente des commandes autonomes, telles que :

  • actions/extraction : cette action extrait votre référentiel sous $GITHUB_WORKSPACE, afin que votre flux de travail puisse y accéder.
  • actions/setup-dotnet : cette action configure un environnement CLI .NET à utiliser dans les actions.
  • dotnet/versionsweeper : cette action balaye les référentiels .NET pour les versions cibles hors support de .NET.

Bien que ces commandes soient isolées en une seule action, elles sont puissantes grâce à la composition du flux de travail. Dans la composition du flux de travail, vous définissez les événements qui déclenchent le flux de travail. Une fois qu’un flux de travail est en cours d’exécution, il est demandé d’effectuer plusieurs travaux . Chaque travail définit un nombre quelconque d’étapes . Les étapes délèguent à GitHub Actions ou appellent des scripts de ligne de commande.

Pour plus d’informations, consultez Présentation de GitHub Actions. Considérez un fichier de flux de travail comme une composition qui représente les différentes étapes à suivre pour générer, tester et/ou publier une application. De nombreuses commandes CLI .NET sont disponibles, dont la plupart peuvent être utilisées dans le contexte d’une action GitHub.

Actions GitHub personnalisées

Bien qu'il y ait beaucoup d'actions GitHub disponibles dans le Marketplace, vous pourriez envisager de rédiger la vôtre. Vous pouvez créer GitHub Actions qui exécutent des applications .NET. Pour plus d’informations, consultez Tutoriel : Créer une action GitHub avec .NET

Fichier de flux de travail

GitHub Actions est utilisé par le biais d’un fichier de flux de travail. Le fichier de flux de travail doit se trouver dans le répertoire .github/workflows du référentiel et doit être YAML (*.yml ou *.yaml). Les fichiers de flux de travail définissent la composition de flux de travail . Un flux de travail est un processus automatisé configurable constitué d’un ou plusieurs travaux. Pour plus d’informations, consultez Syntaxe de workflow pour GitHub Actions.

Exemples de fichiers de flux de travail

Il existe de nombreux exemples de fichiers de flux de travail .NET fournis en tant que didacticiels et guides de démarrage rapide. Voici plusieurs exemples de noms de fichiers de flux de travail :

nom de fichier de flux de travail

Description

Compile (ou génère) le code source. Si le code source ne se compile pas, cela échoue.

Effectue les tests unitaires dans le référentiel. Pour exécuter des tests, le code source doit d’abord être compilé : il s’agit d’un workflow de génération et de test (il remplace le flux de travail build-validation.yml). Les tests unitaires défaillants entraînent l’échec du flux de travail.

Compresse et publie le code source dans une destination.

Analyse votre code pour les vulnérabilités de sécurité et les erreurs de codage. Toutes les vulnérabilités découvertes peuvent entraîner une défaillance.

Secrets chiffrés

Pour utiliser des secrets chiffrés dans vos fichiers de flux de travail, vous référencez les secrets à l’aide de la syntaxe d’expression de flux de travail à partir de l’objet de contexte secrets.

${{ secrets.MY_SECRET_VALUE }} # The MY_SECRET_VALUE must exist in the repository as a secret

Les valeurs secrètes ne sont jamais imprimées dans les journaux de bord. Au lieu de cela, leurs noms sont imprimés avec un astérisque représentant leurs valeurs. Par exemple, à mesure que chaque étape s’exécute dans un travail, toutes les valeurs qu’elle utilise sont générées dans le journal des actions. Les valeurs de secret s’affichent comme suit :

MY_SECRET_VALUE: ***

Important

Le contexte secrets fournit le jeton d’authentification GitHub qui est étendu au référentiel, à la branche et à l’action. Il est fourni par GitHub sans intervention de l’utilisateur :

${{ secrets.GITHUB_TOKEN }}

Pour plus d’informations, consultez Utilisation de secrets chiffrés dans un flux de travail.

Événements

Les flux de travail sont déclenchés par de nombreux types d’événements différents. En plus des événements Webhook, qui sont les plus courants, il existe également des événements planifiés et des événements manuels.

Exemple d’événement webhook

L’exemple suivant montre comment spécifier un déclencheur d’événement webhook pour un flux de travail :

name: code coverage

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main, staging

jobs:
  coverage:

    runs-on: ubuntu-latest

    # steps omitted for brevity

Dans le flux de travail précédent, les événements push et pull_request déclenchent l’exécution du flux de travail.

Exemple d’événement planifié

L’exemple suivant montre comment spécifier un déclencheur d’événement planifié (travail cron) pour un flux de travail :

name: scan
on:
  schedule:
  - cron: '0 0 1 * *'
  # additional events omitted for brevity

jobs:
  build:
    runs-on: ubuntu-latest

    # steps omitted for brevity

Dans le flux de travail précédent, l’événement schedule spécifie l'cron de '0 0 1 * *' qui déclenche l’exécution du flux de travail le premier jour de chaque mois. L’exécution de flux de travail selon une planification est idéale pour les flux de travail qui prennent beaucoup de temps ou effectuent des actions qui nécessitent moins d’attention.

Exemple d’événement manuel

L’exemple suivant montre comment spécifier un déclencheur d’événement manuel pour un flux de travail :

name: build
on:
  workflow_dispatch:
    inputs:
      reason:
        description: 'The reason for running the workflow'
        required: true
        default: 'Manual run'
  # additional events omitted for brevity

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: 'Print manual run reason'
        if: ${{ github.event_name == 'workflow_dispatch' }}
        run: |
          echo 'Reason: ${{ github.event.inputs.reason }}'

    # additional steps omitted for brevity

Dans le flux de travail précédent, l’événement workflow_dispatch nécessite une reason en tant qu’entrée. GitHub voit cela et son interface utilisateur change dynamiquement pour inviter l’utilisateur à fournir la raison de l’exécution manuelle du flux de travail. Le steps imprime la raison fournie par l’utilisateur.

Pour plus d’informations, consultez Événements qui déclenchent des flux de travail.

CLI .NET

L’interface de ligne de commande .NET est une chaîne d’outils multiplateforme pour le développement, la génération, l’exécution et la publication d’applications .NET. L’interface CLI .NET est utilisée pour run en tant que partie de steps individuelles dans un fichier de flux de travail. Les commandes courantes sont les suivantes :

Pour plus d’informations, consultez vue d’ensemble du .NET CLI

Voir aussi

Pour une présentation plus approfondie de GitHub Actions avec .NET, tenez compte des ressources suivantes :