Comment utiliser les actions Github pour automatiser vos constructions de référentiel – CloudSavvy IT
Si vous en avez assez de créer et de publier votre application manuellement, il est peut-être temps de configurer un pipeline CI/CD. Github Actions rend ce processus facile et gratuit pour la plupart des projets, et peut vous faire gagner du temps en automatisant le processus de création de votre application.
Sommaire
Que sont les actions ?
Les actions Github sont des tâches qui s’exécutent dans le cloud. Ils peuvent être configurés avec des fichiers de configuration YAML et déclenchés en fonction des événements qui se produisent dans votre compte. C’est généralement quelque chose comme « nouveau commit poussé vers la branche principale », mais les actions peuvent en fait être configurées pour de nombreux événements différents, y compris lorsque de nouveaux problèmes sont créés, ou même selon un calendrier en tant que tâche cron.
Dans ce cas, nous aimerions mettre en place une compilation automatisée. Ce processus s’exécute généralement chaque fois que des modifications sont apportées au référentiel. Vous pouvez le configurer comme vous le souhaitez – il est courant de l’exécuter sur le master
ou release
branche, mais vous pouvez également exécuter des builds sur les branches dev et feature.
La plupart des processus de construction impliqueront également des tests, et Github Actions peut également le faire. Cela peut être utile pour intercepter les commits qui entraînent l’échec de la construction. Vous ne voulez probablement pas non plus déployer des builds ayant échoué, donc exécuter des tests au préalable dans tous les cas peut être bénéfique.
Avec Github Actions, vous pouvez également automatiser la partie release de votre déploiement. Si tu as un release
ou master
branche à partir de laquelle vous mettez toujours à jour, vous pouvez traiter cette branche comme votre source de déploiement. Vos serveurs téléchargeront les fichiers binaires à partir de la sortie de l’action Github et mettront à jour votre code. Cela est encore plus facile si vous utilisez un gestionnaire de packages ou un registre comme NPM, Maven ou le Docker Hub : les mises à jour peuvent être transmises directement au registre et extraites si nécessaire.
Configurer une compilation automatisée
Les actions Github utilisent un système de configuration basé sur YAML. Vous devrez définir deux choses de base : quand l’action se déclenche et quelles mesures sont prises une fois qu’elle se déclenche.
Votre configuration exacte dépendra énormément du langage, du framework et du système de construction que vous utilisez pour votre application. Le processus général est cependant assez similaire, et pour cet exemple, nous allons configurer une version pour une application basée sur Java à l’aide de l’outil de génération Gradle.
Rendez-vous sur votre référentiel et cliquez sur « Actions ». Github est assez intelligent pour reconnaître le type d’application que contient votre référentiel, et ici, il recommande quelques actions différentes pour la construction de Java.
Cliquer sur « Java avec Gradle » fait apparaître l’éditeur Github pour le fichier YAML, préconfiguré avec une version Java. Cela s’exécute à chaque poussée vers le maître et à chaque demande d’extraction vers le maître. Vous pouvez modifier cela pour qu’il s’exécute également sur d’autres branches, ou configurer une action différente pour les branches dev/feature.
Vous pouvez modifier toutes les variables ici et cliquer sur « Valider » à droite lorsque vous avez terminé. La validation déclenchera une construction si vous l’avez configurée pour s’exécuter en push.
Vous pouvez trouver les exécutions de flux de travail en cours sous l’onglet Actions.
Dépannage des builds ayant échoué
Bien sûr, ce n’est pas toujours aussi facile – dans le monde réel, les environnements de construction peuvent être très fragiles et peuvent échouer pour une multitude de raisons. L’exemple d’action donné par Github pour ce référentiel n’a pas dépassé le démarrage : il ne peut même pas localiser gradlew
pour exécuter la construction.
Une erreur étrange étant donné que cela devrait fonctionner immédiatement, mais une recherche rapide du problème révèle que nous devrions probablement utiliser le bon gradle-build-action
et configurez manuellement la version et les arguments.
Pour modifier la configuration de votre action, rendez-vous sur vos actions et cliquez sur le .yml
fichier sous le nom du flux de travail pour afficher l’éditeur.
Ensuite, vous pouvez le corriger si nécessaire et le valider à nouveau. Commettre des modifications à build.yml
compte comme un engagement à master
il déclenchera donc à nouveau l’action.
Cette fois, cela fonctionne correctement, bien qu’il ait de nouveau échoué à cause d’une petite erreur – ce référentiel veut Gradle 7.1, pas 6.5. Vous devrez résoudre tous ces problèmes pour le pipeline de construction que vous utilisez, afin qu’il corresponde parfaitement à la construction que vous feriez manuellement sur votre machine.
Utilisation de vos artefacts de construction
Une fois que tout est trié, nous voyons enfin la coche verte du succès.
Sauf que ce n’est pas vraiment une construction utile – où sont les artefacts de construction ? Par défaut, cette action crée simplement le référentiel et ne rend aucun élément de sortie disponible.
- name: capture build artifacts uses: actions/upload-artifact@v2 with: name: Artifacts path: build/libs/
Exécuter à nouveau la génération télécharge correctement les artefacts.
Si vous souhaitez que ceux-ci soient automatiquement téléchargeables, vous souhaiterez modifier l’action à exécuter chaque fois qu’une balise de publication est créée sur Github, puis publier sur les packages Github à l’aide de votre jeton (qui est transmis en tant que variable d’environnement).
on: release: types: [created] ... - name: Publish to GitHub Packages uses: gradle/gradle-build-action@4137be6a8bf7d7133955359dbd952c0ca73b1021 with: arguments: publish env: USERNAME: ${{ github.actor }} TOKEN: ${{ secrets.GITHUB_TOKEN }}