GitHub Actions: переносимая схема CI

1. Вы учите не GitHub, а границу проверки

Когда новички впервые видят GitHub Actions, часто кажется, что весь CI — это странный YAML с непонятными заклинаниями. Отпустите это. Я показываю не тайный язык GitHub, а переносимую инженерную схему. GitHub Actions взят потому, что Commerce OS живёт в GitHub, — так PR и workflow-файлы ложатся в один репозиторий.

Как только локальный setup и diagnostics из прошлой лекции собраны в воспроизводимый набор артефактов, нужен механизм, который прогонит тот же контракт на удалённом runner’е. Сначала — каркас job (event, runner, permissions, artifacts), а build, smoke и test checks внутри него потом.

Главная мысль лекции проста: вы учитесь не GitHub Actions как бренду, а CI как границе проверки. Синтаксис у каждого провайдера свой, скелет один: событие запускает job, job получает ограниченные credentials, внутри выполняется bounded команда Claude, дальше сохраняются логи и artifacts, а потом решает человек.

flowchart TD
    A[pull_request или другой CI event] --> B[job на runner]
    B --> C[limited credentials]
    C --> D[bounded Claude run]
    D --> E[logs и artifacts]
    E --> F[human review]

Для начинающего разработчика это особенно полезная перспектива. Держите в голове не список ключевых слов YAML, а четыре вопроса: что запускается, с какими правами, что сохраняется как evidence, кто читает результат. YAML и версии action’ов поменяются, поля у другого провайдера будут другими — эти вопросы останутся.

В этом месте полезно сразу мысленно развести CI event и hook event. pull_request — внешнее событие платформы GitHub, оно никак не связано с hook’ами Claude Code, которые вы настраивали раньше внутри локального workflow. Слово «event» здесь обманчиво: разные системы, разные уровни автоматизации.

2. Workflow — это файл, а не магия

Самый полезный способ подружиться с GitHub Actions — перестать смотреть на workflow как на магический объект. Это просто файл в репозитории: живёт в Git, проходит diff review, меняется маленькими шагами, должен быть понятен следующему, кто его откроет.

Наш первый артефакт обычно лежит по пути .github/workflows/pr-check.yml. Минимальный скелет:

# .github/workflows/pr-check.yml
name: PR Check

on:
  pull_request:
    branches: [main]

jobs:
  verify:
    runs-on: ubuntu-latest

Здесь нет ничего мистического. name — имя сценария в интерфейсе GitHub. on — когда запускаться (у нас на pull_request в main). jobs — что делать (пока одна job verify на машине ubuntu-latest).

Если перевести основные слова на человеческий язык, получается вот такая карта:

workflow

event

job

step

runner

artifact

Очень важно понять ещё одну вещь: runner — это чистая временная машина. Не ваш ноутбук, не машина тимлида, не «тот сервер, где всё настроено три года назад». Поэтому reproducible setup из прошлой лекции тут особенно важен: собирается проект только на одном «счастливом» ноутбуке — CI быстро разоблачит эту романтическую легенду.

И да, маленькая шутка из мира YAML: он любит пробелы чуть больше, чем многие люди любят понедельники. Табуляция и случайные отступы — частая причина очень глупых ошибок. Не страшный, просто требует аккуратности: слева ключ, справа значение, вложенность — пробелами.

3. Собираем первый PR-check для Commerce OS

Теперь сделаем наш первый действительно полезный workflow для Commerce OS. В глубину build и test automation сейчас не идём — это отдельный разговор. Задача — каркас CI job, который живёт в PR, получает код, проверяет в чистой среде и оставляет понятный след.

Обычно такой job начинается с checkout, ограничения прав и таймаута:

permissions:
  contents: read
  pull-requests: write   # нужно только если хотим писать комментарий в PR

timeout-minutes: 15

steps:
  - uses: actions/checkout@v4

Здесь сразу несколько важных решений. contents: read — принцип минимальных привилегий: job только читает код и гоняет проверки, лишних прав не давайте. pull-requests: write нужен не всегда — пока вы сохраняете отчёт как artifact, а не пишете комментарий в PR, его можно убрать. Сперва собирать evidence, публиковать автоматически — потом.

15 — тоже не декоративная строчка. Зависла job — runner не должен молотить бесконечно. Особенно с Claude step внутри: сетевые проблемы, странный prompt, подвисший install-step. Таймаут делает pipeline предсказуемым.

Дальше в job обычно идут шаги подготовки окружения и запуска базовых команд проекта. Запомните важный принцип: CI повторяет локальный базовый workflow команды, а не изобретает свои ритуалы. Локально одни команды, а в CI другие — получите два параллельных мира: «локально зелёно» и «в CI красно».

Именно поэтому прошлая лекция про reproducible setup была фундаментом, а не вступлением для красоты. README, package scripts, Gradle команды, compose-конфиги и CI должны смотреть в одну сторону. Разойдутся — и Claude анализирует не код, а последствия человеческой несогласованности. Совсем другой жанр.

4. Bounded Claude run внутри job

Теперь переходим к самому интересному месту лекции. Тут легко соскользнуть в опасную фантазию: «добавим строчку, и CI станет сам умным инженером». Не станет. Claude в CI — тот же bounded run, что вы видели раньше, только теперь внутри job на удалённой машине.

Практически нам нужны две вещи: на runner доступен сам Claude CLI и настроена аутентификация через secret. Способ разный — install-step, готовый image, action-обёртка. Важна не команда, а факт: без CLI и без аутентификации Claude step не существует.

Чтобы bounded run не превратился в магию, вход должен быть явным: job сначала готовит input artifact — diff или log. Claude в CI не «сам понимает PR», он анализирует конкретный файл, который положил рядом предыдущий step.

Минимальный пример шага:

- name: Подготовить diff как входной артефакт
  run: git show --stat --patch --format=medium HEAD > pr.diff

- name: Краткий разбор diff через Claude
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
  run: |
    cat pr.diff | claude -p "Суммируй изменения и выдели 3 риска" > pr-review.md

Этот пример нужно читать правильно. Сначала job выделяет diff в файл, потом bounded run превращает именно этот вход в отчёт. Флаг и prompt заучивать не надо — точный синтаксис non-interactive режима и опций сверяйте через claude --help и документацию той версии, что стоит у вас в CI. Устойчивый навык другой: у шага явный secret, понятная цель и структурированный результат в файле, а не болтовня в stdout о жизни. С логами так же: вместо pr.diff job кладёт рядом ci-failure.log.

Очень полезно сделать ещё один инженерный шаг и не закапывать длинный prompt в YAML. Ведёт команда Workflow Kit как отдельный артефакт — храните текст CI-промпта рядом, файлом под версионным контролем. CI-файл остаётся коротким, а промпт при изменении виден как diff в нормальном markdown-файле, а не внутри строки на полэкрана.

Важно и другое ограничение: Claude step в PR-check по умолчанию работает только на чтение — анализирует diff, суммирует, выделяет риски. Не мечтайте в первом же workflow о pipeline, который сам себя чинит, правит код, пушит коммиты и ещё извиняется перед коллегами. Это не обучение CI, а приглашение хаоса в репозиторий.

И ещё одна тонкая, но очень важная деталь: у bounded run должен быть узкий вход. Не «прочитай весь репозиторий и подумай о прекрасном», а «проанализируй текущий diff» или «разбери конкретный лог падения job». Claude хорош не когда ему дают весь мир, а когда дают правильно вырезанный кусок мира.

5. Логи, артефакты и человеческое решение

Когда job завершилась, у вас остаётся два основных типа evidence. Лог отвечает на «что происходило во время выполнения», артефакт — на «какой файл-результат мы сохранили после».

Записал Claude step отчёт в pr-review.md — сохраните его как artifact:

- name: Сохранить отчёт как артефакт
  uses: actions/upload-artifact@v4
  with:
    name: pr-review
    path: pr-review.md

Теперь этот файл скачивается из интерфейса Actions и спокойно читается — лучше, чем выискивать фразы в длинном логе между setup-step, checkout-step и служебными сообщениями runner. Для человека удобнее markdown, для следующего слоя автоматизации — просите у Claude JSON.

Есть и ещё один психологически важный момент. Зелёная job и даже хороший Claude-отчёт не дают автоматического разрешения на merge. CI даёт evidence, а не снимает ответственность с разработчика. Зелёная галочка коварна: создаёт ощущение, что система уже всё решила за вас. На деле она сказала одно: «Вот результат проверки. Теперь прочитайте и примите решение».

Если вам пока страшно давать workflow право писать комментарии в PR — это нормальный страх. Начните с artifact: спокойнее и для безопасности, и для обучения. Команда привыкнет к формату отчёта и поймёт, что хочет видеть от Claude, — тогда аккуратно двигайтесь к автоматической публикации summary в pull request.

6. Паттерн в GitLab, Jenkins, Bitbucket

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

on:

job

job

step

runner

runner

runner

Поэтому если завтра вы придёте в команду, где не GitHub, а GitLab или Jenkins, вам не придётся учиться с нуля. Вам нужно будет всего лишь перевести знакомые вопросы на новый диалект: что здесь считается event, где задаются permissions или secrets, как сохраняются artifacts, где человек потом читает evidence.

Именно это и есть durable skill. Не «я помню, как выглядел checkout@v4». А «я понимаю, как устроена граница CI: что запускается, с какими правами, что Claude делает внутри job, какой результат остаётся после выполнения и где человек принимает решение». Когда такое понимание появляется, GitHub Actions перестаёт быть набором YAML-файлов и превращается в нормальный инженерный инструмент, который можно спокойно переносить из проекта в проект.

1

Задача

Claude code, 21 уровень, 2 лекция

Недоступна

Быстрый outline существующего workflow через терминал

Быстрый outline существующего workflow через терминал

Открыть

1

Задача

Claude code, 21 уровень, 2 лекция

Недоступна

Минимальный PR-check workflow для backend-проекта

Минимальный PR-check workflow для backend-проекта

Открыть