From b661ec315330f37aa27bcfc313f9e6b0c980e932 Mon Sep 17 00:00:00 2001 From: Joerg Martin Date: Sat, 1 Aug 2026 09:03:30 +0200 Subject: [PATCH] style: lange Bindestriche durch normalen Bindestrich ersetzen Em-Dash und En-Dash in README und docs durch normalen Bindestrich ersetzt. Reine Zeichenersetzung, keine Logikaenderung. Co-Authored-By: Claude Opus 4.8 --- README.md | 30 +++++++++++++++--------------- docs/plugin-caller-template.md | 24 ++++++++++++------------ docs/runner-setup.md | 30 +++++++++++++++--------------- 3 files changed, 42 insertions(+), 42 deletions(-) diff --git a/README.md b/README.md index 71dda43..ed39114 100644 --- a/README.md +++ b/README.md @@ -4,17 +4,17 @@ Zentrale CI-Bausteine für IDF-Repos. ## Zweck -Dieses Repo ist die Heimat für **geteilte CI-Bausteine**, die von anderen IDF-Repos per `uses:` eingebunden werden. Vorteil: Eine Änderung an einer Stelle wirkt in allen nutzenden Repos — kein 26-facher Copy-Paste-Pflegeaufwand. +Dieses Repo ist die Heimat für **geteilte CI-Bausteine**, die von anderen IDF-Repos per `uses:` eingebunden werden. Vorteil: Eine Änderung an einer Stelle wirkt in allen nutzenden Repos - kein 26-facher Copy-Paste-Pflegeaufwand. Aktuell enthalten: -- `.gitea/workflows/release-plugin.yml` — Reusable Workflow für WordPress-Plugin-Releases. Bei Tag-Push (`v*.*.*`) prüft er Versions-Konsistenz über vier Sync-Stellen, extrahiert den Changelog-Block aus `CHANGELOG.md`, generiert daraus die `== Changelog ==`-Section in `readme.txt`, baut das ZIP und legt einen Gitea-Release mit ZIP-Asset an. +- `.gitea/workflows/release-plugin.yml` - Reusable Workflow für WordPress-Plugin-Releases. Bei Tag-Push (`v*.*.*`) prüft er Versions-Konsistenz über vier Sync-Stellen, extrahiert den Changelog-Block aus `CHANGELOG.md`, generiert daraus die `== Changelog ==`-Section in `readme.txt`, baut das ZIP und legt einen Gitea-Release mit ZIP-Asset an. Geplant: -- `lint-php.yml` — PHPCS / PHPStan für Plugin-Repos. -- `composer/` — geteilte `composer.json`-Snippets. -- `scripts/` — Shell-Helfer für lokales Build und Release. +- `lint-php.yml` - PHPCS / PHPStan für Plugin-Repos. +- `composer/` - geteilte `composer.json`-Snippets. +- `scripts/` - Shell-Helfer für lokales Build und Release. ## Nutzung im Plugin-Repo @@ -38,7 +38,7 @@ jobs: **Auto-Modus (Standard, seit v1.2.0):** Plugin-Header-Version, PHP-Konstante, `Stable tag:` und CHANGELOG-Block hochziehen, committen, nach `main` pushen. Der Workflow erzeugt Tag `v` selbst und legt das Release an. Wenn die Version nicht erhöht wurde, beendet der Workflow still (kein Release, keine Mail). -**Klassischer Modus:** Falls du lieber explizit taggst — `git tag v1.2.3 && git push --tags` triggert denselben Workflow im Tag-Modus. Beide Pfade können koexistieren. +**Klassischer Modus:** Falls du lieber explizit taggst - `git tag v1.2.3 && git push --tags` triggert denselben Workflow im Tag-Modus. Beide Pfade können koexistieren. Details und Fehlerdiagnose im [Caller-Template](docs/plugin-caller-template.md). @@ -46,7 +46,7 @@ Details und Fehlerdiagnose im [Caller-Template](docs/plugin-caller-template.md). Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein: -1. **`.php`** — Plugin-Haupt-PHP mit WordPress-Plugin-Header inklusive Zeile `Version: X.Y.Z`. +1. **`.php`** - Plugin-Haupt-PHP mit WordPress-Plugin-Header inklusive Zeile `Version: X.Y.Z`. 2. **Versions-Konstante** in einer beliebigen PHP-Datei: `define('IDF__VERSION', 'X.Y.Z');` Beispiel: `idf-login-branding` → `IDF_LOGIN_BRANDING_VERSION`. @@ -71,7 +71,7 @@ Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein: ```markdown # Changelog - ## v1.2.3 — 2026-04-23 + ## v1.2.3 - 2026-04-23 ### Neu - … @@ -81,7 +81,7 @@ Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein: --- - ## v1.2.2 — 2026-04-10 + ## v1.2.2 - 2026-04-10 … ``` @@ -89,9 +89,9 @@ Alle vier Versionen (Tag, Plugin-Header, PHP-Konstante, `Stable tag:`) müssen i ## Aufteilung Changelog-Pflege -- **`CHANGELOG.md`** ist die **einzige Pflege-Stelle für den Changelog** — einheitlich über alle IDF-Projekte (Software, Flow, Plugins). Du schreibst den neuen Block hier, fertig. +- **`CHANGELOG.md`** ist die **einzige Pflege-Stelle für den Changelog** - einheitlich über alle IDF-Projekte (Software, Flow, Plugins). Du schreibst den neuen Block hier, fertig. - **`readme.txt`** ist WP-Standard-Metadaten: Plugin-Name, Description, `Requires PHP`, `Tested up to`, `Stable tag` usw. Pflegst du manuell, aber nur diese Felder. -- Der Abschnitt `== Changelog ==` in `readme.txt` wird beim Release **von Actions automatisch generiert** — aus `CHANGELOG.md`. Manuelle Einträge in `readme.txt` unter `== Changelog ==` werden beim nächsten Release überschrieben. +- Der Abschnitt `== Changelog ==` in `readme.txt` wird beim Release **von Actions automatisch generiert** - aus `CHANGELOG.md`. Manuelle Einträge in `readme.txt` unter `== Changelog ==` werden beim nächsten Release überschrieben. So hat jedes Projekt im IDF genau einen Ort, an dem der Changelog lebt: `CHANGELOG.md`. WordPress-Plugins bekommen zusätzlich eine WP-native `readme.txt`, deren Changelog-Teil aber auto-befüllt wird. @@ -99,9 +99,9 @@ So hat jedes Projekt im IDF genau einen Ort, an dem der Changelog lebt: `CHANGEL Die Reusable Workflows selbst sind per SemVer-Tag versioniert (`v1`, `v1.2`, `v1.2.3`). Plugin-Repos referenzieren einen dieser Tags. Empfehlung: -- **Major-Tag (`@v1`)** — rolling, nimmt automatisch Patches und Minors mit. -- **Minor-Tag (`@v1.2`)** — nimmt nur Patches mit. -- **Exakt (`@v1.2.3`)** — einfriert auf genau diese Version. +- **Major-Tag (`@v1`)** - rolling, nimmt automatisch Patches und Minors mit. +- **Minor-Tag (`@v1.2`)** - nimmt nur Patches mit. +- **Exakt (`@v1.2.3`)** - einfriert auf genau diese Version. Breaking Changes am Workflow → neuer Major-Tag, nutzende Repos müssen manuell nachziehen. @@ -110,5 +110,5 @@ Breaking Changes am Workflow → neuer Major-Tag, nutzende Repos müssen manuell Konzeptionelle Grundlagen und der Plugin-Release-Workflow liegen in Notion: - [Deployment & Versionierung](https://www.notion.so/32b36ebfe9178147ad16ee214302c994) -- [Plugin-Migration auf Git — Checkliste](https://www.notion.so/34b36ebfe9178195980fd4a723ebfde5) +- [Plugin-Migration auf Git - Checkliste](https://www.notion.so/34b36ebfe9178195980fd4a723ebfde5) - [Git- & Issue-Workflow](https://www.notion.so/34b36ebfe91781519276f301aac0d74c) diff --git a/docs/plugin-caller-template.md b/docs/plugin-caller-template.md index c5fbd9c..2655764 100644 --- a/docs/plugin-caller-template.md +++ b/docs/plugin-caller-template.md @@ -1,4 +1,4 @@ -# Plugin-Caller-Workflow — Template +# Plugin-Caller-Workflow - Template Jedes Plugin-Repo (`ideenfabrik/idf-`) bekommt genau diese eine Datei, um den Release-Mechanismus zu aktivieren: @@ -19,17 +19,17 @@ jobs: secrets: inherit ``` -**Nur `slug` anpassen** — exakt der Plugin-Slug (= Repo-Name ohne Org-Präfix, z. B. `idf-login-branding`). +**Nur `slug` anpassen** - exakt der Plugin-Slug (= Repo-Name ohne Org-Präfix, z. B. `idf-login-branding`). ## Voraussetzungen im Plugin-Repo Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein: -1. **`.php`** — Plugin-Haupt-PHP mit standardmäßigem Plugin-Header, inklusive Zeile `Version: X.Y.Z`. +1. **`.php`** - Plugin-Haupt-PHP mit standardmäßigem Plugin-Header, inklusive Zeile `Version: X.Y.Z`. 2. **Versions-Konstante** in einer PHP-Datei des Plugins: `define('IDF__VERSION', 'X.Y.Z');` Beispiel: Für `idf-login-branding` → `IDF_LOGIN_BRANDING_VERSION`. -3. **`readme.txt`** im Repo-Root im WordPress-Standard-Format. Nur die WP-Metadaten pflegen — der Changelog-Abschnitt wird vom Release-Workflow automatisch aus `CHANGELOG.md` gefüllt: +3. **`readme.txt`** im Repo-Root im WordPress-Standard-Format. Nur die WP-Metadaten pflegen - der Changelog-Abschnitt wird vom Release-Workflow automatisch aus `CHANGELOG.md` gefüllt: ``` === Plugin Name === Contributors: ideenfabrik @@ -46,11 +46,11 @@ Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein: == Changelog == (wird beim Release automatisch aus CHANGELOG.md generiert) ``` -4. **`CHANGELOG.md`** im Repo-Root — SSOT für den Changelog. Format: +4. **`CHANGELOG.md`** im Repo-Root - SSOT für den Changelog. Format: ```markdown # Changelog - ## v1.2.3 — 2026-04-23 + ## v1.2.3 - 2026-04-23 ### Neu - Feature xyz @@ -60,13 +60,13 @@ Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein: --- - ## v1.2.2 — 2026-04-10 + ## v1.2.2 - 2026-04-10 … ``` Alle vier Werte (Tag, Plugin-Header-`Version:`, PHP-Konstante, `Stable tag:` in `readme.txt`) müssen identisch sein. Der Pre-Flight-Check im Reusable bricht sonst ab. -**Pflege-Aufteilung:** Changelog-Einträge nur in `CHANGELOG.md` pflegen. `readme.txt` bekommt seine `== Changelog ==` beim Release automatisch generiert — manuelle Einträge dort werden überschrieben. +**Pflege-Aufteilung:** Changelog-Einträge nur in `CHANGELOG.md` pflegen. `readme.txt` bekommt seine `== Changelog ==` beim Release automatisch generiert - manuelle Einträge dort werden überschrieben. ## Release-Ablauf (Agent/Mensch) @@ -91,9 +91,9 @@ Danach läuft die Action automatisch durch. Bei Erfolg liegt auf Gitea ein Relea Beim `uses:`-Aufruf die Version pinnen: -- `@v1` — rolling, zieht Patches und Minors automatisch mit. Empfohlen für die meisten Plugins. -- `@v1.2` — Patches ja, Minors nein. -- `@v1.2.3` — exakt einfrieren. Nur für Plugins, die gegen eine bestimmte Workflow-Version validiert wurden. +- `@v1` - rolling, zieht Patches und Minors automatisch mit. Empfohlen für die meisten Plugins. +- `@v1.2` - Patches ja, Minors nein. +- `@v1.2.3` - exakt einfrieren. Nur für Plugins, die gegen eine bestimmte Workflow-Version validiert wurden. Breaking Changes am Reusable Workflow → neuer Major (`v2`). Plugin-Repos müssen dann bewusst auf `@v2` wechseln. @@ -106,7 +106,7 @@ Bei abgebrochenem Release: - **„Plugin-Header-Version ≠ Tag"** → `.php` Version-Zeile korrigieren, Commit, Tag neu setzen. - **„Konstante ≠ Tag"** → Versions-Konstante im PHP anpassen, Commit, Tag neu setzen. - **„Stable tag ≠ Tag"** → `Stable tag:` in `readme.txt` korrigieren, Commit, Tag neu setzen. -- **„Kein Changelog-Block für v…"** → Block `## v1.2.3 — ` in `CHANGELOG.md` anlegen, Commit, Tag neu setzen. +- **„Kein Changelog-Block für v…"** → Block `## v1.2.3 - ` in `CHANGELOG.md` anlegen, Commit, Tag neu setzen. - **Release-Anlage fehlgeschlagen** → Wahrscheinlich fehlende Token-Berechtigung. `GITEA_TOKEN`-Secret prüfen oder den Standard `github.token` nutzen. Wichtig: Ein Tag, unter dem ein Release bereits existiert, kann nicht erneut einen Release erzeugen. Bei Korrekturen eine PATCH-Version höher tagen, nicht denselben Tag neu setzen. diff --git a/docs/runner-setup.md b/docs/runner-setup.md index 1615955..29b6143 100644 --- a/docs/runner-setup.md +++ b/docs/runner-setup.md @@ -1,14 +1,14 @@ -# Gitea Actions Runner — Setup +# Gitea Actions Runner - Setup -Diese Anleitung beschreibt, wie der Gitea Actions Runner auf einem IDF-Server installiert und registriert wird. Der Runner ist der Dienst, der die Release-Workflows aus diesem Repo ausführt. Ohne laufenden Runner bleiben Tag-Pushes ohne Wirkung — die Runs hängen unendlich in der Queue. +Diese Anleitung beschreibt, wie der Gitea Actions Runner auf einem IDF-Server installiert und registriert wird. Der Runner ist der Dienst, der die Release-Workflows aus diesem Repo ausführt. Ohne laufenden Runner bleiben Tag-Pushes ohne Wirkung - die Runs hängen unendlich in der Queue. -**Wichtig:** Diese Anleitung ist die verbindliche SSOT für das Runner-Setup. Bei jedem Server-Wechsel wird sie von vorn abgearbeitet — es gibt keine versteckten Artefakte außerhalb von Git, nur die hier beschriebenen Schritte. +**Wichtig:** Diese Anleitung ist die verbindliche SSOT für das Runner-Setup. Bei jedem Server-Wechsel wird sie von vorn abgearbeitet - es gibt keine versteckten Artefakte außerhalb von Git, nur die hier beschriebenen Schritte. ## Was der Runner ist und was er nicht ist Der Runner ist ein einzelnes ausführbares Binary (`act_runner`), das sich beim IDF-Gitea-Server anmeldet und Jobs aus der Queue abarbeitet. Er ist kein WordPress-, PHP- oder Plesk-Tool, sondern ein unabhängiger Dienst, der nebenher läuft. Technisch ist er vergleichbar mit einem Cron-Daemon, der auf Arbeit wartet. -Der Runner **baut** die Plugin-ZIPs und legt sie als Gitea-Release-Assets ab. Er **verteilt** nichts an Kunden — das ist Aufgabe des Master-Key-Plugins. +Der Runner **baut** die Plugin-ZIPs und legt sie als Gitea-Release-Assets ab. Er **verteilt** nichts an Kunden - das ist Aufgabe des Master-Key-Plugins. ## Voraussetzungen in Gitea @@ -16,11 +16,11 @@ Damit der Runner Reusable-Workflows aus `idf-ci` lesen kann, muss das Repo für **Daher: `ideenfabrik/idf-ci` muss auf Sichtbarkeit „Public" (oder „Limited", falls in der Gitea-Version verfügbar) stehen.** -- **Public** — lesbar für alle, die die Gitea-Instanz erreichen. -- **Limited** — lesbar für alle eingeloggten Gitea-User. In neueren Gitea-Versionen verfügbar. Für unseren Fall äquivalent zu Public, weil der Runner eh mit Token angemeldet ist. -- **Private** — funktioniert nicht, weil der Job-Token keinen Repo-übergreifenden Lesezugriff hat. +- **Public** - lesbar für alle, die die Gitea-Instanz erreichen. +- **Limited** - lesbar für alle eingeloggten Gitea-User. In neueren Gitea-Versionen verfügbar. Für unseren Fall äquivalent zu Public, weil der Runner eh mit Token angemeldet ist. +- **Private** - funktioniert nicht, weil der Job-Token keinen Repo-übergreifenden Lesezugriff hat. -**Zusätzlich:** Gitea-weite Einstellung `REQUIRE_SIGNIN_VIEW` muss auf `false` stehen. Sonst überschreibt sie die per-Repo-Sichtbarkeit und erzwingt Login auch für Public-Repos. Bei Docker-Setups wird die `app.ini` oft aus Environment-Variablen regeneriert — Änderungen direkt in der Datei gehen beim Container-Neustart verloren. Korrekter Weg: Environment-Variable setzen: +**Zusätzlich:** Gitea-weite Einstellung `REQUIRE_SIGNIN_VIEW` muss auf `false` stehen. Sonst überschreibt sie die per-Repo-Sichtbarkeit und erzwingt Login auch für Public-Repos. Bei Docker-Setups wird die `app.ini` oft aus Environment-Variablen regeneriert - Änderungen direkt in der Datei gehen beim Container-Neustart verloren. Korrekter Weg: Environment-Variable setzen: ``` GITEA__service__REQUIRE_SIGNIN_VIEW=false @@ -53,7 +53,7 @@ Einmalige Aktion pro Instanz. - Linux (Debian/Ubuntu; der IDF-Plesk-Host reicht) - Outbound-HTTPS zu `git.ihre-ideenfabrik.de` und zu `github.com` (für standard Gitea-/GitHub-Actions wie `actions/checkout`) -- **Node.js 20 (LTS) oder neuer** — zahlreiche Actions (`actions/checkout`, viele weitere) sind JavaScript-basiert und benötigen Node zur Ausführung. Installation (Debian/Ubuntu): +- **Node.js 20 (LTS) oder neuer** - zahlreiche Actions (`actions/checkout`, viele weitere) sind JavaScript-basiert und benötigen Node zur Ausführung. Installation (Debian/Ubuntu): ```bash curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash - sudo apt install -y nodejs @@ -112,7 +112,7 @@ Organisation-scoped Runner (empfohlen, läuft für alle IDF-Repos): 1. In Gitea einloggen als Admin. 2. Navigation: Organization **ideenfabrik** → Settings → **Actions** → **Runners**. 3. Button **„Create new Runner"**. -4. Registrierungstoken kopieren. Token ist einmalig — für eine zweite Registrierung einen neuen generieren. +4. Registrierungstoken kopieren. Token ist einmalig - für eine zweite Registrierung einen neuen generieren. Alternativ: Instance-weit unter Site Administration → Actions → Runners (dann verfügbar für alle Organisationen). @@ -127,9 +127,9 @@ sudo /opt/act_runner/act_runner register \ --no-interactive ``` -Kein `--labels`-Flag — die Labels kommen aus der Config (siehe Schritt 2). Falls versehentlich mitgegeben, erscheint die Warnung `Labels from command will be ignored, use labels defined in config file.` +Kein `--labels`-Flag - die Labels kommen aus der Config (siehe Schritt 2). Falls versehentlich mitgegeben, erscheint die Warnung `Labels from command will be ignored, use labels defined in config file.` -Nach erfolgreicher Registrierung liegt eine Datei `.runner` im Arbeitsverzeichnis — die ist der Runner-State, nicht weiterkopieren oder committen. +Nach erfolgreicher Registrierung liegt eine Datei `.runner` im Arbeitsverzeichnis - die ist der Runner-State, nicht weiterkopieren oder committen. ### 5. systemd-Service anlegen @@ -183,12 +183,12 @@ Einen Plugin-Repo mit Caller-Workflow nehmen (z. B. `idf-post-prefix`), Tag `v