1. uv install
2. uv run -m gitlab_stats.main \ --gitlab-url "https://gitlab.ozon.ru" \ --token "18Mby_Lwuuyz8YWmHcTk" \ --group "pd" \ --since "2025-04-01" \ --until "2025-10-06" \ --users "mdurbazhev,dnarivonchik,durakov,iliaantonov,bzakaraya,skantay,vbogomolskiy,vkhibin,ryarantsev" \ --csv-out "./out_summary.csv" \ --mr-details-out "./out_mr_details.csv"

или

python -m gitlab_stats.main --gitlab-url "https://gitlab..." --token "..." --group "..." --since "2025-01-01" --users-file ./users.txt

Пояснения и ограничения (честно и прозрачно)

Пуши — считаю через Events API (action=pushed). Events API возвращает события pushed и удобен для подсчёта пушей по пользователям, но поведение/поля событий (напр. наличие author_username/author_email) зависит от версии GitLab и настроек хранения истории событий. Поэтому в реальном окружении могут потребоваться небольшие корректировки (например, по имени/емейлу). Документация Events API — полезный референс. Документация GitLab

Атрибуция failed jobs — делается так: берем pipeline со статусом failed, получаем его sha, затем pull commit по sha и атрибутируем количество failed jobs этому commit author. Это даёт корректную привязку ошибок CI к автору коммита, который их запустил. Если commit не доступен (редко), то fallback — атрибуция к пользователю, который запускал pipeline (pipeline.user.username). См. Pipelines и Jobs API. Документация GitLab +1

Пагинация — реализована универсально (per_page=100, читаем X-Total-Pages), поэтому скрипт корректно работает на больших группах. См. Projects API и пагинацию. Документация GitLab

Точность атрибуции пользователей — мы ищем по совпадению username, email или вхождению имени в поля ответа. Если хочешь строгую привязку (например, по user_id в GitLab), можно расширить скрипт: заранее резолвить всех пользователей через /users?username=... и работать с id. Я могу добавить это по запросу.

Производительность — предусмотрена параллельная обработка проектов (параметр --concurrency). Если у тебя очень большой топ (сотни проектов) — увеличь concurrency аккуратно.

Сроки хранения Events — на self-hosted инстансе retention policy может удалять старые события; если нужно гарантированно собрать данные за длительный период, лучше полагаться на commits/pipelines + audit logs (если нужен админ-доступ). Документация упоминает лимиты хранения событий. Документация GitLab

Ограничения и рекомендации

Поля MR: разные версии GitLab могут отдавать reviewers, assignees, merged_at в разном виде. Если что-то не считается — пришли пример JSON ответа MR (я быстро подправлю).

Точность атрибуции ревьюверов: я считаю assignees и reviewers как ревьюверов; если у вас используется approvals endpoint (reviewers отдельно) — можно добавить GET /projects/:id/merge_requests/:iid/approvals.

Events retention: на self-hosted инстансе старые events могут быть удалены; в таком случае пуши за очень старый период будут недоступны — fallback: считать пуши через commits (меньше деталей).

Производительность: для большой группы с сотнями репозиториев/тысячами MR увеличь --concurrency и убедись, что GitLab выдержит нагрузку (rate limits). Можно добавить exponential backoff/retries — могу дописать.

Точность времени до первого ревью: считаю первый нон-системный note, автором которого не является автор MR. Это практичная метрика; если нужно учитывать только review-type notes (файловые/inline comments), можно фильтровать по note['type'] или по формату position в note (в зависимости от версии GitLab).