Warum wir jedes Mal in acht verschiedenen Linux-Umgebungen testen

Unter Linux reicht es nicht, zu sagen: „Es funktioniert.“

Selbst bei derselben Ubuntu-Distribution unterscheiden sich Systembibliotheken und Toolkits je nach Version. Für die Bildschirmausgabe gibt es X11 und Wayland, und für die koreanische Eingabe werden ibus oder fcitx5 verwendet. Nimmt man noch die Installationsart hinzu, wächst die Zahl der zu prüfenden Kombinationen schnell an.

Dass es auf einem einzigen Entwicklerrechner läuft, bedeutet, dass nur eine von zahlreichen Kombinationen geprüft wurde.

Deshalb habe ich im Repository ein kleines Labor eingerichtet. Für jede Umgebung starten wir eine echte virtuelle Maschine und wiederholen dieselben Prüfungen. Die Ergebnisse tragen wir in einer einzigen Tabelle zusammen.

Was die Tabelle prüft, ist einfach.

Startet die App? Kann man koreanischen Text eingeben?

Wir erleben die ersten dreißig Sekunden, die ein Benutzer nach der Installation der App erleben wird, schon vor ihm.

Eine Umgebung wurde zu einer Datei

Das Labor verwendet virtuelle KVM-Maschinen statt Container. Denn mit Containern lassen sich echte Desktop-Sitzungen und Eingabemethoden-Daemons nur schwer korrekt reproduzieren.

Wir laden das Cloud-Image der Distribution herunter und bereiten es mit cloud-init vor. Der Datenträger wird als Overlay über dem ursprünglichen Image erstellt. Wenn ein Problem auftritt, können wir ihn verwerfen und von vorn beginnen.

Eine Umgebung wird in einer einzigen Datei deklariert. Die Datei enthält die Distribution, das Image, die Sitzung, die Eingabemethode und die zu installierenden Pakete. Wenn man eine neue Kombination prüfen möchte, muss man nur eine Datei hinzufügen.

Die Eingabemethode unterscheidet sich je nach Sitzung. Unter X11 verwenden wir xdotool, unter Wayland ydotool. Da Wayland keine Fensterliste bereitstellt, zeigen wir die App im Vollbildmodus in einem Kiosk-Compositor an. So können wir jedes Mal an derselben Position Eingaben machen.

Die App wird auf dem Host nur einmal gebaut. Diese Binärdatei kopieren wir unverändert auf alle virtuellen Maschinen.

Wenn wir sie für jede Umgebung neu bauen, fließen unterschiedliche Compiler und Bibliotheken in die Ergebnisse ein. Tritt ein Fehler auf, wird es dadurch schwieriger, die Ursache zu finden. Vor allem aber müssen die Datei, die der Benutzer erhält, und die Datei, die das Labor prüft, identisch sein.

Die virtuelle Maschine prüft, der Host protokolliert

In der virtuellen Maschine prüfen wir drei Dinge.

Wir prüfen, ob die Binärdatei ausgeführt wird, ob sich ein Fenster öffnet und ob bei der Eingabe von dkssud der Text 안녕 erscheint.

Jede Prüfung hinterlässt eine JSON-Zeile. Der Host sammelt die Ergebnisse, speichert sie in einer Datei und erstellt daraus eine Tabelle. Die gemessenen Ergebnisse verbleiben im Repository, damit sie mit der nächsten Prüfung verglichen werden können.

Je nach Build wird die koreanische Eingabe unterschiedlich überprüft. In Entwicklungs-Builds können wir die gerade zusammengesetzten Zeichen direkt prüfen. In tatsächlichen Distributions-Builds ist diese Funktion nicht vorhanden. Stattdessen drücken wir die Eingabetaste, speichern die Datei und lesen anschließend den auf dem Datenträger gespeicherten Inhalt.

Dabei habe ich eines gelernt. Nicht die Installationsart, sondern der Build-Typ der App bestimmte die Prüfmethode.

Die erste Tabelle zeigte uns zwei Dinge

Unter Ubuntu 22.04 ließ sich die mit dem System-Toolkit gebaute App nicht öffnen. Der Grund war, dass ein Symbol nicht gefunden wurde, das nur in der neuesten Version von libadwaita vorhanden ist.

Umgekehrt konnten wir erstmals bestätigen, dass die koreanische Eingabe mit der Kombination aus Wayland und ibus ordnungsgemäß funktioniert.

Auf Grundlage dieses Ergebnisses haben wir beschlossen, bei allen Installationsarten dasselbe Toolkit mitzuliefern. Die heutige Tabelle mit acht Zeilen ist eine Absicherung, mit der wir prüfen, ob diese Entscheidung nicht wieder verletzt wurde.

Es gab auch Probleme, die nur in echten Umgebungen sichtbar waren. Anders als Desktop-Ubuntu enthielten die Cloud-Images weder das GTK4-Eingabemodul noch einen anfänglichen Eingabemodus. Sie mussten während der Bereitstellung separat installiert werden.

Das ibus-Modul musste zur Version des in der Distribution installierten Daemons passen. Auch die Verwendung der Eingabewerkzeuge unterschied sich je nach Distribution. Wir mussten die Prüfscripts an die jeweiligen Umgebungen anpassen.

Um den Arbeitsspeicher des Hosts zu schonen, führen wir höchstens zwei virtuelle Maschinen gleichzeitig aus. Sobald wir das Ergebnis einer virtuellen Maschine erhalten haben, fahren wir sie sofort herunter.

All das waren Probleme, die sich nur schwer durch das Lesen des Codes finden ließen. Denn derselbe Code führte je nach Umgebung zu unterschiedlichen Ergebnissen. Deshalb brauchten wir die Tabelle.

Die Tabelle gibt kein Leistungsversprechen ab

Die Tabelle enthält auch die Zeit bis zum Erscheinen des ersten Bildschirms und den Speicherverbrauch. Wir verwenden diese Werte jedoch nicht als Leistungskennzahlen.

Die virtuelle Maschine rendert den Bildschirm ohne GPU per Software, und wir messen nur einmal direkt nach dem Start. Die Werte können sich bei jeder Ausführung unterscheiden. Die Leistungsgrenzen bestimmen wir anhand des Medians aus drei Messungen auf einem Host mit einer echten GPU.

In dieser Tabelle sollte man nicht auf die Millisekunden achten, sondern auf die Häkchen.

Umgebungen, die wir nicht prüfen konnten, lassen wir leer. Fedora und Debian, echte GNOME-Sitzungen sowie Portal-Dialogfelder wie die Dateiauswahl sind noch nicht in der Tabelle enthalten.

Wir füllen ungeprüfte Felder nicht mit „Wird vermutlich funktionieren“ aus.

Wir können nicht bestimmen, welche Umgebung ein Benutzer auswählt. Was wir tun können, ist, diese Umgebung zuerst zu betreten und die App darin zu starten.