github actions

GitHub Actions — это встроенная платформа автоматизации GitHub, позволяющая создавать рабочие процессы (workflows) для сборки, тестирования и развёртывания кода прямо из репозитория. Workflows описываются в YAML-файлах, хранятся в директории .github/workflows/ и запускаются в ответ на события: push, pull request, расписание, ручной вызов и десятки других триггеров.

Ключевые концепции GitHub Actions

Workflow — верхнеуровневый автоматизированный процесс, описанный в YAML. Один репозиторий может содержать несколько workflows.

Job — набор шагов, выполняющихся на одном раннере. Джобы могут работать параллельно или последовательно (с зависимостями через needs).

Step — атомарный шаг внутри джоба: shell-команда или вызов action.

Action — переиспользуемый блок логики. Публикуется в GitHub Marketplace; существуют тысячи готовых actions для Docker, Terraform, деплоя в облака, уведомлений и многого другого.

Runner — виртуальная машина или контейнер, на котором выполняется джоб. GitHub предоставляет hosted runners (Ubuntu, Windows, macOS). Можно настроить self-hosted runner на собственном сервере.

Структура YAML-файла workflow

Минимальный workflow выглядит так: указываем имя, триггер (например, push на ветку main), джоб с именем, раннером и шагами. Каждый шаг либо выполняет shell-команду через run, либо вызывает action через uses.

Важные возможности YAML-конфигурации: матричные сборки (strategy.matrix) — запуск одного джоба с разными версиями языка или ОС; условия (if) — пропуск шага при определённых условиях; кеширование зависимостей (actions/cache) — ускорение сборки; артефакты (actions/upload-artifact) — передача файлов между джобами.

Типичные сценарии использования

CI-пайплайн

На каждый pull request: установка зависимостей, запуск тестов, проверка линтером, сборка проекта. Если хотя бы один шаг завершается с ошибкой, PR нельзя смержить (при включённых branch protection rules).

CD и деплой

После мержа в main: сборка Docker-образа, публикация в Container Registry, деплой в Kubernetes или обновление сервиса на AWS/GCP/Azure. Секреты (токены, пароли) хранятся в Settings → Secrets and variables и доступны в workflow через ${{ secrets.MY_SECRET }}.

Автоматизация репозитория

Автоматическое создание релизов, генерация changelog, синхронизация веток, отправка уведомлений в Slack, закрытие устаревших issues — всё это реализуется через GitHub Actions без внешних CI-серверов.

Маркетплейс и экосистема

GitHub Marketplace содержит тысячи готовых actions. Наиболее популярные: actions/checkout (клонирование репозитория), actions/setup-node, actions/setup-python (настройка языкового окружения), docker/build-push-action (сборка и публикация Docker-образов), aws-actions/configure-aws-credentials (аутентификация в AWS).

Можно создавать собственные actions — JavaScript, Docker или composite (набор шагов). Корпоративные actions публикуются в приватных репозиториях и доступны только внутри организации.

Ценообразование и лимиты

Для публичных репозиториев GitHub Actions бесплатен. Для приватных — бесплатные минуты в зависимости от тарифного плана (Free: 2 000 мин/мес, Pro: 3 000, Team: 3 000, Enterprise: 50 000). Linux-минуты считаются по базовой ставке; Windows — в 2 раза дороже, macOS — в 10 раз. Self-hosted runners не тарифицируются, но требуют поддержки инфраструктуры.

GitHub Actions vs конкуренты

По сравнению с Jenkins GitHub Actions не требует установки и поддержки сервера, имеет нативную интеграцию с GitHub и меньший порог входа. По сравнению с GitLab CI/CD — проигрывает в возможностях встроенного container registry и динамических окружений, но выигрывает при работе в экосистеме GitHub. CircleCI предлагает более гибкое кеширование, но дороже для больших объёмов.

Лучшие практики

• Закрепляйте версии actions через SHA-хеш коммита, а не тег — это защищает от атак на цепочку поставок.
• Храните все секреты в Secrets, никогда не хардкодьте их в YAML.
• Используйте кеширование зависимостей — ускоряет пайплайн в 2–5 раз.
• Разбивайте монолитный workflow на несколько специализированных файлов.
• Включайте concurrency для отмены устаревших запусков при частых пушах.