Артефакты и логи CI: что хранить, а что нельзя класть в S3 как есть

CI-артефакты помогают расследовать падения: report.html, junit.xml, screenshots, coverage, crash dumps. Но если складывать всё в S3 «как есть», артефакты быстро превращаются в архив секретов и персональных данных.

Эта статья для команд, которые уже сохраняют artifacts, но ещё не формализовали retention, доступы и очистку.

Коротко: лог vs артефакт

Лог — текст выполнения job. Артефакт — файл, который job сохраняет после завершения: отчёт, архив, дамп, скриншот. Артефакт живёт дольше лога и часто доступен шире, поэтому риск выше.

Что можно хранить

junit/xml отчёты без payload'ов;
coverage summary;
build metadata;
sanitized screenshots;
короткие failure snippets;
SBOM и dependency reports без секретов.

Что нельзя класть как есть

.env, kubeconfig, .npmrc, .pypirc;
database dumps;
full request/response payloads;
screenshots с пользовательскими данными;
debug archives;
Docker config и cloud credentials;
raw logs с токенами.

Retention и доступы

Спросите для каждого типа артефакта:

кому он нужен;
сколько дней он нужен;
можно ли его пересоздать;
содержит ли он PII или секреты;
нужен ли публичный URL.

Для многих CI-отчётов достаточно 7–14 дней. Для compliance-артефактов нужны другие правила, но они должны проходить отдельную очистку.

Где тут Exlogare

Для RCA обычно не нужен весь bucket артефактов. Достаточно короткого sanitized failure context: последние строки лога, exit code, job name и ссылка на pipeline. Exlogare анализирует этот контекст и возвращает объяснение в MR/PR. Начать можно с generic ingest, а общие принципы — в Security.

Чеклист

Для каждого artifact type есть retention.
Raw dumps не публикуются автоматически.
PII и секреты редактируются.
Доступ к bucket ограничен.
Публичные ссылки отключены по умолчанию.
В RCA отправляется короткий sanitized context, а не весь архив.