Update README.md
Some checks failed
run tests / unittest (pull_request) Successful in 12s
run tests / test-declare-default (pull_request) Successful in 14s
check if project is already released / unittest (pull_request) Failing after 21s
run tests / test-sync-versions (pull_request) Successful in 23s
run tests / test-is-not-yet-released (pull_request) Successful in 21s
run tests / test-declare-with-release-yaml (pull_request) Successful in 20s
run tests / test-skip-release-if-already-released (pull_request) Successful in 22s
run tests / test-declare-directly (pull_request) Successful in 20s

This commit is contained in:
2025-12-22 11:02:48 +00:00
parent abcec8e398
commit 592815eab1

View File

@@ -21,7 +21,7 @@ Darin werden folgende Eigenschaften beschrieben:
- 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
@@ -61,7 +61,7 @@ Wenn ein Projekt veröffentlicht wird, dann werden folgende Schritt ausgeführt:
- `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:
@@ -109,7 +109,7 @@ Wenn es nur ein Artefakt gibt und das auch einfach zu bauen ist, dann kann die K
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:
@@ -157,7 +157,7 @@ Falls ja, ist das kein Fehler. **ABER** es wird in dem Fall weder ein Docker/OCI
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
```yaml
name: check if project is already released
on:
- pull_request