Repositories & CI/CD

Repositories verbinden und Pipelines auf den eQuantic Runnern ausführen.

Repositories verbinden#

Verwenden Sie die GitHub App (empfohlen) für granulare, von der Organisation verwaltete Berechtigungen mit kurzlebigen Installations-Tokens. Azure DevOps wird jetzt unterstützt: Verbinden Sie eine Organisation mit einem Personal Access Token und wählen Sie die Repositories aus (org/project/repo) — die Webhooks (Service Hooks) werden automatisch eingerichtet. GitLab ist ebenfalls verfügbar: Verbinden Sie es mit einem Personal Access Token — gitlab.com oder Ihre eigene selbst gehostete Instanz — und wählen Sie die Projekte aus (auch aus tief verschachtelten Untergruppen); die Webhooks werden automatisch eingerichtet. Bitbucket ist ebenfalls ein vollwertiger Anbieter: Verbinden Sie einen Bitbucket-Workspace mit einem App-Passwort oder einem Atlassian-API-Token (zusammen mit der E-Mail-Adresse Ihres Kontos) und wählen Sie die Repositories aus (workspace/repo); die Webhooks werden automatisch eingerichtet. GitHub, GitLab, Bitbucket und Azure DevOps werden alle vollständig unterstützt.

Auf größeren Bildschirmen zeigt die Ansicht Repositories die verbundenen Repositories jedes Anbieters als Karten oder als kompakte Liste: Zwischen beiden wechseln Sie in der Werkzeugleiste. Sie öffnet sich so, wie Sie sie verlassen haben, mit demselben Anbieter-Tab, derselben Ansicht und demselben Sichtbarkeitsfilter, auch nachdem der Browser geschlossen wurde. Auf dem Smartphone behält die Ansicht ihre eigene Darstellung.

Pipelines#

Die Plattform interpretiert Ihre YAMLs von GitHub Actions, Azure Pipelines (azure-pipelines.yml), GitLab CI (.gitlab-ci.yml) und Bitbucket Pipelines (bitbucket-pipelines.yml) und führt die Jobs auf den eQuantic Runnern aus. Funktionen:

• Job-Graph, abgeleitet aus den needs:-Abhängigkeiten, mit Matrix-Builds, die in parallele Nodes expandieren.
• Concurrency-Gruppen genau wie GitHub sie ausführt, für Workflows und Jobs gleichermaßen (ein Namensraum pro Repository): ein Run oder Job der Gruppe zur Zeit, cancel-in-progress und queue — single lässt nur den neuesten warten, max bis zu 100 in Ankunftsreihenfolge.
• Echte Azure-Pipelines-Tasks für task:-Steps, aufgelöst aus Ihrer eigenen Organisation (Marketplace-Tasks eingeschlossen); reine PowerShell-Tasks und Service Connections werden noch nicht unterstützt.
• Live-Logs pro Step, mit erneuter Ausführung von allem / nur Fehlern / einzelnem Job.
• Visueller Step-Editor (Drag-and-Drop) und erweiterter Bearbeitungsmodus des YAML.
• Manuelle Freigabe vor dem Produktions-Deployment (Quorum N-von-M) und geschützte Environments.
• Konfigurierbarer Cache und Secrets/Variablen pro Repository, mit Referenzen auf Dienstvariablen.
• Pausenschalter auf zwei Ebenen — deaktivieren Sie einen einzelnen lauten Workflow, oder pausieren Sie über den Hauptschalter des Repositories dessen gesamten CI. Eine pausierte Pipeline löst nicht mehr aus (Pushes, Zeitpläne, manueller Start), bleibt aber samt ihrer Historie gelistet; beide Schalter sind standardmäßig eingeschaltet.

Portable Workflows#

Ein für GitHub geschriebener Workflow läuft hier unverändert. Ein paar Dinge sind gut zu wissen:

• secrets.GITHUB_TOKEN ist vorhanden, wie auf GitHub: es ist das Installation-Token des verbundenen Repositories, und ${{ github.token }} liefert denselben Wert. Sie deklarieren es nie — kein eigenes Secret darf GITHUB_* heißen.
• EQUANTIC_SPACE ist true in jedem Step. Der Rest der Umgebung ahmt den Provider bewusst nach (GITHUB_ACTIONS=true, GITHUB_SERVER_URL=https://github.com), damit echte Actions sich genau wie auf GitHub verhalten — deshalb ist dies die einzige Variable, an der ein Workflow erkennt, wo er läuft, für den seltenen Step, der wirklich anders sein muss.
• actions/cache funktioniert über unseren eigenen Cache-Dienst, in beiden Protokollversionen, die die Action spricht. cache-from: type=gha in einem Docker-Build nutzt denselben Speicher.
• Dein Checkout liegt dort, wo GitHub ihn ablegt: $GITHUB_WORKSPACE ist /home/runner/work/<repo>/<repo>, und das übergeordnete Verzeichnis ist $RUNNER_WORKSPACE, das deinem Job gehört. Ein Step schreibt also neben dem Checkout, wie Workflows es tun — git clone … ../<repo>.wiki, um das Wiki eines Repositorys zu lesen, oder ein Build-Ergebnis außerhalb des Baums — und ${{ runner.workspace }} ist dieses Verzeichnis, wie auf einem gehosteten Runner.
• Alle drei Action-Arten laufen: JavaScript, composite und Docker. Eine Docker-Action startet als Container neben dem Job, mit dem Workspace dort eingebunden, wo GitHub ihn einbindet (/github/workspace) — ein docker://-Image wird gezogen, eine Action mit eigenem Dockerfile wird zur Laufzeit gebaut. Nur runs.pre-entrypoint und runs.post-entrypoint laufen nicht, und der Step sagt es im Log, statt sie stillschweigend zu überspringen.
• shell: ist die Shell, die du angefordert hast: bash, sh, python, pwsh oder eine eigene Vorlage wie bash -e {0}. Ein Interpreter, den das Image nicht hat, lässt den Step mit seinem Namen scheitern, statt dein Skript als etwas anderes auszuführen. defaults.run gilt auf Workflow- und Job-Ebene, für shell wie für working-directory.
• github.event ist die gelieferte Payload, also lesen sich github.event.pull_request.number, github.event.head_commit.message und contains(github.event.pull_request.labels.*.name, …) wie auf GitHub. github.event_name sagt, was tatsächlich passiert ist, und die Inputs eines manuellen Starts kommen in inputs und in github.event.inputs an.

Pull Requests#

Bei einem verbundenen Repository (GitHub, GitLab, Bitbucket oder Azure DevOps) können Sie dessen Pull Requests wahlweise in eQuantic verwalten statt beim Anbieter — ein Opt-in pro Repository. Der Code bleibt immer beim Anbieter; eQuantic übernimmt niemals das Git-Hosting.

• Opt-in im Tab Pull requests — aktivieren Sie die von eQuantic verwalteten PRs oder nutzen Sie weiterhin die PRs des Anbieters (Standard).
• PR-Erstellung — wählen Sie Quell- → Ziel-Branch, Titel und Beschreibung; die PRs werden pro Repository durchnummeriert.
• Liste mit Status — open / draft / merged / closed, filterbar.
• Diff-Ansicht — eQuantic berechnet den Diff selbst (Three-Dot, gegen die Merge-Base, wie in den UIs der Anbieter) und speichert ihn: Die Detailseite zeigt eine Zusammenfassung (geänderte Dateien, +Hinzufügungen −Löschungen) und Unified-Hunks pro Datei mit exakten Zeilennummern. Binärdateien und sehr große Diffs werden markiert statt gerendert; neue Pushes auf den Quell-Branch aktualisieren den Diff automatisch über den Repository-Webhook.
• Code-Review im Diff — kommentieren Sie jede beliebige Zeile im Diff: Threads werden an der exakten Zeile verankert, mit Antworten und Auflösen/Wiedereröffnen. Bei neuen Commits gehen bestehende Threads nie verloren — sie werden als veraltet markiert und pro Datei gruppiert.
• Blockierende Kommentare — ein Review-Kommentar kann als blockierend markiert werden; nicht aufgelöste blockierende Kommentare werden am PR prominent hervorgehoben (Banner plus Indikator in der Liste), und nur ihr Autor kann sie auflösen.
• Genehmigungen und Konversation — Reviewer genehmigen den PR oder fordern Änderungen an (ein aktives Votum pro Reviewer; der Autor kann den eigenen PR nicht selbst reviewen), mit Zählern für Genehmigungen/Änderungswünsche am PR und in der Liste — dazu ein allgemeiner Kommentar-Feed am PR, ergänzend zu den Zeilen-Threads.
• Branch-Schutz — definieren Sie in den Repository-Einstellungen Regeln pro Branch-Muster (main, release/*): Mindestzahl an Genehmigungen, lineare Historie, ein gegenüber dem Ziel aktueller Branch, das Verwerfen veralteter Genehmigungen bei neuen Commits sowie ob nicht aufgelöste blockierende Kommentare ein Veto gegen den Merge einlegen — dazu die erlaubten Merge-Strategien und die Standardstrategie.
• Merge in eQuantic — sind alle Bedingungen erfüllt (Genehmigungen, keine angeforderten Änderungen, keine nicht aufgelösten blockierenden Kommentare, Schutzregeln), lässt sich der PR per Merge-Commit, Squash oder Rebase mergen. eQuantic führt den Merge selbst aus und pusht das Ergebnis zum Anbieter — nie über die Merge-API des Anbieters, nie mit Force-Push. Solange der Merge blockiert ist, listet der PR genau auf, was fehlt; ein PR kann auch ohne Merge geschlossen werden.
• Merge-Queue — statt direkt zu mergen, lässt sich ein PR in die Merge-Queue seines Ziel-Branches einreihen. Die Queue arbeitet die Einträge der Reihe nach ab: Jeder wird gegen den aktuellen Stand des Ziels getestet — ein zurückgefallener Branch muss also nicht manuell aktualisiert werden, und das Einreihen ist auch mit veraltetem Branch erlaubt — und erfüllt er zum Merge-Zeitpunkt weiterhin alle Bedingungen, führt eQuantic den Merge aus und pusht das Ergebnis. Ein Konflikt oder eine nicht erfüllte Bedingung entfernt den Eintrag samt Begründung aus der Queue, und der nächste rückt nach; wartende Einträge können die Queue verlassen, und das Queue-Panel im Tab Pull requests zeigt Positionen und Live-Status.
• CI-Checks — Pipeline-Läufe auf den Commits des PRs melden ihren Status nativ am PR: ein Check pro Workflow und Commit — ausstehend, erfolgreich oder fehlgeschlagen — angezeigt im Merge-Panel. Eine Branch-Schutzregel kann zusätzlich Checks vorschreiben: Der PR wird nur gemergt, wenn jeder gemeldete Check bestanden hat — ein fehlgeschlagener oder noch laufender Check blockiert den Merge, ebenso das Fehlen jeglicher gemeldeter Checks (ein vorgeschriebener Check gilt niemals stillschweigend als bestanden). Dieselbe Anforderung gilt auch für Einträge, die über die Merge-Queue gemergt werden.

Preview-Umgebungen#

Jeder offene Pull Request kann eine ephemere Preview-Umgebung bekommen — einen isolierten Dienst, gebaut aus dem PR-Branch, mit eigener URL (pr-N.preview.<deploy-domain>).

• Konfiguration pro Repository im Tab Previews: der Auto-Preview-Schalter, der Ziel-Space und eine optionale Basis-Umgebung, deren Variablen in jede Preview geklont werden.
• Automatischer Lebenszyklus — PR geöffnet → Umgebung wird provisioniert; neue Pushes → Redeploy; Merge/Schließen → Teardown. Die Karte zeigt den Live-Status (building → ready / failed), die URL, Branch/Commit und Autor.
• Manueller Modus — der Tab listet offene PRs ohne Preview, Erstellung mit einem Klick; bestehende Previews können über das Kartenmenü neu gebaut oder zerstört werden.
• Die Preview-URL wird als Kommentar im PR gepostet und aktuell gehalten.