Test des packages d'applications

Bonjour à tous

afin de tester vos packages d’application Yunohost, un script de tests unitaires a été développé.
Ce script permet de vérifier que le package s’installe sans erreur dans différentes configuration.

  • Vérification du package avec Package linter
  • Installation en sous-dossier
  • Installation à la racine du domaine
  • Installation sans accès par url (Pour les applications n’ayant pas d’interface web)
  • Installation en privé
  • Installation en public
  • Mise à jour sur la même version du package
  • Backup puis restore
  • Installation multi-instances
  • Test d’utilisateur incorrect
  • Test de domaine incorrect
  • Test de path mal formé (path/ au lieu de /path)
  • Test de port déjà utilisé

Le script package_check utilise un conteneur LXC pour manipuler le package dans un environnement non parasité par les précédentes installation.

L’usage de package_check implique la création préalable d’un fichier check_process indiquant les tests à effectuer et les arguments du manifest. Ce fichier doit se trouver à la racine du package à tester.
La documentation explique en détail comment créer ce fichier.
Si ce fichier n’est pas présent, package_check sera utilisé en mode dégradé. Il va tenter de repérer les arguments domain, path et admin dans le manifest pour exécuter un nombre restreint de test, en fonction des arguments trouvés.

Le script s’utilise très simplement:
./package_check.sh dir/APP_ynh
ou
./package_check.sh https://github.com/USER/APP_ynh

Attention
En raison de la jeunesse de ce script de test unitaire, il est conseillé de l’utiliser dans une machine virtuelle. Tout les bugs n’ayant pas encore été décelés.

Pour utiliser le script package_check, vous pouvez simplement le cloner.
git clone https://github.com/YunoHost/package_check

N’hésitez pas à remonter tout bug rencontré dans le bug tracker.


Hello

To test your apps packages for Yunohost, a unit testing script was developed.
This script will verify that package installs without error in different configurations.

  • Check the package with Package linter
  • Installation in a subdir
  • Installation at root of domain
  • Installation without url access (For apps without web UI)
  • Private installation.
  • Public installation.
  • Upgrade on same package version
  • Backup then restore
  • Multi-instances installation
  • Test with wrong user
  • Test with wrong domain
  • Test malformed path (path/ instead od /path)
  • Test port already use

Package_check script use an LXC container to manipulate the package in a non parasited environnement by previous installs

The use of package_check implies first creating a check_process file indicating tests to perform and arguments of the manifest. This file must be at root of the package dir.
The documentation explain in detail how to create this file.
If this file is not present, package_check will be used in downgraded mode. It try to retrieve domain, path and admin user arguments in the manifest for execute some tests, based on arguments found.

The script are simple to use
./package_check.sh dir/APP_ynh
or
./package_check.sh https://github.com/USER/APP_ynh

Be careful
Because of the youth of this unit test script, it is advisable to use in a virtual machine. All bugs are not revealed yet.

For use the script, you may simply clone it.
git clone https://github.com/YunoHost/package_check

Don’t hesitate to report any bug found in the bug tracker.

6 Likes

Hello,

As I’ve used your app to package two applications recently, I just wanted to let you know that your work is awesome and makes things A LOT easier for packagers!
Thank you so much! :clap: :+1:

1 Like

Hey guys,

Well, it’s an old post here, but I think it stays the better way to inform all the packagers about the new features about Package check

I’m not going to retrace all the new features since july last year.
But I’m gonna tell you what’s new since a little while. And keep inform by this way.

So what’s new :

  • Using of a config file, package check/config, to store some informations about your installation. Domain, IP, name of the container, etc. Like that, you can change your environment without any conflict with any upgrade of package check.
  • A test fails if the connexion test end on the yunohost portal or the default nginx file. Because, that’s implies your app not answers correctly.
  • Sends a mail to the maintainer (the email in the manifest) if his app fall to the level 0.
  • The execution without LXC, directly in the host, is no longer available. It was really a bad idea…
  • Add a new cli argument, --branch= that allow to execute a test on a branch of the repository instead of master.
  • And an another one, --interrupt with the same behavior than auto_remove. If this argument is set, before each remove the test will pause to allow you to check manually if you want.
  • You can use a smaller version of each argument, -f for --force-install-ok, -i for --interrupt etc. See the readme or the help arg for informations.
  • Some changes on the check_process file.
    • auto_remove information is no longer used. It’s replaced by --interrup argument. You can remove it.
    • wrong_user and wrong_path can be removed to. This tests were removed, because this cases is now handled by yunohost core.
    • corrupt_source, fail_download_source and final_path_already_use were removed too. Because these tests have never working, and it’s canceled for now.
    • A new part was added, ;;; Levels to allow to force some levels if needed.
    • PASSWORD key is no longer needed. If you have a password in your manifest, just add it as any other argument. So without (PASSWORD).
    • The PATH key is now grab directly from your check_process. To allow custom path for some apps.
    • And again, a new part, ;;; Options. This part, for now, allow to specify a alternative mail adress than the manifest. And, the most important, the key Notification accept 4 values, none, down, change or all. This key will determine how you want to be notified for this app. A mail only if your app go to level 0 (none), if your app decrease its level (down), for each level change (change) or for each test, even if the level doesn’t change (all).
      Like that, you can be always informed to how is your app.
  • A limitation for the level 6 was induce, to reach the level 6, your app have to be hosted in the YunoHost-Apps organisation on github. It’s the YEP 1.7.
  • A new transparent test was added. Some files are created before the installation of your app. If this files are missings after some operations around your app, that means your script does something wrong with a potential effect on the system.
  • A new test was added, a test with the script change_url. If you have that kind of script for your app, you can activate this test by change_url=1 in your check_process.
  • The test with the port was rewrite, because it was not really effective. Now, it works fine.
  • And, to finish, a new test was added, just after the first installation. The app is removed, and now, the app is reinstalled after this removed, without a restoration of the container. This test si designed to check if after a remove, your app can be reinstalled correctly. Not so obvious…

Salut les gars,

C’est là un ancien post, mais je pense que ça reste le meilleur moyen d’informer les packageurs sur les évolutions de package check.

Je vais pas retracer tout les nouvelles fonctionnalités depuis juillet dernier.
Mais je vais vous dire ce qu’il y a de nouveau depuis quelques temps. Et continuer à vous informer par la suite ici même.

Donc qu’y a-t-il de nouveau :

  • Usage d’un fichier de config, package check/config, pour enregistrer des informations sur l’installation. Domain, IP, nom du conteneur, etc. De cette manière, vous pouvez changer la configuration de votre installation sans risquer un conflit lors de la mise à jour de package check.
  • Le test échoue si la connexion tombe sur le portail YunoHost ou sur la page par défaut de Nginx. Car cela signifie que l’application ne répond pas correctement.
  • Envoi un mail au mainteneur (Le mail indiqué dans le manifest) si l’app tombe au niveau 0.
  • L’exécution sans LXC, directement dans l’hôte, n’est plus disponible. C’était une mauvaise idée…
  • Ajout d’un nouvel argument CLI, --branch= qui permet d’exécuter sur une branche du dépôt git plutôt que sur master.
  • Et un autre argument, --interrupt qui a le même comportement que auto_remove. Lorsque cette argument est ajouté, le test marque une pause avant chaque remove pour permettre de faire des vérifications manuelles.
  • Chaque argument peut être utiliser en version courte, -f pour --force-install-ok, -i pour --interrupt etc. Vous trouverez plus d’informations dans le readme.
  • Quelques changements dans le fichier check_process
    • L’option auto_remove n’est plus utilisée. Elle est remplacée par l’argument --interrupt. Cette ligne peut être retirée.
    • Les tests wrong_user et wrong_path peuvent aussi être retirés. Ces tests ont été retirés, car ces cas de figures sont géré par le core YunoHost.
    • Les tests corrupt_source, fail_download_source et final_path_already_use sont aussi supprimés. Ils n’ont jamais fonctionné, et c’est pas prévu.
    • Une nouvelle partie a été ajoutée, ;;; Levels pour permettre le forçage de certain niveaux si nécessaire.
    • La clé PASSWORD n’est plus nécessaire. Si vous avez un mot de passe dans votre manifest, vous pouvez simplement l’ajouter comme n’importe quel autre argument. Donc sans (PASSWORD).
    • La clé PATH est désormais récupérée directement dans le check_process. Pour permettre des path spécifiques pour certaines apps.
    • A nouveau, une nouvelle partie, ;;; Options. Cette partie, pour le moment, permet de spécifier une adresse mail alternative à celle du manifest. Et, surtout, la clé Notification accepte 4 valeurs, none, down, change et all. Cette clé va déterminer comment vous souhaitez être informés pour cette app. Un mail seulement si l’app tombe au niveau 0 (none), si l’app descend de niveau (down), si l’app change de niveau (change) ou pour chaque test, même si le niveau ne change pas (all).
      De cette manière, vous pouvez rester toujours informé de comment se porte votre application.
  • Une limitation pour le niveau 6 a été ajoutée, pour atteindre le niveau 6, votre app doit être dans l’organisation YunoHost-Apps sur github. C’est la YEP 1.7.
  • Un nouveau test, transparent, a été ajouté. Des fichiers sont créés avant l’installation de l’application. Si ces fichiers sont manquant après certaines opérations sur l’app, cela indique que le script a fait une bêtise avec d’éventuelles conséquences pour le système.
  • Un nouveau test a été ajouté, pour tester le script change_url. Si vous avez ce script dans votre app, vous pouvez activer ce test en ajoutant change_url=1 dans le check_process.
  • Le test avec le port a été réécris, le précédent n’était pas vraiment efficace. Maintenant il fonctionne correctement.
  • Et pour finir, encore un nouveau test ajouté, juste après la première installation. L’application est supprimée, à présent, l’application est réinstallée après sa suppression, sans restauration du conteneur. Ce test est destiné à vérifié si après la suppression, l’app peut être réinstallée correctement. Ce qui n’est pas si évident…
1 Like