Note
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.
À propos de l’intégration continue
L’intégration continue (CI) est une pratique logicielle qui nécessite un committing fréquent du code dans un dépôt partagé. La plupart du temps, le fait de commiter le code permet de détecter plus rapidement les erreurs, et réduit la quantité de code dont un développeur a besoin pour le débogage lorsqu’il recherche la source d’une erreur. Les mises à jour fréquentes du code facilitent également la fusion des modifications apportées par différents membres d’une équipe de développement logiciel. Ceci est idéal pour les développeurs, qui peuvent alors passer plus de temps à écrire du code et moins de temps à déboguer des erreurs ou à résoudre les conflits de fusion.
Lorsque vous commitez du code dans votre dépôt, vous pouvez générer et tester le code en continu pour être sûr que le commit ne provoque pas d’erreurs. Vos tests peuvent inclure des linters de code (qui vérifient la mise en forme du style), des vérifications de sécurité, la couverture du code, des tests fonctionnels et d’autres vérifications personnalisées.
La génération et le test de votre code nécessitent un serveur. Vous pouvez générer et tester des mises à jour localement avant de pousser (push) du code vers un dépôt, ou vous pouvez utiliser un serveur d’intégration continue qui recherche les nouveaux commits de code dans un dépôt.
À propos de l’intégration continue avec GitHub Actions
L’intégration continue avec GitHub Actions offre des workflows qui peuvent générer du code dans votre référentiel et exécuter vos tests. Les workflows peuvent s’exécuter sur des machines virtuelles hébergées dans GitHub, ou sur des machines que vous hébergez vous-même. Pour plus d’informations, consultez « Utilisation des exécuteurs hébergés par GitHub » et « À propos des exécuteurs auto-hébergés ».
Vous pouvez configurer votre workflow d’intégration continue pour qu’il s’exécute lorsqu’un événement GitHub se produit (par exemple, lorsque le nouveau code est poussé vers votre dépôt), lorsqu’un événement externe se produit si vous utilisez le webhook de dispatch du dépôt, ou selon une planification définie.
GitHub exécute vos tests CI et fournit les résultats de chaque test dans la demande d'extraction, afin que vous puissiez voir si le changement dans votre branche introduit une erreur. Lorsque tous les tests d’intégration continue d’un workflow réussissent, les modifications que vous avez poussées sont prêtes à être examinées ou fusionnées par un membre de l’équipe. Lorsqu’un test échoue, cela peut signifier que l’une de vos modifications a provoqué l’échec.
Lorsque vous configurez l'IC dans votre référentiel, GitHub analyse le code dans votre référentiel et recommande des flux d'IC basés sur le langage et le framework de votre référentiel. Par exemple, si vous utilisez Node.js , GitHub vous proposera un modèle de flux de travail qui installe vos paquets Node.js et exécute vos tests. Vous pouvez utiliser le modèle de flux de travail CI suggéré par GitHub, personnaliser le modèle de flux de travail suggéré, ou créer votre propre fichier de flux de travail personnalisé pour exécuter vos tests CI.
En plus de vous aider à configurer des workflows d’intégration continue pour votre projet, GitHub Actions vous permet de créer des workflows dans le cycle de vie complet de développement logiciel. Par exemple, vous pouvez utiliser des actions pour déployer, empaqueter ou publier votre projet. Pour plus d’informations, consultez « Écriture de workflows ».
Pour obtenir une définition des termes courants, consultez « Comprendre GitHub Actions ».
Modèles de workflow
GitHub offre des modèles de flux de travail de CI pour une variété de langages et de cadres.
Consultez la liste complète des modèles de workflow d’intégration continue proposés par GitHub dans le dépôt actions/starter-workflows sur GitHub.com.