YunoHost/package_check
1
0
Fork 0
mirror of https://github.com/YunoHost/package_check.git synced 2024-09-03 20:06:20 +02:00
Code Issues Projects Releases Packages Wiki Activity
package_check/README-fr.md
Maniack Crudelis d00cd37f5d Handle GitHub url with a branch
2020-04-30 01:13:22 +02:00

11 KiB
Raw Blame History

Package checker pour YunoHost

Projet YunoHost

Read this readme in english

Ensemble de tests unitaires pour vérifier les packages Yunohost.
Le script package_check.sh effectue une succession de test sur un package afin de vérifier sa capacité à s'installer et se désinstaller dans différents cas.
Le résultats des tests est affiché directement et stocké dans le fichier Test_results.log

Le script est capable d'effectuer les tests suivant:

  • 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)
  • Désinstallation
  • Réinstallation après désinstallation
  • Installation en privé
  • Installation en public
  • Upgrade depuis la même version du package
  • Upgrade depuis une précédente version du package
  • Backup
  • Restore après suppression de l'application
  • Restore sans installation préalable
  • Installation multi-instance
  • Test de port déjà utilisé
  • Test du script change_url
  • Test des actions et configurations disponible dans le config-panel

Package check utilise un conteneur LXC pour créer un environnement de test propre sans résidus d'installations précédentes.

Usage:
Pour une app dans un dossier: ./package_check.sh APP_ynh
Pour une app sur github: ./package_check.sh https://github.com/USER/APP_ynh

Il est nécessaire de fournir, à la racine du package de l'app à tester, un fichier check_process pour indiquer au script les arguments attendu et les tests à effectuer.
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.

Déploiement de package_check

Package_check ne peut être installer que sur Debian Stretch ou Debian Buster.

git clone https://github.com/YunoHost/package_check
package_check/sub_scripts/lxc_build.sh

package_check/package_check.sh APP_ynh

Syntaxe du fichier check_process

A l'exception des espaces, la syntaxe du fichier doit être scrupuleusement respectée.

;; Nom du test
# Commentaire ignoré
	; pre-install
		echo -n "Placez ici vos commandes a exéxuter dans le conteneur, "
		echo "avant chaque installation de l'application."
	; Manifest
		domain="domain.tld"	(DOMAIN)
		path="/path"	(PATH)
		admin="john"	(USER)
		language="fr"
		is_public=1	(PUBLIC|public=1|private=0)
		password="password"
		port="666"	(PORT)
	; Actions
		action_argument=arg1|arg2
		is_public=1|0
	; Config_panel
		main.categorie.config_example=arg1|arg2
		main.overwrite_files.overwrite_phpfpm=1|0
		main.php_fpm_config.footprint=low|medium|high|specific
		main.php_fpm_config.free_footprint=20
		main.php_fpm_config.usage=low|medium|high
	; Checks
		pkg_linter=1
		setup_sub_dir=1
		setup_root=1
		setup_nourl=0
		setup_private=1
		setup_public=1
		upgrade=1
		upgrade=1	from_commit=65c382d138596fcb32b4c97c39398815a1dcd4e8
		backup_restore=1
		multi_instance=1
		port_already_use=1 (XXXX)
		change_url=1
		actions=1
		config_panel=1
;;; Levels
	Level 5=auto
;;; Options
Email=
Notification=none
;;; Upgrade options
	; commit=65c382d138596fcb32b4c97c39398815a1dcd4e8
		name=Name of this previous version
		manifest_arg=domain=DOMAIN&path=PATH&admin=USER&password=pass&is_public=1&

;; Nom du test

Nom du scénario de test qui sera effectué.
On peut créer autant de scénario de test que voulu, tous ayant la même syntaxe.
Les différents scénarios de test seront exécutés successivement.

; pre-install

Instruction optionnelle
Si vous devez exécuter une commande ou un groupe de commandes avant l'installation, vous pouvez utiliser cette instruction.
Toutes les commandes ajoutées après l'instruction ; pre-install seront exécutées dans le conteneur avant chaque installation de l'application.

; Manifest

Ensemble des clés du manifest.
Toutes les clés du manifest doivent être renseignée afin de procéder à l'installation.

Les clés de manifest données ici ne le sont qu'à titre d'exemple. Voir le manifest de l'application.

Certaines clés de manifest sont indispensables au script pour effectuer certains test. Ces clés doivent être mises en évidence afin que le script soit capable de les retrouver et de changer leur valeur.
(DOMAIN), (PATH), (USER) et (PORT) doivent être mis en bout de ligne des clés correspondantes. Ces clés seront modifiées par le script.
(PUBLIC|public=1|private=0) doit, en plus de correspondre à la clé de visibilité public, indiquer les valeurs du manifest pour public et privé.

; Actions

List des arguments pour chaque action nécessitant un argument.
action_argument est le nom de l'argument, ainsi que vous pouvez le trouver à la fin de [action.arguments.action_argument].
arg1|arg2 sont les différents arguments à utiliser pour les test. Vous pouvez mettre autant d'arguments que désiré, séparé par |.

Seul actions.toml peut être testé par package_check, pas actions.json.

; Config_panel

List des arguments pour chaque configuration de config_panel.
main.categorie.config_example est l'entrée toml complète pour l'argument de cette configuration.
arg1|arg2 sont les différents arguments à utiliser pour les test. Vous pouvez mettre autant d'arguments que désiré, séparé par |.

Seul config_panel.toml peut être testé par package_check, pas config_panel.json.

; Checks

Ensemble des tests à effectuer.
Chaque test marqué à 1 sera effectué par le script.
Si un test est absent de la liste, il sera ignoré. Cela revient à le noter à 0.

  • pkg_linter: Vérification du package avec package linter
  • setup_sub_dir: Installation dans un path.
  • setup_root: Installation à la racine du domaine.
  • setup_nourl: Installation sans accès http. Ce test ne devrait être choisi que pour les applications ne disposant pas d'une interface web.
  • setup_private: Installation en privé.
  • setup_public: Installation en public.
  • upgrade: Upgrade du package sur la même version. Test uniquement le script upgrade.
  • upgrade from_commit: Upgrade du package à partir du commit spécifié vers la dernière version.
  • backup_restore: Backup et restauration.
  • multi_instance: Installation de l'application 2 fois de suite, pour vérifier sa capacité à être multi-instance.
  • port_already_use: Provoque une erreur sur le port en l'ouvrant avant le script d'install.
    Le test port_already_use peut éventuellement prendre en argument un numéro de port. Si celui-ci n'est pas dans le manifest.
    Le numéro de port doit alors être noté entre parenthèse, il servira au test de port.
  • change_url: Test le script change_url de 6 manières différentes, Root vers un path, path vers un autre path et path vers root. Et la même chose avec un autre domaine.
  • actions: Toutes les actions disponible dans actions.toml
  • config_panel: Toutes les configurations disponible dans config_panel.toml

;;; Levels

Les niveaux 1 à 8 sont déterminés automatiquement.
A l'exception du niveau 5, vous ne pouvez plus forcer une valeur pour un niveau.
Le niveau 5 est déterminé par les résultats de package linter.
La valeur par défaut pour ce niveau est auto, cependant, si nécessaire, vous pouvez forcer la valeur pour ce niveau en la fixant à 1, pour un résultat positif, ou à 0, pour un résultat négatif.
Si vous le faites, veuillez ajouter un commentaire pour justifier pourquoi vous forcez ce niveau.

;;; Options

Options supplémentaires disponible dans le check_process.
Ces options sont facultatives.

  • Email : Permet d'indiquer un email alternatif à celui qui est présent dans le manifest pour les notifications de package check, lorsque celui-ci s'exécute en contexte d'intégration continue.
  • Notification : Degré de notification souhaité pour l'application. Il y a 3 niveaux de notification disponible.
    • down : Envoi un mail seulement si le niveau de l'application a baissé.
    • change : Envoi un mail seulement si le niveau de l'application a changé.
    • all : Envoi un mail pour chaque test de l'application, quel que ce soit le résultat.

;;; Upgrade options

Instruction optionnelle
Pour chaque commit indiqué pour un upgrade, permet d'indiquer un nom pour cette version et les paramètres du manifest à utiliser lors de l'installation préliminaire.
En cas d'absence de nom, le commit sera utilisé.
De même en cas d'absence d'arguments pour le manifest, les arguments du check_process seront utilisés.

3 variables doivent être utilisées pour les arguments du manifest, DOMAIN, PATH et USER.

Le script package_check.sh accepte 6 arguments en plus du package à tester.

  • --bash-mode: Rend le script autonome. Aucune intervention de l'utilisateur ne sera nécessaire.
    La valeur de auto_remove est ignorée.
  • --branch=nom-de-branche: Teste une branche du dépôt plutôt que de tester master. Permet de tester les pull request. Vous pouvez utiliser une url avec une branche, https://github.com/YunoHost-Apps/APP_ynh/tree/my_branch, pour utiliser implicitement cet argument.
  • --build-lxc: Installe LXC et créer le conteneur debian Yunohost si nécessaire.
  • --force-install-ok: Force la réussite des installations, même si elles échouent. Permet d'effectuer les tests qui suivent même si l'installation a échouée.
  • --interrupt: Force l'option auto_remove à 0, le script marquera une pause avant chaque suppression d'application.
  • --help: Affiche l'aide du script

LXC

Package check utilise la virtualisation en conteneur pour assurer l'intégrité de l'environnement de test.
L'usage de LXC apporte une meilleure stabilité au processus de test, un test de suppression échoué n'entraine pas l'échec des tests suivant, et permet de garder un environnement de test sans résidus de test précédents. En revanche, l'usage de LXC augmente la durée des tests, en raison des manipulations du conteneur et de la réinstallation systématique des dépendances de l'application.

Il faut prévoir également un espace suffisant sur l'hôte, au minimum 6Go pour le conteneur, ses snapshots et sa copie de sauvegarde.

L'usage de LXC est facilité par 4 scripts, permettant de gérer la création, la mise à jour, la suppression et la réparation du conteneur.

  • lxc_build.sh: lxc_build installe LXC et ses dépendances, puis créer le conteneur debian.
    Il ajoute ensuite le support réseau, installe YunoHost et le configure. Et enfin configure un accès ssh.
    L'accès ssh par défaut est ssh -t pchecker_lxc
  • lxc_upgrade.sh: Effectue la mise à jour du conteneur à l'aide d'apt-get et recréer le snapshot.
  • lxc_remove.sh: Supprime le conteneur LXC, son snapshot et sa sauvegarde. Désinstalle LXC et déconfigure le réseau associé.
  • lxc_check.sh: Vérifie le conteneur LXC et tente de le réparer si nécessaire.