Если инструмент распространяется как 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
| Критерий | Ручной запуск | GitHub Actions workflow |
|---|---|---|
| Когда происходит | Если кто-то не забыл | На каждый PR автоматически |
| Где виден результат | В терминале | В обсуждении PR |
| Требования к правам | Локальный токен или ключ | GITHUB_TOKEN из Actions |
| Барьер для команды | Нужно уметь запускать CLI | Достаточно открыть комментарий |
Вывод
Такой workflow снимает самый скучный и легко забываемый шаг в работе с CLI-инструментом. Если инструмент умеет отдавать JSON, его почти всегда можно завязать на GitHub Actions. Получается, что проверка становится триггером, а не одолжением. Это один из тех случаев, когда немного автоматизации делает инструмент заметно удобнее.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.