Обзор API ingest для CI — Документация

Один паттерн для любой CI — отправляйте лог упавшей сборки в Exlogare с API-ключом и получайте RCA в дашборде (а на платных тарифах — в Slack/Telegram/Matrix).

Универсальный API ingest — это способ для CI/CD-системы сказать Exlogare “вот этот ран упал, вот лог — обработай”. Работает с любой платформой: Jenkins, CircleCI, TeamCity, Drone, Woodpecker, GitHub Actions, GitLab CI, Buildkite, AppVeyor, ваша собственная.

Кратко

Создайте API-токен в Settings → API tokens со scope ingest.
Добавьте в CI шаг “при падении”, который curl-ом отправит лог на нужный /api/ingest/* эндпоинт.
Откройте страницу Analyses в дашборде — RCA появится там с бэйджем “via API ingest”.

Если вы хотите не собирать JSON вручную, используйте Exlogare CLI. Он вызывает тот же ingest API:

exl ingest --provider generic --project myorg/web --status failed --log-file build.log

Доступно на Free

API ingest доступен на всех тарифах, включая Free. Лимиты Free:

3 активных API-токена одновременно;
20 анализов на всё время;
доставка только в дашборд (Slack/Telegram/Matrix — со Startup и выше).

Аутентификация

Токен передаётся как Bearer:

curl -H "Authorization: Bearer $EXLOGARE_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{ ... }' \
     https://api.exlogare.net/api/ingest/<provider>

Токен в формате exl_… показывается только один раз при создании. Сразу скопируйте его в свой секрет-менеджер.

В CI CLI читает тот же токен из EXLOGARE_TOKEN, поэтому secret store остаётся прежним:

EXLOGARE_TOKEN=exl_... exl ingest --provider generic --project myorg/web --log-file build.log

Какой эндпоинт выбрать

Эндпоинт	Для чего
`POST /api/ingest/jenkins`	Jenkins (declarative, scripted, freestyle)
`POST /api/ingest/circleci`	CircleCI Cloud или Server
`POST /api/ingest/teamcity`	TeamCity (Cloud или self-hosted)
`POST /api/ingest/drone`	Drone CI / Woodpecker
`POST /api/ingest/log`	Generic — Buildkite, AppVeyor, своя CI, GitHub Actions без OAuth, GitLab CI без OAuth

Каждый эндпоинт принимает JSON-тело с нативными именами полей (workflow id / build id / build number) плюс log упавшего шага.

Лимиты

Размер тела: до 10 МиБ на запрос. Больше — 413.
Rate limit: 60 req/min на тенант по умолчанию. Больше — 429.
Квота: каждый ingest расходует месячную / lifetime квоту. Квота закончилась — 403 с {"status":"quota_exhausted"}.
Идемпотентность: повторные POST’ы с тем же (provider, run_id, job_id) возвращают тот же analysis_id — безопасно ретраить из CI.
Логи не хранятся: тело лога обрабатывается в памяти и сразу выбрасывается. Сохраняется только сгенерированный RCA и метаданные (run id, ветка, коммит, URL).

Ответ

Все ingest-эндпоинты возвращают одну форму:

{ "status": "accepted", "analysis_id": "39af2c01-..." }

Используйте analysis_id чтобы дать пользователю прямую ссылку на /dashboard/analyses/<id>.

А что с подписью webhook?

API-токен является аутентификацией. Дополнительная HMAC-подпись поверх ничего не добавит к модели угроз. Если есть подозрение на утечку — просто отзовите токен и выпустите новый.