Auf dieser Seite
GitHub-Integration (geplant)
Den geplanten optionalen GitHub-App-Ablauf, benötigte Berechtigungen und die sichere Übergabe verstehen; die Integration ist derzeit in der Cloud-Kundenoberfläche nicht verfügbar.
Diese Planung können Sie heute für Ihre Anfrage und das Pilotangebot verwenden. Vertragliche Leistungen gelten erst nach schriftlicher Vereinbarung.
Bevor Sie starten
GitHub bleibt optional: Konto, Clustererstellung und OCI-/YAML-/Helm-Deployment benötigen keine Repository-Verbindung. Eine künftige GitHub-App kann signierten Installationsstatus, kurzlebige Installationstokens, geprüfte Webhooks und isolierte Builds ergänzen. Diese Kontrollen sind eine Produktperspektive und keine aktuelle Kundenfunktion.
1. Heute verfügbaren Release-Weg nutzen
- 01
Außerhalb der Cloud bauen
Erstellen Sie ein unveränderliches OCI-Image in einer von Ihnen kontrollierten Registry oder bereiten Sie ein unterstütztes YAML-/Helm-Paket vor. Fixieren Sie Digest/Version und halten Sie den Commit in Ihrem Änderungsprotokoll fest.
- 02
Browser-Eingang auswählen
Wählen Sie im Cloud-Anwendungsworkflow freigegebenes OCI-Image oder YAML-/Helm-Paket und prüfen Sie Validierung und Diff. Ein GitHub-Konto oder Repository-Zugriff ist nicht erforderlich.
- 03
Release-Nachweise verfolgen
Nutzen Sie Revision, Vorgangskennung, Bereitschaft und Rollback-Historie im Browser. Halten Sie die Quellherkunft in Ihrem eigenen Repository-Protokoll fest, bis die optionale Integration qualifiziert ist.
2. Geplanter Verbindungsablauf
Wenn die optionale Funktion veröffentlicht ist, ist folgender Browserablauf vorgesehen: Einstellungen → Integrationen öffnen, GitHub wählen, GitHub-App und angeforderte Repositories prüfen, ausgewählte Organisation/Repositories auf GitHub autorisieren, zur signierten Installationsbestätigung zurückkehren, Repository und Branch wählen und anschließend Arbeitsfläche sowie Build-Policy speichern.
| Kontrolle | Erforderliches Verhalten |
|---|---|
| Berechtigung | Repository-Auswahl ist explizit; die App fordert nur genehmigte minimale Lese-/Webhook-/Build-Berechtigungen an. |
| Token | Installationstokens sind kurzlebig, bereichsgebunden und werden nie angezeigt oder in Kundennotizen gespeichert. |
| Webhook | Signierte Events identifizieren Repository, Ref und Commit; Replay- und Signaturfehler werden abgewiesen. |
| Build | Der Service erfasst Commit-SHA, Build-Logs, Scan-/SBOM-Ergebnis und unveränderlichen Artefakt-Digest. |
3. Vor Autorisierung erneut prüfen
- ✓GitHub-Organisation, Repository, Branch und Umgebung auf die beabsichtigten Werte prüfen.
- ✓Exakte App-Berechtigungen und Verhalten zu Aufbewahrung/Löschung vor der Freigabe lesen.
- ✓Kein persönliches Token, breit berechtigtes Organisationstoken oder beliebige Webhook-URL für den Cloud-Workflow autorisieren.
- ✓OCI/YAML/Helm als Ausweichweg behalten; das Trennen von GitHub darf keine bereitgestellte Anwendung löschen.
4. Wenn Sie jetzt GitHub-Delivery benötigen
Fordern Sie die Fähigkeit in der Pilotanfrage an und nennen Sie Repository, Build-Methode, erforderliche Berechtigungen und Abnahmetest. Bis zur ausdrücklichen Aktivierung nutzen Sie freigegebenes OCI-Image oder YAML-/Helm-Paket. Leiten Sie Verfügbarkeit nicht aus geplanter Produktbeschreibung oder einem generischen Repository-Scanner ab.
Anwendung mit Helm in ClusterPilot bereitstellen → · Cloud-Produktstatus →
Diese Anleitung gilt für Ihren vereinbarten Pilotumfang. Technische Kubernetes-Beispiele sind kein Nachweis einer allgemein verfügbaren Cloud-Funktion.