Repositoryübergreifende Workflows
Lernen Sie, Workflows über verschiedene Repositories hinweg zu verketten, um Abhängigkeiten zu verwalten und komplexe Deployments zu orchestrieren.
Repositoryübergreifende Workflows ist eine kostenlose DevOps Bootcamp-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des DevOps Bootcamp-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der DevOps Bootcamp-Kurs umfasst insgesamt 4 Lektionen.
Einführung in repositoryübergreifende Workflows
In der modernen Softwareentwicklung bestehen Anwendungen häufig aus mehreren Komponenten, die über verschiedene Repositorys verteilt sind. Denken Sie an Microservices, gemeinsam genutzte Bibliotheken oder separate Bereitstellungskonfigurationen.
Die Orchestrierung von Workflows über diese verschiedenen Repositorys hinweg ermöglicht mehr Modularität und eine klarere Trennung von Zuständigkeiten. In dieser Lektion erfahren Sie, wie Sie dies mit GitHub Actions erreichen.
Warum repositoryübergreifende Orchestrierung?
Traditionell sind GitHub-Actions-Workflows auf ein einziges Repository beschränkt. Was aber, wenn Sie Folgendes benötigen:
- Ein Artefakt in einem Repository zu erstellen und eine Bereitstellung in einem anderen auszulösen?
- Ein gemeinsames Konfigurations-Repository, das Aktualisierungen in mehreren Service-Repositorys auslöst?
- Sicherheitsrichtlinien, die in einem zentralen Repository verwaltet werden, in allen anderen durchzusetzen?
Repositoryübergreifende Workflows bieten eine Lösung für diese komplexen Szenarien.
Repositorys verbinden: `repository_dispatch`
GitHub Actions bietet einen speziellen Ereignistyp namens repository_dispatch. Dieser fungiert wie ein benutzerdefinierter Webhook für Ihre GitHub-Repositorys.
- Ein Workflow (der „Sender“) sendet eine API-Anfrage an GitHub.
- Ein anderer Workflow (der „Empfänger“) in einem anderen Repository wartet auf dieses bestimmte Ereignis.
So lassen sich Workflows programmgesteuert über verschiedene Repositorys hinweg auslösen.
Empfänger-Workflow einrichten
Um ein repository_dispatch-Ereignis zu empfangen, muss ein Workflow im Ziel-Repository so konfiguriert werden, dass er darauf wartet. Dies geschieht mit dem Schlüsselwort on:.
So könnte ein Workflow in repo-B aussehen:
name: Receive Dispatch Event
on:
repository_dispatch:
types: [my-custom-event]
jobs:
process-event:
runs-on: ubuntu-latest
steps:
- name: Log event payload
run: |
echo "Event type: ${{ github.event.action }}"
echo "Payload: ${{ toJSON(github.event.client_payload) }}"Die Konfiguration des Empfängers verstehen
Im vorherigen Beispiel:
on: repository_dispatch:weist GitHub an, auf dieses Ereignis zu warten.types: [my-custom-event]gibt an, dass dieser Workflow nur ausgeführt wird, wenn das ausgelöste Ereignis den Typmy-custom-eventhat. Sie können mehrere Typen definieren.github.event.actionenthält den Ereignistyp (z. B.my-custom-event).github.event.client_payloadenthält alle benutzerdefinierten Daten, die mit dem Dispatch gesendet wurden.
Das Ereignis auslösen: Senden aus einem anderen Repository
Um ein repository_dispatch-Ereignis auszulösen, müssen Sie eine HTTP-POST-Anfrage an die GitHub-API senden. Dies können Sie mit curl oder der GitHub CLI (gh cli) aus einem anderen GitHub-Actions-Workflow oder einem Skript heraus tun.
Wichtige Voraussetzungen:
- Der Besitzer und der Name des Ziel-Repositorys.
- Ein Ereignis-
type, auf das der empfangende Workflow wartet. - Ein
client_payloadfür beliebige benutzerdefinierte Daten. - Ein persönliches GitHub-Zugriffstoken (PAT) mit dem
repo-Bereich.
Beispiel: Dispatch mit `gh cli`
Hier sehen Sie einen Workflow in repo-A, der ein Ereignis an repo-B sendet. Beachten Sie, dass wir ein Secret für das Token verwenden und ein client_payload übergeben.
name: Trigger Deploy Workflow
on:
push:
branches: [main]
jobs:
dispatch:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Install GitHub CLI
run: sudo apt-get update && sudo apt-get install gh -y
- name: Dispatch event to repo-B
env:
GH_TOKEN: ${{ secrets.CROSS_REPO_PAT }}
run: |
gh api \
--method POST \
-H "Accept: application/vnd.github.v3+json" \
/repos/YOUR_ORG/repo-B/dispatches \
-f event_type='my-custom-event' \
-f client_payload='{"ref":"${{ github.ref }}", "sha":"${{ github.sha }}"}'Zugriff über Repository-Grenzen hinweg absichern
Das standardmäßig für einen Workflow bereitgestellte GITHUB_TOKEN ist auf das Repository beschränkt, in dem der Workflow ausgeführt wird. Um Ereignisse in *einem anderen* Repository auszulösen, benötigen Sie ein Token mit weitergehenden Berechtigungen.
- Verwenden Sie ein persönliches Zugriffstoken (PAT) mit dem
repo-Bereich. - Speichern Sie dieses PAT als Repository-Secret (z. B.
CROSS_REPO_PAT) im auslösenden Repository. - Hinterlegen Sie PATs niemals direkt in Ihren Workflow-Dateien.
Benutzerdefinierte Daten mit `client_payload` übergeben
Das client_payload ist ein JSON-Objekt, das Sie beim Senden eines Ereignisses einschließen können. Es ist entscheidend, um Kontext oder Daten vom auslösenden Workflow an den empfangenden Workflow zu übergeben.
Beispiele für Daten, die Sie übergeben könnten:
- Die Commit-SHA oder der Branchname, durch den der Build ausgelöst wurde.
- Ein Umgebungsziel (z. B. "staging", "production").
- Eine Versionsnummer eines bereitzustellenden Artefakts.
Denken Sie daran: client_payload ist in den Workflow-Protokollen sichtbar. Vermeiden Sie daher vertrauliche Informationen.
Kurze Überprüfung zu Repository-übergreifenden Workflows
Sie haben gelernt, wie Sie Workflows über verschiedene GitHub-Repositorys hinweg orchestrieren. Testen wir nun Ihr Verständnis der wichtigsten Bestandteile.
Zusammenfassung: Orchestrierung über Repositorys hinweg
Sie haben erfolgreich gelernt, wie Sie Repository-übergreifende Workflows mit repository_dispatch implementieren!
- Warum: Zum Verwalten von Abhängigkeiten und Orchestrieren komplexer Bereitstellungen über mehrere Repositorys hinweg.
- Wie: Ein „Sender“-Workflow stellt einen API-Aufruf an GitHub und löst dadurch einen „Empfänger“-Workflow in einem anderen Repository aus.
- Wichtig: Der Ereignistyp
repository_dispatchund die passendentypesim empfangenden Workflow. - Daten: Verwenden Sie
client_payload, um nicht vertrauliche Informationen zwischen Workflows zu übergeben. - Sicherheit: Verwenden Sie für den Repository-übergreifenden Zugriff immer ein PAT mit dem
repo-Bereich und speichern Sie es als Secret.
Diese leistungsstarke Funktion ermöglicht äußerst flexible und entkoppelte CI/CD-Pipelines.
Häufig gestellte Fragen
Ist die Lektion „Repositoryübergreifende Workflows“ kostenlos?
Ja — der vollständige Text von „Repositoryübergreifende Workflows“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des DevOps Bootcamp-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der DevOps Bootcamp-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Repositoryübergreifende Workflows“?
Lernen Sie, Workflows über verschiedene Repositories hinweg zu verketten, um Abhängigkeiten zu verwalten und komplexe Deployments zu orchestrieren. Du übst DevOps Bootcamp mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um DevOps Bootcamp zu starten?
Keine Vorkenntnisse erforderlich. DevOps Bootcamp auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.
Wie lange dauert die Lektion „Repositoryübergreifende Workflows“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser DevOps Bootcamp-Lektion Code schreiben und ausführen?
Ja. Jede DevOps Bootcamp-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- CI/CD für Monorepos
- Repositoryübergreifende Workflows
- Zentrale Workflow-Verwaltung
- Pfadfilterung und selektive Builds