Build Server Marke Eigenbau

Java, Ruby, Python, dotNet … also, wie es aussieht, gibt es heute keinen einzigen Build-Server, der ordentlich (sprich effizient) programmiert ist, also in C oder C++.
Damit ist von GitLab über Jenkins bis zu TeamCity keiner geeignet auf meinen Intel Atom Servern zu Hause zu laufen.

Es kann doch nicht so schwer sein, ein CMake Build in Docker selbst anzustoßen. Also bauen wir uns das selbst, so wie es sich gehört.


Tja und tatsächlich. Es funktioniert.

Und weil die Details den Rahmen eines BLOG-Eintrags sprengen würden, wurde das Thema zu den Nebenschauplatz-Dokus verlegt:

Build Server Scripting

Diverse Erkenntnisse

  • Windows Server Core Image verdoppelt sich.
    Ein übliches Server-Core Image liegt bei etwa 5 GB, doch nach der VS-BuildTools Installation meldet docker image list Größen von 9 bis 11 GB. Konkret wächst Visual Studio mit jeder Version um ein 1 GB (von 2017 über 2019 bis 2022).

  • docker run kann keine Mehrfachbefehle verkraften.
    Ich bin an cd subdir && run_script.bat total gescheitert. Das klappt wunderbar im Dockerfile und auch so auf der Konsole, aber wenn man es mit docker run myimage cd subdir && run_script.bat kombinieren möchte, will es ums Verrecken nicht ausführen. Dabei habe ich unzählige Kombinationen von ENTRYPOIN mit cmd /s /c und mit jeder Form von Anführungszeichen ausprobiert. So ein F*ck!

  • CMake ist nix für Intel Atom.
    Gut, das wusste ich schon früher … aber bei meine Experimenten störte mich am Meisten, dass CMake für jeden seiner Tests, ob eine Funktion existiert, ein separates Kompilat anfertigt. Und dank der libReSSL gibt es davon zahlreiche, bevor das GATE Projekt übersetzt werden kann. 3-5 Minuten dauert das auf meinem Strom-Sparefroh-Rechner … und wenn man das 20 Mal machen muss, ist das kein Vergnügen.

  • Hyper-V Isolation auch für docker build Am Windows Server baut man normalerweise alles für die eigene Windows Version. Dass docker run --isolation=hyperv auch Container von “fremden” Kernel Versionen starten kann, wusste ich bereits. Aber nun konnte ich beobachten, dass docker build --isolation=hyperv ... auch solche Images erzeugen kann.
    However … schnell ist das auf meiner Hardware allerdings nicht gewesen.

  • CMake ist bei Studio 2017 nur in Version 3.12 integriert. Ich musste daher eine neuere Version nachschließen. Das geht aber ganz leicht per Download und Installation von https://github.com/Kitware/CMake/releases/download/v3.21.3/cmake-3.21.3-windows-x86_64.msi :

    1RUN `
    2  curl -SL --output cmake.msi `
    3  https://github.com/Kitware/CMake/.../cmake-3.21.3-windows-x86_64.msi `
    4  && msiexec.exe /i cmake.msi /quiet /qn `
    5  && del /q cmake.msi `
    6  && setx PATH "C:\Program Files\cmake\bin;%PATH%"
    

Fazit

Nun, ich bin zufrieden, das ich wieder mal ein Problem gelöst habe, das sonst niemand als Problem klassifizieren würde. Aber … “Warum leckt sich der Hund die Eier?”
“Weil er es eben kann!”

Und da mein Domain Controller ja sowieso den Großteil des Tages nichts zu tun hat, darf er nun täglich per Task-Scheduler einen GATE-Windows-Build durchrechnen.

Ich freue mich, dass ich beweisen konnte, dass Buildserver auch “nur mit Wasser kochen”. Und sollte dennoch irgendwann mal der Auftrag auf mich zukommen einen Build-Server ohne Build-Server aufzusetzen, habe ich bereits etwas Vorsprung.


Meine Dokus über:
 
Weitere externe Links zu:
Alle extern verlinkten Webseiten stehen nicht in Zusammenhang mit opengate.at.
Für deren Inhalt wird keine Haftung übernommen.



Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!