ideenfabrik/idf-ci
2
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

style: lange Bindestriche durch normalen Bindestrich ersetzen

Browse Source 
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:
joergmartin
2026-08-01 09:03:30 +02:00
co-authored by Claude Opus 4.8
parent 309826ccb6
commit b661ec3153
3 changed files with 42 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plugin-caller-template.md
+12 -12
View File
@@ -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.