FAQ : Quelques détails techniques
Comment extraire le contenu d'un fichier tar ?
Certains rapports (par exemple les rapports Allure) sont stockés dans un fichier tar.
Il existe plusieurs façons d'extraire le contenu d'un tel fichier tar.
Utilisation de 7-Zip
Téléchargez et installer le logiciel 7-Zip.
Lancez le programme 7-Zip.
Dans son navigateur de fichiers, naviguez jusqu'au répertoire contenant le fichier tar.
SĂ©lectionnez le fichier tar dans le navigateur de fichiers.
Cliquez sur le bouton "Extraire" pour extraire le contenu du fichier tar.
Utilisation de WinZip
Téléchargez et installer le logiciel WinZip.
Lancez le programme WinZip.
Naviguez jusqu'au fichier tar dans le navigateur de la fenĂȘtre principale.
Cliquez sur le bouton "DĂ©compresser" pour extraire le contenu du fichier tar.
Utilisation de la commande tar
Si vous ĂȘtes sur Linux ou MacOS ou, sur Windows, si vous avez MinGW/MSYS, Cygwin ou WSL2 installĂ©, vous pouvez utiliser la commande tar
: tar xvf <fichier tar>
.
Comment afficher un rapport Allure ?
Obsolescence des rapports Allure
Depuis la livraison 2024-03, Squash Orchestrator peut gĂ©nĂ©rer un rapport HTML offrant un aperçu complet des tests d'un workflow. Il s'agit d'une fonctionnalitĂ© redondante avec les rapports Allure, mais ceux de l'orchestrateur sont plus polyvalents et pourront ĂȘtre encore Ă©tendus Ă l'avenir. Nous prĂ©voyons donc de supprimer la prise en charge des rapports Allure :
- Avec la livraison 2024-10, l'orchestrateur cesse de gĂ©nĂ©rer des rapports Allure par dĂ©faut. La gĂ©nĂ©ration peut ĂȘtre rĂ©activĂ©e par configuration, en utilisant la variable d'environnement
OPENTF_ALLURE_ENABLED
: voir la documentation d'OpenTestFactory pour les dĂ©tails. - Au troisiĂšme trimestre 2025, la prise en charge des rapports Allure sera abandonnĂ©e. Aucun rapport Allure ne pourra plus ĂȘtre crĂ©Ă©.
Installation d'Allure
La documentation d'Allure indique comment l'installer.
Affichage d'un rapport Allure
Télécharger le fichier depuis Squash en cliquant sur son nom
Extrayez le contenu du fichier tar, cela va créer un répertoire
allure-report
.
Ouvrez une fenĂȘtre de commandes et naviguez jusqu'au rĂ©pertoire contenant le rĂ©pertoire allure-report
.
Exécutez la commande allure open
.
Votre navigateur va s'ouvrir en affichant le rapport Allure.
Comment mettre en place un hook ?
Les hooks définissent les actions lancées au début et/ou à la fin de l'exécution de chaque test. On peut les utiliser, entre autres, pour remonter des fichiers créés en cours de l'exécution vers Squash.
Les hooks ont la structure suivante :
- name:
events:
if:
before:
after:
Les paramĂštres name
et events
sont obligatoires, de mĂȘme que l'un des paramĂštres before
ou after
.
Il existe deux possibilités pour mettre en place un hook :
-
DĂ©clarer le hook dans la section
hooks
du fichier de configuration du provider. Ce fichier se trouve typiquement dans/app/conf/nom_du_provider.yaml
(par exemple,/app/conf/junit.yaml
) :apiVersion: opentestfactory.org/v1beta1 kind: ProviderConfig current-context: ... contexts: ... hooks: - name: my hook events: - categoryPrefix: junit category: junit before: - run: echo hello after: - run: echo goodbye
-
Utiliser un fichier de définition à part et passer son chemin via la variable d'environnement
{nom_du_provider}_PROVIDER_HOOKS
:JUNIT_PROVIDER_HOOKS=/app/hooks/junit_hooks.yaml
Dans ce fichier, uniquement la section
hooks
sera présente :hooks: - name: my hook events: - categoryPrefix: junit category: junit before: - run: echo hello after: - run: echo goodbye
Si la variable d'environnement {nom_du_provider}_PROVIDER_HOOKS
est définie, les hooks déclarés
dans le fichier de configuration du provider sont ignorés.
Comment remonter des fichiers créés en cours de l'exécution vers Squash ?
Il est possible de faire remonter vers Squash des fichiers créés en cours de l'exécution,
par exemple des captures d'écran. Ces fichiers seront disponibles dans la liste Rapports d'exécution
.
Pour ce faire, il faut mettre en place un hook.
Prenons, à titre d'exemple, l'exécution d'une suite de tests JUnit/Selenium dans un environnement Windows.
Elle utilise le dépÎt Git qui s'appelle seleniumtests
. Une capture d'Ă©cran est faite Ă la fin de chaque test
et sauvegardée dans le dossier target/screenShots
du projet.
Pour que le hook s'applique aux exécutions Squash, il faut d'abord définir les événements (events
) auxquels il est lié.
Squash utilise l'action execute
du provider JUnit :
hooks:
- name: Attach screenshots to JUnit execution results
events:
- categoryPrefix: junit
category: execute
Ensuite, il faut déclarer les actions qui seront lancées à la fin de l'exécution de chaque test :
hooks:
- name: Attach screenshots to JUnit execution results
events:
- categoryPrefix: junit
category: execute
after:
- uses: actions/get-files
with:
pattern: '*.png'
warn-if-not-found: No screenshots found after execution.
working-directory: seleniumtests/target/screenShots
Le hook utilise l'action actions/get-files
pour récupérer tous les fichiers .png
depuis le dossier seleniumtests/target/screenShots
et les attacher aux résultats d'exécution.
Si aucun fichier *.png
n'est présent dans ce dossier, un avertissement sera affiché et l'exécution passera au test suivant.
Attention
Si le dossier des captures d'écran est défini à l'intérieur du projet Git, le chemin doit inclure le nom du projet.
Ce hook est a priori suffisant pour remonter les captures d'Ă©cran. Toutefois, pour
éviter de joindre les captures des tests précédents à chaque test exécuté, il faut également vider le dossier
screenShots
de son contenu avant chaque nouvelle exécution :
hooks:
- name: Attach screenshots to JUnit execution results
events:
- categoryPrefix: junit
category: execute
before:
- uses: actions/delete-file
with:
path: '*.png'
working-directory: seleniumtests/target/screenShots
continue-on-error: true
after:
- uses: actions/get-files
with:
pattern: '*.png'
warn-if-not-found: No screenshots found after execution.
working-directory: seleniumtests/target/screenShots
Le hook utilise l'action actions/delete-file
pour supprimer tous les fichiers .png
dans le dossier seleniumtests/target/screenShots
avant le lancement du test suivant.
L'argument continue-on-error
est ajouté pour ne pas interrompre l'exécution si
le dossier n'est pas trouvé.
On peut, bien Ă©videmment, modifier cet exemple en fonction du projet et l'utiliser pour transmettre, vers Squash, d'autres fichiers que des captures d'Ă©cran.
De mĂȘme, le mot-clĂ© if
peut ĂȘtre utilisĂ© pour restreindre la portĂ©e du hook. Pour tous les dĂ©tails, se reporter Ă la
documentation d'OpenTestFactory : chapitres Hooks et
Hooks pour les plugins de providers.
Comment utiliser Maven Daemon pour l'exécution des tests ?
Qu'est-ce que Maven Daemon ?
Maven Daemon est un wrapper pour Maven qui parallĂ©lise le build des modules en utilisant plusieurs cĆurs du CPU. Il s'agit d'un exĂ©cutable natif, qui consomme moins de mĂ©moire, dĂ©marre plus rapidement et qui, en tant que daemon, n'a besoin d'ĂȘtre lancĂ© qu'une seule fois. Le build devient par consĂ©quent plus performant, ce qui permet aussi de gagner du temps sur l'exĂ©cution des tests.
Pour des tests JUnit ou Cucumber qui ne durent que quelques secondes, la durĂ©e totale d'exĂ©cution peut ĂȘtre rĂ©duite de 10% Ă 20%. Plus les tests sont longs, plus le gain sera faible.
Pour utiliser Maven Daemon au lieu de Maven, il faut d'abord l'installer dans l'environnement d'exécution.
Installer
Les différentes possibilités d'installation de Maven Daemon sont décrites en détail dans le readme du projet.
Pour une installation manuelle, il suffit de télécharger l'archive .zip
le plus
récent depuis apache.org
et de l'extraire dans le répertoire de son choix, puis d'ajouter le chemin du bin
dans le PATH
. La commande mvnd --version
peut alors ĂȘtre utilisĂ©e pour vĂ©rifier
l'installation.
En mĂȘme temps, c'est la commande mvn test
que les providers JUnit et Cucumber de
l'orchestrateur utilisent pour lancer les exécutions. Si l'on veut que les tests
soient exécutés par Maven Daemon, il faut aliaser la commande mvn
de sorte
qu'elle pointe vers l'exécutable mvnd
.
Pointer mvn
vers mvnd
La procĂ©dure dĂ©pendra du systĂšme d'exploitation de l'environnement d'exĂ©cution. On prĂ©sume que Java y est dĂ©jĂ prĂ©sent et que Maven Daemon vient d'y ĂȘtre installĂ©.
Windows
- Renommer l'exécutable
mvnd.exe
(dans lebin
du dossier d'installation de Maven Daemon) enmvn.exe
. - Modifier les variables d'environnement systĂšme :
MAVEN_HOME
prendra comme valeur le chemin du dossier d'installation de Maven Daemon (sansbin
);- on s'assurera que la variable
PATH
contient le chemin relatif de l'exécutable :%MAVEN_HOME%\bin
.
Pour vérifier que la substitution est effective, on peut utiliser la commande where mvn
ou la commande mvn --version
. La premiÚre doit afficher le chemin vers l'exécutable
mvnd
renommé, la seconde les informations relatives à l'installation de Maven Daemon.
Rappel
Une fois les variables d'environnement modifiées et prises en compte, il faut également relancer l'agent de l'orchestrateur dans une nouvelle invite de commandes.
Linux
- Créer, dans le dossier
/usr/local/bin
, le fichiermvn
. Ajouter, dans ce fichier, la ligne/home/user/mvnd_install_path/bin/mvnd "$@"
, puis rendre ce fichier exécutable. - Faire un
echo $PATH
et s'assurer que le chemin/usr/local/bin
se situe avant le chemin demvn
. Si ce n'est pas le cas, ajouter, dans le fichier/home/user/.bashrc
, la ligne suivante :export PATH="/usr/local/bin:$PATH"
- Redémarrer la session.
Pour vérifier les modifications, exécuter la commande which mvn
. Cette commande doit afficher
/usr/local/bin/mvn
. La commande mvn --version
, quant Ă elle, affichera les informations de
Maven Daemon.
Astuce
Une alternative Ă la substitution du chemin de Maven est de remplacer directement son
exécutable. Dans ce cas, il faut se rendre dans le dossier bin
de Maven et remplacer
le fichier mvn
d'origine par le fichier mvn
contenant la ligne /home/user/mvnd_install_path/bin/mvnd "$@"
.
(Le plus prudent est de renommer le mvn
d'origine en mvn.old
.)
Comment arrĂȘter le daemon Ă la fin d'un workflow ?
Sur Windows, quand un workflow est exĂ©cutĂ© avec Maven Daemon, le daemon est lancĂ© Ă l'intĂ©rieur du workspace. Par consĂ©quent, ce dernier ne peut pas ĂȘtre dĂ©finitivement supprimĂ© Ă la fin de l'exĂ©cution. Si l'on veut Ă©viter de polluer le dossier de l'agent de l'orchestrateur, on peut mettre en place un hook au niveau du workflow (un job hook).
Info
La mise en place des job hooks est décrite dans la documentation d'OpenTestFactory.
La premiĂšre solution est d'utiliser un hook de setup
pour lancer le daemon avant
la création du workspace. Dans ce cas, il sera lancé dans le dossier de l'agent et le workspace
pourra ĂȘtre supprimĂ© Ă la fin de l'exĂ©cution.
hooks:
- name: Launch Maven Daemon
events:
- channel: setup
before:
- run: mvn --version
La commande mvn --version
lance un daemon avant d'afficher les informations sur
la version.
On peut aussi arrĂȘter le daemon avant la suppression du workspace pour qu'il libĂšre le dossier respectif :
hooks:
- name: Stop Maven Daemon
events:
- channel: teardown
before:
- run: mvn --stop
Attention
La commande mvn --stop
arrĂȘte tous les daemons indĂ©pendamment de leur statut.