0Pricing
DevOps Bootcamp · Урок

Рабочие процессы между репозиториями

Научитесь связывать рабочие процессы в разных репозиториях для управления зависимостями и координации сложных развёртываний.

«Рабочие процессы между репозиториями» — бесплатный урок DevOps Bootcamp на CoddyKit. Это урок 2 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения DevOps Bootcamp, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс DevOps Bootcamp содержит 4 уроков всего.

Введение в рабочие процессы между репозиториями

В современной разработке программного обеспечения приложения часто состоят из нескольких компонентов, распределенных по разным репозиториям. Например, это могут быть микрослужбы, общие библиотеки или отдельные конфигурации развертывания.

Оркестрация рабочих процессов между такими отдельными репозиториями обеспечивает большую модульность и разделение ответственности. В этом уроке рассматривается, как реализовать это с помощью GitHub Actions.

Зачем нужна оркестрация между репозиториями?

Традиционно рабочие процессы GitHub Actions ограничены одним репозиторием. Но что делать, если Вам нужно:

  • собрать артефакт в одном репозитории и запустить развертывание в другом?
  • чтобы репозиторий общей конфигурации запускал обновления в нескольких репозиториях служб?
  • применять политики безопасности, управляемые в центральном репозитории, ко всем остальным?

Рабочие процессы между репозиториями решают эти сложные задачи.

Связывание репозиториев: `repository_dispatch`

GitHub Actions предоставляет специальный тип события под названием repository_dispatch. Он действует как настраиваемый веб-перехватчик для репозиториев GitHub.

  • Один рабочий процесс («отправитель») отправляет запрос к API GitHub.
  • Другой рабочий процесс («получатель») в другом репозитории ожидает это конкретное событие.

Это позволяет программно запускать рабочие процессы в разных репозиториях.

Настройка рабочего процесса получателя

Чтобы получить событие repository_dispatch, рабочий процесс в целевом репозитории необходимо настроить на его отслеживание. Для этого используется ключевое слово on:.

Рабочий процесс в repo-B может выглядеть так:

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

Разбор конфигурации получателя

В предыдущем примере:

  • on: repository_dispatch: сообщает GitHub, что нужно отслеживать это событие.
  • types: [my-custom-event] указывает, что этот рабочий процесс будет запускаться только при наличии у отправленного события типа my-custom-event. Можно определить несколько типов.
  • github.event.action будет содержать тип события (например, my-custom-event).
  • github.event.client_payload содержит любые пользовательские данные, отправленные вместе с событием.

Инициирование события: отправка из другого репозитория

Чтобы инициировать событие repository_dispatch, необходимо отправить HTTP-запрос POST к API GitHub. Это можно сделать с помощью curl или CLI GitHub (gh cli) из другого рабочего процесса GitHub Actions или скрипта.

Основные требования:

  • Владелец и имя целевого репозитория.
  • Тип события type, которого ожидает рабочий процесс-получатель.
  • Объект client_payload для передачи любых пользовательских данных.
  • Персональный токен доступа GitHub (PAT) с областью действия repo.

Пример: отправка с помощью `gh cli`

Вот рабочий процесс в repo-A, который отправляет событие в repo-B. Обратите внимание, как мы используем секрет для токена и передаём 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 }}"}'

Защита доступа между репозиториями

Предоставляемый рабочему процессу токен GITHUB_TOKEN по умолчанию ограничен репозиторием, в котором выполняется рабочий процесс. Чтобы инициировать события в *другом* репозитории, необходим токен с более широкими разрешениями.

  • Используйте персональный токен доступа (PAT) с областью действия repo.
  • Сохраните этот PAT как секрет репозитория (например, CROSS_REPO_PAT) в репозитории, инициирующем событие.
  • Никогда не записывайте PAT непосредственно в файлы рабочего процесса.

Передача пользовательских данных с помощью `client_payload`

client_payload — это объект JSON, который можно включить при отправке события. Он особенно важен для передачи контекста или данных из инициирующего рабочего процесса в рабочий процесс-получатель.

Примеры данных, которые можно передать:

  • SHA коммита или имя ветки, инициировавшей сборку.
  • Целевое окружение (например, "staging", "production").
  • Номер версии артефакта, который нужно развернуть.

Помните: client_payload отображается в журналах рабочего процесса, поэтому не включайте туда конфиденциальную информацию.

Быстрая проверка рабочих процессов между репозиториями

Вы научились координировать рабочие процессы в разных репозиториях GitHub. Давайте проверим, насколько хорошо вы усвоили основные компоненты.

Итоги: координация между репозиториями

Вы успешно научились реализовывать рабочие процессы между репозиториями с помощью repository_dispatch!

  • Зачем: Чтобы управлять зависимостями и координировать сложные развёртывания в нескольких репозиториях.
  • Как: Рабочий процесс-«отправитель» выполняет вызов API GitHub, инициируя рабочий процесс-«получатель» в другом репозитории.
  • Главное: Тип события repository_dispatch и соответствующие ему значения types в рабочем процессе-получателе.
  • Данные: Используйте client_payload для передачи неконфиденциальной информации между рабочими процессами.
  • Безопасность: Для доступа между репозиториями всегда используйте PAT с областью действия repo, сохранённый как секрет.

Эта мощная возможность обеспечивает гибкие и слабо связанные конвейеры CI/CD.

Часто задаваемые вопросы

Урок «Рабочие процессы между репозиториями» бесплатный?

Да — полный текст урока «Рабочие процессы между репозиториями» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс DevOps Bootcamp, подпишись на CoddyKit PRO. Курс DevOps Bootcamp содержит 4 уроков всего.

Чему я научусь в уроке «Рабочие процессы между репозиториями»?

Научитесь связывать рабочие процессы в разных репозиториях для управления зависимостями и координации сложных развёртываний. Ты практикуешь DevOps Bootcamp с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать DevOps Bootcamp?

Предыдущий опыт не требуется. DevOps Bootcamp на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 2 из 4.

Сколько времени занимает урок «Рабочие процессы между репозиториями»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке DevOps Bootcamp?

Да. Каждый урок DevOps Bootcamp включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. CI/CD для монорепозиториев
  2. Рабочие процессы между репозиториями
  3. Централизованное управление рабочими процессами
  4. Фильтрация по путям и выборочные сборки
← Назад к DevOps Bootcamp