Meldeweg bei rotem Deploy und Zeitlimits fuer die cachly-Jobs

[HeinrichNebula]

WAS — Ein fehlgeschlagener Kan-Deploy meldet sich jetzt selbst, und beide Jobs des cachly-eigenen Workflows bekommen ein Zeitlimit.

WIRKUNG — Fuer Nutzer von kan.cachly.dev aendert sich nichts. Fuer den Betrieb: bisher blieb ein roter Deploy stumm, man musste von sich aus in die Actions-Oberflaeche schauen. Kuenftig geht eine Nachricht in die Telegram-Ops-Gruppe, bei Erfolg wie bei Misserfolg. Solange die beiden Telegram-Secrets fehlen, sagt der Lauf selbst laut, dass niemand benachrichtigt wurde.

ZIEL & VISION — Ziel: die zwei fehlenden Repo-Secrets setzen, dann ist der Meldeweg scharf. Vision: kein Ausrollen mehr, das unbemerkt scheitert, in keinem der Repos.

ERWARTUNG — Nach dem Zusammenfuehren zeigt der naechste Lauf von "Cachly Deploy" einen zusaetzlichen Schritt "Telegram-Meldung (Deploy-Ergebnis)". Weil TELEGRAM_BOT_TOKEN und TELEGRAM_CHAT_ID hier noch nicht gesetzt sind, endet er mit einer gelben Warnung im Lauf-Protokoll (bei rotem Deploy mit einer roten Fehlermeldung) statt mit einer Telegram-Nachricht. Der Lauf wird davon nie rot. NICHT geloest: die Secrets selbst; und die beiden Upstream-Workflows haben weiterhin kein Zeitlimit (Begruendung unten).

---

1. Meldeweg bei rotem Deploy

Geaendert wurde ausschliesslich cachly-deploy.yml — der einzige Workflow dieses Forks, der nach node-1 ausliefert.

Vorbild: kanzlei-kompass/.github/workflows/deploy.yml, Zeilen 94-110. Uebernommen sind if: always(), die Unterscheidung nach job.status und der Versand per curl an die Telegram-Bot-API.

Ein Punkt ist bewusst anders geloest. Das Vorbild setzt still aus, wenn die Secrets fehlen:

[ -z "$TG_TOKEN" ] || [ -z "$TG_CHAT" ] && { echo "telegram secrets unset — skipping"; exit 0; }

Ein Meldeweg, der unbemerkt nichts tut, ist schlimmer als gar keiner, weil man sich auf ihn verlaesst. Hier schreibt der Schritt stattdessen eine Anmerkung in den Lauf:

• Deploy rot und Secrets fehlen: ::error:: — die Meldung erscheint oben in der Lauf-Uebersicht.
• Deploy gruen und Secrets fehlen: ::warning::.
• Versand scheitert (Netz, falsche Chat-Id, Token abgelaufen): ::error:: mit dem Text, der haette rausgehen sollen.

Der Schritt faerbt den Lauf nie rot (er endet immer mit Exit 0). Ein kaputter Meldeweg soll ein gelungenes Ausrollen nicht nachtraeglich als Fehlschlag darstellen.

Nachgewiesen — der run-Block wurde aus der YAML-Datei extrahiert und in vier Faellen ausgefuehrt:

### Secrets fehlen, Deploy ROT
::error::Deploy ist rot UND der Meldeweg ist inaktiv (TELEGRAM_BOT_TOKEN und/oder TELEGRAM_CHAT_ID fehlen als Repo-Secret). Niemand wurde benachrichtigt. Text waere gewesen: Kan Deploy ROT (failure) — 9f8e7d6. Lauf: https://github.com/cachly-dev/kan/actions/runs/101
exit=0
### Secrets fehlen, Deploy GRUEN
::warning::Meldeweg inaktiv — TELEGRAM_BOT_TOKEN und/oder TELEGRAM_CHAT_ID fehlen als Repo-Secret. Bei einem roten Deploy wuerde niemand benachrichtigt.
exit=0
### Secrets da, Versand klappt
Telegram-Meldung zugestellt (success).
exit=0
### Secrets da, Versand scheitert
::error::Telegram-Meldung konnte NICHT zugestellt werden (failure). Text waere gewesen: Kan Deploy ROT (failure) — 9f8e7d6. Lauf: https://github.com/cachly-dev/kan/actions/runs/101
exit=0

2. Secrets — Stand in diesem Repo

$ gh secret list -R cachly-dev/kan
DEPLOY_CHANNEL_KEY      2026-08-09T04:55:57Z
REGISTRY_PASSWORD       2026-08-06T22:41:03Z

TELEGRAM_BOT_TOKEN und TELEGRAM_CHAT_ID fehlen. Auch org-weit gibt es sie nicht:

$ gh secret list --org cachly-dev
CRATES_IO_TOKEN 2026-04-11T01:53:13Z    ALL
NPM_TOKEN       2026-07-05T22:24:54Z    ALL

Sie existieren bisher nur im Kanzlei-Kompass-Repo (gh secret list -R HeinrichNebula/kanzlei-kompass zeigt beide, vom 12.07.2026). Bot-Token und Chat-Id lassen sich von dort uebernehmen, wenn dieselbe Ops-Gruppe gemeint ist.

Zwei weitere Secrets, die der Upstream-Workflow translate.yml braucht (LINGODOTDEV_API_KEY), sind hier ebenfalls nicht gesetzt. Das ist nicht Teil dieser Aenderung, faellt bei der Secret-Pruefung aber auf.

3. Zeitlimits — und warum nur zwei von vier Jobs

Ohne timeout-minutes gilt die GitHub-Voreinstellung von sechs Stunden. Auf dem geteilten self-hosted Node blockiert ein haengender Lauf damit einen halben Tag den Runner-Platz, und in der Oberflaeche sieht man nur "laeuft" — genau das Bild des Zombie-Jobs vom 26.07.2026 bei stayledger.

Zaehlung fuer den Branch cachly-patches, mit demselben Skript vorher und nachher:

• vorher: 0 von 4 Jobs mit Zeitlimit
• nachher: 2 von 4 — beide cachly-eigenen Jobs haben eins

=== VORHER ===
cachly-deploy.yml          job=checks               timeout-minutes=None
cachly-deploy.yml          job=build-and-deploy     timeout-minutes=None
docker-publish.yml         job=build                timeout-minutes=None
translate.yml              job=translate            timeout-minutes=None
SUMME: 0/4 Jobs mit timeout-minutes

=== NACHHER ===
cachly-deploy.yml          job=checks               timeout-minutes=20
cachly-deploy.yml          job=build-and-deploy     timeout-minutes=45
docker-publish.yml         job=build                timeout-minutes=None
translate.yml              job=translate            timeout-minutes=None
SUMME: 2/4 Jobs mit timeout-minutes (YAML aller Dateien fehlerfrei geparst)

docker-publish.yml und translate.yml sind Dateien des Upstream-Projekts kanbn/kan. Sie bleiben bewusst unangetastet: jede Zeile, die wir dort aendern, wird beim naechsten Angleichen an den Upstream zum Konflikt. Beide laufen ausserdem auf ubuntu-latest und feuern in diesem Fork nicht (sie haengen an main und an Tags), belegen also keinen self-hosted Runner. Das Risiko, das die Zeitlimits abwehren sollen, besteht dort nicht.

Geprueft wurde ausserdem jeder run-Block aller drei Dateien mit bash -n:

bash -n: alle 18 run-Bloecke syntaktisch in Ordnung

Der Diff besteht ausschliesslich aus neuen Zeilen in einer Datei:

$ git diff --numstat
54      0       .github/workflows/cachly-deploy.yml

4. Nebenbefund: zwei registrierte Workflows, die nicht auf cachly-patches liegen

Bei der Pruefung ueber die API (im Fork loest gh run list gegen kanbn/kan auf und liefert 404) faellt auf:

$ gh api "repos/cachly-dev/kan/actions/workflows" --jq '.workflows[] | "\(.name)\t\(.path)\t\(.state)"'
Cachly Deploy   .github/workflows/cachly-deploy.yml     active
Docker          .github/workflows/docker-publish.yml    active
kan CD-Fix Probe (temporaer)    .github/workflows/kan-cd-fix-probe.yml  active
.github/workflows/main.yml      .github/workflows/main.yml              active
Translate       .github/workflows/translate.yml         active

kan-cd-fix-probe.yml traegt selbst "temporaer" im Namen und liegt nicht auf dem Default-Branch:

$ git ls-tree --name-only origin/cachly-patches .github/workflows/
.github/workflows/cachly-deploy.yml
.github/workflows/docker-publish.yml
.github/workflows/translate.yml

$ gh api "repos/cachly-dev/kan/contents/.github/workflows/kan-cd-fix-probe.yml?ref=cachly-patches"
gh: Not Found (HTTP 404)

Die Datei liegt also auf einem anderen Branch und bleibt trotzdem als aktiver Workflow registriert. Sie aufzuraeumen gehoert nicht in diesen PR, sollte aber auf die Liste.