claude
35d9dcfabf
Kurze Anleitung für Plugin-Repos, wie sie den Reusable release-plugin-Workflow einhängen — inkl. Voraussetzungen, Release-Ablauf, Pinning-Empfehlung und Fehlerdiagnose.
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 Version-Konsistenz, extrahiert den Changelog-Block, baut das ZIP und legt einen Gitea-Release mit ZIP-Asset an.
Geplant:
lint-php.yml— PHPCS / PHPStan für Plugin-Repos.composer/— geteiltecomposer.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:
tags: ['v*.*.*']
jobs:
release:
uses: ideenfabrik/idf-ci/.gitea/workflows/release-plugin.yml@v1
with:
slug: idf-<plugin-slug>
secrets: inherit
Für die Anwendung reicht git tag v1.2.3 && git push --tags. Alles andere macht der Reusable Workflow.
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: