publish-plugins.sh committet direkt auf main der Registry und scheitert am Schutz #50

New issue

Closed

opened 2026-10-14 18:27:47 +00:00 by alf · 1 comment

alf commented

2026-10-14 18:27:47 +00:00

Owner

Problem

publish-plugins.sh baut ein Plugin, trägt es im lokalen Klon des Registry-Repos ein und committet und pusht direkt auf main. Seit dem Git-Workflow (main geschützt, nur über ship) bricht das ab:

Commit auf main gesperrt - erst Branch anlegen: git checkout -b NN-slug

index.json und das Paket bleiben dabei im Klon vorgemerkt (staged), gepusht wird nichts. Beim Veröffentlichen von strata-modelle 1.0.3 (iris/Iris#46) musste ich die Änderung von Hand im Klon mit ship -r -a "feat(registry): …" einreichen (iris-plugin-registry#1). Das hat funktioniert, ist aber nicht der vorgesehene Weg.

Aufgabe

publish-plugins.sh soll im Registry-Klon selbst nach dem Workflow arbeiten: Branch anlegen (chore/plugin-<id>-<version> o. ä.), committen, danach ship (oder dessen Bausteine) verwenden, statt git commit/git push auf main. Mit --dry-run und --no-push muss sich weiterhin nichts ändern. Dabei beachten: Der Klon darf nach einem Lauf nicht mit vorgemerkten Änderungen auf main liegen bleiben, wenn der Commit scheitert.

Gleiches Muster gilt für andere Werkzeuge, die direkt in ein anderes Repo committen (zu prüfen).

## Problem `publish-plugins.sh` baut ein Plugin, trägt es im lokalen Klon des Registry-Repos ein und **committet und pusht direkt auf `main`**. Seit dem Git-Workflow (`main` geschützt, nur über `ship`) bricht das ab: ``` Commit auf main gesperrt - erst Branch anlegen: git checkout -b NN-slug ``` `index.json` und das Paket bleiben dabei im Klon vorgemerkt (staged), gepusht wird nichts. Beim Veröffentlichen von `strata-modelle` 1.0.3 (iris/Iris#46) musste ich die Änderung von Hand im Klon mit `ship -r -a "feat(registry): …"` einreichen (iris-plugin-registry#1). Das hat funktioniert, ist aber nicht der vorgesehene Weg. ## Aufgabe `publish-plugins.sh` soll im Registry-Klon selbst nach dem Workflow arbeiten: Branch anlegen (`chore/plugin-<id>-<version>` o. ä.), committen, danach `ship` (oder dessen Bausteine) verwenden, statt `git commit`/`git push` auf `main`. Mit `--dry-run` und `--no-push` muss sich weiterhin nichts ändern. Dabei beachten: Der Klon darf nach einem Lauf nicht mit vorgemerkten Änderungen auf `main` liegen bleiben, wenn der Commit scheitert. Gleiches Muster gilt für andere Werkzeuge, die direkt in ein anderes Repo committen (zu prüfen).

alf commented

2026-10-14 18:36:32 +00:00

Author

Owner

Präzisierung: Die Sperre kam vom lokalen Schutz-Hook (install-git-guard) im Klon plugin-registry, nicht von Forgejo. Laut PLUGIN-REGISTRY-REPO.md ist main der Registry bewusst ohne PR-Zwang, damit das Skript direkt pusht. Zwei saubere Wege: den Klon vom Hook ausnehmen (dokumentierte Ausnahme) oder das Skript auf Branch plus ship umstellen. Die Veröffentlichung von strata-modelle 1.0.3 habe ich per ship (iris-plugin-registry#1) eingereicht; das hat funktioniert.

Präzisierung: Die Sperre kam vom **lokalen** Schutz-Hook (`install-git-guard`) im Klon `plugin-registry`, nicht von Forgejo. Laut `PLUGIN-REGISTRY-REPO.md` ist `main` der Registry bewusst ohne PR-Zwang, damit das Skript direkt pusht. Zwei saubere Wege: den Klon vom Hook ausnehmen (dokumentierte Ausnahme) oder das Skript auf Branch plus `ship` umstellen. Die Veröffentlichung von `strata-modelle` 1.0.3 habe ich per `ship` (iris-plugin-registry#1) eingereicht; das hat funktioniert.

alf closed this issue

2026-10-19 13:13:05 +00:00

alf referenced this issue

2026-10-19 16:23:21 +00:00

Browser-Plugin: Chromium-Steuerung mit Session-Navigation #123