Dependency caching for SOLR in GitHub Actions workflow

[j3nsch]

Für jeden Build wird Apache Solr heruntergeladen. Das sollte vermieden werden. Es muss geprüft werden, ob es möglich ist die Downloads nur bei Bedarf durchzuführen. Dabei sollte auch klar sein, wie der Cache gelöscht werden kann.

https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

[j3nsch]

Wie woanders schon gesagt, beim Umstieg auf SOLR 9, können die Download-Zeiten beträchtlich sein. Wenn das für SOLR klappt, können wir vielleicht etwas ähnliches auch für Composer, .vendor machen.

[j3nsch]

Mir ist egal wer sich das anschaut, aber es beeinflusst die Effektivität der Entwicklung und ist daher wichtig.

[j3nsch]

Für einen Vagrant-VM Build hat der Download jetzt gerade 30 Minuten gedauert.

[extracts]

Die Download Geschwindigkeit ließe sich wohl deutlich verbessern, wenn man https://dlcdn.apache.org/solr/solr/ verwendet (siehe dazu auch Kommentar zu 108). Das ginge aber eventuell jeweils nur für den aktuellen Solr Release. Ich werde es auch mal mit https://www.apache.org/dyn/closer.lua/solr/solr/9.4.0/solr-9.4.0.tgz?action=download ausprobieren.

[extracts]

Zeitlicher Unterschied für den GitHub Workflow Step "Install Solr 9.4.0":
mit alter Download URL: knapp 18 Minuten
mit neuer Download URL: 32 Sekunden

[j3nsch]

Gut, das werden wir dann auch für Vagrant ändern. Trotzdem ist es sinnvoll das Caching zu testen und gegebenenfalls einzusetzen.

[j3nsch]

SOLR 7.7.3 wird weiterhin über die Archive-URL heruntergeladen. Die aktuelle Version wird über das CDN herunter geladen. Im CDN ist nur die aktuelle Version verfügbar. Das heißt sobald eine neue Version veröffentlicht wird, brechen unsere Builds unter Umständen. Das ist also noch nicht ideal. Caching würde da auch erst einmal helfen.

Vielleicht kann das Skript auch so umgesetzt werden, dass das Archive als Fallback verwendet wird, wenn die CDN URL nicht funktioniert. Oder löst der Resolver, "closer.lua" das Problem bereits? Es funktioniert für 9.3.0, aber nicht für 7.7.3. Sobald wir den PHP 7 Support aufgeben, kann das erst einmal wieder vereinfacht werden.

[extracts]

Oder löst der Resolver, "closer.lua" das Problem bereits?

Ja, soweit ich es verstehe und auch getestet habe, funktioniert der Resolver für den aktuellen Release als auch für ältere Release-Versionen. Allerdings werden ältere Release-Versionen stets über das langsamere Archiv heruntergeladen.

[j3nsch]

Erläutere hier mal bitte noch in 2 Sätzen die Funktion. Was passiert, wenn die Versionsnummer von Solr geändert wird?

[extracts]

Das tests/bin/install_solr_docker.sh Skript lädt die per --version Parameter angegebene Solr Version (falls sie noch nicht im ./downloads Verzeichnis existiert) herunter und speichert sie im ./downloads Verzeichnis.

Wird die Solr Version im GitHub Workflow geändert, so lädt das Skript diese Solr Version ebenfalls in das ./downloads Verzeichnis herunter.

Am Ende eines erfolgreich durchgelaufenen Workflows werden die Inhalte des ./downloads Verzeichnisses (für bis zu 7 Tage) gecached. Bei einem nächsten Durchlauf des Workflows werden (falls vorhanden) die gecachten Inhalte des ./downloads Verzeichnisses wieder hergestellt, wodurch das tests/bin/install_solr_docker.sh Skript den Download der aktuell verwendeten Solr Version nicht erneut durchführen muss.

[j3nsch]

Zwei Sätze? :-) Danke. Ich denke, der wichtige Punkt, der fehlt, ist, ob die beiden Solr-Dateien im gleichen Cache landen und damit die alte Datei für immer aufgehoben wird oder ob für unterschiedliche Versionen unterschiedliche Caches verwendet werden.

[extracts]

Soweit ich die Doku verstehe, existiert für denselben Cache Key (im selben Branch) nur ein Cache. D.h. die beiden Solr-Dateien landen (mit unterschiedlichen Namen) im selben Cache.

[j3nsch]

Das wäre ein Problem, aber der Key, in der Umsetzung im PR, ist abhängig von der Solr-Version. Das heißt die Dateien sollten in unterschiedlichen Caches landen und damit die alte Version automatisch verschwinden.

[extracts]

Ja, das ist korrekt, der Key basiert aktuell auf der Solr Version.

[j3nsch]

Gut.