GitHub Actions: Практические примеры Workflow, которые изменят ваш CI/CD

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

Что такое GitHub Actions и зачем он нужен?

GitHub Actions — это платформа для автоматизации рабочих процессов (workflow) прямо на GitHub. Вы создаете YAML-файлы, которые описывают последовательность действий (jobs) и шагов (steps), выполняемых при определенных событиях (push, pull request, schedule). Это ваш личный робот-помощник для CI/CD, тестирования, уведомлений и многого другого.

Ключевые концепции: Workflow — файл .yml в папке .github/workflows. Job — набор шагов, выполняемых на одном раннере. Step — отдельная команда или действие. Action — переиспользуемый компонент, «строительный блок» workflow.

Базовый пример: Запуск тестов при каждом пуше

Самый распространенный сценарий — автоматический запуск тестового набора. Создайте файл .github/workflows/run-tests.yml:

name: Run Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm ci
      - run: npm test

Этот workflow сработает при любом push или создании pull request. Он «чекаутит» код, устанавливает Node.js, зависимости и запускает тесты. Просто, но невероятно эффективно для поддержания качества кода.

Продвинутый пример: Сборка и деплой статического сайта

Допустим, у вас есть статический сайт на React/Vue или генераторе типа Hugo. Его можно автоматически собирать и деплоить на GitHub Pages.

name: Deploy to GitHub Pages

on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build
        run: |
          npm ci
          npm run build
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist

Обратите внимание на secrets.GITHUB_TOKEN. Это автоматически создаваемый токен для аутентификации workflow. Для деплоя на внешние сервисы (VPS, S3) используйте секреты репозитория (Settings -> Secrets and variables -> Actions).

Пример с матрицей: Тестирование на разных версиях и ОС

Мощная фича GitHub Actions — матрицы (matrix). Они позволяют запустить один job в нескольких конфигурациях. Например, протестировать код на разных версиях Python и в разных операционных системах.

name: Test Matrix

on: [push]

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        python-version: ['3.9', '3.10', '3.11']
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v4
        with:
          python-version: ${{ matrix.python-version }}
      - run: pip install -r requirements.txt
      - run: pytest

Этот workflow создаст 6 параллельных jobs (2 ОС * 3 версии Python) и выполнит тесты в каждом окружении. Идеально для обеспечения кросс-платформенной совместимости.

Пример с кэшированием: Ускорение сборок

Установка зависимостей (npm install, pip install) часто занимает много времени. Кэширование позволяет сохранять папки node_modules или pip-кеш между запусками workflow.

name: Build with Cache

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Cache Node modules
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-
      - run: npm ci
      - run: npm run build

Ключ кэша зависит от хэша package-lock.json. Если файл не менялся, workflow восстановит кэш и пропустит долгую установку зависимостей.

Полезные шаблоны и советы

1. Запуск по расписанию (cron)

Можно запускать workflow по расписанию, например, для ежедневного обновления данных или запуска тяжелых интеграционных тестов ночью.

on:
  schedule:
    - cron: '0 2 * * *' # Каждый день в 02:00 UTC

2. Ручной запуск (workflow_dispatch)

Добавьте возможность запускать workflow вручную из интерфейса GitHub.

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Environment to deploy to'
        required: true
        default: 'staging'

3. Условное выполнение шагов

Используйте if: для выполнения шагов только при определенных условиях.

- name: Notify on Failure
  if: failure()
  run: ./scripts/send-alert.sh

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

Где хранятся файлы workflow?

В папке .github/workflows/ в корне вашего репозитория. Можно создать несколько YAML-файлов для разных задач.

Есть ли лимиты на использование?

Для публичных репозиториев и тарифа Free на приватных — да. Например, 2000 минут выполнения в месяц на бесплатном тарифе. Детали — в документации GitHub.

Можно ли использовать свои собственные раннеры?

Да! Вы можете настроить self-hosted runners на своих серверах или даже локальных машинах для полного контроля над окружением.

Как отлаживать падающий workflow?

Используйте вкладку «Actions» в вашем репозитории. Там видны все запуски, логи каждого шага. Добавляйте отладочный вывод через echo или включайте debug-логирование с помощью секретов.

Можно ли повторно использовать шаги между workflow?

Да, для этого создавайте собственные Composite Actions или используйте публичные Actions из Marketplace. Это лучшая практика для стандартизации процессов.