- Trigger-Erkennung im "Variablen ableiten"-Step (refs/tags/* vs refs/heads/*)
- Auto-Modus: Header-Version aus Plugin-PHP lesen, Tag v{version} prüfen
→ wenn Tag existiert: stiller Skip; sonst Pre-Flight + Build + Release
- Release-API-Call mit target_commitish, damit Tag im Auto-Modus aus
dem aktuellen HEAD-Commit erzeugt wird
- Klassischer Tag-Push-Modus bleibt unverändert
- Nachfolgende Steps mit if: steps.vars.outputs.skip != 'true' geguarded
Mit re.DOTALL matcht .* auch Newlines. Kombination mit (?:\s+.*)?$\n
führte dazu, dass die erste Version-Zeile bis zum Dateiende gefressen
wurde und Capture-Group leer blieb (0 Zeichen).
Fix: .* durch [^\n]* ersetzen, damit erste Zeile genau auf eine Zeile
begrenzt ist. Gilt für beide Changelog-Parser (Block-Extraktion und
entry_pat in readme.txt-Generator).
Konsistenz mit Software und Flow: CHANGELOG.md ist einziger Pflege-Ort
für den Changelog über alle IDF-Projekte hinweg. readme.txt bleibt als
WP-Standard-Datei erhalten (Plugin-Metadaten, Stable tag), der
Abschnitt == Changelog == wird beim ZIP-Bau aus CHANGELOG.md generiert
und im ZIP mitgeliefert.
Pre-Flight prüft weiter 4 Sync-Stellen inkl. Stable tag.
CHANGELOG.md und readme.txt sind beide Pflichtdateien im Repo.
- Pre-Flight prüft jetzt zusätzlich Stable tag: in readme.txt
- Changelog-Block wird aus readme.txt == Changelog == gezogen
- CHANGELOG.md fällt als Workflow-Abhängigkeit weg
- readme.txt ist Pflichtdatei im Plugin-Repo
Grund: readme.txt ist WP-natives Format, WordPress und Master-Key
parsen es direkt (für CPT-Sync der öffentlichen Plugin-Seite).
Damit gibt es eine SSOT zum Pflegen statt parallele CHANGELOG.md.
Entscheidung dokumentiert in Notion:
https://www.notion.so/32b36ebfe9178147ad16ee214302c994
Kurze Anleitung für Plugin-Repos, wie sie den Reusable
release-plugin-Workflow einhängen — inkl. Voraussetzungen,
Release-Ablauf, Pinning-Empfehlung und Fehlerdiagnose.
claude