Integrationstests mit Windows in der GitHub CI/CD Pipeline

Um die Qualität unserer Test- und Prozessautomatisierungslösung mateo sicherzustellen und stets aktuell zu halten sind automatisierte Integrationstests unverzichtbar. Bis vor Kurzem wurden diese Tests in einer Windows-VM per Google Compute Engine ausgeführt. Um jedoch Kosten zu reduzieren, ohne dabei Abstriche bei der Qualität zu machen, lassen wir die Integrationstests nun in einer GitHub CI/CD-Pipeline laufen. Die zentrale Herausforderung dabei war, eine Windows-Umgebung in der Pipeline bereitzustellen und die Tests darin zuverlässig auszuführen. Im Folgenden wird die Vorgehensweise beschrieben und was wir erzielen konnten.

Ausgangspunkt: Containerisierung mit dockur/windows

Als Grundlage für die Windows-Umgebung in der Pipeline diente das Projekt dockur/windows, welches einen Windows-Container auf Basis von QEMU bereitstellt. Die Architektur in der GitHub Pipeline ist dabei mehrstufig verschachtelt:

• Auf dem Host läuft ein Ubuntu-Runner,

• dieser startet einen Docker-Container,

• in dem wiederum mit Hilfe von QEMU eine Windows-VM läuft,

• in der schließlich die Integrationstests ausgeführt werden.

Durch den Docker-Container bleibt die Umgebung reproduzierbar und lokal ausführbar, was optimale Kontrolle beim Debuggen ermöglicht.

Der Windows-Container stellt zwei wichtige Mount-Punkte bereit:

• /oem: Hier wird ein Batch-Skript (install.bat) hinterlegt, das beim ersten Start des Containers automatisch ausgeführt wird. Es installiert alle nötigen Komponenten und startet weitere Setup-Skripte.

• /data: Dieses Verzeichnis mappt innerhalb der Windows-VM auf einen UNC-Pfad (\\host.lan\Data). In diesem Verzeichnis liegen die Quellen des mateo-Repository. Dieser Zugriff ist mit hoher Geschwindigkeit möglich.  Allerdings bringt das Verzeichnis Einschränkungen beim Ausführen von Windows-Skripten mit sich, wenn sie direkt unter diesem Pfad liegen.

Herausforderung: Zugriff auf den aktuellen Repository-Stand im Container

Ein essenzieller Punkt war, den aktuellen Stand eines bestimmten Branches in den Container zu bringen und dort ausführen zu können. Die direkte Mount-Lösung scheiterte an Performance-Problemen und der UNC-Pfad-Einschränkung:

• Mounts des Repositories über /oem  dauerten sehr lange

• Skripte direkt unter dem UNC-Pfad /data zu starten, ist problematisch

• Das Kopieren des Repositories vom UNC-Pfad in ein anderes Verzeichnis im Container verursachte zusätzlichen Overhead

Die Lösung: Auf dem Ubuntu-Host wird eine virtuelle Festplatte (disk.vhdx) erzeugt und mit NTFS formiert. Das Repository wird direkt in dieses gemountete VHDX Image ausgecheckt. Somit spiegelt die virtuelle Festplatte immer den aktuellen Projektstand wider. Diese Festplatte wird dann per /data in den Container eingebunden und dort mit Windows als lokales Laufwerk eingehängt. Auf diese Weise entfallen zeitraubende Kopiervorgänge und Skriptausführungen finden auf einem “lokalen” Laufwerk statt. Mit einem Checkout des Repositories auf dem Ubuntu-Host wird die docker-compose.yml (unter .github/workflows/windows/docker-compose.yml) für den Containerstart verfügbar gemacht.

Ablauf beim Start des Containers

1. Das Skript install.bat im Verzeichnis /oem wird automatisch gestartet

2. Es bindet die virtuelle Festplatte mit dem ausgecheckten Repository als lokales Windows-Laufwerk ein – so sind die Projektdateien schnell und ohne Kopie verfügbar

3. Anschließend installiert das Skript alle erforderlichen Abhängigkeiten für die Tests

4. Zum Schluss werden die Integrationstests in der Windows-VM ausgeführt

Während des Ablaufs werden umfangreiche Logs erzeugt, die auf dem Ubuntu-Runner eingesehen werden können.

Manuelle und lokale Testausführung

Neben der automatischen Ausführung über Zeitpläne lassen sich die Tests auch manuell per workflow_dispatch-Event triggern, wobei beliebige Branches getestet werden können. Für die lokale Ausführung steht ein Zip-Archiv bereit, das neben install.bat, der disk.vhdx und der docker-compose.yml alle nötigen Dateien enthält. Voraussetzung für die Nutzung ist ein Google-Cloud-Zugriff. Im lokalen Setting startet man den Windows-Container mit docker compose und wartet, bis das Setup abgeschlossen ist, bevor die Tests ausgeführt werden.

Fazit

Das beschriebene Setup zur Ausführung von Windows-basierten Integrationstests in einer GitHub Actions Pipeline ist technisch anspruchsvoll, und konnte erfolgreich umgesetzt werden. Der Einsatz einer virtuellen NTFS-Festplatte in Kombination mit dockur/windows ermöglicht den produktiven Betrieb der Tests, ohne dass Windows-VMs außerhalb der Pipeline kostenintensiv gepflegt werden müssen.