workflow_call
Тема дорожной карты · GitHub Actions
on: workflow_call — это триггер, превращающий обычный GitHub Actions workflow в переиспользуемый, который другие workflow могут вызывать через job-level ключ uses:, передавая типизированные inputs, secrets и читая объявленные outputs. Вызываемый workflow определяет свой публичный контракт в блоке on: workflow_call — имена входных данных, типы, значения по умолчанию, признак обязательности и секреты для передачи, — поэтому вызывающий получает валидацию на этапе YAML и чёткий интерфейс. Этот механизм позволяет командам разрабатывать и использовать стандартные пайплайны для сборки, тестирования и развертывания, что упрощает работу и повышает эффективность.
Как это работает
workflow_call: workflows, вызываемые из других workflows. Триггер on: workflow_call: с inputs:, secrets:, outputs:. Вызов через uses: org/repo/.github/workflows/x.yml@sha. Отличие от composite actions: reusable workflows — целые workflows (несколько jobs), composite actions — наборы шагов внутри одного job. Полезно для "стандартный build-пайплайн", расшаренный между многими репо в org. В отличие от составных actions, цель workflow_call может развернуться на несколько заданий, runner'ов и matrix-комбинаций, что делает её правильным примитивом для общеорганизационных пайплайнов выпуска, сканирований безопасности или лестниц деплоя. Важно отметить, что вызовы workflow_call могут быть пиннуты по конкретным версиям (SHA), что обеспечивает стабильность и предсказуемость результатов.
Когда применять
Reusable workflows — когда нужно расшарить целые пайплайны (security-scan, release-pipeline, deploy-pipeline) между репо: пишите раз, ссылайтесь везде. Composite actions — для расшаривания последовательностей шагов внутри одного job. Пиньте called workflows по SHA в production. Тестируйте изменения reusable workflow в sandbox-репо до roll-out. Этот подход особенно полезен для больших команд, где требуется централизованное управление пайплайнами. Например, команда может опубликовать стандартные пайплайны для сборки, тестирования и развертывания, которые затем могут быть переиспользованы в различных репозиториях.
Типичные ошибки
Ловушки workflow_call: каскадные workflow_call цепочки (A зовёт B зовёт C — отладочный кошмар); сложность передачи секретов (нужен явный secrets: inherit или per-secret pass); breaking inputs в "централизованно-владельческом" workflow ломают consumer-репо (релизьте как новую версию, депрекейтьте старую). Пользователи часто сталкиваются с проблемами, связанными с управлением версиями и передачей секретных данных. Например, если вызываемый workflow изменяет свои входные параметры, это может привести к непредвиденным последствиям для вызывающего workflow. Чтобы избежать таких проблем, рекомендуется использовать конкретные версии вызываемых workflow и тщательно документировать изменения входных параметров.