Commit Graph
4 Commits
Author SHA1 Message Date
tbekemeyer b82d0a2155 push als String statt Boolean, dazu ein Diagnoseschritt
Eine boolesche workflow_call-Eingabe kommt auf dieser Gitea-Version nicht
im aufgerufenen Workflow an — weder ihre Vorgabe noch ein ausdruecklich
uebergebener Wert. inputs.push blieb leer, der Baustein baute immer im
Pruefmodus und meldete dabei Erfolg. Alle Eingaben vom Typ string kamen
im selben Lauf korrekt an; push war die einzige boolesche und die
einzige, die versagte.

push ist deshalb jetzt type: string mit den Werten 'true' und 'false' und
der Vorgabe 'true'. Die Bedingung inputs.push && inputs.push != 'false'
bleibt unveraendert: sie war von Anfang an fuer Boolean und String
gebaut und traegt die Umstellung ohne Anpassung. Der Kommentar an der
Eingabe haelt den Befund fest, damit die Eingabe nicht beim naechsten
Aufraeumen "korrekt" auf boolean zurueckgestellt wird und den Fehler
still zurueckholt.

Neu ist ein Diagnoseschritt am Anfang des Jobs, der den empfangenen Wert
und den daraus abgeleiteten Modus ausgibt. Der Fehler war nur deshalb so
langlebig, weil nirgends sichtbar war, was tatsaechlich ankommt — und
weil ein Lauf ohne Push genauso gruen aussieht wie einer mit. Der Schritt
folgt dem Muster von "Docker-Socket ermitteln" und kann den Job nicht
scheitern lassen.

Brechende Aenderung gegenueber v1: Aufrufer, die push als YAML-Boolean
uebergeben, muessen auf @v2 wechseln und in Anfuehrungszeichen schreiben.
Das README ist entsprechend nachgezogen.

Fixes #4
v2
2026-09-30 17:30:40 +00:00
tbekemeyer 47b77fac54 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.
v1
2026-09-30 14:01:18 +00:00
tbekemeyer 18f672ed2a Geteilte Docker-Build-and-Push-Pipeline anlegen
Die bisher in einem einzelnen Projekt liegende Pipeline zieht als
wiederverwendbarer Workflow (on: workflow_call) nach
.gitea/workflows/docker-build-push.yml um.

Inhaltlich geaendert ist genau eine Stelle: Der Eigentuemer des Images
stand als IMAGE_OWNER fest im env-Block des Workflows, wodurch jedes
Image jedes aufrufenden Projekts unter git.jk-dev.de/suer/... gelandet
waere. Er ist jetzt die Eingabe image-owner mit suer als Vorgabewert,
sodass bestehende Aufrufer unveraendert weiterlaufen.

Der Wert kann nicht im env-Block bleiben: env auf Workflow-Ebene wird
ausgewertet, bevor es einen inputs-Kontext gibt. Die Tag-Liste liest ihn
deshalb unmittelbar aus inputs.

Alles Uebrige ist unveraendert uebernommen, samt der Kommentare, die das
Warum erklaeren: 1Password Connect, runs-on, DOCKER_HOST, Diagnoseschritt,
Multi-Arch und Tag-Schema.

Die README dokumentiert Eingaben, ein vollstaendiges Aufrufbeispiel, die
Voraussetzungen im aufrufenden Repository und den Hinweis, auf einen Tag
statt auf @main zu zeigen.
2026-09-30 12:16:34 +00:00
workflow-util 75c309ac23 Initial commit 2026-09-30 12:08:41 +00:00