CI/CD with GitHub Actions & DevOps Pipelines · Lekcja

Workflows między repozytoriami

Nauczą się Państwo łączyć workflows między różnymi repozytoriami, aby zarządzać zależnościami i koordynować złożone wdrożenia.

Workflows między repozytoriami to bezpłatna lekcja CI/CD with GitHub Actions & DevOps Pipelines na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej CI/CD with GitHub Actions & DevOps Pipelines, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs CI/CD with GitHub Actions & DevOps Pipelines zawiera 4 lekcji w sumie.

Wprowadzenie do przepływów pracy między repozytoriami

We współczesnym tworzeniu oprogramowania aplikacje często składają się z wielu komponentów rozproszonych w różnych repozytoriach. Mogą to być mikrousługi, współdzielone biblioteki lub oddzielne konfiguracje wdrożeń.

Orkiestracja przepływów pracy między tymi niezależnymi repozytoriami zapewnia większą modularność i rozdzielenie odpowiedzialności. W tej lekcji omówimy, jak osiągnąć to za pomocą GitHub Actions.

Dlaczego orkiestracja między repozytoriami?

Tradycyjnie przepływy pracy GitHub Actions są ograniczone do jednego repozytorium. Co jednak w sytuacji, gdy trzeba:

zbudować artefakt w jednym repozytorium i uruchomić wdrożenie w innym?
zaktualizować wiele repozytoriów usług na podstawie zmian we współdzielonym repozytorium konfiguracji?
egzekwować we wszystkich pozostałych repozytoriach zasady bezpieczeństwa zarządzane w centralnym repozytorium?

Przepływy pracy między repozytoriami zapewniają rozwiązanie dla tych złożonych scenariuszy.

Łączenie repozytoriów: `repository_dispatch`

GitHub Actions udostępnia specjalny typ zdarzenia o nazwie repository_dispatch. Działa on jak niestandardowy webhook dla repozytoriów GitHub.

Jeden przepływ pracy („nadawca”) wysyła do GitHub żądanie API.
Inny przepływ pracy („odbiorca”) w innym repozytorium nasłuchuje tego konkretnego zdarzenia.

Umożliwia to programowe uruchamianie przepływów pracy w różnych repozytoriach.

Konfigurowanie przepływu pracy odbiorcy

Aby odebrać zdarzenie repository_dispatch, przepływ pracy w docelowym repozytorium musi być skonfigurowany tak, aby go nasłuchiwał. Służy do tego słowo kluczowe on:.

Przepływ pracy w repo-B może wyglądać tak:

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) }}"

Zrozumienie konfiguracji odbiorcy

W poprzednim przykładzie:

on: repository_dispatch: informuje GitHub, aby nasłuchiwał tego zdarzenia.
types: [my-custom-event] określa, że ten przepływ pracy uruchomi się tylko wtedy, gdy wysłane zdarzenie będzie mieć typ my-custom-event. Można zdefiniować wiele typów.
github.event.action będzie zawierać typ zdarzenia (np. my-custom-event).
github.event.client_payload przechowuje niestandardowe dane wysłane wraz z wywołaniem.

Wyzwalanie zdarzenia: wysyłanie z innego repozytorium

Aby wyzwolić zdarzenie repository_dispatch, należy wysłać żądanie HTTP POST do interfejsu API GitHub. Można to zrobić za pomocą curl lub GitHub CLI (gh cli) z poziomu innego workflow GitHub Actions albo skryptu.

Najważniejsze wymagania:

Właściciel i nazwa docelowego repozytorium.
Typ zdarzenia type, którego nasłuchuje workflow odbiorcy.
Obiekt client_payload zawierający dowolne dane niestandardowe.
Osobisty token dostępu GitHub (PAT) z zakresem repo.

Przykład: wysyłanie zdarzenia za pomocą `gh cli`

Oto workflow w repozytorium repo-A, który wysyła zdarzenie do repozytorium repo-B. Zwróć uwagę, że używamy sekretu dla tokenu i przekazujemy obiekt 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 }}"}'

Zabezpieczanie dostępu między repozytoriami

Domyślny token GITHUB_TOKEN udostępniany workflow ma uprawnienia ograniczone do repozytorium, w którym uruchamiany jest workflow. Aby wyzwalać zdarzenia w *innym* repozytorium, potrzebny jest token z szerszymi uprawnieniami.

Należy użyć osobistego tokenu dostępu (PAT) z zakresem repo.
Ten PAT należy przechowywać jako sekret repozytorium (np. CROSS_REPO_PAT) w repozytorium wyzwalającym.
Nigdy nie należy wpisywać PAT-ów bezpośrednio w plikach workflow.

Przekazywanie niestandardowych danych za pomocą `client_payload`

client_payload to obiekt JSON, który można dołączyć podczas wysyłania zdarzenia. Ma on kluczowe znaczenie przy przekazywaniu kontekstu lub danych z workflow wyzwalającego do workflow odbierającego.

Przykładowe dane, które można przekazać:

SHA commita lub nazwa gałęzi, która wyzwoliła kompilację.
Docelowe środowisko (np. "staging", "production").
Numer wersji artefaktu przeznaczonego do wdrożenia.

Pamiętaj: client_payload jest widoczny w logach workflow, dlatego unikaj umieszczania w nim poufnych informacji.

Szybki test workflow między repozytoriami

Dowiedziałeś się, jak koordynować workflow w różnych repozytoriach GitHub. Sprawdźmy, czy rozumiesz najważniejsze elementy.

Podsumowanie: koordynowanie pracy między repozytoriami

Udało Ci się nauczyć implementowania workflow między repozytoriami za pomocą repository_dispatch!

Dlaczego: Aby zarządzać zależnościami i koordynować złożone wdrożenia w wielu repozytoriach.
Jak: Workflow „nadawcy” wykonuje wywołanie API GitHub, wyzwalając workflow „odbiorcy” w innym repozytorium.
Najważniejsze: Typ zdarzenia repository_dispatch oraz pasujące wartości types w workflow odbiorcy.
Dane: Użyj client_payload, aby przekazywać między workflow informacje, które nie są poufne.
Bezpieczeństwo: W przypadku dostępu między repozytoriami zawsze używaj PAT-a z zakresem repo, przechowywanego jako sekret.

Ta zaawansowana funkcja umożliwia tworzenie bardzo elastycznych i niezależnych potoków CI/CD.

Często zadawane pytania

Czy lekcja „Workflows między repozytoriami” jest bezpłatna?

Tak — pełny tekst „Workflows między repozytoriami” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu CI/CD with GitHub Actions & DevOps Pipelines, przejdź na CoddyKit PRO. Kurs CI/CD with GitHub Actions & DevOps Pipelines zawiera 4 lekcji w sumie.

Co nauczysz się w „Workflows między repozytoriami”?

Nauczą się Państwo łączyć workflows między różnymi repozytoriami, aby zarządzać zależnościami i koordynować złożone wdrożenia. Ćwiczysz CI/CD with GitHub Actions & DevOps Pipelines z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć CI/CD with GitHub Actions & DevOps Pipelines?

Nie wymagamy żadnego doświadczenia. CI/CD with GitHub Actions & DevOps Pipelines w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Workflows między repozytoriami”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji CI/CD with GitHub Actions & DevOps Pipelines?

Tak. Każda lekcja CI/CD with GitHub Actions & DevOps Pipelines zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

CI/CD dla monorepozytoriów
Workflows między repozytoriami
Centralne zarządzanie workflows
Filtrowanie ścieżek i wybiórcze kompilacje

← Powrót do CI/CD with GitHub Actions & DevOps Pipelines