Forgejo / Gitea Smart-Home-Integration, kostenlos und Open Source

Deine Forgejo-, Gitea- oder Codeberg-Repositorys in Gladys: Releases, Issues, CI-Status.
Forgejo und Gitea sind freie, selbst gehostete Software-Forges mit derselben API; Codeberg betreibt Forgejo. Diese Integration verfolgt die Repositorys, die du angibst: Jedes wird ein Gerät mit seinen Sternen, offenen Issues und Pull-Requests, dem neuesten Release und dem CI-Status seines Hauptzweigs. Szenen können auf ein neues Release, ein neues Issue, einen neuen Pull-Request oder eine CI reagieren, die fehlschlägt oder wieder grün wird, und ein Dashboard-Widget zeigt alle Repositorys auf einen Blick.
Getestet mit echten Forgejo-11.0- und Gitea-1.27-Instanzen (Docker, SQLite) und der öffentlichen API von Codeberg; noch nicht mit einer echten Gladys-Instanz: Rückmeldungen sind willkommen unter den Issues.
Was du brauchst
- Gladys Assistant 5.1.0 oder neuer.
- Ein Forgejo oder Gitea, das vom Gladys-Rechner aus erreichbar ist, oder eine öffentliche Forge wie codeberg.org.
- Nur für private Repositorys: ein Zugriffstoken eines Benutzers, der sie lesen darf.
Die Integration liest nur und schreibt nie etwas in die Forge. Bei jeder Aktualisierung (standardmäßig alle 10 Minuten) stellt sie fünf Anfragen pro Repository: das Repository, seine fünf neuesten Releases, Issues und Pull-Requests und den CI-Status seines Standardzweigs. Auf Codeberg lass das Intervall bitte bei 10 Minuten oder mehr und die Liste kurz: Es ist ein kostenloser Dienst eines Vereins, und zu viele Anfragen bekommen die Antwort „HTTP 429“.
Erste Schritte
1. Ein Zugriffstoken erstellen (private Repositorys)
Öffentliche Repositorys brauchen kein Token. Für private öffne in der Forge Einstellungen → Anwendungen → Neuen Token erzeugen, gib ihm einen Namen und die Nur-Lese-Rechte read:repository und read:issue und kopiere es. Das Token sieht, was sein Benutzer sieht: Ein eigener Benutzer schränkt es weiter ein.
2. Die Integration konfigurieren
Öffne in Gladys Integrationen → Forgejo / Gitea → Konfiguration und fülle aus:
- Adresse der Forge: die Adresse, mit der du die Forge öffnest,
http://192.168.1.2:3000,https://git.example.comodercodeberg.org(HTTPS für einen Namen ohne Port). - Zugriffstoken (optional): das Token aus Schritt 1.
- Zu verfolgende Repositorys:
Besitzer/Nameoder aus dem Browser kopierte Links, durch Kommas getrennt, höchstens 20. Beispiel:forgejo/forgejo, ich/meine-app. - Aktualisierungsintervall und Sprache der Namen.
Klicke auf Verbindung testen: die Forge und ihre Version, dann jedes Repository mit seinen Sternen und seinem CI-Status, oder der Grund, warum es nicht lesbar ist.
3. Die Geräte hinzufügen
Füge in Entdecken die gewünschten Repositorys als Geräte hinzu. Die Zahlen kommen sofort. Die Szenenauslöser und das Widget funktionieren auch für ein Repository, das nicht als Gerät hinzugefügt ist.
Die Geräte
Ein Gerät pro Repository, benannt Besitzer/Name, erkannt an der Nummer, die
die Forge dem Repository gibt: Umbenennen oder Übertragen behält das Gerät
(trage den neuen Namen in der Konfiguration ein).
| Funktion | Typ | Wert |
|---|---|---|
| Sterne | Zähler | Sterne des Repositorys |
| Forks | Zähler | Forks |
| Offene Issues | Zähler | offene Issues (ohne Pull-Requests) |
| Offene Pull-Requests | Zähler | offene Pull-Requests |
| Neuestes Release | Text | Tag des neuesten Release, sonst des neuesten Pre-Release |
| Datum des neuesten Release | Text | sein Veröffentlichungsdatum |
| CI-Status | Text | Erfolgreich, Fehlgeschlagen, Läuft oder Keine CI |
| CI erfolgreich | Binär | 1, wenn die CI durchläuft, 0, wenn sie fehlschlägt |
Der CI-Status ist der kombinierte Status des neuesten Commits des Standardzweigs: alle Prüfungen darauf, Forgejo Actions und Gitea Actions inklusive, ebenso Woodpecker, Drone oder Jenkins, wenn sie an die Forge melden. Eine „Warnung“ zählt als erfolgreich. Während die CI läuft, behält CI erfolgreich seinen letzten Wert.
Dashboard
Das Widget Repositorys zeigt eine Zeile pro Repository: den CI-Status, das neueste Release und die Zahl der offenen Issues, fehlschlagende Repositorys zuerst, dann laufende. Wähle Repositorys in seinen Einstellungen, oder lass es leer für alle. Aktualisieren liest die Forge sofort neu.
Szenen
Auslöser
- Neues Release veröffentlicht: Ein Release oder Pre-Release ist erschienen (Filter auf Repository und Typ). Variablen: das Repository, der Name des Release, sein Tag, sein Autor, sein Link und eine Zusammenfassung für eine Nachricht.
- Neues Issue: Jemand hat ein Issue eröffnet. Variablen: das Repository, die Nummer, der Titel, der Autor, der Link und eine Zusammenfassung.
- Neuer Pull-Request: Jemand hat einen Pull-Request eröffnet. Dieselben Variablen.
- CI fehlgeschlagen oder wieder grün: Die CI des Standardzweigs schlägt fehl oder läuft nach einem Fehler wieder durch (Filter auf den Zustand). Variablen: das Repository, der Zweig, der Commit, der Link und eine Zusammenfassung.
Das erste Lesen eines Repositorys lernt nur seinen Zustand: Die Vergangenheit wird nie gemeldet. Entwürfe werden nie gemeldet. Höchstens drei Ereignisse einer Art werden pro Repository und Lesen gesendet (eine Welle importierter Issues überflutet die Szenen nicht). Was gesehen wurde, behält die Integration: Ein Neustart verpasst kein Ereignis und meldet keines doppelt.
Aktionen
- Repository lesen: die Zahlen eines verfolgten Repositorys als Variablen für die nächsten Aktionen: Sterne, Forks, offene Issues und Pull-Requests, neuestes Release, CI-Status, CI erfolgreich.
Szenenideen
- Neues Release veröffentlicht eines Projekts, das du selbst hostest → sende eine Nachricht mit der Zusammenfassung: Zeit für ein Update.
- CI fehlgeschlagen oder wieder grün, Zustand „fehlgeschlagen“ → schalte die Bürolampe auf Rot; Zustand „wieder grün“ → zurück auf Weiß.
- Jeden Montagmorgen → Repository lesen, dann schick dir eine Nachricht mit den offenen Issues und Pull-Requests.
Fehlerbehebung
- Die Forge antwortet nicht: Prüfe die Adresse vom Gladys-Rechner aus
(gleicher Port, gleiches Protokoll); ein Gladys in Docker erreicht den Host
über seine IP-Adresse, nicht über
localhost. - Die Adresse leitet um: Gib die
https://-Adresse ein, auf der der Browser landet. - Zugriffstoken abgelehnt: Das Token wurde gelöscht oder falsch kopiert; erstelle ein neues.
- Repository nicht gefunden, oder privat ohne Token, das es lesen darf:
Prüfe
Besitzer/Nameund die Rechte des Tokens (read:repository). - Repository umbenannt oder übertragen: Gib den neuen Namen ein; das Gerät bleibt.
- Zu viele Anfragen: Wähle ein längeres Intervall oder verfolge weniger Repositorys.
- Die Auslöser für Issues und Pull-Requests feuern bei einem privaten Repository nie, obwohl seine Zahlen stimmen: Dem Token fehlt read:issue.
- Zertifikat abgelehnt: Ein selbst signiertes Zertifikat wird nicht
akzeptiert; nutze die
http://-Adresse im lokalen Netz.
Grenzen
- Nur Lesen: kein Befehl, nichts wird in die Forge geschrieben.
- Höchstens 20 Repositorys, frühestens alle 5 Minuten gelesen: Ein Ereignis kommt bis zu einem Intervall später.
- Nur die CI des Standardzweigs; ein CI-Ergebnis pro Commit (der kombinierte Status), nicht eines pro Workflow.
- Issues und Pull-Requests werden an ihrer Nummer erkannt: Ein gelöschtes und neu erstelltes Issue wird nicht zweimal gesehen.
- Die Texte der Geräte und Szenen folgen der Sprache der Konfiguration; die Funktionsnamen werden beim Hinzufügen eines Geräts festgelegt.
- Entwickelt und getestet mit Forgejo 11.0 und Gitea 1.27; ältere Versionen mit derselben API v1 sollten funktionieren, ohne Garantie.
Konfigurationseinstellungen
Diese Einstellungen fragt Forgejo / Gitea in seinem Konfigurationsbildschirm in Gladys ab.
| Einstellung | Typ | Pflichtfeld | Beschreibung |
|---|---|---|---|
| Deine Forge | section | Nein | Gib die Adresse deines Forgejo oder Gitea ein, oder codeberg.org. Ein Token brauchst du nur für private Repositorys: Erstelle es unter Einstellungen → Anwendungen mit den Rechten read:repository und read:issue. Liste dann die zu verfolgenden Repositorys auf. |
| Adresse der Forge | string | Nein | Die Adresse, mit der du die Forge öffnest: http://192.168.1.2:3000, https://git.example.com oder codeberg.org. |
| Zugriffstoken (optional) | secret | Nein | Nur-Lesen reicht (read:repository, read:issue). Leer: nur öffentliche Repositorys. |
| Zu verfolgende Repositorys | string | Nein | Besitzer/Name oder aus dem Browser kopierte Links, durch Kommas getrennt. Höchstens 20. |
| Optionen | section | Nein | |
| Aktualisierungsintervall | select | Nein | Wie oft die Repositorys gelesen werden: jedes Mal fünf Anfragen pro Repository. |
| Sprache der Namen | select | Nein | Sprache der Funktionsnamen (beim Hinzufügen eines Geräts festgelegt), der CI-Status und der Szenentexte. |
So installierst du Forgejo / Gitea in Gladys
- Öffne in Gladys Integrationen: Forgejo / Gitea erscheint im Katalog neben den nativen Integrationen, mit einem Community-Badge.
- Klicke auf Installieren. Gladys lädt das Docker-Image (
ghcr.io/guim31/gladys-forgejo:1.0.1) herunter, startet es in einer vom Kern isolierten Sandbox und erzeugt die Oberfläche der Integration (Geräte, Erkennung und Konfiguration). - Öffne den Bildschirm Konfiguration der Integration, fülle die Einstellungen aus und speichere.
- Du kannst sie auch direkt über die URL ihres Repositorys installieren: https://github.com/guim31/gladys-forgejo.
Forgejo / Gitea benötigt Gladys >=5.1.0. Der Katalog in Gladys wird stündlich aktualisiert, eine neue Version ist also spätestens eine Stunde nach ihrer Veröffentlichung verfügbar.
Du nutzt Gladys noch nicht? Es ist kostenlos und Open Source: folge der Installationsanleitung, um loszulegen.
Über externe Integrationen
Forgejo / Gitea ist eine externe Integration: eine Community-Integration, die als Docker-Container verpackt und auf GitHub veröffentlicht wird. Gladys installiert sie mit einem Klick und führt sie in einer vom Kern isolierten Sandbox aus. Sie wird von guim31 veröffentlicht und gepflegt, nicht vom Gladys-Kernteam.
- Alle Integrationen durchsuchen, native und aus der Community
- Deine eigene externe Integration bauen und veröffentlichen
- Quellcode auf GitHub — Quelle dieser Dokumentation