Skip to content
Exlogare
Exlogare / Документация

Статус-чеки (Check Run / Build Status)

Exlogare публикует статус-чек у упавшего коммита на GitHub и Bitbucket с прямой ссылкой на разбор. Срабатывает дополнительно к каскаду комментариев.

Когда CI-пайплайн падает и Exlogare запускает AI-анализ корневой причины, мы публикуем в репозиторий два разных артефакта:

  1. Комментарий (привычный каскад: PR/MR-комментарий → комментарий к коммиту → Issue) с полным разбором.
  2. Статус-чек (эта страница) — одну зелёную/красную метку у упавшего коммита с однострочным описанием, которая ведёт к разбору в дашборде Exlogare.

Комментарий — это богатая стабильная поверхность. Статус-чек — сигнал «с одного взгляда», который разработчик видит в шапке PR без необходимости листать треды.

На каких поверхностях он показывается

ПровайдерAPI-эндпоинтГде это видит разработчик
GitHub.com / GHEPOST /repos/{owner}/{repo}/check-runs (REST)Вкладка Checks в PR, виджет required checks, страница коммита
Bitbucket CloudPOST /2.0/repositories/{ws}/{slug}/commit/{sha}/statuses/buildВиджет build statuses у коммита, шапка PR
Bitbucket DCPOST /rest/build-status/1.0/commits/{sha}Виджет build statuses у коммита, шапка PR
GitLabВ текущем релизе не включён. Полный RCA по-прежнему публикуется в виде MR-комментария.—

Ключ на Bitbucket и имя на GitHub равны exlogare/rca. Повторная публикация для того же коммита обновляет существующую запись, а не плодит дубликаты — так перезапуск пайплайна не засоряет страницу коммита.

Что попадает в запись

  • Заголовок: Exlogare RCA - <SEVERITY> severity (например, Exlogare RCA - HIGH severity).
  • Описание / summary: первая строка root_cause от AI, на Bitbucket обрезается до 140 символов. На GitHub в output.summary уходит развёрнутый текст: корневая причина + предложение по фиксу + хинт о недостающем контексте.
  • State / conclusion:
    • GitHub: failure для severity high, action_required для medium, neutral для low. Мы не утверждаем, что CI «упал» нашей записью (он и так упал) — мы показываем именно ту корзину серьёзности, в которую анализ отнёс инцидент.
    • Bitbucket: FAILED для severity high, STOPPED для остальных уровней. Bitbucket принимает только закрытый набор состояний, поэтому такая раскладка — самая близкая, не искажая статус самого билда.
  • URL / details_url: ведёт на /dashboard/analyses/<id> — один клик, и разработчик уже на полном разборе.

Как включить / выключить

Статус-чеки включены по умолчанию на всех тарифах. Отключить можно на двух уровнях:

  1. Командный kill switch. Settings → Feedback channels → «Статус-чек коммита». Выключение отключает канал для всех проектов внутри тенанта.
  2. Per-connection override. Integrations → (проект) → Feedback channels → «Статус-чек у коммита». Удобно, если нужно оставить комментарии на «шумном» monorepo, но не плодить лишние чеки в merge UI.

Эти два уровня объединяются по AND: per-connection включение не может перезаписать командный kill switch. Логика идентична каскаду комментариев.

Требуемые права

  • GitHub: токен подключения (App или PAT) должен иметь scope checks:write. У OAuth-токенов, выданных нашим стандартным приложением, он уже есть. Если ваша организация установила приложение с урезанными скоупами, GitHub вернёт 403 Forbidden, и статус-чек молча пропустится — каскад комментариев продолжит работу.
  • Bitbucket Cloud: OAuth-скоупы нашего приложения (pipeline, repository, pullrequest) уже разрешают писать build statuses. Дополнительных действий не нужно.
  • Bitbucket DC: Personal Access Token подключения должен иметь REPO_WRITE на репозиторий. Эндпоинт /rest/build-status/1.0/commits/{sha} доступен в поддерживаемых версиях DC по умолчанию.

Поведение при ошибках

Статус-чек публикуется fire-and-forget: HTTP-ошибка при отправке логируется, но не останавливает каскад комментариев. На практике вы увидите такое, если:

  • У токена пропал checks:write (GitHub).
  • SHA коммита ещё не известен хосту (редко; бывает, когда наш вебхук обогнал push).
  • Канал выключен на уровне команды или подключения.

Audit log записывает и ref комментария, и ref статус-чека под meta.status_check при каждой успешной публикации — по нему можно посмотреть, что куда легло.

Пример: что мы отправляем

GitHub Check Run:

{
  "name": "exlogare/rca",
  "head_sha": "<sha>",
  "status": "completed",
  "conclusion": "failure",
  "details_url": "https://app.exlogare.net/dashboard/analyses/<id>",
  "output": {
    "title": "Exlogare RCA - HIGH severity",
    "summary": "**Root cause:** ConnectionError to pypi.org\n\n**Fix suggestion:** ..."
  }
}

Bitbucket Build Status (Cloud):

{
  "key": "exlogare/rca",
  "state": "FAILED",
  "name": "Exlogare RCA - HIGH severity",
  "description": "ConnectionError to pypi.org during pip install",
  "url": "https://app.exlogare.net/dashboard/analyses/<id>"
}

Смотрите также

  • Кластеры падений — повторяющиеся падения подсвечиваются «×N»-бейджем в комментарии; статус-чек у коммита остаётся одиночным.
  • Outbound webhooks — чтобы прокидывать тот же RCA в PagerDuty / Sentry / собственные системы.
  • GitHub Actions ingest и Bitbucket OAuth — варианты подключения, в которых Exlogare умеет писать статус-чеки обратно в репозиторий.