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.

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.
• 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.

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.