Bezüglich des Updates der Discourse-Quelldateien, der Abhängigkeiten auf Betriebssystemebene, des Docker-Basisimages, der Ruby-Gems und ähnlicher Komponenten ist es möglich, den Build in zwei Schritten durchzuführen und die oben genannten Aufgaben im ersten Schritt auszuführen.
Dieser erste Schritt ist unabhängig von der Umgebung und könnte sogar in einer CI-Umgebung ausgeführt werden (so dass Sie in den Staging- und Produktionsumgebungen fast identische Images verwenden können, was mögliche Fehler durch Builds zu unterschiedlichen Zeitpunkten vermeidet, ganz zu schweigen von der reduzierten Ausfallzeit).
Die DB-Migration und die Aufgabe assets:precompile müssten weiterhin auf der Zielmaschine ausgeführt werden. Die DB-Migration ist in den meisten Fällen schnell. Die Aufgabe assets:precompile stellt hingegen ein Problem dar, da sie den meisten Zeit in Anspruch nimmt. Ich vermute, dass dies daran liegt, dass einige Assets Umgebungsdaten benötigen, die in der DB definiert sind, wie z. B. bestimmte CSS-Regeln, um ausgeführt werden zu können.
Es wäre hervorragend, wenn diese Aufgabe in zwei Teile zerlegt werden könnte: Zuerst werden alle Assets kompiliert, die nicht von der Umgebung abhängen, und könnten somit in einer CI-Umgebung ausgeführt werden. Im zweiten Schritt würden dann nur noch die Assets kompiliert, die von Daten in der DB usw. abhängen. Wie technisch aufwendig eine solche Implementierung wäre, weiß ich jedoch nicht.
Ich diskutiere das Bootstrapping des App-Containers in zwei Schritten im folgenden Thema:
Die von mir vorgenommenen Änderungen betrafen lediglich die Aufteilung der Discourse-Web-Vorlage in drei Dateien, wobei die Aufgaben gleich bleiben. Es wäre jedoch großartig, wenn das Discourse-Team dies unterstützen würde, damit ich die Aufgaben nicht aufgrund zukünftiger Änderungen an der Web-Vorlage aktualisieren müsste.