torben/chemenu
1
1
Fork 0
Code Issues 26 Pull Requests Actions Packages Releases 32 Activity

Automatisierte Release-Notes: Release-Drafter-Äquivalent für Gitea Actions prüfen #46

New Issue
Open
opened 2026-09-03 18:38:11 +00:00 by torben · 1 comment
torben commented 2026-09-03 18:38:11 +00:00
Owner
Copy Link
Copy Source

Worum es geht

Release-Notes entstehen heute von Hand: wikitool version bump legt das Heading an, die Prosa schreibt der Autor, version notes schneidet den Eintrag für release.yml heraus. Das funktioniert und soll vorerst so bleiben. Dieses Issue hält nur die Frage fest, ob es sich automatisieren lässt — und unter welcher Bedingung sie überhaupt beantwortet werden muss.

Der Auslöser

Dieses Issue wird bearbeitbar, sobald PRs in diesem Repo eingeführt sind. Vorher nicht, und das ist keine Formalie: die einzige bekannte Bauform (GitHub Release Drafter) zieht ihre Notizen aus gemergten Pull Requests. Ohne PRs gibt es keine Quelle, aus der ein Drafter etwas ziehen könnte.

Der Stand dazu, entschieden 2026-09-02: PRs werden nicht grundsätzlich eingeführt, sondern erst, wenn sie CI/CD-seitig einen echten Vorteil bringen. Automatisierte Release-Notes sind genau so ein möglicher Vorteil — und damit ist die Abhängigkeit zirkulär, wenn man sie falsch herum liest. Die Auflösung: die PR-Frage wird an anderen Kriterien entschieden, und dieses Issue ist eines der Argumente, die dann auf dem Tisch liegen. Es treibt die Entscheidung nicht, es wartet auf sie.

Bis dahin bleibt der direkte tools/wikitool publish-Workflow unverändert (AGENTS.md Invariante 5).

Zu klären, wenn der Auslöser gefeuert hat

  • Läuft ein Release-Drafter-Äquivalent überhaupt unter Gitea Actions? GitHubs release-drafter/release-drafter ist eine JavaScript-Action; act_runner führt solche aus (actions/checkout@v7 läuft hier), aber die Action spricht die GitHub-API in Details, die Gitea nicht zwingend deckt. Ungeprüft.
  • Ist ein eigenes, schlankes Skript näher am Bestand? version notes schneidet den Changelog-Eintrag bereits mechanisch heraus, und release.yml verarbeitet ihn schon. Ein Skript, das PR-Titel gegen CHANGES.md hält, wäre möglicherweise weniger Fläche als eine fremde Action.
  • Verhältnis zum Changelog. CHANGES.md ist die kuratierte Fassung; PR-Titel sind Rohmaterial. Ein Drafter, der den Changelog ersetzt, ist nicht gewollt — allenfalls einer, der ihn vorschlägt.

Berührungspunkt mit #42

#42 stellt das Versionsmodell auf einen laufenden Kandidaten mit -beta.n um und führt einen expliziten version release-Vorgang ein. Danach gibt es erstmals einen klar benannten Zeitpunkt, an dem Release-Notes fällig sind — vorher war jeder Bump potenziell ein Release. Das macht eine Automatisierung eher leichter, ist aber keine Abhängigkeit in beide Richtungen: #42 wartet nicht auf dieses Issue.

Akzeptanzkriterien

  • Recherche abgeschlossen: läuft ein Drafter unter Gitea Actions, oder nicht
  • Entscheidung dokumentiert — fremde Action, eigenes Skript, oder bewusst weiterhin von Hand
  • Bei Umsetzung: release.yml angepasst, tools/CONTRACT.md und CHANGES.md-Kopf nachgezogen

Vorgeschichte

Ausgegliedert aus #42 am 2026-09-03. Dort stand die Frage als offener Punkt und später als bewusst zurückgestellter Nicht-Umfang; sie hängt an einem anderen Auslöser als #42 selbst und blockiert dessen Umsetzung nicht.

## Worum es geht Release-Notes entstehen heute von Hand: `wikitool version bump` legt das Heading an, die Prosa schreibt der Autor, `version notes` schneidet den Eintrag für `release.yml` heraus. Das funktioniert und soll vorerst so bleiben. Dieses Issue hält nur die Frage fest, ob es sich automatisieren lässt — und unter welcher Bedingung sie überhaupt beantwortet werden muss. ## Der Auslöser **Dieses Issue wird bearbeitbar, sobald PRs in diesem Repo eingeführt sind.** Vorher nicht, und das ist keine Formalie: die einzige bekannte Bauform (GitHub Release Drafter) zieht ihre Notizen aus gemergten Pull Requests. Ohne PRs gibt es keine Quelle, aus der ein Drafter etwas ziehen könnte. Der Stand dazu, entschieden 2026-09-02: PRs werden **nicht grundsätzlich** eingeführt, sondern erst, wenn sie CI/CD-seitig einen echten Vorteil bringen. Automatisierte Release-Notes sind genau so ein möglicher Vorteil — und damit ist die Abhängigkeit zirkulär, wenn man sie falsch herum liest. Die Auflösung: die PR-Frage wird an anderen Kriterien entschieden, und *dieses* Issue ist eines der Argumente, die dann auf dem Tisch liegen. Es treibt die Entscheidung nicht, es wartet auf sie. Bis dahin bleibt der direkte `tools/wikitool publish`-Workflow unverändert (AGENTS.md Invariante 5). ## Zu klären, wenn der Auslöser gefeuert hat - Läuft ein Release-Drafter-Äquivalent überhaupt unter Gitea Actions? GitHubs `release-drafter/release-drafter` ist eine JavaScript-Action; `act_runner` führt solche aus (`actions/checkout@v7` läuft hier), aber die Action spricht die GitHub-API in Details, die Gitea nicht zwingend deckt. Ungeprüft. - Ist ein eigenes, schlankes Skript näher am Bestand? `version notes` schneidet den Changelog-Eintrag bereits mechanisch heraus, und `release.yml` verarbeitet ihn schon. Ein Skript, das PR-Titel gegen `CHANGES.md` hält, wäre möglicherweise weniger Fläche als eine fremde Action. - Verhältnis zum Changelog. `CHANGES.md` ist die kuratierte Fassung; PR-Titel sind Rohmaterial. Ein Drafter, der den Changelog *ersetzt*, ist nicht gewollt — allenfalls einer, der ihn *vorschlägt*. ## Berührungspunkt mit #42 #42 stellt das Versionsmodell auf einen laufenden Kandidaten mit `-beta.n` um und führt einen expliziten `version release`-Vorgang ein. Danach gibt es erstmals einen klar benannten Zeitpunkt, an dem Release-Notes fällig sind — vorher war jeder Bump potenziell ein Release. Das macht eine Automatisierung eher leichter, ist aber keine Abhängigkeit in beide Richtungen: #42 wartet nicht auf dieses Issue. ## Akzeptanzkriterien - [ ] Recherche abgeschlossen: läuft ein Drafter unter Gitea Actions, oder nicht - [ ] Entscheidung dokumentiert — fremde Action, eigenes Skript, oder bewusst weiterhin von Hand - [ ] Bei Umsetzung: `release.yml` angepasst, `tools/CONTRACT.md` und `CHANGES.md`-Kopf nachgezogen ## Vorgeschichte Ausgegliedert aus #42 am 2026-09-03. Dort stand die Frage als offener Punkt und später als bewusst zurückgestellter Nicht-Umfang; sie hängt an einem anderen Auslöser als #42 selbst und blockiert dessen Umsetzung nicht.
torben added the prio/waitingsize/Marea/workflowkind/decision labels 2026-09-03 18:38:11 +00:00
torben commented 2026-09-09 06:47:54 +00:00
Author
Owner
Copy Link
Copy Source

Recherche-Spike (Auslöser noch nicht gefeuert, PRs weiterhin offen)

Da der Auslöser laut Issue nicht an eine Ja/Nein-Entscheidung, sondern an den tatsächlichen Bedarf für PRs gekoppelt ist, hier die technische Vorabklärung für beide Zweige (mit PRs / ohne PRs).

Quellen

  • release-drafter/release-drafter, Issue #1386 (Gitea-Kompatibilität)
  • Gitea Forum: "Using github actions that look for files in a .github folder"
  • docs.gitea.com/usage/actions/faq (unterstützte Trigger-Events, pull_request Activity-Types)
  • ChristianSch/gitea-release-drafter (Mirror: gitea.kosmos.org/raucao/gitea-release-drafter), README
  • docs.gitea.com/usage/actions/token-permissions (GITEA_TOKEN Scopes)
  • docs.gitea.com API-Referenz: Pull Requests (GET /repos/{owner}/{repo}/pulls)

Befund

  1. GitHubs release-drafter/release-drafter läuft nicht unter Gitea. Die Action spricht die GitHub-REST/GraphQL-API fest an; selbst mit GHE_HOST-Override bleibt die Release-API zwischen Gitea und GitHub inkompatibel. Die Gitea-Community verweist deshalb grundsätzlich auf eigene Actions statt auf GitHub-Release-Actions.
  2. Es gibt ein Gitea/Forgejo-natives Äquivalent (ChristianSch/gitea-release-drafter, ab Version 1.19.0 kompatibel). Es deckt nur einen Ausschnitt des Original-Featuresets ab: name-template, tag-template, ein einfacher version-resolver über PR-Labels (major/minor/patch). Eine Kategorisierung wie beim Original (Features/Fixes/Docs als Abschnitte) ist dort nicht dokumentiert. Wartungsstand ist dünn (1 Star, letzte sichtbare Aktivität am Ursprungsrepo 2023, Mirror-Sync 2025) — Wartungsrisiko für Produktivbetrieb.
  3. Gitea Actions liefert alle nötigen Bausteine für einen eigenen Skript-Ansatz. pull_request-Events unterstützen die Activity-Types opened, edited, closed, reopened, assigned, unassigned, synchronize, labeled, unlabeled; der Event-Payload liefert Titel, Body, Labels, Autor und merged-Flag direkt als Kontextvariablen (gitea.event.pull_request.*), ohne zusätzlichen API-Call. Alternativ liefert GET /repos/{owner}/{repo}/pulls?state=closed&sort=recentclose dieselben Daten nachgelagert.
  4. Berechtigungen sind unkritisch. Sowohl fremde Action als auch eigenes Skript brauchen contents: write (Release anlegen/ändern) und pull-requests: read (Metadaten lesen). Gitea Actions kennt dieselben granularen Scopes und clampt sie auf ein konfigurierbares Maximum pro Repo.

Optionen

Option Machbarkeit Aufwand Hauptrisiko
GitHub-Original release-drafter/release-drafter Nicht lauffähig ohne Eigenbau Hoch Kein realistischer Weg ohne signifikante Eigenentwicklung
gitea-release-drafter (Fremd-Action, Gitea-nativ) Lauffähig ab 1.19.0 Mittel Reduziertes Featureset, schwache Wartungslage
Eigenes Skript auf PR-Events/PR-API Technisch vollständig gedeckt Mittel-Hoch Muss selbst gepflegt werden, dafür exakt auf CHANGES.md/version notes/release.yml zuschneidbar
Weiterhin von Hand (Status quo) Uneingeschränkt funktionsfähig Keiner Kein PR-Nutzen — irrelevant, solange keine PRs existieren

Einschätzung

Solange PRs nicht eingeführt sind, ändert der Spike nichts an der Grundentscheidung: von Hand bleibt richtig. Für den Fall, dass PRs kommen: eigenes schlankes Skript vor gitea-release-drafter. Der Fremd-Fork ist funktional dünner und schwächer gepflegt, spart aber keine Integrationsarbeit — die Anbindung an CHANGES.md/version notes/release.yml fällt in beiden Fällen an. Ein eigenes Skript hat dafür keine Fremdabhängigkeit und lässt sich exakt auf den bestehenden -beta.n-Versionsprozess (#42) zuschneiden. Die GitHub-Originalaction ist keine Option.

Offene Fragen

  • Bleibt der PR-Auslöser unverändert an "PRs sind eingeführt" gekoppelt, oder reicht künftig schon ein konkreter PR-Testbetrieb als Trigger für die Umsetzungsentscheidung?
  • Falls eigenes Skript: reicht der gitea.event.pull_request-Payload aus dem closed-Trigger, oder soll zusätzlich über die PR-API rückwirkend aggregiert werden (z. B. bei nachträglichen Label-Änderungen)?
## Recherche-Spike (Auslöser noch nicht gefeuert, PRs weiterhin offen) Da der Auslöser laut Issue nicht an eine Ja/Nein-Entscheidung, sondern an den tatsächlichen Bedarf für PRs gekoppelt ist, hier die technische Vorabklärung für beide Zweige (mit PRs / ohne PRs). ### Quellen - release-drafter/release-drafter, Issue #1386 (Gitea-Kompatibilität) - Gitea Forum: "Using github actions that look for files in a .github folder" - docs.gitea.com/usage/actions/faq (unterstützte Trigger-Events, pull_request Activity-Types) - ChristianSch/gitea-release-drafter (Mirror: gitea.kosmos.org/raucao/gitea-release-drafter), README - docs.gitea.com/usage/actions/token-permissions (GITEA_TOKEN Scopes) - docs.gitea.com API-Referenz: Pull Requests (`GET /repos/{owner}/{repo}/pulls`) ### Befund 1. **GitHubs `release-drafter/release-drafter` läuft nicht unter Gitea.** Die Action spricht die GitHub-REST/GraphQL-API fest an; selbst mit `GHE_HOST`-Override bleibt die Release-API zwischen Gitea und GitHub inkompatibel. Die Gitea-Community verweist deshalb grundsätzlich auf eigene Actions statt auf GitHub-Release-Actions. 2. **Es gibt ein Gitea/Forgejo-natives Äquivalent** (`ChristianSch/gitea-release-drafter`, ab Version 1.19.0 kompatibel). Es deckt nur einen Ausschnitt des Original-Featuresets ab: `name-template`, `tag-template`, ein einfacher `version-resolver` über PR-Labels (major/minor/patch). Eine Kategorisierung wie beim Original (Features/Fixes/Docs als Abschnitte) ist dort nicht dokumentiert. Wartungsstand ist dünn (1 Star, letzte sichtbare Aktivität am Ursprungsrepo 2023, Mirror-Sync 2025) — Wartungsrisiko für Produktivbetrieb. 3. **Gitea Actions liefert alle nötigen Bausteine für einen eigenen Skript-Ansatz.** `pull_request`-Events unterstützen die Activity-Types `opened, edited, closed, reopened, assigned, unassigned, synchronize, labeled, unlabeled`; der Event-Payload liefert Titel, Body, Labels, Autor und `merged`-Flag direkt als Kontextvariablen (`gitea.event.pull_request.*`), ohne zusätzlichen API-Call. Alternativ liefert `GET /repos/{owner}/{repo}/pulls?state=closed&sort=recentclose` dieselben Daten nachgelagert. 4. **Berechtigungen sind unkritisch.** Sowohl fremde Action als auch eigenes Skript brauchen `contents: write` (Release anlegen/ändern) und `pull-requests: read` (Metadaten lesen). Gitea Actions kennt dieselben granularen Scopes und clampt sie auf ein konfigurierbares Maximum pro Repo. ### Optionen | Option | Machbarkeit | Aufwand | Hauptrisiko | |---|---|---|---| | GitHub-Original `release-drafter/release-drafter` | Nicht lauffähig ohne Eigenbau | Hoch | Kein realistischer Weg ohne signifikante Eigenentwicklung | | `gitea-release-drafter` (Fremd-Action, Gitea-nativ) | Lauffähig ab 1.19.0 | Mittel | Reduziertes Featureset, schwache Wartungslage | | Eigenes Skript auf PR-Events/PR-API | Technisch vollständig gedeckt | Mittel-Hoch | Muss selbst gepflegt werden, dafür exakt auf `CHANGES.md`/`version notes`/`release.yml` zuschneidbar | | Weiterhin von Hand (Status quo) | Uneingeschränkt funktionsfähig | Keiner | Kein PR-Nutzen — irrelevant, solange keine PRs existieren | ### Einschätzung Solange PRs nicht eingeführt sind, ändert der Spike nichts an der Grundentscheidung: von Hand bleibt richtig. Für den Fall, dass PRs kommen: eigenes schlankes Skript vor `gitea-release-drafter`. Der Fremd-Fork ist funktional dünner und schwächer gepflegt, spart aber keine Integrationsarbeit — die Anbindung an `CHANGES.md`/`version notes`/`release.yml` fällt in beiden Fällen an. Ein eigenes Skript hat dafür keine Fremdabhängigkeit und lässt sich exakt auf den bestehenden `-beta.n`-Versionsprozess (#42) zuschneiden. Die GitHub-Originalaction ist keine Option. ### Offene Fragen - Bleibt der PR-Auslöser unverändert an "PRs sind eingeführt" gekoppelt, oder reicht künftig schon ein konkreter PR-Testbetrieb als Trigger für die Umsetzungsentscheidung? - Falls eigenes Skript: reicht der `gitea.event.pull_request`-Payload aus dem `closed`-Trigger, oder soll zusätzlich über die PR-API rückwirkend aggregiert werden (z. B. bei nachträglichen Label-Änderungen)?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/corpus
Betrifft Demo-/Testbett-Frage, Inhalt und Umfang von kb/
 area/distribution
Betrifft Auslieferung, Upgrade, Versionierung einer Instanz
 area/kb
Betrifft kb/-Schema, Contract, Confidence, Lint, Wissensbasis
 area/process
Betrifft den Entwicklungsprozess selbst, nicht den Stack als Artefakt
 area/workflow
Betrifft Git, Merge, Branching, Publish, PRs
 kind/build
Spezifiziert, wartet nur noch auf Umsetzungszeit
 kind/decision
Wartet auf eine Betreiberentscheidung
 kind/defect
Befund: Doku und Realitaet, oder zwei Dokus, widersprechen sich
 prio/blocking
Blockiert oder beschaedigt laufende Arbeit - als naechstes
 prio/planned
Traegt bald Zinsen - eingeplant
 prio/waiting
Sinnvoll, wartet auf einen Ausloeser
 size/L
Mehrere Sitzungen oder offene Designfragen vor dem ersten Commit
 size/M
Mehrere Dateien, Contract- oder Instruction-Aenderung, eigener Testaufwand
 size/S
Eine Sitzung, ein Publish, klar umrissener Schnitt
 status/blocked
Wartet auf ein anderes, noch offenes Issue - nicht eigenstaendig bearbeitbar
 status/incoming
Vom Menschen angelegte Anforderung, unvollständig, muss durch den Stack komplettiert werden.
 status/unconfirmed
Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig
No Label area/workflow kind/decision prio/waiting size/M
Milestone
No items
No Milestone
Assignees
Clear assignees
torben
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: torben/chemenu#46
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?