CONAN der Erfolg-Zerstörer

« | 06 Oct 2019 | »

Wenn man in der CONAN Build Pipeline folgenden Fehler sieht:

‘NoneType’ object has no attribute ‘token’

so ahnt man noch nicht, dass einem das letztendlich den Tag versauen wird.

---

Meine Firma möchte nun weiter Projekte auf CONAN migrieren und somit wird einiges an Ressourcen in diese ehrgeizige Ziel investiert.
Und nun, wo die ersten Erfolge hergezeigt werden können, freut man sich über die angewendete Änderung des Buildsystems.

Und dann tauchen plötzlich Fehler auf, die sich niemand erklären kann.

Voraussetzungen

Bibliotheken wie die ZLIB werden angenehmerweise schon im Internet fix fertig als CONAN Paket angeboten. Folglich setzt man eine Abhängigkeit zur externen Quelle des Softwarepaketes.

Wenn ein Build-Prozess läuft, lädt CONAN die neuen Sourcen und Binaries aus dem Internet und integriert sie als Includes für die Kompilierung und das Linken des Projektes.

So die Theorie, die bis vor Kurzem auch gelebte Praxis war. Doch mit der neuen Fehlermeldung 'NoneType' object has no attribute 'token' war dies wohl nicht mehr so.

Das Problem

Nach langem Herumexperimentieren ohne Erfolg, startete ich eine Suche im Internet. Und siehe dar, auch andere Menschen (wenn auch wenige) meldeten Problem mit CONAN beim Zugriff auf externe Quellen.

Und nach vielen vielen gelesenen Beiträgen, poppte plötzlich die Meldung auf, dass dieses Problem an HTTP Umleitungen liegt.

Ja, ernsthaft … CONAN kommt mit HTTP 301/302 Statuscodes nicht klar.
Und offenbar haben die Server-Betreiber unseres CONAN Paketes neulich eine solche Umleitung gesetzt.

Jetzt wird natürlich stets dazu geraten, sofort die neueste Version von CONAN zu installieren, da laufend Fehlerchen dieser Art korrigiert werden, doch das ist im Firmennetzwerk nicht so einfach.
Wer kennt nicht die bürokratischen Hürden einer Konzernstruktur, wenn man “ganz schnell” ein Softwareupgrade einführen möchte.

Die Lösung

Für uns gibt es momentan keine Lösung. Doch wir nutzten einen Workaround.

Die betroffenen CONAN Pakete wurden mit dem Browser heruntergeladen und manuell mit allen Sourcen in unser eigenes jFrog Repository hochgeladen.

Anstatt die Daten aus dem Netz zu laden, laden wir sie von unseren eigenen Servern beim Buildprozess herunter. Und da hier keine HTTP Umleitung erzwungen wird, hat auch CONAN kein Problem damit.

Dazu muss am Ende nur die Paket-Abhängigkeit von z.B.: zlib/1.2.11@conan/stable
auf
zlib/1.2.11@our-server-id/stable
gesetzt werden.

Gefahr erkannt, Gefahr gebannt.

Fazit

Nur besonders zufrieden stimmt mich der Sachverhalt nicht.

HTTP Umleitungen werden gerne bei der Programmierung vergessen (ist mir ja auch schon passiert), und dann kommt es zu Abbrüchen, die schwer nachvollziehbar werden.

Ich kann daher nur empfehlen, bei der Nutzung von HTTP Bibliotheken immer nach der Konfiguration zu sehen, ob Redirection automatisch behandelt werden oder nicht.

Und die CONAN Entwickler werden dieses Problem hoffentlich bald gelöst haben und einen Patch oder ein neues Release ausrollen.