compose: verwaistes networks-Fragment aus d904734 — Fix wartet auf Branch fix/compose-networks-fragment #1

Closed
opened 2026-07-31 21:10:47 +00:00 by sorb · 2 comments
Owner

Der Runner-Rückbau-Commit d904734 hat beim Entfernen des runner-Services dessen
networks:-Liste als Top-Level-Fragment stehen lassen. Ergebnis: doppelter
networks-Key in docker-compose.yml, YAML invalide, docker compose bricht mit
mapping key "networks" already defined at line 81 ab — der Stack lässt sich aus
dem Repo-Stand heraus nicht deployen.

Der Fix liegt als Branch fix/compose-networks-fragment (Commit 69ef148) hier
in der Gitea
— entfernt das Fragment und das nur vom Runner genutzte
default-Netz:

-networks:
-      - default
-
 networks:
   traefik:
     external: true
-  default:

Warum der Branch ausgerechnet hier liegt

Weil ich beim Rückbau am 2026-07-31 die Spiegel-Richtung falsch gelesen habe: Der
Fix wurde von CFGMON aus direkt nach main in dieser Gitea gepusht. Das verstößt
gegen die Repo-Topologie (Backlogs/hosts/overmind.md): git.lab ist kanonisch,
diese Gitea ist Push-Mirror-Ziel, direkte Gitea-Pushes sind tabu. Der nächste
Mirror-Lauf hätte den Commit force-artig überschrieben und den Fix still
verschwinden lassen.

main steht deshalb wieder auf d904734, also exakt auf dem Stand von git.lab —
die Spiegelung ist wieder konsistent. Der Fix ist nicht verloren, sondern parkt
auf dem Branch, bis er den kanonischen Weg genommen hat.

CFGMON kann git.lab (Overmind, 10.58.73.17) nicht erreichen: kein VPN ins
Homelab, kein Routing, DNS löst außerhalb des Labs nicht auf. Der Weg führt
zwingend über den Mac.

Zu tun

Vom Mac aus, aus dem thread-net-git-Klon (Remote-Namen ggf. anpassen):

git fetch gitea
git cherry-pick 69ef148
git push origin main          # origin = git.lab

Danach spiegelt git.lab den Commit von selbst hierher, und dieser Branch kann
weg (git push gitea --delete fix/compose-networks-fragment).

Zustand auf CFGMON

Der Rückbau selbst ist vollständig: Runner-Container, Docker-Netz,
runner-data/ und .env sind entfernt, der Runner-Eintrag builder-1 ist aus
der Gitea gelöscht, das Actions-Registrierungstoken ist rotiert. Gitea, Traefik
und cAdvisor laufen unverändert.

/opt/thread-net-git ist auf fix/compose-networks-fragment ausgecheckt, damit
die reparierte docker-compose.yml auf der Platte liegt und der Stack
deploybar bleibt. Nach dem Sync über git.lab bitte zurück auf main.

Der Runner-Rückbau-Commit d904734 hat beim Entfernen des `runner`-Services dessen `networks:`-Liste als Top-Level-Fragment stehen lassen. Ergebnis: doppelter `networks`-Key in `docker-compose.yml`, YAML invalide, `docker compose` bricht mit `mapping key "networks" already defined at line 81` ab — der Stack lässt sich aus dem Repo-Stand heraus nicht deployen. **Der Fix liegt als Branch `fix/compose-networks-fragment` (Commit 69ef148) hier in der Gitea** — entfernt das Fragment und das nur vom Runner genutzte `default`-Netz: ```diff -networks: - - default - networks: traefik: external: true - default: ``` ## Warum der Branch ausgerechnet hier liegt Weil ich beim Rückbau am 2026-07-31 die Spiegel-Richtung falsch gelesen habe: Der Fix wurde von CFGMON aus direkt nach `main` in dieser Gitea gepusht. Das verstößt gegen die Repo-Topologie (`Backlogs/hosts/overmind.md`): git.lab ist kanonisch, diese Gitea ist Push-Mirror-Ziel, direkte Gitea-Pushes sind tabu. Der nächste Mirror-Lauf hätte den Commit force-artig überschrieben und den Fix still verschwinden lassen. `main` steht deshalb wieder auf d904734, also exakt auf dem Stand von git.lab — die Spiegelung ist wieder konsistent. Der Fix ist nicht verloren, sondern parkt auf dem Branch, bis er den kanonischen Weg genommen hat. CFGMON kann git.lab (Overmind, `10.58.73.17`) nicht erreichen: kein VPN ins Homelab, kein Routing, DNS löst außerhalb des Labs nicht auf. Der Weg führt zwingend über den Mac. ## Zu tun Vom Mac aus, aus dem thread-net-git-Klon (Remote-Namen ggf. anpassen): ``` git fetch gitea git cherry-pick 69ef148 git push origin main # origin = git.lab ``` Danach spiegelt git.lab den Commit von selbst hierher, und dieser Branch kann weg (`git push gitea --delete fix/compose-networks-fragment`). ## Zustand auf CFGMON Der Rückbau selbst ist vollständig: Runner-Container, Docker-Netz, `runner-data/` und `.env` sind entfernt, der Runner-Eintrag `builder-1` ist aus der Gitea gelöscht, das Actions-Registrierungstoken ist rotiert. Gitea, Traefik und cAdvisor laufen unverändert. `/opt/thread-net-git` ist auf `fix/compose-networks-fragment` ausgecheckt, damit die reparierte `docker-compose.yml` auf der Platte liegt und der Stack deploybar bleibt. Nach dem Sync über git.lab bitte zurück auf `main`.
Author
Owner

Erledigt (2026-07-31, ~22:45 lokal, vom Mac aus): Der Fix hat den kanonischen Weg genommen.

  • 69ef148 als 15c8f2d auf main gecherry-pickt und nach git.lab gepusht; der Push-Mirror hat den Stand nach Gitea gespiegelt (verifiziert: beide main auf 15c8f2d3). YAML lokal gegengeprüft.
  • Park-Branch fix/compose-networks-fragment hier gelöscht — Historie und Begründung bleiben in diesem Issue erhalten.

Verbleibender Handgriff auf CFGMON (unkritisch, wann immer passend): cd /opt/thread-net-git && git checkout main && git pull — inhaltlich identisch mit dem ausgecheckten Fix-Branch, danach ist der Checkout wieder auf dem Standard-Branch.

Ursache fürs Protokoll: Der Rückbau-Commit d904734 (aus der Mac-Session) hat beim Entfernen des runner-Services dessen networks:-Liste als Top-Level-Fragment stehen lassen — mein Fehler; der Commit wurde vor dem Push nicht mit docker compose config validiert. Lehre übernommen: Compose-Änderungen künftig vor dem Push syntaxprüfen.

**Erledigt** (2026-07-31, ~22:45 lokal, vom Mac aus): Der Fix hat den kanonischen Weg genommen. - `69ef148` als `15c8f2d` auf `main` gecherry-pickt und nach **git.lab** gepusht; der Push-Mirror hat den Stand nach Gitea gespiegelt (verifiziert: beide `main` auf `15c8f2d3`). YAML lokal gegengeprüft. - Park-Branch `fix/compose-networks-fragment` hier gelöscht — Historie und Begründung bleiben in diesem Issue erhalten. Verbleibender Handgriff auf CFGMON (unkritisch, wann immer passend): `cd /opt/thread-net-git && git checkout main && git pull` — inhaltlich identisch mit dem ausgecheckten Fix-Branch, danach ist der Checkout wieder auf dem Standard-Branch. Ursache fürs Protokoll: Der Rückbau-Commit `d904734` (aus der Mac-Session) hat beim Entfernen des runner-Services dessen `networks:`-Liste als Top-Level-Fragment stehen lassen — mein Fehler; der Commit wurde vor dem Push nicht mit `docker compose config` validiert. Lehre übernommen: Compose-Änderungen künftig vor dem Push syntaxprüfen.
sorb closed this issue 2026-07-31 21:15:15 +00:00
Author
Owner

Migriert nach git.lab: axion1337.chat/thread-net-git#1 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

**Migriert nach git.lab**: [axion1337.chat/thread-net-git#1](https://git.lab/axion1337.chat/thread-net-git/-/issues/1) (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/thread-net-git#1