Feature/GitHub workflow release

[dippeal]

Aufgrund des issues #39 habe zwei github workflows gebaut.

Mit dem ersten workflow wird ein offizielles Release erstellt. Dies geschieht manuell über Actions > "openjverein official release" > "Run workflow".

Es wird ein tag und ein release erstellt. Der Name des tags ist die Versionsnummer. Die Nummer wird aus dem Quellcode ermittelt. Der Name des Release ist "Release [Versionsnummer]". Es wird das kompilierte Plugin als Zip angehängt. Der Beschreibungstext wird automatisch anhand der commits zwischen diesem und dem letzten release erstellt.

Der zweite workflow "openjverein nightly release" erstellt ein nightly release. Es wird automatisch ausgeführt sobald 1. ein PR in den master überführt wird, oder 2. wenn ein push in den master erfolgt (commit push). Das nightly wird als pre-release gekennzeichnet. Tag und release werden immer überschrieben, solange sich die Versionsnummer von jverein nicht ändert.

Installation
Nach merge des PR wird die nightly action sofort ausgeführt. Es sind keine weiteren Anpassungen am Repository nötig.

Sonstiges
Die build.xml hat nun eine "nightly" und "lib" Methode.
Die Methode nightly erstellt im Ordner ./releases/nightly die folgenden Dateien:

• "jverein.[Version]-nightly.zip"
• "Source code (zip)"
• "Source code (tar.gz)
  Beim Ausführen des "official release" werden analog zur nightly die gleichen Anhänge, wie in der Auflistung, erstellt.

Die Methode lib erstellt die Datei "jverein-lib.jar" im Ordner ./releases.

Da Java 1.7 sehr veraltet ist, habe ich die Java Version in den build.properties auf 11 gesetzt.

Ich weiß es kann einiges am Code optimiert/verändert werden, aber es sollte soweit funktionieren.

[almereyda]

Glückwunsch zu dieser eleganten Lösung. Das sieht alles viel besser aus, als ich es mir vorgestellt hatte. Viele der Patterns sind neu für mich. Zu Java kann ich nichts sagen, aber mir gefällt das Plattformupdate auf die 11er Serie.

Um den Lerneffekt für mich zu erhöhen, kommentiere ich meine Beobachtungen im Code. Alle Kommentare auf nightly-builds.yml ließen sich ebenso auf release.yml anwenden.

Passen die Vorschläge das Zero Trust Berechtigungssystem zu verwenden eurerseits so?

Und habt ihr eine ähnliche Meinung bzgl. Rolling Releases für die nightlies und gepinnten Versionen für die stabilen Veröffentlichungen?

Einzig die Release Action marvinpinto/action-automatic-releases bereitet mir ein wenig Kopfzerbrechen. Sie erscheint schwer wartbar (öffnen von der minifizierten index.js killt meinen Browser, siehe der PR für automatische Release Notes) und hat lange keine Aktualisierungen gesehen. Ich benutze gerne ncipollo/release-action, aber es gibt auch google-github-actions/release-please-action und die zwei anderen, welche in der README der archivierten actions/create-release Action genannt werden.

Weiterhin denke ich, dass sich die hier gegebenen Beispiele auch gut auf

• Github Actions willuhn/jameica#37
• Github Actions willuhn/hibiscus#76

werden anwenden lassen, da beide hier schon beispielhaft mitgebaut werden. Vielleicht lässt sich das in Zukunft auch etwas entheddern, und hier auf OpenJVerein beschränken, indem versionierte Artefakte der anderen genutzt werden.

Ich habe mich sehr gefreut, als ich den PR gesehen habe, und denke das ist ein guter Satz nach vorne. Mit den gemachten Vorschlägen gedenke ich diesen noch etwas zu ergänzen.

Wie seht ihr das alles?

[almereyda]

PS: Die Screenshots sind von https://github.com/dippeal/jverein/actions & https://github.com/dippeal/jverein/releases?

[dippeal]

PS: Die Screenshots sind von https://github.com/dippeal/jverein/actions & https://github.com/dippeal/jverein/releases?

Ja. Allerdings nicht mehr komplett rekonstruierbar, da ich meinen master branch, auf den openjverein Stand, zurückgesetzt habe. Damit sind die workflows nicht mehr da.

[dippeal]

Der aktuelle PR Merge funktioniert wie gewünscht und kann geprüft & übernommen werden.

[almereyda]

Ich denke das ist gut herangereift.

Nur noch Kleinigkeiten:

Gibt es eine Möglichkeit Leerzeilen am Ende von Textdateien über alle IDEs und Systeme (Linux, mac, Windows) hinweg zu erzwingen?

Ließe sich vielleicht ein Git Pre-Commit Hook einbauen, der überprüft, dass alle in git enthaltenen Dateien diese Leerzeile haben?

Ich würde das wenn dann gerne in diesem Zyklus mit einbauen, damit es in Zukunft keine Frage mehr ist. Es fügt aber eine Dependency auf pre-commit hinzu.

https://github.com/pre-commit/pre-commit-hooks/blob/main/pre_commit_hooks/end_of_file_fixer.py

[BT-11]

Hi jon,
koenntest du bitte nochmal erklären warum am Ende aller files Leerzeilen hinzugefügt werden sollen?
ich kenne nur das übliche Problem mit den unterschiedlichen File-Endings bei Windows und UNIX. (Aber das ließe sich auch anders lösen.) Gruß

[almereyda]

Hallo BT-11. Danke für's nachfragen. Ich wollte den Kommentar erst an Ort und Stelle in die beiden Dateien anfügen, dachte mir dann aber das hier zu bündeln.

Wenn wir uns den Diff dieses PRs angucken, sehen wir am Ende von beiden Dateien eine Warnung:

https://github.com/openjverein/jverein/pull/83/files#diff-e780cb03e0575bf97176af613cf9b23d9337cc6a8d309a7475704fc756cfcce3R94

https://github.com/openjverein/jverein/pull/83/files#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34R86

Dies ist die gleiche Warnung die git ausgibt, wenn mensch git diff ausführt und keine Leerzeile am Ende einer Datei ist. Das Web ist leider zu voll von Referenzen auf "git No newline at end of file", weshalb ich mich auf eine oberflächliche Betrachtung beschränken möchte.

Dies waren die treffendsten Zusammenfassungen des Themas:

• unix - Why should text files end with a newline? - Stack Overflow C99
• unix - Why should text files end with a newline? - Stack Overflow POSIX

Leider scheint es auf git-scm.com oder auch in den GitHub oder GitLab Docs keine Erwähnung dessen zu geben.

git, und damit sein Diff Algorithmus, basieren auf C, welches definiert, dass eine Zeile immer mit einem Neue-Zeile-Zeichen enden muss, d.h. auch wenn sie leer ist. Es bereitet dem Diff Algorithmus zudem Probleme Änderungen korrekt zu verfolgen, wenn diese Leerzeile nicht existiert. Aus der obigen Quelle:

• 5.1.1.2 Translation phases — C99 Language Standard documentation
• POSIX | Definitions | 3.206 Line

[BT-11]

Hi Jon,
aus meiner über 20 jährigen Erfahrung als Java Develpoper kann ich sagen, dass dies ein bekanntes Problem mit dem unterschiedlichen Unix und Windows file-endings ist.
Auf keinen Fall ist die Lösung immer eine newline an die Datei zu hängen, wenn da keine ist.
Stattdessen bietet GIT die Möglichkeit das gut zu handhaben. Das server github repo sollte alle files im UNIX mode speichern. Beim clone prozess entscheidet dann git anhand des Zielsystem ob es automatisch file endings konvertiert. Bei einem push wird entsprechend nach unix konvertiert und das bei einem Diff auch berücksichtigt. Das as ist eigentlich Standard. https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to- handle-line-endings

[dippeal]

Können wir bitte erstmal eine Sache (diesen PR) abschließen und dann weitere Features in separaten issues/furture requests besprechen.

[almereyda]

Mir ist das bei meinem Review aufgefallen, deswegen stellte ich die Frage.

Hierbei geht es nicht um \cr\lf (Windows) oder \lf (POSIX) am Ende einzelner Zeilen, sondern um ein fehlendes \n am Ende der Datei nach dem letzten \n der letzten Zeile mit Buchstaben, weswegen GitHub und Git eine Warnung ausgeben. Darauf wollte ich hinweisen.

Wie wir damit umgehen steht uns ja frei.