Средний

GitHub Actions: workflow на практике

Урок 2 из 5 в курсе CI/CD: автоматизация сборки и деплоя

Содержание курса (2/5)

GitHub Actions: workflow на практике

GitHub Actions — самая популярная CI/CD платформа. Workflow файлы в формате YAML описывают, когда запускать пайплайн, какие шаги выполнять и как передавать данные между ними.

Почему это важно: GitHub Actions бесплатен для публичных репозиториев и доступен из коробки. Умение писать workflows — базовый навык для любого разработчика, работающего с GitHub.

Главная идея

Workflow = YAML-файл в .github/workflows/. Он определяет: триггер (on), окружение (runs-on), шаги (steps). Шаги могут использовать готовые actions из маркетплейса или выполнять произвольные команды.

Как это выглядит на практике

  1. Создаём .github/workflows/ci.yml в репозитории
  2. Определяем триггер: on push и pull_request для ветки main
  3. Описываем job: выбираем ubuntu-latest, настраиваем язык
  4. Добавляем шаги: checkout, установка зависимостей, тесты, линтер
  5. Пушим файл — GitHub автоматически обнаруживает workflow
  6. При каждом PR вкладка Checks показывает статус пайплайна

Примеры кода

Полный CI workflow для Rails

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true
      - run: bundle exec rubocop --parallel

  test:
    runs-on: ubuntu-latest
    needs: lint  # запускается только после успешного lint
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: password
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    env:
      DATABASE_URL: postgres://postgres:password@localhost:5432/test
      RAILS_ENV: test
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true
      - run: bin/rails db:setup
      - run: bundle exec rspec --format progress

Матрица версий и кэширование

jobs:
  test:
    strategy:
      matrix:
        ruby: ['3.2', '3.3']
        os: [ubuntu-latest, macos-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: ${{ matrix.ruby }}
          bundler-cache: true
      - run: bundle exec rspec

  # Результат: 4 параллельных job'а
  # ubuntu + 3.2, ubuntu + 3.3
  # macos + 3.2, macos + 3.3

Что происходит под капотом

  • Workflow файлы в .github/workflows/ автоматически распознаются GitHub
  • needs: [lint] — создаёт зависимость между job'ами, lint должен пройти первым
  • services: — запускает Docker-контейнеры (PostgreSQL, Redis) рядом с основным runner'ом
  • strategy.matrix — запускает job для каждой комбинации параметров параллельно
  • Секреты (API-ключи, токены) хранятся в Settings → Secrets и доступны через ${{ secrets.NAME }}

Типичные ошибки и заблуждения

  • «GitHub Actions только для тестов» — можно деплоить, публиковать пакеты, генерировать документацию, создавать релизы
  • «Маркетплейс actions безопасны» — проверяйте автора и пиньте версию (uses: action@v4, не @main)
  • «Нужно писать всё с нуля» — маркетплейс содержит тысячи готовых actions для типовых задач

Ключевые выводы

  • Workflow = YAML с триггером (on), job'ами (jobs), шагами (steps)
  • needs создаёт зависимости между job'ами, matrix — параллельный запуск для разных конфигураций
  • services — готовые Docker-контейнеры для БД и сервисов прямо в CI

Термины урока

{:term=>"Workflow", :definition=>"YAML-файл в .github/workflows/, описывающий автоматический процесс CI/CD"}
{:term=>"Runner", :definition=>"Виртуальная машина (ubuntu-latest, macos-latest), на которой выполняется workflow"}
{:term=>"Matrix strategy", :definition=>"Запуск одного job с разными комбинациями параметров (версии языка, ОС) параллельно"}

Связь с работой backend-разработчика

Начните с простого workflow (checkout → install → test), затем добавляйте: lint, services (PostgreSQL), кэширование, matrix testing. Каждый шаг увеличивает надёжность пайплайна и уменьшает количество багов в production.

Мини-разбор реальной ситуации

Open-source библиотека тестировалась только на Ruby 3.3, но пользователи жаловались на ошибки в 3.2. Добавление matrix strategy с двумя версиями Ruby выявило 3 бага совместимости, которые были незаметны в одной версии.

Что запомнить

  • Один файл .github/workflows/ci.yml запускает полный CI при каждом PR
  • services: postgres — база данных в CI без настройки Docker
  • Секреты → Settings → Secrets, не хардкодьте ключи в workflow

Итог

GitHub Actions — мощная и доступная CI/CD платформа. YAML-формат workflow позволяет описать весь пайплайн декларативно: от запуска тестов с PostgreSQL до параллельного тестирования на разных версиях языка.

Комментарии к уроку

Войдите, чтобы оставить комментарий.

Пока нет комментариев — будьте первым.