GitHub Actions et .NET
Dans cette présentation, vous découvrirez le rôle que GitHub Actions joue dans le développement d’applications .NET. GitHub Actions permet à vos dépôts de code source d’automatiser l’intégration continue et la livraison continue. En outre, GitHub Actions expose des scénarios plus avancés, en fournissant des crochets pour l’automatisation avec des révisions de code, la gestion de branche et le tri des problèmes. Avec votre code source .NET dans GitHub, vous pouvez tirer parti de GitHub Actions de bien des façons.
GitHub Actions
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 différents travaux. Chaque travail définit un certain nombre d’étapes. Les étapes délèguent à GitHub Actions ou appellent des scripts de ligne de commande.
Pour plus d’informations, consultez Introduction à GitHub Actions. Voyez un fichier de flux de travail comme une composition qui représente les différentes étapes de génération, de test et/ou de publication d’une application. De nombreuses commandes CLI .NET sont disponibles, dont la plupart peuvent être utilisées dans le contexte d’une action GitHub.
GitHub Actions personnalisées
Bien qu’il existe de nombreuses GitHub Actions disponibles sur la Place de marché, vous pouvez créer les vôtres. Vous pouvez créer des GitHub Actions qui exécutent des applications .NET. Pour plus d’informations, consultez Tutoriel : Créer une action GitHub avec .NET
Fichier de workflow
Les GitHub Actions sont utilisées via 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 au format YAML (*.yml ou *.yaml). Les fichiers de flux de travail définissent la composition du flux de travail. Un workflow est un processus automatisé configurable qui comprend un ou plusieurs travaux. Pour plus d’informations, consultez Syntaxe de workflow pour GitHub Actions.
Exemple de fichiers de flux de travail
Il existe de nombreux exemples de fichiers de flux de travail .NET fournis sous forme detutoriels et de démarrages rapides. Voici plusieurs bons exemples de noms de fichiers de flux de travail :
Nom du fichier de flux de travail
Description
Compile (ou génère) le code source. Si le code source ne se compile pas, cela échouera.
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 en fait d’un flux de travail de génération et de test (il remplacerait le flux de travail build-validation.yml). L’échec des tests unitaires entraîne l’échec du flux de travail.
Compresse et publie le code source dans une destination.
Analyse votre code à la recherche de failles de sécurité et d’erreurs de codage. Toutes les vulnérabilités découvertes peuvent entraîner un échec.
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. 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’il 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 limité 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. Outre les é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énements 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énements planifiés (tâche 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 le cronde '0 0 1 * *' qui déclenchera 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 à s’exécuter ou qui 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énements manuels 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 à indiquer la raison de l’exécution manuelle du flux de travail. Les steps impriment la raison fournie par l’utilisateur.
Pour plus d’informations, consultez Événements qui déclenchent des workflows.
CLI .NET
L’interface de ligne de commande (CLI) de .NET est une nouvelle chaîne d’outils multiplateformes pour développer, générer, exécuter et publier des 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. Parmi les commandes communes, on peut citer :
Pour plus d’informations, consultez Vue d’ensemble de .NET CLI
Voir aussi
Pour plus d’informations sur GitHub Actions avec .NET, consultez les ressources suivantes :
Démarrage(s) rapide(s) :
Tutoriel(s) :
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour