Der Schutz „Commit trägt schon ein v-Tag, nichts tun“ zählt jetzt nur Tags derselben Art (dev, beta, stabil). Vorher hätte ein dev-Tag nach einem Fast-Forward-Merge in `release/*` das Beta-Tag und damit Build und Deploy nach beta verhindert.
Getestet im lokalen Harness: Feature vom Release-Head taggen, Fast-Forward nach `release/2.4`, Lauf auf release ergibt `v2.4.1-beta.2` auf demselben Commit; erneuter Lauf tut nichts. Release als `bump-v2.0.1`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: #5
## Was
Das Plugin `bump` setzt nur noch den Tag auf den auslösenden Commit. Es gibt keinen Versions-Commit mehr, `package.json` bleibt unberührt. Der Build nimmt die Version aus dem Tag (`CI_COMMIT_TAG`, im Beispiel als Build-Arg `VERSION`).
Grund: Mit Versions-Commit war der Head eines PRs immer der Bump-Commit mit `[skip ci]`. Dafür startet Woodpecker keine Pipeline, der verlangte Status-Check fehlt, der PR ist nicht mergebar (oumta-app). Ohne Commit bleibt der Head der des Entwicklers. Nebeneffekt: keine `update version`-Commits mehr in der Historie.
- `release_branch`: nächste stabile Version ist der höchste vorhandene Patch der Linie plus eins (vorher Patch-Bump aus `package.json`).
- Ein Commit, der schon ein `v*`-Tag trägt, wird nicht erneut getaggt. Ein Neustart der Pipeline baut also nicht doppelt.
- Image auf `alpine:3.20` wie `deploy`, Node wird nicht mehr gebraucht.
- `author_name` und `author_email` entfallen.
Breaking: Apps, die die Version aus `package.json` anzeigen, müssen sie aus dem Build-Arg lesen (Anforderung in oumta-deploy folgt). Release als `bump-v2.0.0`.
## Getestet
Lokal gegen ein Bare-Repo: feature von develop und von release, erste und weitere Betas, erneuter Lauf auf demselben Commit, hotfix mit und ohne Patch, production, `release_branch` mit vorhandenen stabilen Tags, Linie nach stabilem Tag, weitergelaufener Branch, fehlendes Token. Keine Commits auf den Branches.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: #4
## Was
Folge-PR zum Review von #2 gegen `zugaenge.md`, D8, D9 und W4 in oumta-deploy.
- `production/*`: kein Bump, der Schritt bricht mit Hinweis ab. Ein Release ist ein Retag (D9, W4).
- `main` hat keine Release-Rolle mehr. Stabile Tags gibt es nur über `settings.release_branch` als Patch-Bump, für Repos ohne Majors wie oumta-keyklo. Die Commit-Message wird nicht mehr ausgewertet.
- Linie für dev-Tags: der nächste `release/*`- oder `hotfix/*`-Branch nach jüngster Merge-Base, bei Gleichstand die niedrigere Linie. Vorher zählten nur `release/*` und nur Branch-Spitzen.
- Existiert das stabile Tag einer Linie (`v2.4.0`), geht es mit dem nächsten Patch weiter (`v2.4.1-beta.0`). Vorher blieb die Beta-Linie auf `.0` stehen und der nächste Promote wäre an „Version noch frei“ gescheitert.
- `hotfix/X.Y` ohne Patch wird abgelehnt, es würde mit `release/X.Y` kollidieren.
- Branch und Tag gehen in einem atomaren Push. Vorher konnte der Bump-Commit ohne Tag landen und jeder weitere Lauf stieg mit Exit 0 aus.
- README: Regeln, Einschränkung des Secrets auf Images und Events, Paket-Schreibrecht von `oumta-ci` in `actions`, Beispiel ohne `develop`.
## Getestet
Lokal als Image gegen ein Bare-Repo: feature von develop, erste und zweite Beta, feature von release, hotfix mit und ohne Patch, production, `release_branch`, `release_line`, Linie nach stabilem Tag, weitergelaufener Branch, fehlendes Token.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: #3
## Was
- `woodpecker/bump/`: Plugin, das aus Branch und Commit den nächsten Tag ableitet und setzt (dev, beta, hotfix→beta, main mit und ohne Marker, `release_line`), siehe D8 in oumta-deploy.
- `.woodpecker/plugins.yaml` baut jetzt beide Plugins mit Pfadfilter je Plugin; Release über Tag `bump-vX.Y.Z` bzw. `deploy-vX.Y.Z`.
- Nachträge zum deploy-Plugin aus #1: `plugin-docker-buildx:6` exakt wie in `WOODPECKER_PLUGINS_PRIVILEGED` (war nach dem Merge noch `6.1.2`), Registry-Login mit `oumta-ci` und Secret `oumta_ci_token` statt der globalen Secrets, README-Beispiele entsprechend (zugaenge.md in oumta-deploy).
## Voraussetzungen vor dem Tag
- Secret `oumta_ci_token` in Woodpecker für `actions/ci-cd`, freigegeben für `woodpeckerci/plugin-docker-buildx:6`, Events `push`, `tag`, `manual`.
- `oumta-ci` mit Paket-Schreibrecht in der Org `actions`.
## Getestet
Lokal gegen ein Bare-Repo: dev, beta, hotfix→beta, main mit und ohne Marker, `release_line`, weitergelaufener Branch, fehlendes Token.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: #2
## Was
Woodpecker-Plugin `deploy` (`git.uesome.de/actions/ci-cd/deploy`): schreibt ein gepushtes dev- oder beta-Image mit Digest nach `tanztee/oumta-deploy`. Die Umgebung entscheidet dort `ci/deploy-image.sh` anhand des Tags (`-dev.` → dev, `-beta.` → beta, sonst nichts; prod nur per PR). Digest per `crane`, kein Docker-Daemon nötig (dafür tanztee/oumta-deploy#20).
- `woodpecker/deploy/`: Dockerfile (`alpine:3.20`, bash, git, crane) und `deploy.sh`
- `.woodpecker/plugins.yaml`: Push/PR mit Änderungen unter `woodpecker/deploy/**` → nur Probe-Build (`dry_run`, ohne Secrets); Tag `deploy-vX.Y.Z` → Push als `:vX.Y.Z`
- `README.md`: Abschnitt „Woodpecker plugins“ mit Settings und Beispiel
Das Token von `oumta-ci` steht nur im Credential-Helper, nicht in URL oder Config.
## Getestet (lokal, crane als Stub, gegen Kopie von oumta-deploy `a74c73d`)
| Fall | Ergebnis |
| --- | --- |
| `v2.0.1-dev.…`, `AUTH_IMAGE` | `deploy(dev): oumta-auth …` |
| `v2.0.9-beta.7`, `APP_V{major}_IMAGE` | `APP_V2_IMAGE` in beta |
| `v2.0.1` | nichts zu tun, Exit 0 |
| keyklo, `envs: dev beta` | zwei Commits |
| gleicher Tag erneut | „bereits aktuell“ |
| ohne `deploy_token` | Abbruch mit Meldung |
Offen: echter Lauf gegen Registry und Gitea per HTTPS.
## Vor dem ersten Lauf in Woodpecker
1. `actions/ci-cd` aktivieren.
2. Repo-Secrets `registry_username`/`registry_password` (Schreibrecht auf Pakete der Org `actions`), nur Event `tag`, nur Image `woodpeckerci/plugin-docker-buildx`.
3. Prüfen, ob `plugin-docker-buildx:6.1.2` privilegiert laufen darf (`WOODPECKER_PLUGINS_PRIVILEGED`).
Tag `deploy-v1.0.0` erst nach dem Merge und grünem Probe-Build.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: #1
tu