conan cache save

Conan v1 hatte in meiner Firma einen gravierenden Nachteil, wenn es um CI/CD Build Pipelines ging:

Wie kann man Pakete lokal exportieren speichern? Anwort: Gar nicht. Nur Uploads ins Artifactory und anschließend Downloads sind gestattet.

Zum Glück haben die Conan v2 Macher dieses Problem aufgegriffen und gelöst.


Im Internet ist Sache mit CONConanN einfach:
Ein Conan Rezept definiert, wo Quellcodes abgelegt sind, und welche Abhängigkeiten und Einstellungen für das Kompilieren der Codes benötigt werden.

Der Nutzer eines Conan Pakets bekommt mit conan install alles Notwendige heruntergeladen und auch gleich alle Bibliotheken mit dem eigenen Compiler gebaut.

Doch … bei mir sahen die Anforderungen ganz anders aus.

Prebuilt binary packages

Bei großer Enterprise-Software können wir nicht unzählige Pakete jeden Tag neu bauen, wir benötigen fertige getestete Bibliotheken für jeden Compiler und für jede unterstützte Plattform.

Aus diesem Grund wurden CI/CD Pipelines eingerichtet, die alle Varianten eines Lib-Projektes erzeugten, abtesteten und dann für die weitere Verwendung ins lokale jFrog-Artifactory hochluden.

An dieser Stelle musste eine Grenzlinie gezogen werden:
Pakete aller Plattformen durften nur dann gemeinsam hochgeladen werden, wenn alle (und zwar wirklich alle) Builds erfolgreich durchgelaufen waren.

In Conan v1 konnte man ein Paket aber nur per conan upload “abspeichern”, und somit mussten wir für die Builds ein temporäres Respository anlegen, das erst mal alles annehmen sollte.
Wenn alle Builds fertig waren, startete ein weiterer Job, der wieder alle temporären Builds herunterlud und ins eigentliche Zielrepo hochladen sollte. Beim einem Fehler eines Jobs wurden einfach alle temporären Builds gelöscht und der Entwickler durfte das Problem suchen.

Effizient war diese Vorgehensweise nicht … aber sie war besser als alle anderen Alternativen, wo die Conan-Caches manuell in den nächsten Job verschoben wurden, wo es dann zum Zusammenprall mit den anderen Builds kam.

Cache save/restore

Conan 2 führt zum Glück zwei Kommandos ein, mit denen der Conan Cache Inhalt extrahiert werden kann, und zwar auf Paket-Ebene.
So können wir beim Ende eines Build-Prozesses das lokale Paket mit conan cache save -f file.tar.gz extrahiere und als .tar.gz zwischenspeichern.
Dieses “Artefakt” kann nun über die nativen Funktionen der Datenweiterreichung des Build-Systems zu einem Folgejob geschoben werden, der mit conan cache restore -f file.tar.gz alle Build-Resultate importiert und gemeinsam ins Ziel-Repository hochlädt.

Hinweis: Es schadet nicht das Paket im Cache von Source- und Build-Resten zu befreien. Ein conan cache clean "*" erledigt das recht zuverlässig.

Fazit

Es sind oft die kleinen Dinge, die große Erleichterungen bringen. Ein conan upload wirkt nicht viel umständlicher als ein conan cache save, doch in der Praxis braucht man viele weitere Infos wie unterschiedliche Ziel-Repos und zusätzliche Build-Cleanup Jobs.

Mit der conan cache save/restore und der Nutzung von nativen Build-Artifacts für die Weitergabe der Daten vereinfachten sich unsere Build-Scripts um einiges.

In diesem Sinne:

Danke an das Conan 2 Team für dieses wichtige neue Feature!

📧 📋 🐘 | 🔗 🔔
 

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!