Thore CimbalandClaude Opus 5
a1def8666e
ADR-0012 made docs/issues/ canonical for the management scope only and left gitops, ThreadNet-Web and threadnet-call on GitLab "until the component adopts". That split produced exactly what it invited: two numbering worlds where management#20 and gitops#20 are different issues, drift nobody had to answer for (gitops#61 carried no milestone since 2026-08-11), and component backlogs that host sessions without lab access cannot read at all. The 46 open component issues are now files 0056-0101. The file id is the group-wide identifier; provenance lives in the frontmatter (new field `projekt` plus gitlab_iid) and in the filename, so "gitops#61" still finds 0091. Bodies are copied verbatim; comments and history stay on GitLab, as with the 2026-08-11 management import. Both scripts learned the second dimension: spiegel_issues.py routes each file to its origin project, reopens issues that are open in the repo but closed on the board, and writes the new iid back after creating one; gruppenpruefung.py checks drift across all four trackers instead of management alone. What the mirror cannot decide stays a finding, not a silent state. Two things needed a hand, both recorded in the files: gitops#61 had no milestone (M1 - it is a live account-takeover path) and carried two area labels where the schema holds one. The Gitea migration footers in the imported bodies point at decommissioned trackers; their links are removed, the provenance sentence stays. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.1 KiB
type, id, status, created, milestone, priority, due, projekt, gitlab_iid, related
| type | id | status | created | milestone | priority | due | projekt | gitlab_iid | related |
|---|---|---|---|---|---|---|---|---|---|
| issue | 0084 | next | 2026-08-02 | M1 | medium | 2026-09-01 | gitops | 51 |
CI: CANONIZE_TOKEN für die automatische TURN-Rotation hinterlegen
Adoptiert aus gitops#51 (2026-08-18, ADR-0019). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei.
Der Job canonize_rotation in .gitlab-ci.yml übernimmt die monatliche TURN-Rotation automatisch (kein Handgriff mehr, kein Kalendereintrag). Der Schedule läuft, zwei Probeläufe sind durch — es fehlt nur noch das Push-Token.
Was zu tun ist (2 Minuten, braucht deine Rechte)
- Settings → Access Tokens in diesem Projekt: Token anlegen
- Name z. B.
canonize-rotation - Rolle Maintainer (nötig, weil
mainprotected ist) - Scope
write_repository— mehr nicht - Ablauf: setzen und im Kalender vormerken, sonst steht der Job irgendwann still
- Name z. B.
- Settings → CI/CD → Variables: Variable
CANONIZE_TOKENmit dem Wert, masked und protected
Danach nichts weiter — der nächste Lauf nimmt sie von selbst.
Warum das nötig ist
Der Rotations-CronJob läuft im Cluster und erreicht git.lab nicht; er pusht seinen Branch nach Gitea. Von dort muss die Rotation über git.lab zurück, sonst überschreibt sie der nächste Mirror-Push und Flux spielt still das alte Shared Secret wieder ein — ein Fehler, der kein Symptom erzeugt.
Stand
| Job + Doku | ✅ 02c60cb, CLAUDE.md in beiden Repos |
| Schedule (täglich 17:05) | ✅ angelegt |
| Probelauf | ✅ Pipeline 161 grün: „Keine offene Rotation" |
CANONIZE_TOKEN |
⬜ dieses Issue |
Bis dahin ist nichts kaputt: Ohne offene Rotation läuft der Job grün durch. Erst wenn am 01.09. wirklich rotiert wird und das Token fehlt, bricht er ab — laut und sichtbar, statt still das Falsche zu tun.
Nebenbei aufgefallen: Der Branch turn-secret-rotation-20260728-192656 liegt auf git.lab und Gitea, steckt aber längst in main — eine Karteileiche vom Juli. Kann weg, ist aber harmlos.