Pourquoi nous effectuons systématiquement des vérifications dans huit environnements Linux

Sous Linux, dire que « ça marche » ne suffit pas.

Même sous Ubuntu, les bibliothèques système et les boîtes à outils diffèrent selon la version. Le mode d’affichage se divise entre X11 et Wayland, et la saisie du coréen utilise ibus ou fcitx5. Si l’on ajoute les modes d’installation, le nombre de combinaisons à vérifier augmente rapidement.

Le fait que l’application s’exécute sur l’ordinateur d’un développeur signifie qu’une seule combinaison parmi une multitude a été vérifiée.

J’ai donc créé un petit laboratoire dans le dépôt. Pour chaque environnement, je lance une véritable machine virtuelle et je répète les mêmes vérifications. Les résultats sont regroupés dans un seul tableau.

Ce que vérifie ce tableau est simple.

L’application démarre-t-elle ? Peut-on saisir du coréen ?

Nous vivons à l’avance les trente premières secondes que l’utilisateur connaîtra après avoir installé l’application.

J’ai fait de chaque environnement un fichier

Le laboratoire utilise des machines virtuelles KVM plutôt que des conteneurs. En effet, les conteneurs reproduisent difficilement une véritable session de bureau et le démon de méthode de saisie.

Je récupère l’image cloud de la distribution et je la prépare avec cloud-init. Le disque est créé sous forme de couche superposée à l’image d’origine. En cas de problème, je peux le supprimer et recommencer.

Chaque environnement est déclaré dans un fichier unique. Ce fichier contient la distribution, l’image, la session, la méthode de saisie et les paquets à installer. Pour vérifier une nouvelle combinaison, il suffit d’ajouter un fichier.

La méthode de saisie varie selon la session. Sous X11, j’utilise xdotool ; sous Wayland, ydotool. Wayland ne fournissant pas de liste des fenêtres, j’affiche l’application en plein écran dans un compositeur en mode kiosque. Cela permet de saisir du texte au même endroit à chaque fois.

L’application n’est compilée qu’une seule fois sur l’hôte. Le même binaire est ensuite copié tel quel dans toutes les machines virtuelles.

Si elle était recompilée dans chaque environnement, des compilateurs et des bibliothèques différents se mêleraient aux résultats. En cas d’échec, il serait plus difficile d’en trouver la cause. Surtout, le fichier reçu par l’utilisateur doit être le même que celui vérifié par le laboratoire.

La machine virtuelle vérifie, l’hôte consigne

Dans la machine virtuelle, je vérifie trois choses.

Je regarde si le binaire s’exécute, si la fenêtre s’affiche et si 안녕 apparaît lorsque je saisis dkssud.

Chaque vérification produit une ligne de JSON. L’hôte rassemble les résultats, les enregistre dans un fichier et les transforme en tableau. Les résultats mesurés restent dans le dépôt afin d’être comparés à ceux des vérifications suivantes.

La méthode de vérification de la saisie du coréen varie selon le type de compilation. Dans les versions de développement, je peux vérifier directement les caractères en cours de composition. Cette fonction n’existe pas dans les versions réellement destinées à la distribution. À la place, j’appuie sur Entrée, j’enregistre le fichier, puis je lis le contenu écrit sur le disque.

J’ai appris une chose au cours de ce processus. Ce n’était pas le mode d’installation qui déterminait la méthode de vérification, mais le type de compilation de l’application.

Le premier tableau m’a appris deux choses

Sous Ubuntu 22.04, l’application compilée avec la boîte à outils du système ne s’ouvrait pas. Elle ne trouvait pas un symbole présent uniquement dans la version la plus récente de libadwaita.

À l’inverse, j’ai aussi confirmé pour la première fois que la saisie du coréen fonctionnait correctement avec la combinaison Wayland et ibus.

À partir de ces résultats, j’ai décidé d’inclure la même boîte à outils dans tous les modes d’installation. Le tableau actuel de huit lignes sert de garde-fou pour vérifier que cette décision ne soit pas remise en cause.

Certains problèmes n’étaient visibles que dans un environnement réel. Contrairement à Ubuntu pour ordinateur de bureau, l’image cloud ne comportait ni module de saisie GTK4 ni mode de saisie initial. Il fallait les installer séparément pendant le provisionnement.

Le module ibus devait correspondre à la version du démon installée dans la distribution. L’utilisation des outils de saisie variait également d’une distribution à l’autre. Il a fallu séparer les scripts de vérification en fonction des environnements.

Afin d’économiser la mémoire de l’hôte, seules deux machines virtuelles au maximum s’exécutent simultanément. Dès que les résultats d’une machine virtuelle sont reçus, celle-ci est arrêtée.

Tous ces problèmes étaient difficiles à trouver en lisant uniquement le code. Le même code produisait des résultats différents selon l’environnement. C’est pour cela que ce tableau était nécessaire.

Le tableau ne promet pas de performances

Le tableau indique également le temps nécessaire à l’affichage du premier écran et l’utilisation de la mémoire. Mais je ne les utilise pas comme indicateurs de performance.

La machine virtuelle dessine l’écran par logiciel, sans GPU, et la mesure n’est effectuée qu’une seule fois, juste après le démarrage. Les valeurs peuvent varier à chaque exécution. Les seuils de performance sont définis à partir de la médiane de trois mesures réalisées sur un hôte doté d’un véritable GPU.

Dans ce tableau, ce ne sont pas les millisecondes qu’il faut regarder, mais les coches.

Les environnements qui n’ont pas pu être vérifiés restent vides. Fedora et Debian, une véritable session GNOME ainsi que les boîtes de dialogue de portail, comme celle permettant de sélectionner un fichier, ne figurent pas encore dans le tableau.

Je ne remplis pas les cases non vérifiées par « ça devrait probablement marcher ».

Nous ne pouvons pas décider quel environnement l’utilisateur choisira. Ce que nous pouvons faire, c’est entrer dans cet environnement avant lui et essayer d’y lancer l’application.