Pipeline 518 today was red with zero jobs - a push where no rule matched, which
GitLab still turns into a pipeline and then marks failed. The standstill check
reported it correctly, and it was the only finding standing between the scheduled
checks and green.
Acknowledging it would have been the wrong move twice over: the entry would name one
pipeline id, so the next empty pipeline files a fresh finding, and the underlying
behaviour - red without a fault - is exactly what management #0104 is about. Rules
that prevent the empty pipeline remove the class instead.
schedule comes first deliberately. The daily canonization changes no paths, so a
changes-based rule alone would drop it.
Pipeline 521: the variable is visible inside the job, the push to a throwaway ref
succeeded and the ref was removed again. Combined with the token's own properties -
Maintainer, write_repository only - the monthly canonization has what it needs on
2026-09-01.
Two things the probe itself taught, kept here rather than in the removed block: an
API-triggered pipeline has source "api", not "web", so the first attempt silently
skipped the job entirely; and this repo has no "pruefen" stage, which rejected the
pipeline outright. Both would have cost the same time again next year.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Runs only on a web pipeline started with TEST_CANONIZE=1, pushes a throwaway ref
and deletes it again, and never touches main. Removed after the test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Observed rather than reasoned: after the leftover rotation branch was deleted on
both remotes, pipeline 492 still reported it. The runner recycles its workspace
under GIT_STRATEGY=fetch, and git fetch without --prune keeps remote-tracking refs
for branches that no longer exist upstream. The job would have kept naming a branch
nobody can find, indefinitely - and before the previous commit it would have kept
failing on it, with deletion offering no way out.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The daily canonize_rotation job had been red for nine days. Cause: the branch
turn-secret-rotation-20260728-192656 was merged on Gitea back in July but never
deleted, so the job kept trying to merge it into a main that had moved on. Its
merge base is ancient, so the merge conflicts in ten files - not only docs but
coturn-secret.yaml, synapse-turn-secret.yaml and element-server-suite.yaml.
That made the failure worse than noise. The job's own advice is "resolve by hand",
and a careless resolution there rolls the TURN shared secret back to the July
value; Synapse and coturn would then disagree and TURN would be dead. main already
carries a newer rotation (2026-08-01 against 2026-07-28), so there was never
anything to gain from the merge.
The job now reads the SOPS lastmodified stamp - metadata, not a secret - from both
sides and skips a branch whose rotation is not newer than main's, naming it as
cleanup. It stays green while doing so, deliberately: AGENTS.md makes this red
pipeline the only alarm channel for the Gitea exception, and a pipeline that is red
every day for housekeeping is not an alarm any more. A genuine conflict still fails,
now with an explicit warning never to take the older secret.
Verified both directions against the real repository state, not just the happy path:
the leftover branch is detected as superseded, and with the roles swapped a real
rotation is still recognised as needing canonization.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add canonize_wiki to the daily schedule: bare-clone the public Gitea wiki repo
(sorb/ThreadNetWiki) and push its main to git.lab axion1337.chat/threadnet-wiki,
closing the second half of ADR-0015 (Wiki.js->Gitea->canonize->git.lab, the same
reversal as the TURN rotation). The target was created empty, so the first push
creates main and later runs fast-forward — no force, branch protection intact.
Auth via the WIKI_CANONIZE_TOKEN CI variable (project token, write_repository).
Schedule ist angelegt und zweimal probegelaufen; offen bleibt nur das
CANONIZE_TOKEN, jetzt mit Issue-Verweis (gitops#51) statt einer allgemeinen
Anleitung. Auch die beiden Probelaeufe sind vermerkt - Pipeline 159 hat die
fehlende Lab-CA aufgedeckt, 161 lief gruen durch.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Der Probelauf des neuen Jobs ist an genau der Stelle gescheitert, an der man es
nicht vermutet: 'git fetch gitea' lief durch (Gitea ist oeffentlich lesbar),
'git fetch origin main' dagegen brach ab mit 'unable to get local issuer
certificate'. Der Runner stellt die Lab-CA nur seinem eigenen Klon-Schritt
bereit, nicht dem Job-Script - der Klon oben im Log gelingt, der eigene
git-Aufruf zwei Zeilen spaeter nicht.
Zwei Aenderungen:
1. Die CA-Kette liegt jetzt als ci/lab-ca-chain.crt im Repo und wird per
GIT_SSL_CAINFO gesetzt (CI_SERVER_TLS_CA_FILE zuerst, falls ein spaeterer
Runner sie doch liefert). Ein CA-Zertifikat ist oeffentlich, kein Geheimnis -
dieselbe Loesung wie im wiki-bookstack-Repo. Verifiziert: die Kette
(aXionLabs Root + Intermediate) validiert https://git.lab.
2. 'git fetch origin main' faellt ganz weg. Der Runner hat main mit voller
Historie schon ausgecheckt, CI_COMMIT_SHA ist dessen Stand - ein Netzaufruf
weniger und eine Fehlerquelle weniger.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Vorher brach der Job ohne CANONIZE_TOKEN sofort ab - auch dann, wenn gar keine
Rotation offen war. Das haette taeglich eine rote Pipeline erzeugt, bis das
Token existiert, und ausgerechnet die Gitea-Strecke ungetestet gelassen.
Jetzt laeuft der Job erst bis zur Feststellung 'nichts zu tun' durch (verifiziert
dabei Fetch und Erkennung) und verlangt das Token nur, wenn wirklich gepusht
werden muss. Rot wird die Pipeline dann, wenn es zaehlt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Drei Dinge, die zusammengehoeren.
1. Falscher Satz raus. 'there is no direct-to-Gitea exception left' stand seit
eff643e (2026-08-02, von mir) achtzehn Zeilen ueber einem Absatz, der eine
laufende Ausnahme beschreibt - der Wiki-Umzug hatte die letzte Ausnahme auf
REPO-Ebene beseitigt, ich hatte das zu 'gar keine mehr' verallgemeinert.
2. Das Warum der Gitea-Kopie ergaenzt. Bisher stand nur der Mechanismus da
('the cluster pulls from Gitea'), nicht der Grund: git.lab haelt die
Bauplaene, Gitea eine Kopie, die der Cluster OHNE verfuegbares Lab erreicht.
Ohne diese Begruendung sieht der Aufbau nach Altbestand aus - eine spaetere
Session koennte die Flux-Quelle auf git.lab 'geradeziehen' und genau die
Lab-Unabhaengigkeit zerstoeren, fuer die sie da ist. Steht jetzt als
ausdrueckliche Warnung in beiden CLAUDE.md.
3. Den monatlichen Handgriff abgeschafft. Der Rotations-CronJob laeuft im
Cluster, erreicht git.lab nicht und pusht nach Gitea; von dort musste die
Rotation bisher per Hand ueber git.lab zurueck. Wird das vergessen,
ueberschreibt der naechste Mirror-Push sie und Flux spielt still das ALTE
Shared Secret wieder ein - ein Fehler ohne Symptom.
Der Schedule-Job canonize_rotation holt jetzt taeglich jeden
turn-secret-rotation-*-Branch von Gitea, der nicht in main steckt, merged
und pusht ueber git.lab. Taeglich statt monatlich zum Rotationstermin, weil
ein monatlicher Lauf genau einen Versuch haette.
Faellt etwas aus dem Rahmen - Merge-Konflikt oder ein Secret ohne ENC[ -,
bricht der Job ab und pusht NICHTS. Die rote Pipeline ist der Alarm; ein
zusaetzlicher Termin waere wieder ein Todo, das man vergessen kann.
Verifiziert: YAML parst, alle elf Script-Bloecke sind gueltige sh-Syntax, und
die Kernlogik gegen den echten Repo-Stand durchgespielt - beide vorhandenen
Rotations-Branches werden korrekt als 'schon in main' uebersprungen.
Noch offen (braucht Rechte, siehe Dateikopf): Project Access Token als
CANONIZE_TOKEN hinterlegen und den taeglichen Schedule anlegen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
'siehe Backlogs CFGMON-11' - das Repo heisst seit dem PM-Framework-Umbau
management (ADR-0005). Zu CFGMON-11 gibt es kein Issue, die Arbeit war beim
Umzug abgeschlossen; deshalb datiert statt verlinkt. Reiner Kommentar, die
Job-Definition ist unberuehrt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Der deploy-on-push-Check (YAML-Manifest-Pruefung, SOPS-ENC-Kontrolle) laeuft
jetzt als leichter Job in der Lab-GitLab-CI; milestone-release.yml war seit
jeher toter Code (kein Runner, Releases wurden manuell per API erstellt,
siehe Issue #33). Flux bleibt unberuehrt - es zieht weiterhin vom
Gitea-Mirror. Damit verliert der Gitea-Runner builder-1 seinen letzten
aktiven Konsumenten.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Thore Cimbal
