idf-ci

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.

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.

Geplant:

• 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

In jedem Plugin-Repo (ideenfabrik/idf-<slug>) liegt ein schlanker Caller-Workflow, der den Reusable aufruft:

# .gitea/workflows/release.yml
name: Release
on:
  push:
    branches: [main]      # Auto-Modus: Release sobald Header-Version hochgezogen wurde
    tags: ['v*.*.*']      # Klassischer Modus: manuelle Tags sind weiterhin möglich

jobs:
  release:
    uses: ideenfabrik/idf-ci/.gitea/workflows/release-plugin.yml@v1
    with:
      slug: idf-<plugin-slug>
    secrets: inherit

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<X.Y.Z> 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.

Details und Fehlerdiagnose im Caller-Template.

Pflichtdateien im Plugin-Repo

Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein:

1. <slug>.php — Plugin-Haupt-PHP mit WordPress-Plugin-Header inklusive Zeile Version: X.Y.Z.
2. Versions-Konstante in einer beliebigen PHP-Datei: define('IDF_<UPPER_SLUG_OHNE_IDF_>_VERSION', 'X.Y.Z'); Beispiel: idf-login-branding → IDF_LOGIN_BRANDING_VERSION.
3. readme.txt im Repo-Root im WordPress-Plugin-Format mit mindestens den Metadaten:

   === Plugin Name ===
   Contributors: ideenfabrik
   Tags: …
   Requires at least: 6.0
   Tested up to: 6.4
   Requires PHP: 7.4
   Stable tag: 1.2.3
   License: GPLv2 or later
   
   == Description ==
   …
   
   == Changelog ==
   (wird beim Release automatisch aus CHANGELOG.md gefüllt)
   

4. CHANGELOG.md im Repo-Root mit einem Block für jede Version:

   # Changelog
   
   ## v1.2.3 — 2026-04-23
   
   ### Neu
   - …
   
   ### Gefixt
   - …
   
   ---
   
   ## v1.2.2 — 2026-04-10
   …
   

Alle vier Versionen (Tag, Plugin-Header, PHP-Konstante, Stable tag:) müssen identisch sein. Der Pre-Flight-Check im Reusable bricht sonst ab.

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.
• 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.

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.

Versionierung dieses Repos

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.

Breaking Changes am Workflow → neuer Major-Tag, nutzende Repos müssen manuell nachziehen.

Dokumentation

Konzeptionelle Grundlagen und der Plugin-Release-Workflow liegen in Notion:

• Deployment & Versionierung
• Plugin-Migration auf Git — Checkliste
• Git- & Issue-Workflow