Plattformen
Datenquellen und Manager sind plattformneutral. Die Plattform ist der Ort der Merge Requests, des Dashboard-Issues, der local>-Presets und der Projektliste: eine Schnittstelle (publish.Platform) mit zwei Implementierungen.
- GitLab: produktiv bewiesen über ein Estate von 200 Repositories
- GitHub: bewiesen gegen einen Fake, der die API spricht, und in einem lesenden Lauf; das erste Produktions-Repository steht aus
- Weitere: ein Paket unter
platform/, ein Test-Server, ein Fall inwire
GitLab
Produktiv bewiesen über ein Estate von 200 Repositories.
| Variable | |
|---|---|
PINUP_GITLAB_URL / CI_SERVER_URL | die Instanz |
PINUP_GITLAB_TOKEN / GITLAB_TOKEN | Personal oder Project Access Token mit api und write_repository; CI_JOB_TOKEN wird genutzt, wenn keiner gesetzt ist, und kann nur lesen |
PINUP_REGISTRY_HOST / CI_REGISTRY | die Container-Registry der Instanz, wo der Token gegen einen Pull-Token getauscht wird |
Merge Requests werden per Source-Branch gefunden (nur offene; ein geschlossener ist Geschichte und wird nicht wieder geöffnet), angelegt und angeglichen mit Titel, Beschreibung, Labels und Merge-when-pipeline-succeeds. Ein von den Rechten her verweigerter Automerge steht neben dem Request, nicht als Fehler. Ein Request, dessen Branch der Plan nicht mehr nennt, wird mit dem Zusatz autoclosed im Titel geschlossen. Das Signatur-Urteil eines Commits kommt aus der API, so weiß ein Lauf, ob seine Commits als Verified gezeigt werden. Das Dashboard ist das eigene Issue des Bots mit exakt diesem Titel; ein Issue, das jemand anderes so nennt, ist nicht das Dashboard. local>-Presets kommen über den Raw-File-Endpunkt. Autodiscovery läuft über jedes nicht archivierte Projekt, in dem der Token Mitglied ist.
pinup token rotate erneuert den eigenen Token des Bots vor dem Ablauf und schreibt den neuen in die CI-Variablen, die es nennt, auf Gruppen- oder Projektebene. Ein Job-Token kann sich nicht selbst rotieren.
GitHub
Bewiesen gegen einen Fake, der die API spricht, und in einem lesenden Lauf gegen pinups eigenen Spiegel; das erste Produktions-Repository steht aus.
| Variable | |
|---|---|
PINUP_PLATFORM=github | oder impliziert durch ein GitHub-Token ohne GitLab-Instanz in der Umgebung |
PINUP_GITHUB_URL / GITHUB_SERVER_URL | der Host; github.com, wenn leer; ein Enterprise-Host unter /api/v3 |
PINUP_GITHUB_TOKEN / GITHUB_TOKEN | classic repo, oder fine-grained mit Contents, Pull Requests und Issues read/write; auf github.com bedient es auch die github-*-Datenquellen |
Pull Requests werden per Head als owner:branch gefunden (der gleichnamige Branch eines Forks ist ein anderer Request), angelegt und angeglichen (Titel, Body, Labels). Auto-Merge wird über GraphQL scharf geschaltet und zurückgenommen, die einzige API, die GitHub dafür hat; „noch nicht“ (nichts zu warten) wird von „nicht erlaubt“ (Repository-Einstellung) unterschieden, und Letzteres steht neben dem Request. git authentifiziert über den Askpass als x-access-token. Das Dashboard ist das eigene Issue des Bots mit exakt dem Titel; die Pull Requests, die der Issues-Endpunkt mitliefert, bleiben draußen. Autodiscovery listet die Repositories, in die der Token pushen darf und die nicht archiviert sind.
Was GitHub nicht kennt, wird gesagt, nicht simuliert: ein Request kann nicht verlangen, dass sein Branch beim Merge gelöscht wird (das ist die Repository-Einstellung delete_branch_on_merge), und Auto-Merge braucht ein Repository, das es erlaubt.
Eine hinzufügen
Eine Implementierung ist ein Paket unter platform/ mit den Methoden von publish.Platform, ein iface.go, das sie zusichert, ein Test-Server, der das Protokoll spricht (Pagination eingeschlossen) hinter dem verweigernden Transport, ein Fall in wire.Platform und einer im Umgebungs-Leser. Gitea und Forgejo liegen nah an GitLabs Form.
Weiter
Sicherheit
Wohin der Token geht, was ein Repository den Bot tun lassen kann und was nicht, wie Commits signiert werden.