Update README.md

README.md

@@ -1,6 +1,6 @@
 # release action
-
-Gitea/Github-Action, die hilft das Veröffentlichen von Projekten zu automatisieren.
+Gitea/Github-Action, die hilft das Veröffentlichen von Projekten zu
+automatisieren.
 
 ## Features
   - Laden von Credentials und Einrichten der Runner-Umgebung
@@ -14,14 +14,14 @@ Gitea/Github-Action, die hilft das Veröffentlichen von Projekten zu automatisie
   - Anlegen von Git-Tags
 
 ## Verwendung
-Die Action erwartet eine Beschreibung des zu veröffentlichenden Projekts in `.gitea/release.yaml`.
-Darin werden folgende Eigenschaften beschrieben:
+Die Action erwartet eine Beschreibung des zu veröffentlichenden Projekts in
+`.gitea/release.yaml`. Darin werden folgende Eigenschaften beschrieben:
  - Welche Datei legt die aktuelle Version fest?
  - Welche Artefakte sollen veröffentlicht werden?
  - Welche Releases sollen wann aktualisiert werden?
 
 ### Beispiel für release.yaml
-```#!yaml
+```yaml
 # Die Version wird in der Datei Cargo.toml im Hauptverzeichnis des Projekts festgelegt
 version_descriptor: Cargo.toml
 
@@ -45,23 +45,30 @@ deployments:
     release_name: masa-images-testing
 ```
 
-Alle möglichen Einstellungen können [hier](https://gitea.puzzleyou.net/actions/release/src/branch/master/src/release/tests/assets/release.yaml) eingesehen werden.
+Alle möglichen Einstellungen können
+[hier](https://gitea.puzzleyou.net/actions/release/src/branch/master/src/release/tests/assets/release.yaml)
+eingesehen werden.
 
 ### Aufruf im Workflow
-Die Action kann die generischen Aufgaben bei einem Release übernehmen. Was sie nicht kann
-ist die Artefakte bauen. Wie das zu tun ist muss das Projekt selbst beschreiben.
+Die Action kann die generischen Aufgaben bei einem Release übernehmen. Was sie
+nicht kann ist die Artefakte bauen. Wie das zu tun ist muss das Projekt selbst
+beschreiben.
 
-Dafür gibt es zwei Möglichkeiten: Die Kurzform in einem Schritt und die Langform in mehreren Schritten.
+Dafür gibt es zwei Möglichkeiten: Die Kurzform in einem Schritt und die
+Langform in mehreren Schritten.
 
 #### Langform
 Wenn ein Projekt veröffentlicht wird, dann werden folgende Schritt ausgeführt:
-- `actions/release/declare`: Hier wird die `release.yaml` gelesen und die Credentials werden geladen.
-- `actions/release/sync-versions`: Hier werden die Versionen der Artefakte mit der Version des Projekts synchronisiert.
+- `actions/release/declare`: Hier wird die `release.yaml` gelesen und die
+  Credentials werden geladen.
+- `actions/release/sync-versions`: Hier werden die Versionen der Artefakte mit
+  der Version des Projekts synchronisiert.
 - Hier muss das Projekt die Artefakte bauen.
-- `actions/release/release`: Hier werden die Artefakte veröffentlicht, das Helm-Release aktualisiert und das Gitea-Release angelegt.
+- `actions/release/release`: Hier werden die Artefakte veröffentlicht, das
+  Helm-Release aktualisiert und das Gitea-Release angelegt.
 
 Beispiel:
-```#!yaml
+```yaml
 name: release
 on:
   push:
@@ -105,11 +112,13 @@ jobs:
 ```
 
 #### Kurzform
-Wenn es nur ein Artefakt gibt und das auch einfach zu bauen ist, dann kann die Kurzform `actions/release` verwendet werden. Das ist der Normalfall.
-Im Parameter `build_run` muss das Projekt (in Form eines Bash-Scripts) beschreiben wie die Artefakte gebaut werden.
+Wenn es nur ein Artefakt gibt und das auch einfach zu bauen ist, dann kann die
+Kurzform `actions/release` verwendet werden. Das ist der Normalfall. Im
+Parameter `build_run` muss das Projekt (in Form eines Bash-Scripts) beschreiben
+wie die Artefakte gebaut werden.
 
 Beispiel:
-```#!yaml
+```yaml
 name: release
 on:
   push:
@@ -128,18 +137,28 @@ jobs:
 ```
 
 ## Umgebungsvariablen
-Die Action stellt einige Umgebungsvariablen bereit, die im Workflow nützlich sein können:
-- `RELEASE_IMAGE_TAG`: Tag, der Docker/OCI-Images zugewiesen werden muss, damit diese veröffentlicht und in Helm-Releases verwendet werden können. Entspricht momentan dem Commit-Hash.
+Die Action stellt einige Umgebungsvariablen bereit, die im Workflow nützlich
+sein können:
+- `RELEASE_IMAGE_TAG`: Tag, der Docker/OCI-Images zugewiesen werden muss, damit
+  diese veröffentlicht und in Helm-Releases verwendet werden können. Entspricht
+  momentan dem Commit-Hash.
 - `RELEASE_IMAGE_LOCAL_NAME_XXX`: Voller Name eines Docker/OCI-Images mit Tag.
-- `RELEASE_IS_PRERELEASE`: Wird gerade ein Release (master/main) oder ein Prerelease (testing) verarbeitet?
-- `RELEASE_PROJECT_IS_RELEASED`: Wurde das Projekt schon unter dieser Version veröffentlicht?
-- `RELEASE_PROJECT_CURRENT_VERSION`: Aktuelle Version des Projekts, z.B. '2.10.4'
-- `RELEASE_PROJECT_PLANNED_VERSION`: "Geplante" Version des Projekts. Entspricht der aktuellen Version mit optionalem Suffix bei Prerelease, z.B. '2.10.4-dev42'
+- `RELEASE_IS_PRERELEASE`: Wird gerade ein Release (master/main) oder ein
+  Prerelease (testing) verarbeitet?
+- `RELEASE_PROJECT_IS_RELEASED`: Wurde das Projekt schon unter dieser Version
+  veröffentlicht?
+- `RELEASE_PROJECT_CURRENT_VERSION`: Aktuelle Version des Projekts, z.B.
+  '2.10.4'
+- `RELEASE_PROJECT_PLANNED_VERSION`: "Geplante" Version des Projekts.
+  Entspricht der aktuellen Version mit optionalem Suffix bei Prerelease, z.B.
+  '2.10.4-dev42'
 
 ## Release vs. Prerelease
-Die Release-Action kann für Releases (merge in master/main) oder Prereleases (merge in testing) verwendet werden.
+Die Release-Action kann für Releases (merge in master/main) oder Prereleases
+(merge in testing) verwendet werden.
 
-Es unterscheiden sich dann image-tags, git-tags und Versionsnummern der Artefakte.
+Es unterscheiden sich dann image-tags, git-tags und Versionsnummern der
+Artefakte.
 
 ### Release
 - Image-Tags: `v1`, `v1.2`, `v1.2.3`, `latest`, `master/main.latest`
@@ -152,12 +171,16 @@ Es unterscheiden sich dann image-tags, git-tags und Versionsnummern der Artefakt
 - Versionsnummern: Wie Projekt, mit Suffix `-dev$ACTION_LAUF_NUMMER`
 
 ## Prüfung ob eine Version schon veröffentlicht wurde
-Beim Release selbst (merge in main/master) wird geprüft ob eine Version bereits veröffentlicht wurde.
-Falls ja, ist das kein Fehler. **ABER** es wird in dem Fall weder ein Docker/OCI-Image hochgeladen, noch ein Helm-Release aktualisiert oder irgendwelche anderen Artefakte veröffentlicht.
-Das kann erwünscht sein, wenn eine Änderung nicht ausgerollt werden muss (z.b. Dokumentation angepasst, fixtures verändert, etc.)
+Beim Release selbst (merge in main/master) wird geprüft ob eine Version bereits
+veröffentlicht wurde. Falls ja, ist das kein Fehler. **ABER** es wird in dem
+Fall weder ein Docker/OCI-Image hochgeladen, noch ein Helm-Release aktualisiert
+oder irgendwelche anderen Artefakte veröffentlicht. Das kann erwünscht sein,
+wenn eine Änderung nicht ausgerollt werden muss (z.b. Dokumentation angepasst,
+fixtures verändert, etc.)
 
-Um bei einem Pull-Request eine Warnung zu sehen, wenn die Version nicht erhöht wurde kann folgender Workflow verwendet werden. Es ist keine Anpassung nötig.
-```#!yaml
+Um bei einem Pull-Request eine Warnung zu sehen, wenn die Version nicht erhöht
+wurde kann folgender Workflow verwendet werden. Es ist keine Anpassung nötig.
+```yaml
 name: check if project is already released
 on:
   - pull_request
@@ -170,4 +193,5 @@ jobs:
       - uses: https://gitea.puzzleyou.net/actions/release/check-is-not-released@v0
 ```
 
-Bei einem Prerelease (merge in testing) muss die Version nicht angepasst werden. Das geschieht automatisch.
+Bei einem Prerelease (merge in testing) muss die Version nicht angepasst
+werden. Das geschieht automatisch.