Как связать cxgrd с GitHub Actions и получать отчёт о рисках в каждом PR

Если инструмент распространяется как CLI, его внедрение упирается в дисциплину. Люди забудут, пропустят, отложат. И именно эту проблему решает GitHub Actions workflow, который автор cxgrd собрал для своего инструмента. Проверка зависимостей и анализ радиуса поражения изменений теперь запускаются автоматически на каждый pull request, а результат приходит в комментарий к PR.

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

Workflow выглядит как конвейер из четырёх шагов:

• Устанавливаются зависимости проекта и сам cxgrd.
• Запускается cxgrd scan — сканирование каталога проекта.
• Команда cxgrd check выполняет blast radius анализ и компиляторные проверки.
• Результат — уровень риска, затронутые файлы, типы изменений — публикуется в комментарий к pull request.

Причём комментарий не плодится на каждый прогон. Если PR уже получил один отчёт, а потом в него прилетел новый коммит, этот же комментарий обновляется. Не нужно искать новые сообщения в куче — всё актуально в одном месте.

Как это устроено технически

Внутри cxgrd уже был BlastRadiusAnalyzer, который отправлял результаты проверок в БД и на командный дашборд. Но для CI-комментария нужен машиночитаемый формат, поэтому к check добавили флаг --json. Дальше осталось написать небольшой скрипт, который читает JSON и собирает текст отчёта.

Интересная деталь: для отправки комментария не нужен отдельный токен с правами на репозиторий. GitHub Actions сам инжектит GITHUB_TOKEN в каждый прогон. Он ограничен текущим репозиторием и может писать комментарии, если указано permissions: pull-requests: write. Сам скрипт выполняется через actions/github-script@v7 — там уже есть доступ к API GitHub через github.rest, и комментарий создаётся вызовом issues.createComment. Номер PR берётся из context.issue.number, потому что GitHub видит pull request как issue.

На что обратить внимание

Повторить этот подход просто, но есть пара граблей:

• Не забудьте флаг --json. Без него скрипт не получит структурированный результат.
• Проверьте permissions. Если забыть pull-requests: write, токен не сможет оставить комментарий.
• Обновляйте комментарий, а не создавайте новый. Иначе после серии коммитов в PR будет свалка из отчётов.
• Номер PR не нужно хардкодить — он доступен в контексте действия.

Сравнение: ручной запуск vs workflow в Actions

Вывод

Такой workflow снимает самый скучный и легко забываемый шаг в работе с CLI-инструментом. Если инструмент умеет отдавать JSON, его почти всегда можно завязать на GitHub Actions. Получается, что проверка становится триггером, а не одолжением. Это один из тех случаев, когда немного автоматизации делает инструмент заметно удобнее.