push als String statt Boolean, dazu ein Diagnoseschritt #6

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

bk-dev-bot commented

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

Fixes #4

Die Eingabe push kommt als type: boolean nicht im Baustein an — weder ihre
Vorgabe noch ein ausdrücklich übergebener Wert. inputs.push bleibt leer, der
Baustein baut immer im Prüfmodus und meldet dabei Erfolg. Alle Eingaben vom Typ
string kommen im selben Lauf korrekt an; push war die einzige boolesche und
die einzige, die versagte (Gitea 1.27.0, Belege in #4).

Was sich ändert

push ist jetzt type: string, Werte 'true' / 'false', Vorgabe
'true'.
Die Bedingung inputs.push && inputs.push != 'false' bleibt unverändert.
Sie war von Anfang an dafür gebaut, Boolean und String zu vertragen, und
trägt die Umstellung ohne Anpassung. Der Kommentar am 1Password-Schritt hält
das jetzt ausdrücklich fest.
Der Kommentar an der Eingabe nennt den Befund samt Verweis auf #4 — sonst
stellt es beim nächsten Aufräumen jemand „korrekt“ auf boolean zurück und
holt den Fehler still zurück.

Neuer Diagnoseschritt „Eingaben melden“ am Anfang des Jobs. Er gibt den
rohen Wert und den abgeleiteten Modus aus, nach dem Muster von
„Docker-Socket ermitteln“, und kann den Job nicht scheitern lassen:

- name: Eingaben melden
  env:
    PUSH_ROH: ${{ inputs.push }}
    PUSH_MODUS: ${{ (inputs.push && inputs.push != 'false') && 'veroeffentlichen' || 'nur bauen' }}
  run: |
    echo "push (roh):        '${PUSH_ROH}'" || true
    echo "Modus:             ${PUSH_MODUS}" || true

Ausgabe im Protokoll:

push (roh):        'true'
Modus:             veroeffentlichen

README nachgezogen: beide Aufrufbeispiele auf push: 'true' bzw.
push: 'false', korrigierte Eingabetabelle, ein Hinweis, dass boolesche
workflow_call-Eingaben auf dieser Gitea-Version nicht durchgereicht werden,
und der Vermerk, dass dies eine brechende Änderung gegenüber v1 ist.

Absicherung

Der Workflow lässt sich hier nicht ausführen — er hat außer workflow_call
keinen Auslöser, und Container-Builds sind im Workspace unmöglich. Geprüft
wurde daher statisch:

YAML geparst mit zwei YAML-1.2-Parsern (js-yaml, yaml 2.x). on bleibt
in beiden ein String und wird nicht zu true verschluckt. Die Vorgabe von
push ist die Zeichenkette "true", nicht der Boolean.
Alle 22 ${{ … }}-Ausdrücke aufgelöst. Jede der 13 inputs.*-Referenzen
zeigt auf eine deklarierte Eingabe; umgekehrt wird jede deklarierte Eingabe
auch verwendet. Genutzte Kontexte: inputs, vars, secrets, steps,
github.

Die Bedingung für alle Eingabeformen durchgerechnet (Modell der
GitHub-/Gitea-Ausdruckssemantik: leerer String ist falsch, jeder andere wahr;
==/!= castet über Typgrenzen zu Zahl, 'false' wird dabei zu NaN):

Eingabe	`inputs.push`	wahr?	`!= 'false'`	Bedingung	`push:` an die Action	Modus
`push: 'true'` (Vorgabe)	`"true"`	ja	ja	wahr	`'true'`	veröffentlichen
`push: 'false'`	`"false"`	ja	nein	falsch	`'false'`	nur bauen
`push: ''` (leer)	`""`	nein	ja	falsch	`'false'`	nur bauen
`push: true` (YAML-Boolean)	`true`	ja	ja	wahr	`'true'`	veröffentlichen
`push: false` (YAML-Boolean)	`false`	nein	ja	falsch	`'false'`	nur bauen

Alle fünf Fälle ergeben den fachlich richtigen Modus — die Bedingung musste
deshalb nicht angefasst werden. Einschränkung, die man kennen muss: Für die
beiden Boolean-Zeilen gilt das nur, wenn der Wert überhaupt ankommt. Auf
dieser Gitea-Version tut er das nicht; ein unquotiertes push: false läuft
dann in die Vorgabe 'true' — also in den Push. Der Diagnoseschritt macht
genau das sichtbar, und das README warnt davor.

Diff geprüft: nur die Typumstellung, der Diagnoseschritt und Kommentare.
Keine bestehende Zeile wurde entfernt, alle vorhandenen erklärenden
Kommentare stehen unverändert; die neuen Absätze sind angehängt.

Nach dem Merge zu tun

v2 taggen (nicht v1 verschieben — v1 bleibt stehen, damit
bestehende Aufrufe nicht unangekündigt kippen).
Aufrufer in bekemeyer-klein/bk-dev-website auf @v2 umstellen:
- ci.yml → push: 'false'
- deploy.yml → push: 'true'

Dieser PR fasst bk-dev-website bewusst nicht an; die Aufrufer werden getrennt
nachgezogen, nachdem v2 steht. Nicht von mir gemergt und nicht getaggt.

Fixes #4 Die Eingabe `push` kommt als `type: boolean` nicht im Baustein an — weder ihre Vorgabe noch ein ausdrücklich übergebener Wert. `inputs.push` bleibt leer, der Baustein baut immer im Prüfmodus und meldet dabei Erfolg. Alle Eingaben vom Typ `string` kommen im selben Lauf korrekt an; `push` war die einzige boolesche und die einzige, die versagte (Gitea 1.27.0, Belege in #4). ## Was sich ändert - **`push` ist jetzt `type: string`**, Werte `'true'` / `'false'`, Vorgabe `'true'`. - **Die Bedingung `inputs.push && inputs.push != 'false'` bleibt unverändert.** Sie war von Anfang an dafür gebaut, Boolean *und* String zu vertragen, und trägt die Umstellung ohne Anpassung. Der Kommentar am 1Password-Schritt hält das jetzt ausdrücklich fest. - **Der Kommentar an der Eingabe nennt den Befund** samt Verweis auf #4 — sonst stellt es beim nächsten Aufräumen jemand „korrekt“ auf `boolean` zurück und holt den Fehler still zurück. - **Neuer Diagnoseschritt „Eingaben melden“** am Anfang des Jobs. Er gibt den rohen Wert und den abgeleiteten Modus aus, nach dem Muster von „Docker-Socket ermitteln“, und kann den Job nicht scheitern lassen: ```yaml - name: Eingaben melden env: PUSH_ROH: ${{ inputs.push }} PUSH_MODUS: ${{ (inputs.push && inputs.push != 'false') && 'veroeffentlichen' || 'nur bauen' }} run: | echo "push (roh): '${PUSH_ROH}'" || true echo "Modus: ${PUSH_MODUS}" || true ``` Ausgabe im Protokoll: ``` push (roh): 'true' Modus: veroeffentlichen ``` - **README nachgezogen:** beide Aufrufbeispiele auf `push: 'true'` bzw. `push: 'false'`, korrigierte Eingabetabelle, ein Hinweis, dass boolesche `workflow_call`-Eingaben auf dieser Gitea-Version nicht durchgereicht werden, und der Vermerk, dass dies eine brechende Änderung gegenüber `v1` ist. ## Absicherung Der Workflow lässt sich hier nicht ausführen — er hat außer `workflow_call` keinen Auslöser, und Container-Builds sind im Workspace unmöglich. Geprüft wurde daher statisch: - **YAML geparst** mit zwei YAML-1.2-Parsern (js-yaml, `yaml` 2.x). `on` bleibt in beiden ein String und wird nicht zu `true` verschluckt. Die Vorgabe von `push` ist die Zeichenkette `"true"`, nicht der Boolean. - **Alle 22 `${{ … }}`-Ausdrücke aufgelöst.** Jede der 13 `inputs.*`-Referenzen zeigt auf eine deklarierte Eingabe; umgekehrt wird jede deklarierte Eingabe auch verwendet. Genutzte Kontexte: `inputs`, `vars`, `secrets`, `steps`, `github`. - **Die Bedingung für alle Eingabeformen durchgerechnet** (Modell der GitHub-/Gitea-Ausdruckssemantik: leerer String ist falsch, jeder andere wahr; `==`/`!=` castet über Typgrenzen zu Zahl, `'false'` wird dabei zu `NaN`): | Eingabe | `inputs.push` | wahr? | `!= 'false'` | Bedingung | `push:` an die Action | Modus | | --- | --- | --- | --- | --- | --- | --- | | `push: 'true'` (Vorgabe) | `"true"` | ja | ja | **wahr** | `'true'` | veröffentlichen | | `push: 'false'` | `"false"` | ja | nein | **falsch** | `'false'` | nur bauen | | `push: ''` (leer) | `""` | nein | ja | **falsch** | `'false'` | nur bauen | | `push: true` (YAML-Boolean) | `true` | ja | ja | **wahr** | `'true'` | veröffentlichen | | `push: false` (YAML-Boolean) | `false` | nein | ja | **falsch** | `'false'` | nur bauen | Alle fünf Fälle ergeben den fachlich richtigen Modus — die Bedingung musste deshalb nicht angefasst werden. Einschränkung, die man kennen muss: Für die beiden Boolean-Zeilen gilt das nur, *wenn* der Wert überhaupt ankommt. Auf dieser Gitea-Version tut er das nicht; ein unquotiertes `push: false` läuft dann in die Vorgabe `'true'` — also in den Push. Der Diagnoseschritt macht genau das sichtbar, und das README warnt davor. - **Diff geprüft:** nur die Typumstellung, der Diagnoseschritt und Kommentare. Keine bestehende Zeile wurde entfernt, alle vorhandenen erklärenden Kommentare stehen unverändert; die neuen Absätze sind angehängt. ## Nach dem Merge zu tun 1. **`v2` taggen** (nicht `v1` verschieben — `v1` bleibt stehen, damit bestehende Aufrufe nicht unangekündigt kippen). 2. **Aufrufer in `bekemeyer-klein/bk-dev-website` auf `@v2` umstellen:** - `ci.yml` → `push: 'false'` - `deploy.yml` → `push: 'true'` Dieser PR fasst `bk-dev-website` bewusst nicht an; die Aufrufer werden getrennt nachgezogen, nachdem `v2` steht. **Nicht von mir gemergt und nicht getaggt.**

bk-dev-bot added 1 commit 2026-09-30 19:31:17 +02:00

push als String statt Boolean, dazu ein Diagnoseschritt b82d0a2155

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

jklein approved these changes

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

jklein merged commit b82d0a2155 into main

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

jklein deleted branch push-als-string

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

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: workflow-util/pipelines#6