Nachdem ich mein Build-Ökosystem hin zu Gitlab migriert habe, habe ich nun den nächsten Schritt in Angriff genommen: Continuous Integration oder kurz: CI...

Das wollte ich eigentlich zunächst nur in ganz kleinem Rahmen betreiben: Für statische Codeanalyse. Auf Arbeit wird auf unserem Buildserver dazu Findbugs benutzt. Da dies aber die Analysen auf JAR-Dateien ausführt, müsste man dazu erstmal solche haben.

Meine ersten Versuche führte ich daher mittels PMD aus - das wurde aber schnell langweilig: Das Finden, welche Regeln für mich sinnvoll sind stellte sich als (mich) enorm ermüdende Angelegenheit heraus. Daher überlegte ich, das bereits in meinem Projekt befindliche Target sanitycheck auf die Gitlab-Pipelines und Jobs abzubilden.

Das stellte sich als Arbeit heraus, die mich fast einen ganzen Tag kostete - das lag aber wohl vor allem an der Tatsache, dass ein Build-System, das jahrelang gewachsen ist und aus mehreren ineinander verflochtenen Ant-Skripten besteht, nun einmal nicht so einfach auseinanderzunehmen ist.

Auch wenn das Vorhaben fehlgeschlagen wäre: ich habe dadurch in besagten Ant-Skripten einmal kräftig aufräumen können - bereits das wäre die Arbeit wert gewesen.

Bevor ich auf die Details eingehe - hier die wichtigsten Erkenntnisse, die ich gewonnen habe:

• Innerhalb eines Jobs werden die Verzeichniswechsel nicht zurückgenommen - zwischen Jobs schon: Jeder Job beginnt im Top-Level-Verzeichnis des ausgecheckten Projektes
• Dateien, die in einem Job innerhalb der ausgecheckten Hierarchie erzeugt werden (generierte Quelltexte zum Beispiel) stehen im darauf folgenden Job nur dann zur Verfügung, wenn sie als Artefakte markiert werden
• Man sollte daran denken, dass man nur Java-Unit-Tests als Teil von Pipelines ausführt, die keine Graphische Oberfläche benötigen (Stichwort: headless!)

Nun aber zu meinem Setup: Es sollte folgende Dinge tun:

• Annotation-Prozessoren bauen
• Quelltexte mittels Annotation-Prozessoren erzeugen
• Alle Quelltexte übersetzen und Jars erstellen
• Anwendungen sQLshell und dWb+ erstellen
• Unit-Tests ausführen
• Dokumentation für dWb+ und Aviator erstellen

Alle diese Aspekte konnte ich unter Zuhilfenahme der bestehenden Ant-Skripte mittels des in diesem Gist niedergelegten Skripts realisieren.

Findbugs ist noch nicht integriert - ich wollte zunächst ein Stadium erreichen, das mein altes Ant-Target sanitycheck abbildet. Findbugs wird der nächste Schritt sein...

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )