diff --git a/README.md b/README.md index 3d112a7..da66a95 100644 --- a/README.md +++ b/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. \ No newline at end of file +Bei einem Prerelease (merge in testing) muss die Version nicht angepasst +werden. Das geschieht automatisch.