Boolesche Eingabe push kommt nicht an — auf string umstellen #4

New Issue

2026-09-30T19:25:47+02:00

bk-dev-bot commented

2026-09-30 19:25:47 +02:00

Die Eingabe push vom Typ boolean kommt im Baustein nicht an. Weder ihre Vorgabe noch ein ausdrücklich übergebener Wert wirken — der Baustein baut immer im Prüfmodus und meldet dabei Erfolg.

Belege

Gemessen an zwei Läufen des ersten Abnehmers (bekemeyer-klein/bk-dev-website):

Lauf	Aufruf	Ergebnis
272	`push` weggelassen, Vorgabe `true`	kein `--push`, nichts veröffentlicht, Lauf grün
276	`push: true` ausdrücklich übergeben	kein `--push`, nichts veröffentlicht, Lauf grün

Die Kommandozeile aus Lauf 276:

docker buildx build --file docker/bk-dev-website.dockerfile --iidfile … \
  --platform linux/amd64 --attest … \
  --tag git.jk-dev.de/bekemeyer-klein/bk-dev-website:latest \
  --tag git.jk-dev.de/bekemeyer-klein/bk-dev-website:2026.09.1 …

Kein --push. Dazu im Protokoll:

WARNING: No output specified with docker-container driver.
Build result will only remain in the build cache.
To push result image into registry use --push

Die Eingrenzung

Im selben Lauf kommen alle Eingaben vom Typ string korrekt an:

Eingabe	Typ	Wirkung
`platforms`	string	`--platform linux/amd64` ✔
`registry`, `image-owner`, `container-name`	string	Tags korrekt aufgelöst ✔
`push`	boolean	wirkungslos ✘

push ist die einzige boolesche Eingabe des Bausteins, und sie ist die einzige, die nicht ankommt. Die Bedingung inputs.push && inputs.push != 'false' wertet den leeren Wert als falsch — fachlich richtig, nur bekommt sie nie etwas anderes zu sehen.

Instanz: Gitea 1.27.0.

Behebung

push auf type: string umstellen, Werte 'true' / 'false', Vorgabe 'true'.

Die vorhandene Bedingung trägt das unverändert: Sie wurde seinerzeit ausdrücklich so gebaut, dass sie Boolean und String verträgt — 'true' ist truthy und ungleich 'false', 'false' ist truthy aber gleich 'false'. Beide Fälle ergeben das Richtige.

Zusätzlich einen Diagnoseschritt aufnehmen, der den empfangenen Wert ausgibt. Der Fehler war nur deshalb so langlebig, weil nirgends sichtbar war, was tatsächlich ankommt — und weil ein Lauf ohne Push genauso grün aussieht wie einer mit.

Folgen

Bricht bestehende Aufrufe, die push: true als YAML-Boolean übergeben. Nach Absprache wird deshalb v2 getaggt statt v1 zu verschieben; Aufrufer ziehen bewusst nach.

Für bk-dev-website sind das zwei Stellen: ci.yml (Prüfmodus, push: 'false') und deploy.yml (push: 'true').

Die Eingabe `push` vom Typ `boolean` kommt im Baustein nicht an. Weder ihre Vorgabe noch ein ausdrücklich übergebener Wert wirken — der Baustein baut immer im Prüfmodus und meldet dabei Erfolg. ## Belege Gemessen an zwei Läufen des ersten Abnehmers (`bekemeyer-klein/bk-dev-website`): | Lauf | Aufruf | Ergebnis | | --- | --- | --- | | 272 | `push` weggelassen, Vorgabe `true` | kein `--push`, nichts veröffentlicht, Lauf grün | | 276 | `push: true` **ausdrücklich** übergeben | kein `--push`, nichts veröffentlicht, Lauf grün | Die Kommandozeile aus Lauf 276: ``` docker buildx build --file docker/bk-dev-website.dockerfile --iidfile … \ --platform linux/amd64 --attest … \ --tag git.jk-dev.de/bekemeyer-klein/bk-dev-website:latest \ --tag git.jk-dev.de/bekemeyer-klein/bk-dev-website:2026.09.1 … ``` Kein `--push`. Dazu im Protokoll: ``` WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push ``` ## Die Eingrenzung Im selben Lauf kommen **alle Eingaben vom Typ `string` korrekt an**: | Eingabe | Typ | Wirkung | | --- | --- | --- | | `platforms` | string | `--platform linux/amd64` ✔ | | `registry`, `image-owner`, `container-name` | string | Tags korrekt aufgelöst ✔ | | `push` | **boolean** | **wirkungslos** ✘ | `push` ist die einzige boolesche Eingabe des Bausteins, und sie ist die einzige, die nicht ankommt. Die Bedingung `inputs.push && inputs.push != 'false'` wertet den leeren Wert als falsch — fachlich richtig, nur bekommt sie nie etwas anderes zu sehen. Instanz: Gitea 1.27.0. ## Behebung `push` auf `type: string` umstellen, Werte `'true'` / `'false'`, Vorgabe `'true'`. Die vorhandene Bedingung trägt das unverändert: Sie wurde seinerzeit ausdrücklich so gebaut, dass sie Boolean **und** String verträgt — `'true'` ist truthy und ungleich `'false'`, `'false'` ist truthy aber gleich `'false'`. Beide Fälle ergeben das Richtige. **Zusätzlich einen Diagnoseschritt aufnehmen**, der den empfangenen Wert ausgibt. Der Fehler war nur deshalb so langlebig, weil nirgends sichtbar war, was tatsächlich ankommt — und weil ein Lauf ohne Push genauso grün aussieht wie einer mit. ## Folgen Bricht bestehende Aufrufe, die `push: true` als YAML-Boolean übergeben. Nach Absprache wird deshalb **`v2`** getaggt statt `v1` zu verschieben; Aufrufer ziehen bewusst nach. Für `bk-dev-website` sind das zwei Stellen: `ci.yml` (Prüfmodus, `push: 'false'`) und `deploy.yml` (`push: 'true'`).

bk-dev-bot referenced this issue

2026-09-30 19:28:52 +02:00

Kleinere Schwachstellen: wandernder Action-Verweis, falsche Beschreibung, doppelter Tag #5

bk-dev-bot referenced this issue from a commit

2026-09-30 19:30:45 +02:00

push als String statt Boolean, dazu ein Diagnoseschritt

bk-dev-bot referenced a pull request that will close this issue

2026-09-30 19:31:17 +02:00

push als String statt Boolean, dazu ein Diagnoseschritt #6

jklein closed this issue

2026-09-30 19:32:40 +02:00

bk-dev-bot referenced this issue from a commit