Mozilla-Entwickler Tim Taubert hat am 9. August 2016 den Aufbau einer Taskcluster-CI für NSS erläutert. Die bisherigen Buildbots führten Builds und Tests nacheinander aus. Auf einzelnen Maschinen dauerte die Rückmeldung über mögliche Fehler dadurch zehn bis fünfzehn Stunden. Angestrebt werden 15 bis 30 Minuten, nicht als bereits belegtes Messergebnis.
Ein Build versorgt mehrere Testaufgaben
Die neue Struktur zerlegt große Testläufe in parallel ausführbare Aufgaben. Build-Tasks stellen Binärdateien als Artefakte bereit, die nachfolgende Tests herunterladen. Linux-Aufgaben laufen in Docker-Containern. Eine Decision Task erzeugt den Aufgaben-Graphen samt Abhängigkeiten. Repository-Pushes stoßen die Verarbeitung an; für Mozilla-gehostete Mercurial-Projekte beschreibt Taubert die Anbindung über mozilla-taskcluster.
TreeHerder zeigt Build- und Testergebnisse an. Ein zusätzlicher Bot informiert per IRC und E-Mail über Fehler. Neben Linux waren Windows-Aufgaben, statische Analyse sowie AddressSanitizer und LeakSanitizer bereits vorhanden. ARM-Worker befanden sich noch im Aufbau. Der Text ist ein Entwicklungsbericht, keine Ankündigung einer nummerierten NSS-Version.
Wiederverwendung reduziert unnötige Build-Arbeit
Für Entwicklungsteams ist die Trennung von Erzeugung und Prüfung übertragbar: Mehrere Tests können dieselben Binärdateien untersuchen, statt jeweils erneut zu kompilieren. Das spart doppelte Arbeit, ersetzt aber keine Prüfung von Abhängigkeiten und reproduzierbaren Testumgebungen. Parallelität allein garantiert weder kürzere Gesamtlaufzeiten noch bessere Testabdeckung.
Auch Unity Cloud Build unterstützte bereits mehrere Build-Ziele pro Projekt. Der NSS-Bericht behandelt einen anderen Schwerpunkt: die Aufteilung von Testläufen und die Weitergabe ihrer Eingabeartefakte. Für Spiele- und Toolteams sind beides Bausteine automatisierter Qualitätssicherung, aber keine austauschbaren Funktionen.