## 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
6 lines
231 B
Docker
6 lines
231 B
Docker
# Woodpecker plugin: writes dev and beta image tags with digest to oumta-deploy
|
|
FROM alpine:3.20
|
|
RUN apk add --no-cache bash git ca-certificates crane
|
|
COPY deploy.sh /usr/local/bin/deploy.sh
|
|
ENTRYPOINT ["/usr/local/bin/deploy.sh"]
|