actions/release
8
0
Fork 0
Code Issues Pull Requests Actions Packages Releases 21 Wiki Activity

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

Browse Source
This commit is contained in:
David Übler
2025-12-22 11:02:48 +00:00
parent abcec8e398
commit 592815eab1
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
README.md
View File

@@ -21,7 +21,7 @@ Darin werden folgende Eigenschaften beschrieben:
- Welche Releases sollen wann aktualisiert werden? - Welche Releases sollen wann aktualisiert werden?
### Beispiel für release.yaml ### Beispiel für release.yaml
```#!yaml ```yaml
# Die Version wird in der Datei Cargo.toml im Hauptverzeichnis des Projekts festgelegt # Die Version wird in der Datei Cargo.toml im Hauptverzeichnis des Projekts festgelegt
version_descriptor: Cargo.toml 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. - `actions/release/release`: Hier werden die Artefakte veröffentlicht, das Helm-Release aktualisiert und das Gitea-Release angelegt.
Beispiel: Beispiel:
```#!yaml ```yaml
name: release name: release
on: on:
push: 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. Im Parameter `build_run` muss das Projekt (in Form eines Bash-Scripts) beschreiben wie die Artefakte gebaut werden.
Beispiel: Beispiel:
```#!yaml ```yaml
name: release name: release
on: on:
push: 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.) 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. 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 name: check if project is already released
on: on:
- pull_request - pull_request