GitHub

GitHub ist die Integration, mit der die meisten Workspaces beginnen. Die SprintLoop-GitHub-App ist das, was es einer Lane erlaubt, einen Branch zu pushen, ein PR zu öffnen, Status-Updates zu posten und CI-Signale zurück in das Audit-Ledger der Lane zu ingestieren. Ohne die App sind Lanes auf GitHub Read-only; mit ihr sind sie vollwertige Mitarbeiter.

Diese Seite behandelt Installation, Scopes, Repo-Verbindung, Branch Protection, Webhook-Flow und die häufigsten Stolperer.

Die App installieren

Aus SprintLoop heraus: Settings → Integrations → GitHub → Install the GitHub App. Du wirst zu GitHubs App-Install-Flow weitergeleitet.

GitHub bittet dich auszuwählen:

Account oder Org. Nimm denjenigen, dem die Repos gehören, gegen die SprintLoop Lanes dispatchen soll. Du kannst die App auf mehreren Orgs installieren und später zwischen ihnen wechseln.
Repos. Wähle All repositories, wenn du jedes Repo der Org verbinden willst, oder Only select repositories, um eine Teilmenge zu wählen. Der „select”-Pfad ist empfohlen — er begrenzt den Blast-Radius, falls eine Lane sich daneben benimmt.

Nach der Installation bist du zurück in SprintLoop mit einer grünen Status-Zeile für jedes verbundene Repo. Die App holt den Default-Branch, die Branch-Protection-Rules und die CI-Konfiguration im Hintergrund; das dauert üblicherweise 5–15 Sekunden.

Benötigte Scopes

Die App fordert zur Installationszeit folgende Permissions an:

Scope	Wofür
`contents: write`	Lane-Branches pushen, Commits schreiben
`pull_requests: write`	PRs öffnen, Status-Kommentare posten
`checks: read`	CI-Status ins Lane-Audit-Ledger ingestieren
`members: read`	PR-Reviewer-Vorschläge aus deinem Team zeigen
`metadata: read`	Repo-Settings lesen (Default-Branch, Branch Protection)

Sie fordert nicht an:

secrets — SprintLoop liest oder schreibt nie deine Repo-Secrets.
packages — kein Zugriff auf GitHub Packages.
admin:org — kein Zugriff auf Org-Admin-Endpoints.
delete:repo — keine destruktiven Permissions.

Wenn dein Security-Team auditieren muss: Das Manifest ist unter https://github.com/apps/sprintloop veröffentlicht, und die Scopes sind von der öffentlichen App-Seite sichtbar.

Repo-Verbindung

Ein Repo ist „verbunden”, sobald die App darauf installiert ist UND der Workspace es unter Settings → Integrations → GitHub → Repos gelistet hat. Die Erst-Installation befüllt die Liste automatisch; du kannst ein Repo später abkoppeln, ohne die App zu deinstallieren.

Jedes verbundene Repo bekommt:

Einen Default-Branch (auto-detektiert von GitHub).
Eine Scope-Policy (Default: Lanes dürfen jeden Pfad unter dem Repo claimen).
Ein CI-Ingest-Setting (Default: checks: all).
Einen optionalen PR-Template-Override.

Verbindung ist pro Workspace. Dasselbe Repo kann an zwei SprintLoop-Workspaces verbunden sein — nützlich, wenn ein OSS-Projekt getrennte Dev- und Security-Workspaces hat. Lanes aus verschiedenen Workspaces gegen dasselbe Repo teilen keine Scope-Claims; Konflikte werden zur PR-Merge-Zeit auf der GitHub-Seite gelöst.

Was passiert, wenn eine Lane ein PR öffnet

Der volle Flow:

Owner approved die Lane.
SprintLoop pushed die signierten Commits der Lane in einen Branch namens sprintloop/<workspace-handle>/<lane-id> im verbundenen Repo.
SprintLoop öffnet ein PR via GitHub-API. PR-Title ist der Title der Lane; PR-Body enthält den Brief, die verwendete Harness, Modell-Versionen, die Verdicts des Review Committee und einen Link auf die Audit-Seite der Lane.
GitHub feuert Status-Checks und alle Branch-Protection-required Reviewer.
SprintLoop ingestiert Check-Ergebnisse zurück in die Lane-Chain (signierte Einträge — jeder CI-Status ist auditierbar).
Wenn das PR auf GitHub gemerged wird (durch dich oder einen anderen Teammate), empfängt SprintLoop den pull_request.closed-Webhook, markiert die Lane als merged und stempelt den Federation-Root.

Die PR-Description ist standardmäßig ausführlich. Wenn dein Team knappere PRs bevorzugt, setze ein Template unter Settings → Integrations → GitHub → PR template. Das Template supportet dieselben Liquid-artigen Variablen wie der Lane-Brief ({{lane.title}}, {{lane.harness}} etc.).

Branch Protection

Wenn dein Repo Branch Protection hat, die N Approvals verlangt, CI grün verlangt oder Force-Pushes einschränkt, respektiert SprintLoop alles davon. Das Sign-off der Lane ist intern — es ist eine Attestation, dass der Workspace-Owner die Lane reviewed hat — kein GitHub-Review. Deine Branch-Protection-Rules gelten weiterhin auf GitHub.

Ein häufiges Pattern: Branch Protection verlangt einen externen GitHub-Review zusätzlich zum SprintLoop-Sign-off. Das Team bekommt die Sicherheit eines fremden Augenpaars; der Audit-Trail der Lane fängt alles ein, was die SprintLoop-Reviewer-Agents und der Workspace-Owner gesehen haben.

Wenn Branch Protection einen Status-Check verlangt, den die Lane nicht erfüllen kann (z. B. ein Custom-Check, der nur bei Änderungen an geschützten Pfaden läuft), siehst du ein gelbes Banner auf der Lane-Seite, das den fehlenden Check benennt. Der Merge wird fehlschlagen, bis der Check erfüllt oder die Rule angepasst ist.

Webhooks, die die App abonniert

Die App abonniert:

pull_request — um PR-Merge / -Close zu tracken.
push — um die Repo-Map für die Context Engine zu refreshen.
check_run und check_suite — um CI-Status zu ingestieren.
installation und installation_repositories — um die verbundenen-Repos-Liste in Sync zu halten.
workflow_run — um Actions-Runs der Lane zuzuordnen, die sie getriggert hat.

Webhooks werden an https://api.sprintloop.ai/integrations/github/webhook zugestellt. Der Endpoint verifiziert auf jedem Request den GitHub-Signature-Header und returned in <50 ms 200 (Arbeit wird gequeued, nicht inline erledigt). Wenn GitHub in den Settings deiner Org persistente Webhook-Failures meldet, ist das fast immer transient — die App retried und heilt sich selbst — aber eine anhaltende 24h-Failure-Rate über 1 % sollte dem Support gemeldet werden.

Häufige Stolperer

„Meine Lane hat gepushed, aber kein PR wurde geöffnet.” Prüfe, ob der Branch der Lane gegen die richtige Basis gepushed wurde. Wenn dein Default-Branch develop (nicht main) ist, nutzt die Lane develop als Basis, außer du übersteuerst pro Dispatch. PR-Erzeugung kann auch fehlschlagen, wenn vom selben Branch bereits ein PR existiert (wir öffnen nicht doppelt).

„CI ist auf GitHub grün, aber die Lane zeigt pending.” Der Check-Ingest hängt vom check_suite.completed-Webhook ab. Einige CI-Provider brauchen 30–60s, um ihn nach dem sichtbaren grünen Häkchen zu feuern. Wenn nach 5 Minuten immer noch pending, hat der Webhook uns nicht erreicht — re-triggere die Suite aus GitHub oder klick Re-sync CI auf der Lane-Seite.

„Ich will GitLab oder Bitbucket stattdessen nutzen.” GitLab wird über dieselbe Form von Integration supportet — siehe Integrations index. Bitbucket steht auf der Roadmap für Q3 2026.

„Die App fragt mich bei jedem neuen Repo nach Re-Grant der Permissions.” GitHub Apps haben einen Permission-Grant pro Org; neue Repos müssen unter der Configure-Seite der App hinzugefügt werden. Wir auto-claimen neu erstellte Repos nicht — Opt-in ist ein bewusster Akt.