holm.tools.public/release

Fork 0

⚙️ 🤖 Push-Fehler wird verschluckt: `git push && git push --tags` bricht unter set -e nicht ab #3

New issue

Open

opened 2026-09-22 11:15:10 +02:00 by holm · 1 comment

holm commented

2026-09-22 11:15:10 +02:00

Owner

Dimension	Bewertung	Einschätzung
Aufwand	`█░░░░░░░░░`	Sehr niedrig — eine Zeile trennen
Nutzen	`█████████░`	Sehr hoch — ohne den Fix meldet das Tool Erfolg, wo nichts ankam
Bruchhäufigkeit	`███░░░░░░░`	Niedrig — nur wenn der Push scheitert, dann aber immer
Nachhaltigkeit	`█████████░`	Sehr hoch — einmal getrennt, dauerhaft ehrlich
Dringlichkeit	`███████░░░`	Hoch — hinterlässt ein falsch platziertes Tag auf dem Server

Symptom (aufgetreten 2026-09-22, Repo `holm.dotfiles.secret/wsm25.network.mikrotik`)

→ next version: v0.9.0
[dev 1086ecb] chore(release): v0.9.0
ssh: connect to host forgejo.mueller.network port 2222: Network is unreachable
Schwerwiegend: Konnte nicht vom Remote-Repository lesen.
✅ released v0.9.0
✅ forgejo release v0.9.0 published

Der Push schlug fehl — das Script lief trotzdem bis zum Ende durch und meldete
zweimal Erfolg.

Ursache

Zeile 100 (Schritt 7):

git push && git push --tags

set -e bricht nicht ab, wenn ein Kommando links von && fehlschlägt —
nur der letzte Befehl einer &&-Liste wird auf den Exit-Status geprüft. Der
erste git push scheitert, git push --tags wird übersprungen, der Status
der Gesamtliste ist der des letzten ausgeführten Befehls, und das Script
läuft weiter.

Folgeschaden

Schritt 8 legt danach das Forgejo-Release per API an. Forgejo erzeugt dabei
ein Tag, wenn keines existiert — und zwar auf target_commitish (Default:
main). Ergebnis auf dem Server:

Objekt	Zustand
Release `v0.9.0`	angelegt, `target=main`
Tag `v0.9.0` remote	zeigt auf den alten `main`-Merge, nicht auf den Release-Commit
Branch `dev` remote	unverändert auf dem Vorgänger-Release

Das Tag muss danach von Hand gelöscht werden, sonst zeigt der Release auf
einen Commit, der die Release-Inhalte gar nicht enthält. Ein späteres
git push --tags wird abgelehnt, weil der Name remote schon belegt ist.

Fix

git push
git push --tags

Zwei eigene Zeilen — set -e greift dann wie vorgesehen und das Script bricht
vor Schritt 8 ab. Wünschenswert zusätzlich: Schritt 8 nur ausführen, wenn das
Tag remote nachweislich angekommen ist (git ls-remote --tags origin "$next").

Umgebung

RouterOS-unabhängig, reines Shell-Verhalten. Aufgetreten mit
release.sh im Stand vom 2026-05-31 (Symlink ~/bin/release), git 2.x,
bash. Auslöser war ein Ausfall des Forgejo-SSH-Dienstes auf Port 2222
(IPv4 connection refused, IPv6 network unreachable, HTTPS 443 lief) —
der Ausfall selbst gehört nicht in dieses Issue.

🤖 angelegt von Claude v00 (API/Token holm)

| Dimension | Bewertung | Einschätzung | |---|---|---| | Aufwand | `█░░░░░░░░░` | Sehr niedrig — eine Zeile trennen | | Nutzen | `█████████░` | Sehr hoch — ohne den Fix meldet das Tool Erfolg, wo nichts ankam | | Bruchhäufigkeit | `███░░░░░░░` | Niedrig — nur wenn der Push scheitert, dann aber immer | | Nachhaltigkeit | `█████████░` | Sehr hoch — einmal getrennt, dauerhaft ehrlich | | Dringlichkeit | `███████░░░` | Hoch — hinterlässt ein falsch platziertes Tag auf dem Server | ## Symptom (aufgetreten 2026-09-22, Repo `holm.dotfiles.secret/wsm25.network.mikrotik`) ``` → next version: v0.9.0 [dev 1086ecb] chore(release): v0.9.0 ssh: connect to host forgejo.mueller.network port 2222: Network is unreachable Schwerwiegend: Konnte nicht vom Remote-Repository lesen. ✅ released v0.9.0 ✅ forgejo release v0.9.0 published ``` Der Push schlug fehl — das Script lief trotzdem bis zum Ende durch und meldete zweimal Erfolg. ## Ursache Zeile 100 (Schritt 7): ```bash git push && git push --tags ``` `set -e` bricht **nicht** ab, wenn ein Kommando links von `&&` fehlschlägt — nur der letzte Befehl einer `&&`-Liste wird auf den Exit-Status geprüft. Der erste `git push` scheitert, `git push --tags` wird übersprungen, der Status der Gesamtliste ist der des letzten *ausgeführten* Befehls, und das Script läuft weiter. ## Folgeschaden Schritt 8 legt danach das Forgejo-Release per API an. Forgejo erzeugt dabei ein Tag, wenn keines existiert — und zwar auf `target_commitish` (Default: `main`). Ergebnis auf dem Server: | Objekt | Zustand | |---|---| | Release `v0.9.0` | angelegt, `target=main` | | Tag `v0.9.0` remote | zeigt auf den alten `main`-Merge, **nicht** auf den Release-Commit | | Branch `dev` remote | unverändert auf dem Vorgänger-Release | Das Tag muss danach von Hand gelöscht werden, sonst zeigt der Release auf einen Commit, der die Release-Inhalte gar nicht enthält. Ein späteres `git push --tags` wird abgelehnt, weil der Name remote schon belegt ist. ## Fix ```bash git push git push --tags ``` Zwei eigene Zeilen — `set -e` greift dann wie vorgesehen und das Script bricht vor Schritt 8 ab. Wünschenswert zusätzlich: Schritt 8 nur ausführen, wenn das Tag remote nachweislich angekommen ist (`git ls-remote --tags origin "$next"`). ## Umgebung RouterOS-unabhängig, reines Shell-Verhalten. Aufgetreten mit `release.sh` im Stand vom 2026-05-31 (Symlink `~/bin/release`), git 2.x, bash. Auslöser war ein Ausfall des Forgejo-SSH-Dienstes auf Port 2222 (IPv4 `connection refused`, IPv6 `network unreachable`, HTTPS 443 lief) — der Ausfall selbst gehört nicht in dieses Issue. > 🤖 angelegt von Claude v00 (API/Token holm)

holm added the

Kind/Bug

Priority/High

labels

2026-09-22 11:15:10 +02:00

holm referenced this issue from a commit

2026-09-22 12:16:09 +02:00

docs(pemmikan): Forgejo-SSH-Ausfall beim v0.9.0-Release + release.sh verschluckt Push-Fehler

holm commented

2026-09-22 12:28:45 +02:00

Author

Owner

Wiedervorlage 2026-09-23 (Holm 2026-09-22: „issue für morgen")

Holm hat den Fix für morgen terminiert. Damit morgen nichts nachrecherchiert
werden muss, hier der fertige Stand.

Patch, Zeile 100

 # 7. push
-git push && git push --tags
+git push
+git push --tags
 printf '✅ released %s\n' "$next"

Mehr braucht es für das gemeldete Symptom nicht: set -e prüft nur den
letzten Befehl einer &&-Liste, getrennte Zeilen brechen sofort ab. Schritt 8
(Forgejo-Release) wird dann gar nicht erst erreicht — und ohne Schritt 8 legt
Forgejo auch kein Tag auf main an.

Optionale zweite Absicherung

Falls der Push einmal „erfolgreich" ist, das Tag aber trotzdem nicht ankommt
(Server-seitiger Hook, Ref-Filter), fängt das ein Vorab-Check vor Schritt 8:

git ls-remote --tags origin "refs/tags/$next" | grep -q . || {
  printf '❌ tag %s nicht am remote — release wird nicht angelegt\n' "$next" >&2
  exit 1
}

Ob das mit rein soll, ist Ermessenssache; der Einzeiler oben behebt den
belegten Fall.

Abnahme

Kein Testlauf nötig, der das Remote anfasst — das Verhalten lässt sich isoliert
zeigen:

bash -c 'set -e; false && true; echo "läuft weiter"'   # -> Ausgabe erscheint, rc=0 (gemessen)
bash -c 'set -e; false; true; echo "läuft weiter"'     # -> keine Ausgabe, rc=1 (gemessen)

Kontext

Aufgetreten beim Release v0.9.0 von
holm.dotfiles.secret/wsm25.network.mikrotik während des Forgejo-SSH-Ausfalls
vom 2026-09-22 (11:3x–12:05). Aufräumen dort erledigt: falscher Release (id
4778) und falsches Remote-Tag gelöscht, sauber nachgezogen, Tag zeigt jetzt auf
den Release-Commit. Der Ausfall selbst lag beim Tunnel docker24 → caddy2
(ssh -N ohne ExitOnForwardFailure=yes) und ist bei wsm25-hosting
dokumentiert — gehört nicht in dieses Issue.

🤖 angelegt von Claude v00 (API/Token holm)

## Wiedervorlage 2026-09-23 (Holm 2026-09-22: „issue für morgen") Holm hat den Fix für morgen terminiert. Damit morgen nichts nachrecherchiert werden muss, hier der fertige Stand. ### Patch, Zeile 100 ```diff # 7. push -git push && git push --tags +git push +git push --tags printf '✅ released %s\n' "$next" ``` Mehr braucht es für das gemeldete Symptom nicht: `set -e` prüft nur den letzten Befehl einer `&&`-Liste, getrennte Zeilen brechen sofort ab. Schritt 8 (Forgejo-Release) wird dann gar nicht erst erreicht — und ohne Schritt 8 legt Forgejo auch kein Tag auf `main` an. ### Optionale zweite Absicherung Falls der Push einmal „erfolgreich" ist, das Tag aber trotzdem nicht ankommt (Server-seitiger Hook, Ref-Filter), fängt das ein Vorab-Check vor Schritt 8: ```bash git ls-remote --tags origin "refs/tags/$next" | grep -q . || { printf '❌ tag %s nicht am remote — release wird nicht angelegt\n' "$next" >&2 exit 1 } ``` Ob das mit rein soll, ist Ermessenssache; der Einzeiler oben behebt den belegten Fall. ### Abnahme Kein Testlauf nötig, der das Remote anfasst — das Verhalten lässt sich isoliert zeigen: ```bash bash -c 'set -e; false && true; echo "läuft weiter"' # -> Ausgabe erscheint, rc=0 (gemessen) bash -c 'set -e; false; true; echo "läuft weiter"' # -> keine Ausgabe, rc=1 (gemessen) ``` ### Kontext Aufgetreten beim Release `v0.9.0` von `holm.dotfiles.secret/wsm25.network.mikrotik` während des Forgejo-SSH-Ausfalls vom 2026-09-22 (11:3x–12:05). Aufräumen dort erledigt: falscher Release (id 4778) und falsches Remote-Tag gelöscht, sauber nachgezogen, Tag zeigt jetzt auf den Release-Commit. Der Ausfall selbst lag beim Tunnel docker24 → caddy2 (`ssh -N` ohne `ExitOnForwardFailure=yes`) und ist bei wsm25-hosting dokumentiert — gehört nicht in dieses Issue. > 🤖 angelegt von Claude v00 (API/Token holm)

holm referenced this issue

2026-09-25 13:58:10 +02:00

⚙️ 🤖 release.sh: Forgejo-Release-POST scheitert mit HTTP 500 (nixos.fleet 2×) #5