llmdocsсправочник разработчика

GitHub Actions

Материал из llmdocs — справочник разработчика
Портал: Git, CI/CD, DevOps
GitHub Actions
Типплатформа CI/CD и автоматизации
РазработчикGitHub (Microsoft)
Анонсоктябрь 2018
Общая доступностьноябрь 2019
Описание процессовYAML в каталоге .github/workflows/
РаннерыLinux, Windows, macOS (облачные) и self-hosted
Каталог готовых действийGitHub Marketplace
Бесплатнопубличные репозитории; лимит минут для приватных

GitHub Actions — система автоматизации, встроенная в GitHub: она запускает рабочие процессы (workflows), описанные в YAML-файлах прямо в репозитории, в ответ на события — push, открытие pull request, публикацию релиза, расписание или ручной запуск.[1] Чаще всего Actions используют для CI/CD: собрать проект, прогнать тесты и линтеры, собрать и опубликовать образ, развернуть приложение. Но это и универсальный инструмент: разметка задач, генерация документации, публикация сайта на GitHub Pages, обновление зависимостей.

История

GitHub анонсировал Actions в октябре 2018 года как средство автоматизации, а в ноябре 2019 года выпустил с полноценной поддержкой CI/CD и бесплатными минутами для публичных репозиториев.[6] Благодаря интеграции в саму платформу и каталогу готовых действий (Marketplace) сервис быстро потеснил внешние CI-системы — Travis CI, CircleCI — в открытых проектах.

Устройство

  • Workflow — YAML-файл в .github/workflows/. В репозитории их может быть сколько угодно.
  • Событие (on:) — что запускает процесс: push, pull_request, schedule (cron), workflow_dispatch (кнопка), release и десятки других.[3]
  • Job — набор шагов, выполняемых на одной машине. Задания идут параллельно, если не связаны через needs:.
  • Step — шаг: либо команда оболочки (run:), либо готовое действие (uses:).
  • Action — переиспользуемый компонент: JavaScript-код, Docker-контейнер или составное действие из шагов. Хранится в репозитории и подключается по ссылке владелец/репо@версия.
  • Runner — машина, исполняющая задание: облачная виртуальная машина GitHub (ubuntu-latest, windows-latest, macos-latest) или собственная (self-hosted).

Пример

# .github/workflows/ci.yml
name: CI
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python: ["3.12", "3.13"]
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v6
      - run: uv sync --python ${{ matrix.python }}
      - run: uv run pytest

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

Матрица (strategy.matrix) запускает задание для каждого сочетания параметров — версий языка, операционных систем. Выражения ${{ ... }} дают доступ к контексту: ветке, событию, секретам, выходам предыдущих шагов.[2]

Секреты и права

Секреты задаются в настройках репозитория, окружения или организации и попадают в процесс через secrets.*; в логах они маскируются. Каждый запуск получает временный токен GITHUB_TOKEN для работы с API репозитория — его права стоит сужать блоком permissions:. Окружения (environments) добавляют свои секреты и правила: обязательное одобрение человеком, ограничение веток.

Вместо долгоживущих ключей облаков рекомендуется OIDC: процесс получает подписанный токен от GitHub и обменивает его на временные учётные данные у провайдера, который доверяет конкретному репозиторию и ветке.[5]

Безопасность

Actions — частая цель атак на цепочку поставок:[4]

  • Фиксируйте сторонние действия по хешу коммита, а не по тегу: тег можно перенаправить. В марте 2025 года злоумышленники переписали теги популярного действия tj-actions/changed-files, и в логах тысяч репозиториев оказались секреты.[7]
  • Событие pull_request_target выполняется с секретами и правами целевого репозитория — запускать в нём код из чужого PR опасно.
  • Не подставляйте недоверенные данные (заголовок PR, имя ветки) в run: через ${{ }} — это инъекция команд; передавайте их через переменные окружения.
  • Self-hosted раннеры в публичных репозиториях позволяют любому, кто откроет PR, выполнить код на вашей машине.

Переиспользование

  • Составные действия (runs.using: composite) — набор шагов в отдельном action.yml.
  • Переиспользуемые workflow (on: workflow_call) — целый процесс, вызываемый из других репозиториев.
  • Кеш (actions/cache, встроенный кеш в setup-действиях) и артефакты (actions/upload-artifact) ускоряют сборки и передают файлы между заданиями.

Отладка локально возможна утилитой act, которая запускает workflow в Docker; статус и логи удобно смотреть через gh run list и gh run watch.

Ограничения

Облачные раннеры ограничены по времени задания (6 часов) и бесплатным минутам для приватных репозиториев; минуты macOS и Windows тарифицируются дороже Linux. YAML-логика с выражениями быстро становится трудночитаемой, а процесс жёстко привязан к GitHub — переезд на GitLab CI или другую систему требует переписывания.

См. также

Источники

  1. GitHub Docs — GitHub Actions
  2. GitHub Docs — Workflow syntax for GitHub Actions
  3. GitHub Docs — Events that trigger workflows
  4. GitHub Docs — Security hardening for GitHub Actions
  5. GitHub Docs — About security hardening with OpenID Connect
  6. GitHub Blog — GitHub Actions now supports CI/CD, free for public repositories (2019)
  7. CISA — Supply chain compromise of tj-actions/changed-files (CVE-2025-30066)
Категории: