Valider les modifications avec GitHub Actions

Avec un développement basé sur le tronc, chaque modification proposée fait l’objet d’une pull request. Cette pull request est également le moment idéal pour lancer des vérifications automatisées. Une modification qui interrompt le script d’entraînement ne doit pas atteindre mainet un réviseur ne doit pas avoir à intercepter manuellement chaque erreur de code.

Flux de travail, déclencheurs et porte de qualité

Un flux de travail GitHub Actions est un fichier YAML stocké dans votre référentiel sous .github/workflows/. Il définit ce qu’il faut exécuter, quand l’exécuter et dans quelle séquence. Un déclencheur (la on: clé) indique GitHub quand le démarrer.

Pour le flux de validation Proseware, le déclencheur pull_request convient à la tâche. Par défaut, il s’exécute lorsqu’une pull request est ouverte, rouverte ou reçoit de nouveaux commits. Son résultat apparaît sous la forme d’un contrôle d’état sur la pull request.

Tâches, agents d’exécution et étapes

Un flux de travail organise le travail en travaux. Chaque tâche s’exécute sur un runner — une machine virtuelle fournie par GitHub ou gérée par votre organisation. Un travail contient des étapes ordonnées qui examinent le référentiel, installent les outils et exécutent des commandes.

Pour le code de formation Proseware, un travail de validation peut :

1. Consultez le référentiel.
2. Installez un linter (tel que Flake8 pour Python) et exécutez-le sur les scripts d’entraînement.
3. Exécutez des tests unitaires (tels que Pytest) pour vérifier que les fonctions de script se comportent correctement.

Ces étapes s’exécutent automatiquement à chaque pull request. Personne n’a à se rappeler de les exécuter localement.

Vérifications requises

L’exécution automatique des vérifications n’est que la moitié de la protection. L’autre aspect consiste à rendre ces vérifications bloquantes. Dans les paramètres de protection des branches, l’option Exiger la réussite des vérifications d’état avant la fusion vous permet de nommer des tâches spécifiques. Une pull request ne peut pas être fusionnée tant que les tâches indiquées ne se sont pas terminées avec succès.

Ensemble, le développement basé sur le trunk et les vérifications de statut obligatoires forment une barrière qualité : le scientifique des données ouvre une demande de tirage, le flux de travail s’exécute et le bouton de fusion reste désactivé tant que le code n’a pas passé tous les contrôles.