Modèles GitHub Actions privés pour votre organisation

GitHub Actions est le petit nouveau dans le domaine de l’intégration et du déploiement continus (CI/CD), mais il surpasse rapidement les serveurs d’automatisation open source traditionnels. Depuis un certain temps, l’équipe de développement de Sinch Mailgun sait que certains des outils et technologies utilisés pour la configuration voient leur communauté se réduire, et risquent de devenir trop spécialisés pour être raisonnablement maintenus. C’est pour ces raisons que nous effectuons actuellement une migration de notre système CI/CD basé sur Jenkins vers le CI/CD de GitHub Actions. En toute transparence : parfois, certaines fonctionnalités manquent à l’appel, à moins que vous ne soyez un client GitHub Enterprise…

Si je dis cela, c’est parce que, jusqu’à très récemment, les modèles de flux de travail dans les dépôts privés n’étaient pas pris en charge, ce qui nous a obligés à utiliser une solution de contournement. Heureusement, GitHub a récemment publié une mise à jour qui prend désormais en charge cette fonctionnalité pour ses abonnements Enterprise. Mais pour les personnes utilisant les abonnements Free ou Team de GitHub, le problème persiste. Nous ignorons si, et quand, GitHub déploiera cette mise à jour pour d’autres abonnements. En attendant, voici ce que nous avons vécu et la manière dont nous avons résolu le problème.

Mon expérience préalable avec GitLab CI a facilité mon apprentissage de GitHub Actions, mais les détails plus subtils se sont avérés différents. Par exemple, l’inclusion d’un ensemble d’étapes d’un projet dans un autre est très différente. GitHub Actions et GitLab CI prennent tous deux en charge la réutilisation d’étapes d’un dépôt à un autre, mais les abonnements Free et Team de GitHub Actions exigent que les étapes à inclure soient accessibles publiquement. Dans GitLab CI, on peut utiliser l’authentification pour importer les tâches, étapes, variables, etc. d’un dépôt privé à l’aide de la directive includes directive.

Au moment de la rédaction de cet article, GitHub Actions comptait plusieurs tickets (en fait, deux) pour le suivi de cette fonctionnalité très attendue concernant les dépôts privés. Ces tickets étaient ouverts depuis près de 18 mois et la fonctionnalité vient tout juste d’être ajoutée pour les abonnements Enterprise. Je ne sais pas quand (ni si) cette fonctionnalité sera disponible pour tout le monde, mais il s’agit d’une fonction essentielle pour prendre en charge la réutilisation privée des flux de travail.

J’ai parcouru les publications de Stack Overflow et creusé les fils de discussion des tickets GitHub, mais je n’ai trouvé aucune solution de contournement satisfaisante pour pallier l’impossibilité d’inclure des flux de travail d’autres dépôts privés au sein d’une même organisation. 

J’ai pensé que les sous-modules git pourraient constituer une solution envisageable. Après tout, cela permet à un dépôt d’en inclure un autre. Pouvions-nous inclure nos modèles de flux de travail en tant que sous-module dans notre dépôt et utiliser la gestion des sous-modules de git pour maintenir les modèles à jour ? C’était possible, mais pas si nous voulions conserver des modèles non pertinents pour certains dépôts dans le dépôt de modèles. Git considère un dépôt comme la plus petite unité dans la gestion des sous-modules. Notre solution consistait donc à disposer d’un dépôt contenant uniquement les flux de travail pertinents, ou à éviter complètement d’utiliser les sous-modules.

Nous avons choisi de ne pas utiliser de sous-modules, car nous souhaitions qu’un seul dépôt de flux de travail contienne des modèles Go et Python (entre autres), mais cette réflexion m’a permis de recueillir des informations précieuses. Certaines l’utilisation de liens symboliques pour inclure des parties d’un dépôt dans un autre au lieu de sous-modules.

Nous avons donc essayé de lier notre modèle au flux de travail de notre application. ln $DIR/workflows/go/build_and_push.yml $DIR/my-app/.github/workflows/build_and_push.yml fonctionne pour maintenir notre modèle de flux de travail en synchronisation avec notre application… jusqu’à ce que nous exécutions une commande git qui modifie le modèle (git change les inodes des fichiers qu’il modifie). Puisque nous voulions pouvoir utiliser la commande git pull pour obtenir les mises à jour des modèles, il nous fallait trouver un moyen d’appliquer automatiquement les modifications du dépôt de modèles au fichier d’une application.

En l’absence de fonctionnalité native pour inclure des modèles privés dans nos flux de travail et face à notre désir d’avoir un dépôt unique stockant nos modèles de flux de travail, nous avons opté pour cette solution simple qui permet d’optimiser la facilité d’application des mises à jour de modèles. En attendant que les abonnements Free et Team de GitHub prennent en charge les modèles privés, vous pouvez migrer, mais voici une solution possible que nous avons essayée et testée.

Nous incluons des exemples de hooks git dans notre dépôt de modèles (par ex., hooks/post-checkout.sample), car toute commande git susceptible de rompre des liens doit également les rétablir. Les hooks pour post-checkout et post-merge ressemblent à ceci :

                                

                                    #!/bin/sh
#
# An example hook script to keep your application workflow up-to-date with this
# template. For example, this updates my-app's workflow with the go template.
#
# To activate, this must have execute permission and be copied like so:
#
# $ cp hooks/post-checkout.sample .git/hooks/post-checkout
# $ chmod +x .git/hooks/post-checkout

# setup our project directory, assumes my-app is sibling
export PROJ_DIR=..
# remove existing workflow for clean install
rm $PROJ_DIR/my-app/.github/workflows/build_and_push.yml
# link app workflow to template
ln -v $PROJ_DIR/workflows/go/build_and_push.yml $PROJ_DIR/my-app/.github/workflows/build_and_push.yml
                                
                            

git merge et git checkout sont des opérations courantes qui rompent les liens ; nous exécutons donc ce script après ces actions.

Ainsi, pour que les utilisateurs puissent appliquer des modèles de flux de travail à leurs applications, ils doivent :

1. Cloner notre dépôt workflows.
2. Modifier hooks/post-checkout.sample et hooks/post-merge.sample pour les adapter à leur(s) application(s).
3. Les copier dans leurs emplacements .git/hooks respectifs et leur accorder les autorisations d’exécution.
4. Effectuer un git checkout ou un git pull (git checkout master depuis la branche principale fonctionne).

Malheureusement, cela ne permet pas de maintenir le dépôt de modèles à jour de manière autonome, et nécessite une certaine interaction de la part des personnes responsables du projet pour adopter les mises à jour : après tout, les modifications doivent être appliquées au dépôt distant. Il est possible de le faire via les commandes suivantes :

                                

                                    # from the workflow templates repo
$ git pull
# from the project repo
$ git add .github/workflows/
$ git commit -m "upgrade workflow template"
$ git push
                                
                            

Ensuite, le flux de travail s’exécutera avec les modifications les plus récentes provenant du dépôt de modèles.

Puisque nous avons choisi d’optimiser la facilité d’application des modèles, nous avons dû faire d’autres compromis avec notre solution de contournement. Le plus évident est la configuration requise. Nous demandons aux utilisateurs d’organiser leurs dépôts d’une manière bien précise et de copier-coller manuellement des fichiers. Ces exigences entraînent une certaine fragilité, le système pouvant tomber en panne si des fichiers sont déplacés ou si les inodes changent sans que nous en ayons connaissance.

Cependant, cette solution de contournement présente un avantage intéressant. Nous avons découvert un ensemble d’outils et de scripts qui peuvent fonctionner dans un contexte générique. Nous avons créé un gestionnaire de paquets générique basé sur git, qui utilise des liens et des hooks git pour mettre à jour les fichiers entre différents dépôts git :

                                

                                    #!/bin/sh

# set paths/files (relative to workflows repo)
export TEMPLATE_DIR=.
export APP_DIR=../my-app
export DOCKER_TEMPL=go/Dockerfile
export WKFLW_TEMPL=go/build.yml

#remove files for clean install
rm $APP_DIR/Dockerfil $APP_DIR/.github/workflows/build.yml

# link app workflow to template
ln -v $TEMPLATE_DIR/$DOCKER_TEMPL $APP_DIR/Dockerfile
ln -v $TEMPLATE_DIR/$WKFLW_TEMPL $APP_DIR/.github/workflows/build.yml

                                
                            

Alors, pourquoi GitHub Actions ? Eh bien, notre système actuel nécessite des modifications, des pull requests, des déploiements et bien plus encore pour intégrer un nouveau service. De plus, en tant qu’utilisateur de GitHub Enterprise, nous disposons d’un quota important de minutes d’exécution dans GitHub Actions, et nous avons donc décidé d’évaluer cette alternative. 

Maintenant que nous utilisons GitHub Actions depuis un certain temps, voici mes conclusions :

Comme vous pouvez le constater, l’herbe n’est pas toujours plus verte ailleurs. Cependant, nous prédisons que GitHub, bénéficiant des ressources inépuisables de Microsoft, finira par distancer Jenkins à long terme. 

Bien que notre solution de contournement ne soit pas parfaite, elle fonctionne en attendant que GitHub prenne en charge les modèles privés pour les abonnements hors Enterprise. Si cela se produit, vous pourrez migrer vos modèles vers un dépôt unique. 

Cela dit, nous possédons un compte GitHub Enterprise, mais nous n’avons pas encore la possibilité d’activer la fonctionnalité de dépôt privé que GitHub vient d’ajouter. Nous essayons encore d’en déterminer la cause. En attendant, nous utilisons notre solution de contournement et vérifierons à l’avenir si nous pouvons accéder à cette nouvelle fonctionnalité. Restez à l’écoute !

Auteur·trice: Jacob Simonson Software Developer III at Sinch Mailgun