Je vous invite à partager vos réflexions sur d’éventuels workflows d’intégration continue (CI) qui exécuteraient des tests sur des plugins non officiels fournis par la communauté.
Certaines communautés dépendent fortement de plugins sans maintenance établie :
Étant donné que les tests de plugins dépendent d’une installation Discourse comme banc d’essai, je me demande à quoi pourrait ressembler un flux de travail d’intégration continue soutenu par la communauté.
Certains plugins incluent des spécifications, comme l’implémentation d’activitypub par @angus, qui, si je comprends bien, permettent les tests pour l’intégration continue.
Actuellement, je pense à deux façons possibles d’améliorer les tests des plugins non officiels, en fonction des spécifications / tests inclus dans la source du plugin :
a) construire une machinerie qui aide les mainteneurs de sites à exécuter des tests dans un environnement de staging
b) avoir un service qui duplique une image de test prédéfinie pour signaler les tests exécutés sur le dernier code publié du plugin.
En plus de l’intégration continue avec des tests backend et frontend, que la plupart des plugins Pavilion ont maintenant, nous avons un système de gestion de plugins dont l’intégration continue fait partie. Voici comment cela fonctionne
Qui affiche l’état des vérifications de compatibilité des plugins Pavilion (et parfois d’autres) par rapport à tests-passed et stable. Ceci est mis à jour chaque jour, automatiquement.
Cela repose bien sûr sur des tests, y compris des tests de fumée (smoke tests), des spécifications (backend) et des tests qunit (frontend).
Notre plugin d’abonnement (Custom Wizard) a la couverture de test la plus étendue, comme vous pouvez l’imaginer, mais certains de nos plugins gratuits incluent une bonne suite de tests backend et frontend (par exemple, Locations).
L’écriture de tests est une bonne pratique et Pavilion est certainement devenu encore plus discipliné dans ce domaine à mesure que nous avons mûri en tant qu’entreprise.
De manière critique, les tests documentent également la fonctionnalité prévue, ce qui est extrêmement important, en particulier lors des mises à jour de compatibilité ou du refactoring.
C’est une architecture selon le diagramme de @angus, avec plusieurs dépôts impliqués, mais voici le serveur de statut :
C’est aussi une approche :
Ne jamais implémenter une correction sans vérifier s’il existe un test, et si un test approprié n’existe pas, en ajouter un.
Idéalement, développer d’abord le test, montrer qu’il échoue, puis corriger le problème et confirmer que votre nouveau test réussit.
De cette façon, votre couverture s’améliore au fil du temps…
De plus :
La rétro-adaptation des tests peut être risquée car vous pourriez mal interpréter ce que le code avait l’intention de faire… mieux que de ne rien faire cependant…
Tous les plugins officiels ont des spécifications que vous pouvez utiliser comme exemples. Le plugin discourse-plugin-Skelton inclut des actions GitHub pour exécuter des tests à chaque commit, et je pense, quotidiennement.
a) Ceci est disponible via les actions GitHub : les plugins avec des spécifications / tests appropriés utilisant les actions GitHub auront un badge sur GitHub, si tous les tests réussissent et que l’état des actions CI est lisible par l’API.
b) À l’exception des plugins officiels de Discourse et des plugins de pavilion, il n’existe pas d’aperçu automatique pour les administrateurs, si les plugins utilisés fonctionneront dans la version prévue pour la mise à jour ?
D’après ce que je comprends, c’est une solution au problème inverse : Discourse trop ancien pour un plugin.
Comment traiter l’autre sens : plugin trop ancien pour Discourse ?
Est-ce que /admin/upgrade pourrait avertir des plugins qui échouent aux tests pour une mise à niveau prévue ?
Nous avions initialement l’intention de fournir une version non marquée de notre tableau de bord de plugins où les auteurs tiers pourraient présenter leurs plugins pour inclusion. Cela n’a pas pris, en partie parce que la population de développeurs de plugins tiers est très restreinte.
La création de plugins tiers pour Discourse est assez spécialisée et les tiers fournissant des plugins avec une bonne couverture de tests est très spécialisée !
Beaucoup de freelances dans ce domaine ont rejoint Pavilion ou CDCK (ou, avec le temps, les deux !)
Nous avons donc finalement décidé de fusionner notre tableau de bord dans notre site communautaire marqué.
