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 <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.8
@@ -1,4 +1,4 @@
|
||||
# Plugin-Caller-Workflow — Template
|
||||
# Plugin-Caller-Workflow - Template
|
||||
|
||||
Jedes Plugin-Repo (`ideenfabrik/idf-<slug>`) 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. **`<slug>.php`** — Plugin-Haupt-PHP mit standardmäßigem Plugin-Header, inklusive Zeile `Version: X.Y.Z`.
|
||||
1. **`<slug>.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_<UPPER_SLUG_OHNE_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"** → `<slug>.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 — <Datum>` in `CHANGELOG.md` anlegen, Commit, Tag neu setzen.
|
||||
- **„Kein Changelog-Block für v…"** → Block `## v1.2.3 - <Datum>` 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.
|
||||
|
||||
+15
-15
@@ -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<X
|
||||
- **Neu-Registrierung (z. B. nach kaputtem State):** `sudo rm /opt/act_runner/.runner`, neuen Token aus Gitea holen, Schritt 4 erneut ausführen, Service neu starten.
|
||||
- **Deregistrierung:** Runner in Gitea-UI löschen, `.runner`-Datei auf dem Server entfernen, Service stoppen.
|
||||
|
||||
## Server-Wechsel — Checkliste
|
||||
## Server-Wechsel - Checkliste
|
||||
|
||||
Wenn der IDF-Server gewechselt wird (neuer Plesk-Host o. ä.):
|
||||
|
||||
1. Diese Anleitung auf dem neuen Server von Schritt 1 an durchlaufen.
|
||||
2. In Schritt 3 einen **neuen** Registrierungstoken erzeugen — alte Tokens nicht wiederverwenden.
|
||||
2. In Schritt 3 einen **neuen** Registrierungstoken erzeugen - alte Tokens nicht wiederverwenden.
|
||||
3. Optional: den alten Runner in der Gitea-UI deaktivieren, damit er nicht doppelt zieht.
|
||||
4. Nach Verifikation (Schritt 6 + 7): alte Server-Installation zurückbauen.
|
||||
|
||||
@@ -206,7 +206,7 @@ Entweder `idf-ci` steht auf Private, oder Gitea-weit ist `REQUIRE_SIGNIN_VIEW =
|
||||
Node.js ist nicht installiert oder nicht im PATH. Abschnitt „Voraussetzungen auf dem Server" durchgehen und Node 20 LTS installieren. Nach `sudo apt install -y nodejs` läuft der nächste Re-run.
|
||||
|
||||
**Runs hängen auf `queued`, Runner steht aber auf Online.**
|
||||
Label-Mismatch. Der Workflow schreibt `runs-on: self-hosted`, der Runner muss dasselbe Label anbieten. In der Gitea-UI die Labels des Runners prüfen — stehen dort nicht `self-hosted, linux, x64`, liegt es an Schritt 2.
|
||||
Label-Mismatch. Der Workflow schreibt `runs-on: self-hosted`, der Runner muss dasselbe Label anbieten. In der Gitea-UI die Labels des Runners prüfen - stehen dort nicht `self-hosted, linux, x64`, liegt es an Schritt 2.
|
||||
|
||||
**Runner zeigt `offline` nach systemd-Start.**
|
||||
`sudo journalctl -u act_runner --since '5 min ago'` lesen. Häufige Ursachen: Token abgelaufen, DNS funktioniert nicht, `git.ihre-ideenfabrik.de` nicht erreichbar.
|
||||
|
||||
Reference in New Issue
Block a user