Tja... man baut so vor sich hin.
Ein Tool hier, ein Dienst da, dazwischen ein Experiment, das nach drei Wochen still gestorben ist. Und irgendwann sitzt du vor deinem eigenen GitLab und scrollst. Und scrollst.
121 Projekte. Ich habe das nicht geschätzt, ich habe es zählen lassen.
Das Problem ist nicht die Zahl. Das Problem ist, dass ich bei der Hälfte davon nach sechs Monaten selbst nicht mehr sagen kann, ob das Ding produktiv läuft, ob es längst von was anderem abgelöst wurde oder ob es einfach nur rumliegt. Und ein Repo-Name wie wbbgi hilft da... sagen wir mal: begrenzt.
Also gibt es jetzt das Tooliversum. Eine Seite, alle Projekte, gruppiert nach Zusammenhang.
Was drin steht 🗂️
Keine Repo-Liste. Davon habe ich schon eine, die heißt GitLab.
Was mir gefehlt hat, sind die Verbindungen. Dass jeder KI-Dienst über den llmproxy geht statt direkt an Ollama. Dass LabControl per Ansible alles andere ausrollt. Dass NeuroTrack die alte PEF-Webapp abgelöst hat und die trotzdem noch als Datenquelle rumsteht.
Jede Karte sagt deshalb drei Dinge:
- Was es tut — und zwar warum es existiert, nicht welche Art von Software es ist
- Was der Status ist — produktiv, in Arbeit, Werkzeug oder abgelöst
- Womit es spricht — wer hängt am Reverse Proxy, wer wird von wem deployt
Und ja, retired bleibt drin. Ein Projektfriedhof gehört zur Wahrheit dazu. Die alte PHP-Fassung der Familiengalerie war vier Jahre lang mein Backup-Plan, die lösche ich nicht aus der Historie, nur weil sie unhübsch ist.
Eine YAML, drei Seiten 📄
Der Aufbau ist unspektakulär, und das ist Absicht:
data/projects.yaml die Datenbasis -- das Einzige, was von Hand editiert wird
data/exclude.yaml die Sperrliste
scan.py Repos einsammeln, gegen die Datenbasis abgleichen
briefing.py unbekannte Repos aufbereiten
build.py alle Fassungen erzeugen
build.py baut daraus drei Ausgaben: die interne Fassung mit allen Hostnamen, und je eine für meine beiden Blogs. In den öffentlichen fliegen die internen Adressen raus — die sind ohnehin nur im Heimnetz erreichbar, aber ich muss sie ja nicht ins Netz schreiben.
Die Blog-Fassungen ziehen ihre Farben aus den CSS-Variablen des jeweiligen Blogs. Heißt: der Dark-Mode-Umschalter nimmt die Karten einfach mit, ohne dass ich zwei Themes pflege. Kleiner Trick, große Wirkung.
Der Scan macht die Drecksarbeit 🔍
scan.py liest zwei Quellen: die Verzeichnisse auf meiner Platte und die Projektliste der GitLab-Instanz über die API. Beides zusammengeführt, gegen die Datenbasis gehalten, fertig ist die Arbeitsliste:
- NEU — gefunden, steht aber noch nicht auf der Seite
- WEG — steht auf der Seite, ist aber nirgends mehr auffindbar
- AUSGESCHLOSSEN — was die Sperrliste geschluckt hat
Der erste Lauf war ernüchternd: 40 Projekte NEU. Also nicht „da fehlen ein paar", sondern ein Drittel des Bestands.
Nettes Detail am Rande: Sammeleinträge auf der Seite decken oft mehrere Repos ab. Ohne Gegenmaßnahme meldet der Scan die dann fröhlich alle als neu. Dafür gibt's ein covers-Feld — sonst wäre der Report Rauschen und ich würde ihn nach dem zweiten Mal ignorieren.
Vierzig Repos, die sich nicht erklären 📦
Und jetzt? Vierzig Repos aufmachen, verstehen, beschreiben.
Das Problem: die meisten davon haben als README das GitLab-Standardtemplate. „To make it easy for you to get started with GitLab." Danke. Sehr aufschlussreich.
Also noch ein Skript. briefing.py holt sich zu jedem Repo einen flachen Klon nach /tmp, liest Dateibaum, Dateitypen, die letzten Commits, README und Manifeste aus, schreibt daraus ein kompaktes Briefing — und räumt den Klon wieder weg. Auch dann, wenn unterwegs was schiefgeht.
Zwei Dinge stellten sich als nötig heraus:
- Die Sperrliste greift vor dem Klonen. Was nicht auf die Seite darf, wird gar nicht erst angefasst.
- Ab einer bestimmten Größe wird nicht geklont, sondern die API gefragt. Drei Godot-Projekte bringen zusammen 12 GB auf die Waage, weil generierte 3D-Assets im Repo liegen. Dateibaum, Commits und README gibt's auch über die GitLab-API, ohne dass mir die Platte volläuft.
30 von 40 READMEs waren tatsächlich blankes Template. Der Filter dagegen hat die Briefings von 216 auf 70 KB eingedampft.
Ach ja, und der Fricklerpunkt des Tages: Ich hatte das Skript zuerst inspect.py genannt. Das überschattet das Python-Standardmodul gleichen Namens für alles, was in dem Verzeichnis läuft. Ist mir prompt um die Ohren geflogen. Heißt jetzt briefing.py. Fricklerpunkt verdient.
Ergebnis: 97 Karten statt 69. Sechs Repos bestanden aus einem README und sonst nichts — die stehen jetzt auf der Sperrliste, bis mal Inhalt dazukommt.
Was das Skript nicht kann ✍️
Ich hätte das komplett automatisieren können. README einlesen, ein LLM drüberlaufen lassen, fertig.
Habe ich bewusst nicht.
Was dabei rauskommt, kennt ihr: "Ein Python-Projekt zur Verwaltung von Backups." Danke. Sehr hilfreich. Das steht auch im Repo-Namen.
Was ich stattdessen dort stehen haben will, ist sowas:
Failsafe-Backup der GitLab-Instanz per reinem, sequenziellem Tar-Streaming über SSH. Entstand, weil sowohl
gitlab-backup createals auch rsync bei ~60 GB Repos so viel RAM zogen, dass sie den ganzen Proxmox-Host in eine OOM-Panic rissen.
Das ist der Unterschied zwischen einer Liste und einer Doku. Das erste ist Metadaten, das zweite ist die Geschichte dahinter — und die weiß kein Scanner.
Also: das Skript sammelt, meldet und baut. Die Prosa schreibe ich. Mit KI-Unterstützung, klar, aber auf Basis dessen, was ich tatsächlich über die Projekte weiß. Das Prompt dafür liegt im Repo, damit der nächste Durchlauf nicht wieder bei null anfängt.
Was rausfliegt 🚫
Nicht alles gehört auf eine öffentliche Seite. Arbeitsbezogene Repos zum Beispiel. Oder der Ordner, in dem ich vor zwei Jahren einen Pacman-Nachbau angefangen und nie beendet habe.
Dafür gibt es die Sperrliste — und die greift an zwei Stellen: Der Scan meldet gesperrte Projekte nie als „neu", und build.py bricht ab, falls doch mal eins in der Datenbasis landet.
Zwei Sicherungen statt einer, weil genau das die Sorte Fehler ist, die man erst nach dem Deploy bemerkt. Und dann ist es zu spät. HUST
Fazit
Es ist keine Raketenwissenschaft. Eine YAML, drei Skripte, ein bisschen CSS. Aber es ist der Unterschied zwischen „irgendwo hab ich da mal was gebaut" und einer Seite, auf der ich in zehn Sekunden nachsehe.
Von der ersten Zeile bis zu 97 Karten war es ein Nachmittag. Der aufwändige Teil war nicht das Skript — es war die Frage, was man über ein Repo schreibt, das sich selbst nicht erklärt. ;-)
Schaut rein: Tooliversum →
Transparency Note: Einige Inhalte, Code-Snippets oder Grafiken in diesem Post wurden mittels KI (LLMs / Vibecoding) erstellt oder unterstützt, jedoch von mir persönlich kuratiert, überarbeitet und geprüft. Wie immer... sonst wär's ja nicht ehrlich. ;-)