Push-Steuerung, Pflicht-Eigentuemer und konfigurierbare Registry

Der Baustein taugt jetzt auch fuer reine Prueflaeufe. Die neue Eingabe push (boolean, Vorgabe true) steuert, ob gepusht wird. Bei push: false entfaellt der 1Password-Schritt, es findet kein Registry-Login statt und docker/build-push-action baut mit push: false. Bei push: true bleibt alles wie bisher. Damit nutzt die CI eines Projekts dieselbe Bau-Logik wie das Deployment, statt sie zu duplizieren. Folge, die man kennen muss: der Checkout-Token stammt aus demselben 1Password-Schritt. Ohne Push faellt der Checkout auf den Standard-Token des Jobs zurueck, und der kann keine privaten Submodule klonen. Der Modus taugt deshalb nur fuer Projekte ohne private Submodule. Dokumentiert im Workflow und in der README. Die vier Versionsangaben sind nicht mehr Pflicht -- sie dienen ausschliesslich der Tag-Liste, die ohne Push bedeutungslos ist, und ein Prueflauf muesste sonst Platzhalter erfinden. required von true auf false zu senken ist rueckwaertskompatibel. Die Vorgabe ist 0 bzw. 0.0.0 und nicht leer: die Tag-Liste wird auch ohne Push gebildet und ein leerer Wert ergaebe das ungueltige ".../<name>:". Aus dem Review: - image-owner ist jetzt required ohne Vorgabe. Der Eigentuemer ist je Projekt verschieden und soll nie stillschweigend geraten werden -- genau das war der Fehler des frueheren, fest verdrahteten "suer". Bestehende Aufrufer muessen ihn dadurch ergaenzen; das ist gewollt. - REGISTRY ist von einem festen env-Eintrag zur Eingabe registry mit Vorgabe git.jk-dev.de geworden. Der env-Block auf Workflow-Ebene entfaellt damit ersatzlos -- er kannte ohnehin keinen inputs-Kontext. Registry und Eigentuemer werden dort gelesen, wo der Kontext sicher vorhanden ist: im Login-Schritt und in der Tag-Liste.
2026-09-30 14:01:18 +00:00
1 parent 18f672ed2a
commit 47b77fac54
@@ -9,38 +9,55 @@ hier werden nicht selbst ausgelöst, sondern von anderen Repositories über
 ### `.gitea/workflows/docker-build-push.yml`

 Baut ein Docker-Image und schiebt es als Multi-Arch-Manifest
-(`linux/amd64,linux/arm64`) in die Registry `git.jk-dev.de`. Läuft auf einem
-Runner mit dem Label `ubuntu-docker`.
+(`linux/amd64,linux/arm64`) in eine Registry, vorgabegemäß `git.jk-dev.de`.
+Läuft auf einem Runner mit dem Label `ubuntu-docker`.

 Gepusht wird unter fünf Tags:

 ```
-git.jk-dev.de/<image-owner>/<container-name>:latest
-git.jk-dev.de/<image-owner>/<container-name>:<version-number>
-git.jk-dev.de/<image-owner>/<container-name>:<major>
-git.jk-dev.de/<image-owner>/<container-name>:<major>.<minor>
-git.jk-dev.de/<image-owner>/<container-name>:<major>.<minor>.<patch>
+<registry>/<image-owner>/<container-name>:latest
+<registry>/<image-owner>/<container-name>:<version-number>
+<registry>/<image-owner>/<container-name>:<major>
+<registry>/<image-owner>/<container-name>:<major>.<minor>
+<registry>/<image-owner>/<container-name>:<major>.<minor>.<patch>
 ```

 Der Checkout holt Submodule mit; die Zugangsdaten dafür und für die Registry
 kommen zur Laufzeit aus 1Password Connect.

+Mit `push: false` entfällt der Push — der Baustein baut dann nur. Damit nutzt
+die CI eines Projekts dieselbe Bau-Logik wie das Deployment, statt sie zu
+duplizieren. Siehe [Prüfmodus](#prüfmodus-ohne-push).
+
 #### Eingaben

 | Eingabe                | Pflicht | Vorgabe                   | Bedeutung |
 | ---------------------- | ------- | ------------------------- | --------- |
-| `version-number`       | ja      | —                         | Vollständige Version, wird als Tag gesetzt |
-| `version-number-major` | ja      | —                         | Major-Anteil für die mitwandernden Tags |
-| `version-number-minor` | ja      | —                         | Minor-Anteil |
-| `version-number-patch` | ja      | —                         | Patch-Anteil |
 | `container-name`       | ja      | —                         | Name des Images |
 | `dockerfile`           | ja      | —                         | Pfad zum Dockerfile |
 | `docker-context`       | ja      | —                         | Build-Kontext |
-| `image-owner`          | nein    | `suer`                    | Eigentümer-Segment des Images, also der mittlere Teil von `<registry>/<owner>/<name>` |
+| `image-owner`          | ja      | —                         | Eigentümer-Segment des Images, also der mittlere Teil von `<registry>/<owner>/<name>` |
+| `push`                 | nein    | `true`                    | Ob das Image gepusht wird. Bei `false` werden keine Zugangsdaten aus 1Password geholt und es findet kein Registry-Login statt — siehe [Prüfmodus](#prüfmodus-ohne-push) |
+| `registry`             | nein    | `git.jk-dev.de`           | Registry, für die getaggt und — beim Push — bei der angemeldet wird |
+| `version-number`       | nein    | `0.0.0`                   | Vollständige Version, wird als Tag gesetzt |
+| `version-number-major` | nein    | `0`                       | Major-Anteil für die mitwandernden Tags |
+| `version-number-minor` | nein    | `0`                       | Minor-Anteil |
+| `version-number-patch` | nein    | `0`                       | Patch-Anteil |
 | `timeout-minutes`      | nein    | `45`                      | Harte Grenze für den Build-Job |
 | `platforms`            | nein    | `linux/amd64,linux/arm64` | Zielplattformen der Manifest-Liste |
 | `build-args`           | nein    | —                         | Zusätzliche Build-Argumente, ein `NAME=wert` je Zeile |

+Dass `image-owner` Pflicht ist und `registry` nicht, ist Absicht: Der Eigentümer
+ist je Projekt verschieden und soll nie stillschweigend geraten werden — genau
+das war der Fehler des früher fest verdrahteten `suer`, unter dem die Images
+aller Projekte landeten. Die Registry ist dagegen praktisch immer dieselbe.
+
+Die vier Versionsangaben dienen ausschließlich der Tag-Liste. Sie sind keine
+Pflicht mehr, damit ein Prüflauf keine Platzhalter erfinden muss; wer pusht,
+übergibt sie wie bisher. Ihre Vorgabe ist bewusst `0.0.0` und nicht leer — die
+Tag-Liste wird auch ohne Push gebildet, und ein leerer Wert ergäbe das ungültige
+`…/<name>:`.
+
 #### Aufrufbeispiel

 ```yaml
@@ -62,12 +79,45 @@ jobs:
 `secrets: inherit` ist notwendig — der Workflow braucht `OP_CONNECT_TOKEN` aus
 dem aufrufenden Repository.

+#### Prüfmodus ohne Push
+
+Mit `push: false` baut der Baustein nur und veröffentlicht nichts. Es werden
+dann keine Zugangsdaten aus 1Password geholt und es findet kein Registry-Login
+statt. Die CI eines Projekts nutzt damit dieselbe Bau-Logik wie das Deployment,
+statt sie zu duplizieren.
+
+Weder Secrets noch Versionsangaben sind dafür nötig:
+
+```yaml
+jobs:
+  build-check:
+    uses: workflow-util/pipelines/.gitea/workflows/docker-build-push.yml@v1
+    with:
+      container-name: bk-dev-website
+      dockerfile: ./Dockerfile
+      docker-context: .
+      image-owner: bekemeyer-klein
+      push: false
+```
+
+> **Private Submodule funktionieren in diesem Modus nicht.**
+> Der Checkout-Token stammt aus demselben 1Password-Schritt, der ohne Push
+> übersprungen wird. Der Checkout fällt deshalb auf den Standard-Token des Jobs
+> zurück. Der genügt für das ausführende Repository, nicht aber für die
+> Submodule in eigenen privaten Repositories — deren Klon scheitert mit
+> `Repository not found`. Projekte **mit** privaten Submodulen können
+> `push: false` daher nicht verwenden; für Projekte ohne Submodule ist der
+> Modus unproblematisch.
+
+`secrets: inherit` kann hier entfallen. Es zu belassen schadet nicht — der
+Workflow greift ohne Push auf kein Secret zu.
+
 #### Voraussetzungen im aufrufenden Repository

 | Name               | Art      | Zweck |
 | ------------------ | -------- | ----- |
-| `OP_CONNECT_HOST`  | Variable | Adresse des 1Password-Connect-Servers im Cluster |
-| `OP_CONNECT_TOKEN` | Secret   | Zugang zu diesem Connect-Server |
+| `OP_CONNECT_HOST`  | Variable | Adresse des 1Password-Connect-Servers im Cluster. Nur beim Push nötig |
+| `OP_CONNECT_TOKEN` | Secret   | Zugang zu diesem Connect-Server. Nur beim Push nötig |
 | `DOCKER_HOST`      | Variable | Nur nötig, wenn der Runner-Daemon rootless läuft und sein Socket nicht unter `/var/run/docker.sock` liegt (dann z. B. `unix:///run/user/1000/docker.sock`). Ist die Variable nicht gesetzt, nutzt Docker seinen Default. |

 Die eigentlichen Zugänge für Checkout und Registry liegen in 1Password