Release-Pipeline für spielbare Versionen erstellen

[AMatutat]

Es soll eine Release-Pipeline eingerichtet werden, eine GitHub CI, die manuell ausgelöst werden kann (z. B. über ein Label).

Die Pipeline baut die verschiedenen spielbaren Versionen (JARs inklusive JRE) und pusht sie in Orphan-Branches. Dabei muss geprüft werden, welche JARs gebaut werden müssen.

Für jedes Projekt (produs/lescrod) soll jeweils ein eigener Branch existieren, mit Unterverzeichnissen für macOS, Linux und Windows.

Ziel ist es, eine einfache „Hier lad dir das runter“-Version bereitzustellen. Wenn der Workflow erneut ausgeführt wird, werden die Inhalte im Orphan-Branch entsprechend ersetzt.

[fabianprojects]

Bei der Umsetzung der Release-Pipeline sind wir auf einige Probleme gestoßen. Github erlaubt im Repo nur Dateien, die kleiner als 100mb sind. Die fertige Jar Datei für Blockly umfasst rund 250mb. Die Jar Datei kann man noch weiter verkleinern, da besonders Bilddateien und Sounddateien viel Speicherplatz einnehmen.
Um besser erkennen zu können, was wieviel Platz einnimmt, habe ich die Datei einmal entpackt und analysiert.

Im entpackten Zustand ist die Datei natürlich größer. Besonders die Popups und dieser .com Ordner nehmen sehr viel Speicherplatz ein. Man kann das natürlich alles noch ein wenig optimieren, jedoch ist fraglich, ob man am Ende unter die 100mb kommt. Wichtig ist auch, dass das JRE in der Jar noch nicht enthalten ist. Fügt man das noch hinzu, steigt die Größe nochmal um mindestens 50mb.

Damit man größere Dateien hochladen kann, bietet Github Git Large File Storage an. Hier könne auch größere Dateien im Repo gespeichert werden, jedoch ist der Speicherplatz und die Bandbreite stark eingegrenzt. Die Maximale Bandbreite pro Monat liegt bei 10gb und der Speicherplatz bei 10gb. Das heißt, wenn man 5 Jars mit jeweils 100mb erstellt und nur einer alle Pullt, sind schon 500 mb an Bandbreite weg. Das wird nicht reichen.

Alternativ zu den Orphan Branches kann man auch Releases machen. Hier ist der Vorteil, dass eine Release Datei bis zu 2gb groß sein darf. Das würde für unsere Anforderungen reichen. Es gibt verschiedene Releases z.B. Draft Releases oder auch offizielle Releases. Draft Releases könnte man für unser Team nutzen, damit jeder schnell auf eine ausführbare Datei zugreifen kann. Offizielle Releases könnte man dann für die Lehrkräfte oder Schüler bereitstellen. Denkbar wäre bei jedem Merge auf den Master eine Pipeline für die Draft Releases laufen zu lassen und für die offiziellen Releases einen Pipeline mit manuellem Trigger zu erstellen.

[AMatutat]

@cagix meinung? Für mich scheint die Datenbegrenzung ein K.O Kriterium.

[cagix]

ist die bandbreite bei lfs wirklich so winzig? wenn ja, dann werdet ihr um releases lieder doch nicht drumrum kommen.

[fabianprojects]

Ne ich hatte mich leider vertippt. Sind auch 10gb. Wird aber trotzdem knapp wenn viele Leute regelmäßig pullen

[cagix]

naja, dann macht halt releases.

@AMatutat bitte überlegt euch vorher aber bitte ein sinnvolles schema ... versionsnummern würde ich vermeiden wollen, weil das automatisch immer die fragen nach major/minor/... und die damit verbundenen oft sinnlosen diskussionen hochwirft. vielleicht sowas wie "2604" für das release im april 2026, und irgendwo gibts noch ne tabelle, was das ding im vergleich zur vorversion mehr kann und was gefixt wurde und so. ne liste mit pr/commits würde ich aber eher nicht anlegen, das kann man sich ja im github selbst raussuchen.

und was genau macht unsere jars so fett? was ist denn in "com" und "popups" drin?

[fabianprojects]

Also in Popups sind Bilder, die die Spielmechaniken erklären sollen. Die Bilder waren vorher im PNG Format und die habe ich in das JPG Format umgewandelt und noch ein wenig komprimiert. Aus den 150mb wurden 15mb. In dem "com" und "meta-inf" Ordner sind Bibliotheken. Ich bin mir unsicher, ob man diese noch ein wenig reduzieren kann.
Für den Multiplayer braucht man Netzwerkbibliotheken, die sehr viel Speicherplatz wegnehmen. Für jedes Betriebssystem braucht man eine eigene Bibliothek und standardmäßig sind in jedem Jar alle Biobliotheken für alle Betriebssysteme. Da könnte man vielleicht noch ein wenig optimieren.

Ich bin jetzt nach der Kompression von Bildern und einigen Sounddateien auf eine Größe von knapp 95mb gekommen. Da fehlt jedoch noch das JRE. Mit JLINK kann man die Größe vom JRE bei 30 - 50mb halten. Da sind im JRE nur die Funktionen enthalten, die man auch wirklich für das Projekt braucht.

Wenn man alles optimiert, wird es trotzdem schwierig werden unter den 100mb zu bleiben.

[cagix]

Also in Popups sind Bilder, die die Spielmechaniken erklären sollen. Die Bilder waren vorher im PNG Format und die habe ich in das JPG Format umgewandelt und noch ein wenig komprimiert. Aus den 150mb wurden 15mb.

wow. das ist ja mal anständig!

In dem "com" und "meta-inf" Ordner sind Bibliotheken. Ich bin mir unsicher, ob man diese noch ein wenig reduzieren kann. Für den Multiplayer braucht man Netzwerkbibliotheken, die sehr viel Speicherplatz wegnehmen. Für jedes Betriebssystem braucht man eine eigene Bibliothek und standardmäßig sind in jedem Jar alle Biobliotheken für alle Betriebssysteme. Da könnte man vielleicht noch ein wenig optimieren.

die frage ist, was das alles für geraffel ist und ob man das so wirklich braucht.

ich erinnere mich, dass mal irgendwer hier vor ner weile zu faul war, ne einfache pfadberechnung oder sowas zu machen und stattdessen lieber eine riesige apache bibliothek für den einen funktionsaufruf einbinden wollte 🙈 ...

auf der anderen seite bindet das jetzt ne menge energie, die wir im projekt ziemlich sicher für andere dinge brauchen.

Ich bin jetzt nach der Kompression von Bildern und einigen Sounddateien auf eine Größe von knapp 95mb gekommen. Da fehlt jedoch noch das JRE. Mit JLINK kann man die Größe vom JRE bei 30 - 50mb halten. Da sind im JRE nur die Funktionen enthalten, die man auch wirklich für das Projekt braucht.

Wenn man alles optimiert, wird es trotzdem schwierig werden unter den 100mb zu bleiben.

und selbst das nutzt uns bei einem limit von 10gb für traffic nicht, oder? das wäre nach ca. 100 downloads im monat auch alle.

[AMatutat]

@AMatutat bitte überlegt euch vorher aber bitte ein sinnvolles schema ... versionsnummern würde ich vermeiden wollen, weil das automatisch immer die fragen nach major/minor/... und die damit verbundenen oft sinnlosen diskussionen hochwirft. vielleicht sowas wie "2604" für das release im april 2026, und irgendwo gibts noch ne tabelle, was das ding im vergleich zur vorversion mehr kann und was gefixt wurde und so. ne liste mit pr/commits würde ich aber eher nicht anlegen, das kann man sich ja im github selbst raussuchen.

Bin ich bei dir. Das ist ein Release für „Spieler“, nicht für Coder.
Ich stelle mir am Ende irgendwie zwei Releases vor:

1. „Blockly Dungeon – Februar 2026“
2. „Escape the Dungeon – Mai 2026“

Und dann wirklich nur eine Liste der wichtigsten Änderungen für den User.
z. B.:
„Neuer Escape Room: CyberSecurity“ (und dann ggf. ein Link zur umfangreichen Beschreibungs-Doku)

Wenn wir intern eine API ändern etc., dann juckt das den Spieler nicht (ggf. braucht es dann nicht mal einen neuen Release).

Ich würde mich da an „richtigen“ Spiele-Patchnotes orientieren (z. B. https://www.leagueoflegends.com/en-us/news/game-updates/league-of-legends-patch-26-4-notes/).

Wie viel Mühe man sich bei der Gestaltung und Aufbereitung macht, würde ich mal offenlassen. Für große neue Features oder Escape Rooms evtl. mehr Mühe, für Bugfixes und kleine Änderungen eher weniger.

Gerade wenn wir Richtung Low-Code-Interface/Editor denken, sollten wir die neuen Möglichkeiten schon gut präsentieren.