Repo Stats

Repo Stats sammelt, was GitHub über die eigenen Repositories weiß, in einer SQLite-Datei und zeichnet es. Das Programm läuft selbst gehostet in einem Container im eigenen Netz, ist in Python geschrieben (FastAPI) und steht unter der AGPL-3.0.

Wozu es gut ist

GitHub zeigt den Verkehr pro Repository, für vierzehn Tage, ein Repository nach dem anderen. Aufrufe, eindeutige Besucher, Clones und Herkunft werden nach vierzehn Tagen gelöscht. Es gibt keine Übersicht über mehrere Repositories, und die Zahl der Release-Downloads wird pro Datei geführt, aber in der Oberfläche nicht angezeigt. Ein täglicher Sammellauf löst alle drei Punkte. Jeder Lauf liefert das komplette Vierzehn-Tage-Fenster, ein Ausfall von weniger als zwei Wochen heilt sich daher von selbst.

Was drinsteht

• Über das Konto: Sterne, Forks, Beobachter, offene Issues, Release-Downloads, Besucher und Clones über alle verfolgten Repositories, dazu die Herkunft der Besucher und der zeitliche Verlauf. Jede Kachel öffnet eine Aufschlüsselung nach Repository.
• Pro Repository: Mitwirkende, Commits, offene und gemergte Pull Requests, Erfolgsquote und Dauer der CI-Läufe, die meistbesuchten Seiten, Downloads je Release-Datei und die offenen Issues mit Links.
• Eine Sternkurve bis zum ersten Stern, rekonstruiert aus den Zeitstempeln der einzelnen Stargazer.
• Für Home-Assistant-Integrationen die Installationszahl von analytics.home-assistant.io, aufgeteilt nach Version. Gezählt werden nur Versionen, die aus dem eigenen Repository stammen, denn eine Integrations-Domain gehört allen, die sie ausliefern.

Jede Zahl trägt eine Erklärung, was sie tatsächlich zählt. Clone-Zahlen etwa bestehen meist aus Maschinen: Jeder actions/checkout ist für GitHub ein Clone, bei einem Matrix-Build einer pro Job. Deshalb steht in den Kacheln die Zahl der unterschiedlichen Besucher und Klonenden vorn und die Rohzahl klein darunter.

Betrieb

git clone https://github.com/sphings79/repostats.git
cd repostats
cp .env.example .env     # Token und Konto eintragen
docker compose up -d

Danach läuft das Dashboard auf http://<host>:8377. Beim ersten Aufruf legt man Benutzername und Passwort fest, unter „Verwaltung“ wählt man die Repositories und startet „Jetzt alles sammeln“. Das Image wird für amd64 und arm64 unter ghcr.io/sphings79/repostats:latest veröffentlicht. Die Daten liegen in einer SQLite-Datei in einem Volume, ein Backup ist eine Dateikopie. Stündlich werden die günstigen Zähler aktualisiert (Sterne, Forks, Beobachter, Release-Downloads), täglich alles andere; die Uhrzeit des Komplettlaufs (FULL_RUN_HOUR, voreingestellt 4 Uhr UTC) lässt sich einstellen.

Zugriffstoken

GITHUB_TOKEN und GITHUB_LOGIN sind erforderlich. Beim fein granularen Token wird Lesezugriff auf „Administration“ gebraucht, das schaltet die Verkehrszahlen frei, dazu Contents, Issues, Metadata, Pull requests und Actions für die CI-Zahlen. Klassisch genügt der Scope repo. Die Sternhistorie braucht ein zweites, klassisches Token mit public_repo (GITHUB_TOKEN_STARS), weil GitHub fein granulierte Tokens am Stargazer-Endpunkt abweist; so braucht das Haupttoken nirgends Schreibrechte.

Sicherheit und Grenzen

Die Diagramme sind serverseitig erzeugtes SVG, ohne Chart-Bibliothek, Build-Schritt oder CDN. Nach außen gehen nur Anfragen an die GitHub-API und an die Home-Assistant-Statistik; Telemetrie und Update-Prüfung gibt es nicht. Die Anmeldung richtet man direkt nach dem Start im Browser ein, denn bis dahin legt das Konto an, wer den Port zuerst erreicht – und im Container liegt ein Token, das auch private Repositories lesen kann. Für den Betrieb hinter einem Reverse Proxy liegt ein Traefik-Beispiel mit Beschränkung auf das eigene Netz bei. Fremde Repositories lassen sich nur über ihre öffentlichen Zahlen beobachten; den Verkehr sieht nur der Eigentümer.