GitHub
Aktivität, CI-Status, Commits, Pull Requests und Issues für ein Repository.
Was es tut
Beobachtet ein einzelnes Repository und zeigt, was darin passiert.
Die Kopfzeile trägt den Repo-Namen, seinen jüngsten Release-Tag und den Status des letzten Workflow-Laufs: bestanden, fehlgeschlagen, laufend oder ausstehend. Darunter zeigt eine Statistikzeile Sterne, Forks und offene Issues, und eine Metazeile die Hauptsprache, wann zuletzt gepusht wurde, und den Standard-Branch.
Dann die Listen, jede mit einstellbarer Länge:
- Commits: kurzer SHA, erste Zeile der Nachricht, relative Zeitangabe.
- Pull Requests: Nummer nach Zustand eingefärbt (violett gemergt, grün offen, rot geschlossen), Titel, Alter. Nach Zustand und Sortierung filterbar.
- Issues: Nummer, Titel, Alter. Pull Requests werden herausgefiltert, die Issue-Liste enthält also tatsächlich Issues.
- Pipelines: ein Statuspunkt, Workflow-Name, Branch und Zeit.
Das Release-Badge ist anklickbar und öffnet die Release-Seite.
Woher die Daten kommen
Die GitHub-API, direkt von deinem Rechner abgefragt. Öffentliche Repositories funktionieren ohne Anmeldung; verbinde ein GitHub-Konto für private Repos und höhere Rate-Limits.
Ein 404 auf ein Repository, von dem du weißt, dass es existiert, bedeutet meist einen fehlenden Token-Scope, und das Widget sagt das, statt einen nackten Fehler zu zeigen.
Grenzen
- Ein Repository pro Widget. Für Arbeit, die sich über mehrere Repos verteilt, nimm Benachrichtigungen, Review-Anfragen oder Zugewiesene Issues.
- Nur lesend: Es mergt nicht, kommentiert nicht und startet keine Workflows neu.
- Die Aktualisierung läuft über ein Intervall in Minuten, das du festlegst, nicht über einen Live-Webhook.