Berücksichtigung von Sprachdateien bei einem Git-Deployment überdenken?

[ams-tschoening]

Ich habe Contao 3.5.0 durch das Klonen des Git-Repos und Auschecken des entsprechenden Branches installiert, Composer für die Abhängigkeiten genutzt und dann Check ausgeführt, um die Installation zu verifizieren. Dabei wurden mir zuerst alle Sprachdateien außer Englisch aus fehlend angemeckert, weil die nicht mit versioniert werden. Ich habe mich also des Transifex-Clients angenommen, alle Sprachen herunter geladen und danach wurden die mir aber als korrupt angemeckert, obwohl die per originalem Client gekommen sind und dieser bei nachfolgenden Aufrufen auch keine Fehler vermeldet oder so, sondern die bereits vorhandenen Sprachen einfach ignoriert. Den Client habe ich per apt-get install transifex-client bezogen und die Dateien per tx pull -a.

In meinem Szenario brauche ich auch nicht unbedingt mehr Sprachen als das per Git ausgelieferte Englisch, in keinem Fall brauche ich aber mehr als Deutsch. Check scheint sich aber an den Release-Archiven zu orientieren, was bei einem Git-Deployment nicht bis ins letzte Detail passen muss.

Ich habe also zwei Probleme: Ich muss mehr Sprachen herunterladen als ich brauche, nur um Check glücklich zu machen, wenn ich das aber mache, scheint der Download nicht mal vergleichbar mit den Release-Archiven. Letztendlich kriege ich so oder so von Check also eine unnötig lange Liste mit Meldungen, in denen wirklich interessante leicht untergehen könnten.

Wäre es daher nicht sinnvoller, für Git-Deployments die Sprachdateien optional zu machen? Man bräuchte dafür ja nicht einmal eine aufwendige Konfiguration oder so, sondern könnte einfach das Vorhandensein eines Git-Repos für Contao selbst erkennen und dann darauf hinweisen, dass Sprachdateien aus technischen Gründen nicht geprüft werden. Wenn mein Prozedere richtig und der Download der Sprachdateien nicht vernünftig reproduzierbar ist, kann man die eh nicht prüfen, weil man ja keine Hashes als Referenz hat.

Welche Dateien zu ignorierende Sprachdateien sind, könnte man theoretisch wiederum der Datei .tx/config aus dem Contao-Verzeichnis entnehmen, dort müssen ja alle aufgeführt sei. Alles, was den dort aufgeführten Pfaden mit Platzhalter <lang> entspricht, wird aus den JSON-Dateien mit Vergleichsdaten zur Laufzeit bei der Durchführung der Prüfung selbst einfach entfernt und damit ignoriert.

Ganz allgemein scheint Check auf ein Git-Deployment nicht so richtig vorbereitet zu sein, denn die Dateien vendor/autoload.php und vendor/composer/autoload_real.php werden bei mir auch angemeckert, weil sie auch lokal generiert wurden.

Meinungen?

[BugBuster1701]

Du hast das schon richtig erkannt meiner Meinung nach, Contao Check ist für offizielle Contao Versionen gedacht. Nicht für Entwickler Installationen per git clone, GitHub ist nunmal eine Entwickler Plattform. Das Leo unter "release" auch die kompletten Versionen inkl. der Vendors und Sprachen ablegt, ist seine Entscheidung. Das nach einen tx Aufruf die Checksummen für die Sprachen nicht stimmen müssen ist auch klar, die können ja mittlerweile ebenfalls weiter entwickelt/übersetzt worden sein.

Im übrigen, du kannst auch gezielte Sprachen mit dem tx Client laden, du mußt nicht alle nehmen. tx pull -l de nur für deutsch.

[ams-tschoening]

Ich betreibe mein Contao produktiv, aus Git heraus lassen sich Updates einfach wesentlich einfacher mergen, als mit Verzeichnissen oder Zips über FTP oder solchem Käse hantieren zu müssen. Die Frage ist also einfach nur, ob man Check wirklich auf irgendwelche speziellen Release-Archive ausrichten möchte oder nicht. Da es absolut üblich ist, Webanwendungen aus Versionsverwaltung heraus zu deployen, erscheint mir das unnötig und wenig hilfreich.

Dass ich nur spezielle Sprachen laden kann, habe ich gesehen, bringt mir aber nichts, weil Check dann alle anderen eben als fehlend anmeckert.

[BugBuster1701]

Und? Du weißt doch das es richtig ist, dass diese fehlen. Ansonsten für einfache und praktische Updates gibt es das Live-Update, oder auch in einfacher Art und nicht Major-übergreifend das easyUpdate3.

[ams-tschoening]

Richtig, das weiß ich, ich nutze Check ja aber um zu prüfen, ob halbwegs alles in Ordnung ist und dann ist es wenig sinnvoll, dass ich aus Hunderten zu ignorierender Einträge den einen finden muss, den ich eigentlich nicht ignorieren möchte. Und theoretisch kann Check dieses Problem ja lösen...

[ams-tschoening]

Dann mal anders: Was prüft Check denn alles bei der Validierung der lokalen Installation? Auf flüchtige Blicke in Validator hinein sieht es so aus, als würden nur die Release-Dateien geprüft. Darauf kann ich dank git status dann natürlich verzichten und dann kann man problemlos sagen, dass Check dafür einfach nicht genutzt werden soll.

Streng genommen könnte man ja aber auch so Dinge wie das Vorhandensein aller nachträglich installierten Moduldateien prüfen usw. Wenn das aber nicht der Fall ist, nutze ich es für die lokale Validierung einfach nicht mehr.

[BugBuster1701]

als würden nur die Release-Dateien geprüft.

richtig. git status hilft dir aber auch nur wenn Änderungen nicht committed sind.

Sicherlich könnte man den Check etwas tunen, das dieser beispielsweise nur mit einer Zeile erwähnt das eine ganze Sprache, von mir aus je Modul und Core, nicht vorhanden ist, wenn das genau der Fall wäre. Andererseits wie gesagt ist der dazu da, genau die Release Version zu checken, wo zu Anfang ja alles dabei ist, bevor man dann beispielsweise anfängt überflüssige Sprachen zu löschen (mach ich per cron). Speziell wenn man über den Check gleich Contao noch installiert hat, kann man gleich prüfen ob das alles erfolgreich war.

[ams-tschoening]

Committete Änderungen haben per Definition (erst mal) ihre Richtigkeit, darüber mache ich mir weniger Sorgen. Fehlende Dateien und nicht committete Änderungen sind da schon interessanter und genau dagegen hilft git status dann ja gleichermaßen und Sprachdateien kann ich einfach jederzeit beliebig herunterladen.

Wie wäre es also stattdessen einfach mit ein bisschen mehr Doku für diesen Fall? Man kann ja einfach hinschreiben, was der Validator macht, dass das für git-Deployments aus diversen Gründen nicht gedacht ist und man stattdessen git status nutzen sollte, das hat man ja eh. Dann dürften alle Unklarheiten wie meine beseitigt sein. Ich schreibe das auch gern selbst.

[frontendschlampe]

Der Check ist aber grundsätzlich für den "normalen" User - der will das Ding einfach hochladen und schauen, ob seine Installation in Ordnung ist bzw. prüfen, ob sein Webpaket für Contao geeignet ist. Der User selbst und wahrscheinlich auch der Webspace haben noch nie was von GIT gehört! Das ein Poweruser andere Voraussetzungen hat, steht außer Frage. Das sollte man bedenken!