Il m’est arrivé une mésaventure très désagréable à la fin de l’année dernière concernant deux de mes dépôts open-source hébergés sur GitHub.com.
J’ai naïvement cru les informations de migration du service Travis-CI.org vers le service Travis-CI.com et ai effectivement migré les dépôts de « MédiaThèque » et de « l’Entrepôt ».
Quelle grave erreur !
Il faut dire que j’étais en confiance car les services du .org m’avaient bien aidé jusqu’à présent, d’autant plus qu’ils sont gratuits : pour un « hobbyiste » comme moi c’est une condition hyper importante.
Dans cet article, je vous propose, d’abord, de découvrir ma malheureuse expérience pour éventuellement vous permettre d’éviter de vous embarquer dans une situation similaire. Ensuite et surtout, je vous expliquerai comment j’ai résolu mon besoin pour le dépôt GitHub de l’« Entrepôt » grâce notamment aux « GitHub Actions », au module Node @wordpress/env et en m’inspirant du projet Gutenberg.
Mise à jour : le support de Travis-CI.com m’a répondu 😅. Voici la traduction de leur réponse.
Au fait, c’est quoi l’Intégration Continue (signification du CI dans Travis-CI) ?
J’ai découvert l’intérêt de ce procédé en contribuant au projet open-source BuddyPress, l’extension de WordPress qui dynamise vos sites communautaires. Nous – j’écris « nous » car je fais partie de son équipe de développement depuis janvier 2014 et j’ai été promu comme l’un de ses développeurs en chef en septembre 2020 – l’utilisons pour automatiser une série de tests qui s’exécutent à chaque fois que nous validons la modification du code du projet (autrement dit à chaque « commit »).
Le grand intérêt concernant les tests unitaires de PHP c’est qu’il est possible de définir des matrices pour enchaîner ces tâches en combinant les versions de PHP et de WordPress. Dans notre cas, nous testons BuddyPress avec les versions 5.6, 7.2, 7.3 et 7.4 de PHP et les versions 4.9 à « Trunk » (version de développement) de WordPress. Ainsi, lorsqu’un ou plusieurs tests unitaires échouent, ça nous permet d’identifier la ou les versions concernées et d’adapter notre code pour maintenir une rétro-compatibilité conforme à la définition de la configuration requise de BuddyPress.
Il peut également arriver que des tests échouent sur la version de développement de WordPress (se reporter à cet exemple récent), cette alerte nous permet d’anticiper un changement à venir dans WordPress et de prévoir sa prise en compte dans une nouvelle version de BuddyPress. Voici, pour illustrer ce propos, le résultat d’un des « builds » de l’extension communautaire. Pour en savoir plus sur l’intégration continue ou le déploiement continu, je vous invite à lire cet article.
Migrer, mais quelle idée ?
Ça peut effectivement surprendre : pourquoi migrer d’un service qui nous satisfait et partir à l’aventure sur un service qui, certes, se veut la version professionnelle du premier, mais dont on ignore tout ?
Veuillez noter que Travis-CI.org fermera dans plusieurs semaines, et migrera tous les comptes vers Travis-CI.com. Veuillez rester à l’écoute ici pour plus d’informations.
Travis-CI.org
Le fait déclencheur est ce message d’alerte qui est apparu sur le site Internet Travis-CI.org. Le destin du .org est tout simplement de disparaître et comme vous pouvez le lire, si vous ne faites rien, vos dépôts seront automatiquement migrés sur Travis-CI.com. Aussi, j’ai pensé qu’avant d’envisager une telle migration pour BuddyPress, la tester avec mes dépôts open-source personnels nous permettrait de nous assurer que c’était la bonne solution.
Avant de tester cette migration, je me suis documenté pour comprendre ses implications. En particulier, j’ai cherché à savoir si migrer vers Travis-CI.com rendait le service dont nous bénéficions sur Travis-CI.org payant.
Q. Travis-CI.com se débarrassera-t-il des utilisateurs « libres » provenant de Travis-CI.org ?
Travis-CI.com
R. Travis CI continuera d’offrir un niveau gratuit pour les dépôts publics ou open-source sur Travis-CI.com qui ne seront pas affectés par la migration.
Ci-dessus, je vous ai mis la traduction de l’information la plus importante de la foire aux questions dédiée à cette migration qui est disponible sur le site Travis-CI.com. Si toutefois, d’ici à votre lecture, cette information avait été modifiée, j’ai pris la précaution de copier son état tel qu’il était au moment où je l’ai consultée.
J’ai donc compris que comme les dépôts de « MédiaThèque » et de « l’Entrepôt » sont à la fois publics et open-source (tout comme BuddyPress, d’ailleurs), je pouvais, sans risque, appuyer sur le bouton de migration, le maintien de la gratuité du service semblant être prévu.
Une procédure de migration ultra simple et un service qui fonctionne, pourvu que ça dure…
J’ai donc cliqué 😱.
Tout s’est parfaitement déroulé : après quelques étapes comme la sélection des dépôts devant être migrés sur Travis-CI.com, c’était en place.
Les validations de modification de code que j’ai réalisées ensuite étaient bien testées sur l’infrastructure de Travis-CI.com et ce beaucoup plus rapidement que sur celle de Travis-CI.org ! Trop cool. Je ne me doutais pas à l’époque que ces réjouissances seraient de courte durée.
J’ai très vite fait la connaissance de « Montana from Travis CI », lequel me sollicitait régulièrement par courriel pour partager avec moi des astuces, ou m’informer sur les avantages de l’offre payante.
Crédits épuisés, fin de la partie.
Et puis, un soir, je me suis aperçu que les tests unitaires ne s’effectuaient plus. Lorsque j’ai consulté l’espace des réglages de mes dépôts sur le site de Travis-CI.com, une alerte me demandait de vérifier mon compte car ses crédits étaient épuisés. Dans l’interface de mon compte, il m’était suggéré de le mettre à niveau pour un plan supérieur afin de continuer à bénéficier du service. Sauf que je ne peux pas me permettre de payer 69$ par mois pour financer l’automatisation de tests unitaires d’un ou deux dépôts GitHub, ce n’est pas raisonnable.
J’ai alors remarqué que l’interface intégrait un deuxième onglet pour les crédits réservés aux projets open-source. Après l’avoir activé, je me suis rendu compte que ce type de crédit était lui aussi à 0. J’ai d’abord pensé qu’il y avait un quota mensuel et que je l’avais dépassé. Seulement comme l’interface m’indiquait que le rechargement des crédits « open-source » était systématiquement prévu le même jour que la date courante et que rien ne se passait jamais, j’ai fini par envoyer un courriel au service support pour demander des explications le 28 décembre 2020.
J’ai reçu une réponse automatique de prise en compte contenant la référence de ma demande (ticket Zendesk numéro 25044) qui était signé de « Mes amis @Travis-CI ». Comme j’utilisais une offre gratuite, je me suis dit que les explications n’arriveraient pas rapidement, il ne me restait plus qu’à patienter.
Pendant ce temps là, « Montana from Travis CI » s’en donnait à cœur joie ! Il n’arrêtait pas de m’envoyer des courriels publicitaires. Ça a commencé à sévèrement m’agacer car, à chaque fois, je croyais que c’était la réponse à ma demande de support. Une semaine après mon premier courriel, il m’a écrit pour me dire que je n’avais pas encore testé la génération manuelle des tests et m’a invité à le faire. Sauf que, vu que mon crédit était scotché à 0, ce n’était pas possible 😡. Ce jour là, j’ai eu besoin de me défouler : un clic rageur sur le lien de désabonnement m’a fait du bien.
Le 23 janvier 2021, ma situation n’ayant pas évoluée, je me suis replongé dans la documentation du service et je suis tombé sur cette autre foire au question au sujet de la facturation des services.
Chacun des plans de Travis CI contient une quantité de crédits mensuels réservés aux projets open-source qui ne sont affectés qu’à l’exécution de builds de dépôts publics. Pour en savoir plus, veuillez contacter l’équipe d’assistance Travis CI. Dans l’e-mail, veuillez inclure : votre nom de compte et votre fournisseur VCS (comme travis-ci.com/github/[nom de votre compte]), le montant de crédits (minutes de création) que vous souhaitez demander (si celui-ci ne s’avère pas suffisant, vous pourrez répéter le processus pour en demander plus ou pour rediscuter d’un montant renouvelable).
Travis-CI.com
Ci-dessus, je vous ai mis la traduction de l’information la plus importante de cette nouvelle foire aux questions. Si toutefois, d’ici à votre lecture, cette information avait été modifiée, j’ai pris la précaution de copier son état tel qu’il était au moment où je l’ai consultée.
J’ai alors mis à jour mon ticket de support en répondant à la confirmation de prise en compte que j’avais initialement reçu, conformément à ce que cette confirmation précisait dans un tel cas. Ma réponse intégrait donc mon nom de compte, une demande de 10000 crédits par mois et un texte complémentaire expliquant que je commençais à me demander s’ils se décideraient à respecter ce qu’ils écrivaient dans la documentation de leur service…
Les aventuriers de la tribu ont décidé de vous éliminer et leur sentence est irrévocable !
Le 6 février 2021, j’ai compris que je ne recevrais jamais de réponse de Travis-CI.com. J’ai donc supprimé toutes les autorisations accordées à leur service dans les réglages de mes dépôts et de mon profil sur GitHub. Je leur ai également envoyé un dernier courriel pour leur exprimer ma déception.
Suite à cette expérience, et si, vous aussi, vous utilisez le service Travis-CI.org, je vous suggère de ne pas attendre la dernière minute pour trouver une alternative à ce service afin d’éviter d’être leurrés par l’offre soi-disant « gratuite » de Travis-CI.com. Je l’ai personnellement vécu comme une imposture et rien ne garantit que vos projets open-source ne subissent le même sort que les miens. Alors…
Migrons vers les « GitHub Actions ».
Dans le cadre du projet BuddyPress, nous n’avons pas attendu jusqu’au 6 février pour commencer à réfléchir à une alternative à Travis-CI.org. Lors d’une de nos réunions de développement, après avoir fait part à l’équipe de mes inquiétudes concernant notre intégration continue par rapport au prochain arrêt des services du site Travis-CI.org au profit d’un service équivalent mais manifestement payant, nous sommes tombés d’accord pour travailler à la mise en place d’actions GitHub en remplacement. Cela nous est apparu d’autant plus adapté que le projet WordPress s’est également orienté vers cette solution.
Nos échanges d’alors ont éveillé ma curiosité sur cette fonctionnalité d’intégration continue de GitHub. Aussi, lorsque je trouvais un moment, j’ai commencé à parcourir sa documentation, et surtout la manière dont les projets WordPress et Gutenberg élaborent leur fichier d’instructions pour déclencher ces « GitHub Actions ».
S’agissant de la documentation des actions de GitHub, je vous conseille de consulter le chapitre dédié à la migration de votre intégration continue depuis Travis avant de vous rendre sur celui qui présente comment doivent être stockés et rédigés les fichiers d’instructions dans votre dépôt GitHub.
Avant de me lancer dans la rédaction de ce fichier d’instructions pour mon extension « Entrepôt », une étape préalable a consisté à choisir une stratégie pour récupérer la version de développement de WordPress laquelle contient, en particulier, le répertoire tests/phpunit, la classe WP_UnitTestCase et les fonctions nécessaires à l’installation de WordPress et à l’activation en tant qu’extension « must use » de l’« Entrepôt » (ou de toute autre extension désireuse de mettre en place des tests unitaires, d’ailleurs).
Si je pouvais reproduire ce que je faisais via la configuration de Travis en clonant le répertoire GitHub de WordPress, en créant le fichier de configuration des tests, etc.., avant de cloner celui de mon extension, mes travaux de contribution dans la mise en place du nouvel environnement de développement de BuddyPress basé sur Docker m’ont permis de découvrir qu’on pouvait simplifier énormément la mise en place de l’intégration continue des tests unitaires PHP.
Facilitez leur la contribution et simplifiez vous l’automatisation de vos tests unitaires grâce à « @wordpress/env »
Le projet Gutenberg, en plus de fournir un nouvel éditeur de contenu (et prochainement une nouvelle expérience d’édition complète de nos sites WordPress), partage avec la communauté des modules Node.js très intéressants pour les développeurs d’extensions. Il y a par exemple le module « @wordpress/scripts » qui vous permet, entre autres, d’améliorer le format et la performance de vos fichiers JavaScript et de vos styles CSS et plus particulièrement pour notre besoin le module « @wordpress/env ».
Grâce à ce deuxième module, et après avoir satisfait ses dépendances (Installation de Node.js et de Docker), vos contributeurs n’aurons plus que deux commandes à lancer une fois qu’ils auront cloné le répertoire GitHub de votre extension, et du moment que Docker s’exécute en arrière plan, avant de pouvoir jouer avec votre extension dans un site WordPress de test disponible à l’URL http://localhost:8888 :
npm install
npm run wp-env startComme je le disais plus tôt, depuis la version 6.0.0 de BuddyPress, nous avons intégré un tel environnement à notre dépôt : notre codex propose un tutoriel détaillé (en anglais) sur la manière de l’installer pour celles et ceux souhaitant des compléments par rapport à ma description un peu expéditive dans cet article.
Un des intérêts de cet environnement est que vous pouvez personnaliser sa configuration à l’aide du fichier .wp-env.json et définir ainsi sa version de WordPress, de PHP, les extensions à installer (exemple : nous incluons l’extension BP REST à l’environnement de développement de BuddyPress) en plus de celle de votre dépôt GitHub et d’autres constantes WordPress.
Pour l’embarquer dans vos outils de développement, il suffit de l’ajouter dans les dépendances de développement de votre fichier package.json comme je l’ai fait pour l’extension « Entrepôt » et d’ajouter dans sa propriété scripts une ligne pour référencer la commande wp-env.
Lorsqu’on souhaite lancer des tests unitaires dans cet environnement, il est nécessaire d’ajouter d’autres dépendances de développement à l’aide de l’outil Composer : les paquets wp_phpunit/wp_phpunit et la version 7.5.20 du paquet phpunit/phpunit. Ce deuxième paquet nous permettra de nous assurer que WordPress sera en mesure de jouer les tests quelque soit la configuration de la machine virtuelle.
En effet WordPress n’est pas compatible avec les versions ultérieures de PHPUnit qui pourraient être installées sur la machine virtuelle qui sera utilisée par les « GitHub Actions ». Pour intégrer ces dépendances installables via l’outil Composer, il suffit de les ajouter dans le fichier composer.json comme je l’ai fait pour l’« Entrepôt ». Pensez enfin à installer localement ces dépendances à l’aide de la commande suivante :
composer installLe dernier préalable consiste à ajouter deux lignes de commande dans la propriété scripts de votre fichier package.json pour référencer les commandes qui exécuteront les tests sur un WordPress classique et un WordPress Multisite. De cette manière, après s’être assuré que Docker s’exécute en arrière plan et avoir lancé l’environnement à l’aide de la commande npm run wp-env start, il est possible de lancer les tests unitaires localement pour éventuellement ajuster le fichier de démarrage ou « bootstrap » de votre suite, comme j’ai pu le faire dans cette modification.
S’inspirer des actions de WordPress et de Gutenberg pour rédiger le fichier d’instructions de notre « GitHub Action ».
Si vous avez lu la page de la documentation que j’ai partagée plus tôt, vous savez que ce ou ces fichiers (en cas d’actions multiples) sont à écrire au format YAML en respectant une structure spécifique et à déposer dans le répertoire .github/workflows/ de notre dépôt GitHub.
Comme c’est toujours un peu délicat de partir d’une feuille blanche, j’ai pris le parti (et je vous conseille de le faire aussi) de m’inspirer des travaux réalisés par les contributeurs de WordPress et dans le cas présent du projet Gutenberg car ce dernier utilise le module « @wordpress/env » pour déclencher ses tests unitaires PHP dans sa « GitHub Action ».
Comme dans ce fichier une seule version de PHP est testée, j’ai complété mon observation par le fichier d’instructions utilisé par WordPress pour mettre en place ma matrice de versions de PHP à tester.
Pour en savoir plus sur la syntaxe à utiliser dans votre fichier d’instructions, je vous recommande de parcourir cette page de la documentation des « GitHub Actions » : elle contient de nombreux exemples pour vous aider à vous familiariser avec cet outil d’intégration continue et vous permettra d’affiner les évènements qui déclenchent votre action, les tâches (« jobs ») à effectuer dans votre action, les possibilités d’y intégrer des actions développées par la communauté ainsi que leur découpage en étapes (« steps »).
Point important par rapport à mon besoin de tester différentes versions de PHP lors du déroulement de mon action : pour assurer le changement de la version PHP de l’environnement de développement basé sur « @wordpress/env », j’ai utilisé la variable d’environnement reconnue par wp-env pour informer sur l’image Docker de WordPress à utiliser : WP_ENV_PHP_VERSION.
L’intégration continue de l’« Entrepôt » est migrée et fonctionne à nouveau !
Pour ne retenir que le positif de cette expérience, l’indifférence totale de Travis-CI.com par rapport à ma demande de support m’a permis de surmonter l’obstacle des changements techniques à mettre en œuvre, lesquels, sont toujours des freins à la sortie d’un service. J’ai pu découvrir tout l’intérêt des actions de GitHub dont je n’avais entrevu que la possibilité de déploiement d’une extension, à partir de son dépôt GitHub, sur le répertoire officiel des extensions de WordPress.
L’enregistrement de nouvelles extensions, thèmes ou blocs dans l’« Entrepôt », lequel repose sur la rédaction de « Pull Requests », a retrouvé les vérifications automatiques qui me font gagner un temps précieux.
15/04/2021 la réponse que je n’attendais plus!
Veuillez accepter nos sincères excuses pour tout inconvénient causé par les retards dans le traitement de votre demande de crédit open-source pendant que nous apportions des améliorations à la plate-forme. L’open source a toujours été et sera toujours au cœur de ce que Travis CI représente. Après avoir examiné vos qualifications Open Source, j’ai le plaisir de vous informer que 25 000 crédits ont été ajoutés à votre compte, vous permettant de reprendre l’exécution des versions OSS. Lorsque vos crédits commencent à s’épuiser à nouveau, veuillez contacter l’équipe d’assistance.
Mesure de consommation de crédits
OS. # CRÉDITS PAR MINUTE DE CONSTRUCTION COMMENCÉE
Linux. dix
FreeBSD expérimental. dix
Les fenêtres. 20
MacOS. 50
S’il vous plaît laissez-nous savoir si vous avez des questions!
Merci et bonne construction!
Travis-CI.com
Il semble finalement que la gratuité du service Travis-CI.com pour les projets open-source ne soit pas un leurre. Je n’ai pas vérifié par moi-même, ceci dit : je ne suis pas resté bloqué durant 4 mois et demi, j’ai préféré migrer sur les GitHub Actions… Tout est bien qui finit bien 😌