Gradle-Tools für KMP-Projekte. Die Build- und Settings-Plugins lesen ihre gemeinsame Konfiguration aus .config.yml im Projektverzeichnis.

Im Menü von devTools stehen zur Verfügung:

Das Settings-Plugin liest kmpdevtools aus dem Abschnitt [versions] in gradle/mflisar.versions.toml. Diese Version ist die Soll-Version für den literalen Plugin-Eintrag in settings.gradle.kts und die kmp-devtools-Workflow-Referenzen in .github/workflows/*.yml und *.yaml. Bei Abweichungen werden die Dateien aktualisiert und der aktuelle Gradle-Lauf mit einer entsprechenden Fehlermeldung abgebrochen. Danach muss der Sync beziehungsweise Build erneut gestartet werden. Sind alle Versionen konsistent, läuft Gradle normal weiter. Das manuelle Werkzeug updateDevTools verwendet dieselbe Update-Logik und aktualisiert zusätzlich die Soll-Version im Katalog. Die zuvor eingetragene Settings-Plugin-Version muss noch auflösbar sein, damit die automatische Synchronisierung ausgeführt werden kann.

Die folgenden Workflows werden im Consumer-Projekt auf Job-Ebene über uses aufgerufen:

Fertige Consumer-Vorlagen heißen delegating-*.yml, liegen unter files/workflows und referenzieren Version 9.0.5. Kopiere die vier YAML-Dateien nach .github/workflows im Library-Projekt. Pages und Markdown-Dokumentation laufen bei Pushes auf main oder master; Publishing und Release Notes beim Veröffentlichen eines Releases.

Der einzige Input ist config-file: ein Pfad relativ zum Root des Consumer-Projekts, standardmäßig .config.yml. Ohne with wird dieser Standard verwendet. Projektwerte wie die Java-Version werden daraus gelesen. Die festen env-Werte bleiben im Workflow sichtbar, sind aber keine aufrufbaren Einstellungen; sie zeigen auch, welche Werte später bei Bedarf in die Config ausgelagert werden können.

Beim Markdown-Linkcheck werden die GitHub-Pages-Root-URL des Repositorys und alle unter apps.publish.url-path konfigurierten Publish-URLs automatisch ausgeschlossen (mit optionalem abschließendem Slash, Query oder Fragment). Die Config-Action liefert diese relativen Pfade als publish-url-paths-json; der Markdown-Workflow erzeugt daraus direkt vor Lychee die URL-Filter. Andere URLs werden weiterhin geprüft.

name: Documentation
on:
  push:
    branches: [main]

permissions:
  contents: write

jobs:
  docs:
    uses: MFlisar/kmp-devtools/.github/workflows/reuseable-update-markdown-docs.yml@main
    with:
      config-file: .config.yml

Trigger und optional run-name definiert der Consumer. Publishing wird üblicherweise bei release: types: [published] aufgerufen. Für Maven Central benötigt der Publishing-Workflow GPG_KEY, GPG_PASSWORD, MAVEN_CENTRAL_USERNAME und MAVEN_CENTRAL_PASSWORD, die der Aufrufer explizit über secrets oder über secrets: inherit weitergibt. Die Publishing-Vorlage verwendet secrets: inherit (innerhalb desselben Benutzers, derselben Organisation oder desselben Enterprise). Für andere Aufrufer werden die benötigten Secrets explizit zugeordnet. Die anderen drei Vorlagen benötigen keine Secret-Weitergabe; GITHUB_TOKEN steht automatisch zur Verfügung. Für publish.target: github wird stattdessen TARGET_REPOSITORY_TOKEN mit Schreibzugriff auf das konfigurierte Ziel-Repository benötigt. Für Release Notes muss bereits ein Release zum aktuellen Tag existieren; bei einem Tag-Push muss der Consumer dessen Erstellung vor dem Aufruf sicherstellen. Für GitHub Pages muss das Consumer-Repository für die Bereitstellung über GitHub Actions eingerichtet sein.

Die Workflows checken das Consumer-Repository aus und verwenden zentral MFlisar/kmp-devtools/.github/actions/read-config@main; eine lokale Kopie der Action ist nicht erforderlich. Der Config-Pfad wird an diese Action weitergegeben; Gradle liest weiterhin seine .config.yml im Projekt-Root. publish.yml bleibt ein lokaler, nicht wiederverwendbarer Workflow dieses Repositorys.

Die Datei enthält die projektweiten Angaben für Publishing, Module und die Dokumentationsgenerierung. Pfade beziehen sich auf das Projektverzeichnis.

Die obersten Abschnitte publish, config, apps, project, modules und documentation sind erforderlich. publish.github wird benötigt, wenn publish.target: github gesetzt ist. Bei Modulen sind plugin und internal optionale Flags; bei documentation ist main-screenshot-path optional.