Workflows på tværs af repositories
Lær at kæde workflows sammen på tværs af forskellige repositories for at håndtere afhængigheder og orkestrere komplekse deployments.
Workflows på tværs af repositories er en gratis Intensiv DevOps-uddannelse-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Intensiv DevOps-uddannelse, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Intensiv DevOps-uddannelse-kurset indeholder 4 lektioner i alt.
Introduktion til arbejdsgange på tværs af kodearkiver
I moderne softwareudvikling består applikationer ofte af flere komponenter, der er fordelt på forskellige kodearkiver. Det kan være mikroservices, delte biblioteker eller separate konfigurationer til implementering.
Koordinering af arbejdsgange på tværs af disse adskilte kodearkiver giver større modularitet og bedre adskillelse af ansvarsområder. Denne lektion gennemgår, hvordan du opnår dette med GitHub Actions.
Hvorfor orkestrere på tværs af kodearkiver?
Traditionelt er GitHub Actions-arbejdsgange begrænset til ét kodearkiv. Men hvad nu, hvis du har brug for:
- At bygge en artefakt i ét kodearkiv og udløse en implementering i et andet?
- Et fælles konfigurationskodearkiv, der udløser opdateringer i flere tjenestekodearkiver?
- At håndhæve sikkerhedspolitikker, der administreres i et centralt kodearkiv, på tværs af alle andre?
Arbejdsgange på tværs af kodearkiver giver en løsning på disse komplekse scenarier.
Forbindelse mellem kodearkiver: `repository_dispatch`
GitHub Actions tilbyder en særlig hændelsestype med navnet repository_dispatch. Den fungerer som en tilpasset webhook til dine GitHub-kodearkiver.
- En arbejdsgang (afsenderen) sender en API-anmodning til GitHub.
- En anden arbejdsgang (modtageren) i et andet kodearkiv lytter efter denne specifikke hændelse.
Det gør det muligt programmatisk at udløse arbejdsgange på tværs af forskellige kodearkiver.
Konfiguration af modtagerarbejdsgangen
For at modtage en repository_dispatch-hændelse skal en arbejdsgang i målarkivet konfigureres til at lytte efter den. Det gøres ved hjælp af nøgleordet on:.
Her er et eksempel på, hvordan en arbejdsgang i repo-B kan se ud:
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) }}"Forståelse af modtagerkonfigurationen
I det foregående eksempel:
on: repository_dispatch:fortæller GitHub, at den skal lytte efter denne hændelse.types: [my-custom-event]angiver, at denne arbejdsgang kun kører, hvis den afsendte hændelse har typenmy-custom-event. Du kan definere flere typer.github.event.actionindeholder hændelsestypen (f.eks.my-custom-event).github.event.client_payloadindeholder alle tilpassede data, der blev sendt sammen med hændelsen.
Udløsning af hændelsen: Afsendelse fra et andet lager
Hvis du vil udløse en repository_dispatch-hændelse, skal du sende en HTTP POST-anmodning til GitHub API'et. Det kan du gøre ved hjælp af curl eller GitHub CLI (gh cli) fra en anden GitHub Actions-arbejdsgang eller et script.
Vigtige krav:
- Det målrettede lagers ejer og navn.
- En hændelse af typen
type, som modtagerarbejdsgangen lytter efter. - En
client_payloadtil brugerdefinerede data. - Et personligt GitHub-adgangstoken (PAT) med
repo-omfang.
Eksempel: Afsendelse med `gh cli`
Her er en arbejdsgang i repo-A, der sender en hændelse til repo-B. Bemærk, hvordan vi bruger en hemmelighed til tokenet og sender en client_payload.
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 }}"}'Sikring af adgang på tværs af lagre
Det standardiserede GITHUB_TOKEN, som en arbejdsgang får, er begrænset til det lager, hvor arbejdsgangen kører. Hvis du vil udløse hændelser i *et andet* lager, skal du bruge et token med bredere tilladelser.
- Brug et personligt adgangstoken (PAT) med
repo-omfang. - Gem dette PAT som en lagerhemmelighed (f.eks.
CROSS_REPO_PAT) i det udløsende lager. - Indkod aldrig PAT'er direkte i dine arbejdsgangsfiler.
Overførsel af brugerdefinerede data med `client_payload`
client_payload er et JSON-objekt, som du kan inkludere, når du sender en hændelse. Det er afgørende for at overføre kontekst eller data fra den udløsende arbejdsgang til modtagerarbejdsgangen.
Eksempler på data, du kan overføre:
- Den commit-SHA eller det grennavn, der udløste bygningen.
- Et miljømål (f.eks. "staging", "production").
- Et versionsnummer for en artefakt, der skal implementeres.
Husk: client_payload er synlig i arbejdsgangens logfiler, så undgå følsomme oplysninger.
Kort kontrol af arbejdsgange på tværs af lagre
Du har lært, hvordan du orkestrerer arbejdsgange på tværs af forskellige GitHub-lagre. Lad os teste din forståelse af de vigtigste komponenter.
Opsummering: Orkestrering på tværs af lagre
Du har lært at implementere arbejdsgange på tværs af lagre ved hjælp af repository_dispatch!
- Hvorfor: Til håndtering af afhængigheder og orkestrering af komplekse implementeringer på tværs af flere lagre.
- Hvordan: En "afsender"-arbejdsgang foretager et API-kald til GitHub, som udløser en "modtager"-arbejdsgang i et andet lager.
- Nøglepunkt: Hændelsestypen
repository_dispatchog matchendetypesi modtagerarbejdsgangen. - Data: Brug
client_payloadtil at overføre ikke-følsomme oplysninger mellem arbejdsgange. - Sikkerhed: Brug altid et PAT med
repo-omfang, gemt som en hemmelighed, til adgang på tværs af lagre.
Denne effektive funktion muliggør meget fleksible og løst koblede CI/CD-pipelines.
Lær Intensiv DevOps-uddannelse med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 142
- Lektioner
- 568
Ofte stillede spørgsmål
Er lektionen “Workflows på tværs af repositories” gratis?
Ja — alle 3 lektioner i læringssporet Intensiv DevOps-uddannelse, inklusive “Workflows på tværs af repositories”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Intensiv DevOps-uddannelse-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Workflows på tværs af repositories”?
Lær at kæde workflows sammen på tværs af forskellige repositories for at håndtere afhængigheder og orkestrere komplekse deployments. Du øver dig i Intensiv DevOps-uddannelse med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Intensiv DevOps-uddannelse?
Der kræves ingen tidligere erfaring. Intensiv DevOps-uddannelse på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.
Hvor lang tid tager lektionen “Workflows på tværs af repositories”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Intensiv DevOps-uddannelse-lektion?
Ja. Alle Intensiv DevOps-uddannelse-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- CI/CD til monorepos
- Workflows på tværs af repositories
- Centraliseret workflowadministration
- Stifiltrering og selektive builds