Allez les amis, comme promis, quelques détails sur les activités du groupe Apps.
Et comme, je n’ai pas la motivation de tout vous dire ce soir, et que je pense qu’il faudra un peu de temps pour tout assimiler. On va démarrer un feuilleton 
Toutefois, je mettrais à jour le premier post régulièrement pour les prochains.
Alors tout d’abord, bienvenu à nos nouveaux membres dans le groupes Apps, @frju365, @JimboJoe et @maxime.
Et la première étape pour parfaire votre entrée dans le groupe sera simplement de signer un petit document sans importance avec une goutte de sang. Pas d’inquiétude, rien d’important, ce sera sans conséquence sur votre vie 
Première responsabilité en tant que membre du groupe App, la veille:
Suivre les sections Apps et Apps packaging du forum pour être informé de tout ce qui s’y passe.
Ce qui n’implique pas de répondre à tout les messages bien sûr, mais au moins de se tenir informer pour être en mesure de suivre l’actualité du packaging. Ça évolue très vite !
Suivre la section Apps sur redmine
https://dev.yunohost.org/projects/apps
Ainsi que les quelques issues perdues dans les autres sections, comme celles-ci:
https://dev.yunohost.org/issues/621
https://dev.yunohost.org/issues/799
En général des bugs qui touchent le packaging, mais qui concernent le code du core.
Ce genre de bug passent sur le salon dev, c’est un bon moyen de les repérer.
Suivre ce qui se passe (de loin au moins) sur l’organisation YunoHost-Apps pour les apps communautaires, il n’est pas nécessaire (heureusement) de suivre tout ce qui s’y passe.
En revanche, il important de suivre les apps officielles pour lesquelles nous devons maintenir un niveau de qualité et que nous devons maintenir à jour.
Surveiller également quelques autre dépôts liés au packaging:
- Le dépôt apps pour les listes d’apps principalement (On en reparlera plus tard)
- Package check, notre outil de test unitaire pour les applications.
- CI_package_check, la base de notre intégration continue. Qui peut également être utilisée par les packageurs pour leurs propres apps.
- Package linter, notre analyseur statique, qui est utilisé par Package check.
- L’app d’exemple, la base pour commencer un package.
- Le dépôt YunoHost dans une certaine mesure, pour la partie concernant les helpers.
Surveiller régulièrement aussi yunodash, pour connaître la situation de la liste officielle par rapport aux dépôts d’apps. (Mais on en reparlera)
Et s’abonner à la mailing list Apps, qui ne risque pas de vous spammer…
Et enfin, être présent (dans la mesure du possible, cela va de soit) sur le salon xmpp Apps au moins, et éventuellement sur le salon xmpp Dev.
Bien entendu, tout cela est conditionné à votre disponibilité. Il n’est pas demandé d’être présent en permanence, nous avons tous d’autres choses à faire.
Seconde responsabilité du groupe Apps, les décisions:
Pour ne pas paraphraser, je vous invite tout d’abord à lire notre méthodologie de prise de décision (Et même tout le document par la même occasion si vous ne le connaissiez pas).
En sommes, ce qu’il faut en retenir, c’est qu’une décision doit être validée par plusieurs personnes.
Ce faisant, en tant que membre du groupe Apps, nous avons la responsabilité de s’intéresser aux décisions qui sont initiées et qui concernent le groupe et de donner un avis.
Pour les discussion sur le forum (Ça arrive), ce n’est en général que donner son avis. De même pour l’intégration d’un nouveau membre, qui sera débattue en privé sur le forum.
Mais on trouvera surtout des décisions à prendre sur github, sur les différents dépôts à surveiller.
Chaque PR, en fonction de son importance sera soumise à une prise de décision du groupe.
Votre avis sera requis (Si vous êtes disponible pour le faire), mais devra être réfléchi. Autrement dit, avant de valider une PR, il est nécessaire de bien lire le code et de le comprendre. Quitte à dire simplement que vous n’avez pas d’avis si le sujet vous dépasse.
- Les dépôts package check, CI_package_check et package linter sont en général validé en micro décision, pour la simple raison qu’il n’ont qu’un seul contributeur principal.
- L’app d’exemple devra systématiquement être discutée et validée, car elle n’est pas critique, mais elle aura des conséquences sur tous les nouveaux packages
- Il en de même pour les helpers, qui doivent toujours être discutés car leur usage se répercute directement sur les packages. Et un helper déjà utilisé doit être modifié avec parcimonie.
- Enfin le dépôts Apps, de loin le plus actif en la matière, présentera différents cas.
- Les mises à jour de la liste communautaire peuvent en général être validé en micro décision, à partir du moment ou l’auteur de la PR modifie ses propres apps.
- Les mises à jour de la liste officielle seront en revanche toujours validée par le groupe, afin d’assurer la qualité des applications officielles.
- Enfin, nous trouverons ici les décisions pour ajouter une nouvelle application officielle, qui doit subir un examen approfondis afin de s’assurer que l’application respecte toutes les YEPs requises.
- Pour les autres PR, ce sera au cas par cas.
N’oublions pas que ce qui permet de faire avancer YunoHost, c’est notre réactivité sur ces prises de décision, et ce qui fait sa qualité, c’est notre attention et notre vigilance sur ces décisions.
Fonctionnement des listes d’applications.
Il ne s’agit pas d’une responsabilité du groupe Apps, seulement de détails intéressant à connaître pour comprendre comment tout cela fonctionne.
Le sujet n’étant pas parfaitement maîtrisé, vous m’excuserez d’éventuelles erreurs. Et le cas échéant, vous êtes invités à les corriger.
Commençons déjà par la base, que nous connaissons, les listes d’applications sont les listes community.json et official.json, toutes deux basées sur le même modèle:
"NOM DE L'APPLICATION": {
"branch": "BRANCHE À UTILISER",
"level": NIVEAU DE L'APP,
"revision": "COMMIT À UTILISER",
"state": "ÉTAT DE L'APP",
"url": "ADRESSE DU DÉPÔT GITHUB"
},
- La branche sera en général master, mais c’est à vous de voir.
- Le level sera (plus tard) affiché à divers endroit pour donner de la visibilité sur cette information. Pour le moment cette information n’est pas utilisée.
Toutefois, il est a noté que le niveau est calculé par l’intégration continue, qui se chargera de mettre à jour cette information dans les listes. Donc il est inutile de changer cette information manuellement. - La ‘revision’ est donc le commit cible, qui sera utilisé lors de l’installation et qui permet également de connaître la date de dernière mise à jour. Nous en reparlerons par la suite.
- ‘state’ est simplement l’état de l’application,
working,inprogressounotworkingselon l’état d’avancement de l’application.
Pour
validateden official, je ne sais pas…
- Enfin url est simplement l’adresse du dépôt github du package.
Toutefois, les listes d’applications ne sont pas utilisées directement en l’état, ce format json est seulement destiné à notre usage.
Le serveur, tartare, vérifie toutes les 5 min si les listes doivent être mise à jour à l’aide du script should_i_rebuild.sh.
Le cas échéant, il exécute le script list_builder.py qui construira à partir de la liste json un nouveau fichier json contenant les infos déjà présentes ainsi que la date de dernière mise à jour et le contenu du manifest.
C’est ce second fichier json, accessible sur https://app.yunohost.org qui sera utilisé par la documentation ainsi que l’admin web et la moulinette.
Les helpers et le core
Le core de YunoHost n’est pas de la responsabilité du groupe Apps. Toutefois, il peut arriver parfois qu’on décèle un bug qui touche les applications et qu’on sache comment le régler.
Dans ce cas bien évidemment, on ne se prive pas pour corriger le bug, nous somme dans une communauté libre. MAIS, une communauté qui a une méthode de fonctionnement, donc il y a plusieurs règles à respecter si vous touchez au core.
- La première règle est tout d’abord de travailler sur la branche unstable uniquement. Avant de faire une quelconque modification, veillez à bien vérifier la branche sur laquelle vous vous trouvez !
- La seconde règle est très simple, vous faites une Pull Request sur unstable, et vous demandez l’avis du groupe Dev Core.
- Et la 3e règle est encore plus simple, vous ne mergez en aucun cas ! Seul le groupe Dev Core est habilité à le faire, alors on va en discuter avec eux, on supplie, on lè*** quelques c*** et on attends. C’est frustrant, je sais…
Il existe UNE exception à la 3e règle, c’est les helpers, les helpers bénéficient d’une responsabilité partagée entre les groupes Apps et Dev Core. Donc il est possible de merger une PR d’un helper vous-même, en respectant les règles habituelles de prises de décisions.
Parlons d’avantages des helpers.
Les helpers sont simplement des fonctions bash, que nous chargeons dans les scripts par la commande source /usr/share/yunohost/helpers
Pour le détail technique,
/usr/share/yunohost/helpersest simplement un script qui va se charger d’inclure tout les fichiers de fonctions contenu dans/usr/share/yunohost/helpers.d/
Les helpers sont de la forme suivante:
# Description rapide du helper
#
# example: Exemple d'usage du helper
# example: var=$(ynh_helper arg1)
# example: ynh_helper arg1
#
# usage: Description normalisée de l'usage du helper
# usage: ynh_helper needed_arg1 needed_arg2
# usage: ynh_helper needed_arg1 [optionnal_arg1]
# | arg: Nom de l'argument - Description de l'argument
# | arg: needed_arg1 - Premier argument
# | arg: needed_arg2 - Deuxième argument
# | arg: optionnal_arg1 - Argument optionnel
ynh_helper () {
[...]
}
Les helpers doivent être simple d’usage, n’hésitez pas à proposer des helpers qui utilisent d’autres helpers pour les rendre encore plus simple. Il faut garder à l’esprit la clarté du code et la factorisation pour rendre les helpers facile à comprendre et facile à maintenir.
Un maître mot, la simplicité, plus nous avons des helpers bien conçus et efficace, plus le packaging devient simple et accessible. Et plus le packaging est simple, moins les packageurs auront à se soucier des spécificités de YunoHost pour adapter une application. Et nous aurons ainsi d’autant plus d’applications disponibles pour YunoHost.
L’autre intérêt d’utiliser des helpers, c’est qu’ils limitent l’obsolescence des applications, car nous pouvons ainsi adapter les helpers déjà utilisés plutôt que demander à chaque packageur de s’adapter à une nouvelle règle.
Pour terminer, si un helper est ajouté, n’oubliez pas de l’ajouter à la documentation. Car un super nouveau helper qui n’est pas utilisé, c’est dommage… 
La documentation autour du packaging
Nous allons parler pour une majeure partie de la doc existante, donc cet épisode deviendra obsolète avec le temps.
La doc du packaging commence ici avec la page principale, qui explique comment faire un package. Si ce n’est déjà fait, je vous encourage à aller lire toute cette documentation et ses liens.
Mais attardons nous d’avantage sur quelques pages spécifiques de la doc qu’il est bon de connaître.
Tout d’abord, pour commencer par le début, nous disposons d’une page de documentation spécifique pour les débutants en packaging, qui ne connaissent pas du tout le développement.
C’est un point de départ pour les contributeurs très débutant.
https://yunohost.org/#/packaging_apps_start_fr
Un autre point qui semble souvent porter à confusion et la gestion du multi instance par YunoHost, nous disposons d’une documentation qui en explique le fonctionnement.
https://yunohost.org/#/packaging_apps_multiinstance_fr
Il y a également une doc très bien faite sur les possibilités offerte par le manifest.
https://yunohost.org/#/packaging_apps_manifest_fr
Plusieurs autres pages de documentation détaillent d’autres aspects du packaging.
Poursuivons avec trois pages très importantes, que vous aurez très souvent à consulter (et qu’il vaut mieux garder sous la main)
Le man des helpers
https://yunohost.org/#/packaging_apps_helpers_fr
C’est notre bible de l’usage des helpers en version facile à lire, comprendre par là sans avoir à aller fouiller dans les différents scripts de helpers pour trouver les commentaires d’usages.
Cette documentation devrait être maintenu à jour du mieux que nous pouvons, car elle sera sans doute un point de passage régulier des packageurs en quête de helpers.
Les niveaux des applications
https://yunohost.org/#/packaging_apps_levels_fr
Le détail de chaque niveau et chaque YEP qui doit être validée pour y parvenir.
Avant d’accepter une app à un niveau donné, même si le niveau a été validé par le serveur de CI, il est bon de venir vérifier sur cette page que tout les prérequis sont bien satisfait.
De la même manière, pour savoir comment faire pour qu’une app passe au niveau suivant, c’est ici qu’il faut venir trouver l’information.
Les YEP
https://yunohost.org/#/packaging_apps_guidelines_fr
Un bon gros morceau, qui nous permettra de savoir si une application respecte ou non les YEP requises à un niveau donné. Les YEP sont toutes détaillées ici.
Ce petit tour de la documentation autour du packaging n’avait rien d’exhaustif, mais c’était l’occasion de mettre le doigt sur certains pages importante. Et de nous rappeler au combien il est important que nous disposions d’une documentation clair, complète et à jour.
Il est beaucoup plus simple, pour nous comme pour les autres contributeurs de disposer d’une documentation bien écrite plutôt que de devoir décrypter le code source.
C’est par ici que ça passe, et n’oubliez pas de discuter avec les membres du groupe Communication avant de merger la documentation.
Fonctionnement de Package check (1ère partie)
Tout d’abord, pour éviter de paraphraser, je vous invite à lire le readme qui explique déjà tout ce qu’il y a savoir sur l’usage de package check.
Cela fait, nous pourrons nous attarder ce qui se passe vraiment sous le capot.
Le cas d’usage le plus fréquent étant l’usage via Jenkins, nous aborderons plus spécifiquement cet aspect.
Au démarrage, package check va se mettre à jour, par une méthode un peu bourrine consistant en un script qui se substitue au processus courant pour télécharger et remplacer les fichiers et relancer finalement package check.
Ensuite il va mettre à jour Package linter.
C’est un avantage et un inconvénient à la fois, les tests utilisent toujours la dernière version de Package check et Package linter, mais si une erreur se glisse dans le code, elle sera répercutée immédiatement.
Avant de démarrer un test, le conteneur LXC va être arrêté et restauré afin de s’assurer de travailler sur un conteneur sain.
Nous retrouverons l’arrêt du conteneur dans le script lxc_launcher.sh
La restauration du conteneur utilise rsync au lieu de lxc-snapshot pour accélérer travail, 10 à 20 secondes au lieu de 4 à 5 minutes. Car rsync va se contenter de remplacer seulement les fichiers modifiés.
L’app sera ensuite clonée depuis github avant d’être travaillée.
Il est important ici de noter que le dépôt est cloné qu’une fois au début de l’exécution, donc si l’app est modifiée après les tests n’en tiendrons pas compte.
A chaque nouveau test, l’application sera simplement copiée sur le conteneur.
Après ça, package check va parser le fichier check_process de l’application, si il est présent.
Le parsing n’est pas forcément optimal, le check_process va être lu ligne par ligne.
Je vous épargne les détails du parsing, mais le parser va se concentrer sur la première série de test, indiquée par ;;; et placer en mémoire la liste des tests à effectuer et le nom des arguments dont il va se servir pour installer l’application.
Il exécutera les tests avant de continuer le parsing sur les séries de tests suivantes.
Si l’application ne dispose pas d’un check_process, Package check va tenter de lire le manifest pour déterminer les tests qu’il peut faire et les arguments à utiliser.
L’exécution des tests eux-mêmes, par TESTING_PROCESS fera l’objet de notre prochain épisode (car il y a trop à dire…)
Considérons donc que toute les séries de tests sont terminées. Nous nous situerons donc juste après TESTING_PROCESS
La config réseau du conteneur LXC va être arrêtée avant de passer à l’affichage des résultats.
Celui-ci va commencer par calculer le niveau de l’application en se basant sur les résultats des tests.
Avant d’afficher les résultats, une note basée sur le nombre de tests réussi et le niveau calculé précédemment.
Package check va alors terminer avec les éventuelles notifications, un message sur le salon apps si c’est l’instance officielle de CI et un mail (bientôt directement au mainteneur de l’app) si l’app à obtenu un niveau de 0.
Et voilà, package check est près à redémarrer pour un nouveau test.
Fonctionnement de Package check (2e partie)
La série de test démarre avec la fonction TESTING_PROCESS qui va enchaîner les tests, selon ce qui aura été lu dans le check_process.
A l’exception du test de PACKAGE_LINTER, qui se contente d’exécuter Package linter, tout les tests utilisent des fonctions communes permettant de gérer leur environnement ou d’effectuer des tests génériques.
-
TEST_LAUNCHER
TEST_LAUNCHER est uniquement une fonction d’abstraction qui permet de limiter la redondance de LXC_STOP, et qui a permis pendant un moment de placer les vérifications du bug #654. -
SETUP_APP
Comme son nom le laisse imaginer, c’est la fonction qui va se charger d’installer l’application.
Globalement, il s’agit simplement d’unsudo yunohost --debug app installavec les arguments nécessaire pour le manifest.
Mais avant le démarrage du test, avec LXC_START, le script va exécuter COPY_LOG. -
COPY_LOG
COPY_LOG est une fonction en 2 temps, avec l’argument ‘1’ la fonction repère la fin du log yunohost-cli.log. Avec l’argument ‘2’, la fonction lit le log à partir de la ligne précédemment noté et le copie. Ainsi, seul le log des commandes entre les 2 appel de COPY_LOG sera extrait. -
LXC_START
La fonction pour prendre en charge le conteneur LXC et exécuter les commandes.
Cette fonction travaille en plusieurs étapes, tout d’abord le conteneur va tenter de démarrer jusqu’à 3 fois.
Le démarrage du conteneur à proprement parler log son démarrage dans le fichierlxc_boot.log.
Ensuite, le conteneur a 10 secondes pour démarrer et être accessible en ssh.
Suite à cela, le démarrage du conteneur est vérifié. Ainsi que sa connectivité.
Si le démarrage est un succès, le package à tester est copié sur le conteneur puis la commande en argument de LXC_START est exécutée dans le conteneur.
Le résultat de la commande exécutée dans le conteneur est reprise pour servir de code de sortie à la fonction LXC_START.
Enfin, le résultat de l’exécution de la commande est récupéré pour être copié dans le log du test.
LXC_START ne prenant pas en charge l’arrêt du conteneur, il est possible de l’appeler à plusieurs reprises pour exécuter des commandes successives sur le conteneur.
De retour dans SETUP_APP, la variable YUNOHOST_RESULT prend le code de retour de LXC_START pour savoir si l’installation de l’app est réussie ou non selon YunoHost.
Ensuite, APPID va prendre l’ID de l’app pour pouvoir manipuler l’application par la suite
-
REMOVE_APP
Cette fonction, qui sert donc évidemment à supprimer une application fonctionne de manière similaire à SETUP_APP. Avec COPY_LOG et LXC_START.
Toutefois, si le paramètreauto_removeest à 0, le processus marquera une pause pour permettre à l’utilisateur d’aller faire un tour dans le conteneur avant la suppression de l’app.
Pour accéder au conteneur, la fonction LXC_CONNECT_INFO affiche les informations de connexion. -
CHECK_URL
Cette fonction va tenter d’accéder à l’application via son interface web à l’aide de curl. Simulant ainsi un utilisateur normal.
Le test ne sera effectué que si la variableuse_curlest à 1. Seul les tests CHECK_SETUP_SUBDIR et CHECK_SETUP_ROOT fixent cette valeur à 1.
Si l’application ne propose pas d’installation publique/privée, un accès public sera forcé sur / avec un skipped_uris.
Le test de connexion s’effectue 2 fois de suite, une fois avec un / à la fin de l’adresse, une fois sans. Pour s’assurer que la config nginx est correcte.
Pour déterminer le résultat du test de connexion, plusieurs résultats sont analysés:- Le code de sortie de curl
- Le code HTTP renvoyé. Les codes 0xx, 4xx ou 5xx sont considérés comme des erreurs, à l’exception de 401 qui est une demande d’identification de l’application et 503 qui bénéficie d’un délai de 3 secondes avant d’être définitivement une erreur.
- La page affichée, si la page de destination est la page par défaut de nginx, c’est une erreur. Si c’est le portail, ce sera une erreur pour tout les tests sauf le test d’installation privé.
-
LOG_EXTRACTOR
LOG_EXTRACTOR est appelé pour afficher le log YunoHost relatif au test effectué.
Le log est tiré de l’extraction de COPY_LOG, et de celui-ci sont extraient les erreurs et warnings indiqués par la moulinette.
Ensuite la fonction appelle CLEAR_LOG et PARSE_LOG. -
CLEAR_LOG
Cette fonction supprime simplement quelques warnings inutiles, afin de limiter le bruit parasite. -
PARSE_LOG
L’affichage des erreurs et des warnings du log sur la sortie standard dans leurs couleurs respectives.
En cas d’erreur affichée, le résultat du test est considéré comme un échec -
LXC_STOP
En fin d’exécution d’un test, le conteneur est arrêté et restauré pour reprendre le prochain test sur un conteneur sur lequel aucune installation n’a été faite.
Fonctionnement de Package check (3e partie)
L’ensemble des tests utilisent des mécanismes similaires, voyons en détail le déroulement du premier test, CHECK_SETUP_SUBDIR, qui correspond donc à une installation classique de l’application dans un path.
Une des parties les plus importante est la modification des arguments qui seront donnés à la ligne de commande pour l’installation.
C’est la variable MANIFEST_ARGS_MOD qui embarquera ces arguments.
Pour ce test, le domaine, le path et l’utilisateur, au moins, seront renseigné.
En particulier, on utilisera ici le path contenu dans le check_process ou celui par défaut.
Si l’application dispose d’un paramètre public/privé, on le placera en mode public pour faciliter le test de connexion ultérieur avec curl.
Ensuite, nous allons simplement utiliser les fonctions disponible pour installer l’application, puis récupérer le log d’installation.
On termine avec un test de connexion à l’aide de la fonction CHECK_URL.
Pour déterminer les résultats de l’installation, 3 résultats sont analysés.
- YUNOHOST_RESULT correspond au code de sortie de la commande YunoHost, c’est donc le résultats de la commande
yunohost install. Si il est différent de 0, la commande a rencontré une erreur ou l’analyse du log en a révélé une. - curl_error est le résultat de la fonction CHECK_URL, un résultat différent de 0 est obtenu si curl rencontre une erreur, si la page renvoi un code d’erreur HTTP ou si la page obtenue est le défaut d’nginx.
- Et enfin YUNO_PORTAL doit être à 0, c’est à dire que l’accès curl ne doit pas avoir abouti au portail YunoHost.
Si ces 3 valeurs sont à 0, alors le test est réussi.
On peut alors supprimer l’application, analyser le résultat de la suppression et s’assurer ainsi que le script de suppression fonctionne également correctement.
Ce test fonctionne exactement comme le précédent, à l’exception que celui-ci installera à la racine du domaine.
Ce test est dédié aux applications ne disposant pas d’une interface web. Le test sera similaire aux 2 précédents, à l’exception qu’on ne tentera pas d’accès avec curl.
Le résultat du test se basera ici uniquement sur le résultat de la commande yunohost install et son log.
Le test d’upgrade de l’application commencera par installer l’application comme précédemment, pour choisir le path à utiliser ce test vérifie les résultats des précédents tests pour déterminer un mode d’installation qui a déjà fonctionné.
Si l’installation préalable de l’application est réussie, le test va simplement exécuter le test d’upgrade et en analyser le résultat.
Pour déterminer le résultat, on utilisera à nouveau YUNOHOST_RESULT, curl_error et YUNO_PORTAL.
Le test le plus redouté…
C’est également le test le plus long, car il va installer l’app dans un path ET à la racine.
Pour débuter, le test commencera par installer l’application à la racine.
Si l’installation est un succès, un backup de l’application est fait, avec une analyse de son résultat et de son log.
Le backup est ensuite extrait du conteneur pour être réutilisé plus tard.
A présent que le backup est fait et mis en sûreté, l’application est supprimée puis restaurée. On retrouve bien sûr notre analyse de la commande, le log et un test d’accès curl.
Ensuite, le conteneur est restauré dans son état d’origine, le mettant ainsi dans un état ou l’application n’a jamais été installé.
Le backup est remis à sa place dans le conteneur puis l’application est à nouveau restaurée. Ce test permet ainsi de simuler une migration de l’application sur un autre système en utilisant la restauration.
Après cette série de test, l’application subit à nouveau les même tests en étant installé cette fois dans un path.
Si seulement l’une des étapes échoue lors de tout ces tests, l’ensemble du test backup/restore est invalidé.
Ce sera ici un simple test d’installation en path et à la racine en jouant sur le paramètre public/privé de l’application.
En revanche, les résultats diffèrent sur le test en installation privé où c’est le portail YunoHost qui est attendu.
Ce test va procéder à 3 installations successives de l’application en modifiant chaque fois son path d’installation.
La première installation se fera avec le path habituel.
La seconde verra son path suffixé de -2.
Alors que la 3e sera préfixé de 3-.
En plus de tester l’installation multi-instance, ce test va provoquer une éventuelle erreur en introduisant un tiret dans le path. C’est un caractère autorisé, mais qui peux provoquer des erreurs si il n’est pas pris en compte.
Si au moins 2 installations sur les 3 réussissent, ce test est validé.
Cette fonction rassemble 4 tests différents
wrong_user et wrong_path consistent tout deux à indiquer respectivement un nom d’utilisateur et un nom de domaine volontairement faux pour vérifier le comportement de l’application. Ces tests sont inutiles depuis la version 2.4 de Yunohost…
incorrect_path consiste à volontairement indiquer un path mal écrit, pour simuler une faute de frappe de l’utilisateur.
Le path sera simplement modifié de /path à path/ pour induire des erreurs dans le script d’installation.
port_already_use utilise le port renseigné dans le check_process. Celui-ci doit être le port utilisé par l’application.
Le port ciblé sera ensuite simplement ouvert pour simuler un usage de ce dernier.
L’application devra donc trouver un autre port libre à utiliser.
Voila qui clos ces 3 épisodes dédiés à Package check, maintenant vous ne pourrez plus dire que vous ne savez pas comment ça marche !
Prochain épisode sur le fonctionnement de package check, en toute humilité je vous expliquerais pourquoi il est si grandiose et omnipotent 
