release action
Gitea/Github-Action, die hilft das Veröffentlichen von Projekten zu automatisieren.
Features
- Laden von Credentials und Einrichten der Runner-Umgebung
- Veröffentlichen von Artefakten
- Docker Images
- Python Pakete (wheel, sdist)
- NPM Pakete
- Tarballs
- Ausrollen von Helm-Releases
- Anlegen von Gitea-Releases
- Anlegen von Git-Tags
Verwendung
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
# Die Version wird in der Datei Cargo.toml im Hauptverzeichnis des Projekts festgelegt
version_descriptor: Cargo.toml
artefacts:
# Es soll ein Docker/OCI-Image mit dem Namen masa-images veröffentlicht werden
- type: oci_image
name: masa-images
# Es soll ein Python-Paket als Wheel veröffentlicht werden
- type: wheel
# Unter diesem Pfad ist das Wheel abgelegt (vor dem Upload in die Registry)
filename: ./scratch/wheels/*.whl
# Diese Datei bestimmt die Version des Pakets.
# Wird synchronisiert mit der Version des Projekts.
version_descriptor: pyproject.toml
deployments:
# Bei einem Prerelease (push in testing) soll das Helm-Release masa-images-testing
# aktualisiert werden.
- type: helm
release_name: masa-images-testing
Alle möglichen Einstellungen können hier 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.
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 dierelease.yamlgelesen 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.
Beispiel:
name: release
on:
push:
branches:
- master
- testing
jobs:
check:
uses: ./.gitea/workflows/checks.yaml
release:
needs: ["check"]
runs-on: action-runner
env:
RUSTC_WRAPPER: sccache
steps:
- uses: actions/checkout@v4
- uses: https://gitea.puzzleyou.net/actions/release/declare@v0
- uses: https://gitea.puzzleyou.net/actions/release/sync-versions@v0
- name: build image
run: |
nix develop --command just build-image ${RELEASE_IMAGE_TAG}
sccache --show-stats
- name: build wheel
run: |
mkdir -p ./scratch/wheels
nix develop --command \
maturin build \
--release \
--out ./scratch/wheels/ \
--strip \
-m Cargo.toml \
--compatibility linux \
--interpreter python3.13
sccache --show-stats
- uses: https://gitea.puzzleyou.net/actions/release@v0
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.
Beispiel:
name: release
on:
push:
branches:
- master
- testing
jobs:
release:
runs-on: action-runner
steps:
- uses: actions/checkout@v4
- uses: https://gitea.puzzleyou.net/actions/release@v0
with:
build_run: docker build -t "${RELEASE_IMAGE_LOCAL_NAME_ALI}" .
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.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 vs. Prerelease
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.
Release
- Image-Tags:
v1,v1.2,v1.2.3,latest,master/main.latest - Git-Tags:
v1,v1.2,v1.2.3,latest - Versionsummern: Wie Projekt
Prerelease
- Image-Tags:
v1.2.3-dev4,development,testing.latest - Git-Tags:
v1.2.3-dev4,development - 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.)
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.
name: check if project is already released
on:
- pull_request
jobs:
check:
runs-on: action-runner
steps:
- uses: actions/checkout@v4
- 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.