GitHub Actions: последовательный запуск Workflow и управление зависимостями

В сложных проектах часто возникает необходимость запускать не только отдельные jobs внутри одного workflow, но и целые workflow последовательно — чтобы один запускался только после успешного (или неуспешного) завершения другого. Это позволяет создавать полноценные цепочки автоматизации: сборка → тестирование → деплой и т. д.

В этой статье разберём, как настроить workflow, который запускается по завершению другого, а также как добавить логику обработки результатов — запуск по успеху или по ошибке предыдущего workflow.

Запуск одного workflow после завершения другого

Для связи между workflow в GitHub Actions используется триггер workflow_run.
Он позволяет задать зависимость: один workflow (например, deploy.yml) запускается только после завершения другого (например, build.yml).

Пример базовой конфигурации:

name: Deploy

on:
  workflow_run:
    workflows: ["Build"]
    types:
      - completed

Здесь:

• workflows — указывает имя workflow, за завершением которого нужно следить.
• types — определяет состояние, при котором будет срабатывать триггер.
  Значение completed означает, что запуск произойдёт после завершения (успех или ошибка) предыдущего workflow.

Если нужно отслеживать только успешное выполнение, можно добавить условие if на уровне jobs.

Пример цепочки workflow

Допустим, у нас есть два файла:

.github/workflows/build.yml

name: Build
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Building project..."

.github/workflows/deploy.yml

name: Deploy
on:
  workflow_run:
    workflows: ["Build"]
    types: [completed]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying..."

Теперь при каждом коммите в репозиторий сначала выполнится Build, а только после его завершения автоматически запустится Deploy.

Добавление логики по результатам предыдущего workflow

Триггер workflow_run предоставляет объект контекста github.event.workflow_run, в котором содержится информация о предыдущем запуске, включая его статус.

С помощью этого объекта можно проверять, успешно ли завершился предыдущий workflow, и выполнять разные действия в зависимости от результата.

Пример:

name: Conditional Deploy

on:
  workflow_run:
    workflows: ["Build"]
    types: [completed]

jobs:
  success:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Previous workflow succeeded! Proceeding to deploy..."

  failed:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Previous workflow failed! Skipping deploy."

Теперь в зависимости от статуса выполнения Build будет запускаться либо job success, либо job failed.

Многоуровневая цепочка workflow

GitHub Actions позволяет создавать до трёх последовательных связей между workflow.
То есть можно построить цепочку:

Build → Test → Deploy → Notify

Каждый следующий workflow запускается с помощью workflow_run после завершения предыдущего.
Однако более глубокая вложенность (5-й, 6-й и далее уровни) будет проигнорирована — GitHub не разрешает бесконечные цепочки для предотвращения циклов и перегрузки системы.

Отладка и тестирование

Чтобы проверить работу зависимости:

1. Сделайте коммит в репозиторий — это запустит первый workflow.
2. Перейдите во вкладку Actions.
3. Убедитесь, что второй workflow стартует только после завершения первого.
4. Измените код в первом workflow так, чтобы он завершился с ошибкой, и посмотрите, как поведёт себя связанный workflow с условием failure.

Практическое применение

Такой подход удобно использовать для:

• пошагового CI/CD (сборка, тесты, деплой, уведомления);
• автоматической документации (генерация после успешного тестирования);
• разделения ответственности между командами (каждая поддерживает свой workflow).

GitHub Actions даёт гибкие возможности по построению логичных цепочек автоматизации, при этом всё управляется обычными YAML-файлами прямо в репозитории.

Заключение

Используя workflow_run и условия if, можно строить мощные сценарии CI/CD, где каждый этап зависит от результата предыдущего. Это не только повышает надёжность процессов, но и делает систему автоматизации максимально прозрачной и предсказуемой.

Создавайте цепочки workflow, добавляйте логику успеха и ошибок — и ваш DevOps-процесс станет ещё более гибким и интеллектуальным.

Автор: Александр Сокирка

Занимаюсь веб разработкой с 2007 года. Имею большой опыт в веб-дизайне и разработке сайтов. Являюсь автором YouTube канала Быть Программистом. Основатель бренда Aletheme и автор тем для WordPress на маркетплэйсе Envato. С 2017 года занимаюсь обучением людей желающим стать программистами. Мои обучающие программы можно найти на этом сайте или на Udemy.