Свой бадж в GitLab

Маленькие, прикольные штуки, отображающие концентрированную информацию, которые можно использовать в любом месте, где можно вставить картинку.

Если говорить о GitLab, то он предоставляет два баджа по умолчанию Pipeline status и Test coverage.

Первый — глупый, который просто показывает статус последнего выполненного пайплайна. Второй — хитрый, показывает процент покрытого тестами кода.

Откуда берутся баджи?

Для полного понимания как они генерируются, рассмотрим пару примеров. Каждый бадж может существовать только в контексте определённого пути, в котором хранятся важные параметры и генерируемые данные.

Для вышеперечисленных двух баджей нам предоставляется адрес и данные GitLab'ом. Для вычисления данных, на основе которых будет создан бадж Test coverage, GitLab'у нужна регулярка.

Простой пример с pipeline status

Он имеет путь:

https://gitlab.com/<group>/<project>/badges/<branch>/pipeline.svg

Здесь важный параметр — это <branch>. Так GitLab понимает, для какой ветки искать последний pipeline.

Дальше дело техники: по окончанию каждого пайплайна, относящегося к указанной ветке, GitLab берёт его статус и генерирует соответствующий бадж. Имя этого баджа — pipeline — изменить нельзя.

Пример Test coverage

Этот интересней — он имеет больше динамики и контроля. Может быть доступен по пути:

https://gitlab.com/<group>/<project>/badges/<branch>/coverage.svg?job=<job>

Снова этот параметр <branch>, определяющий пайплайн, на который GitLab будет реагировать. Ещё там есть job, так как в каждом пайплайне обычно несколько джобов.

Адрес иконки готов. Для генерации баджа нужен процент. Он вычисляется на основе:

• регулярки для поиска значения, которая указывается в настройках проекта по адресу https://gitlab.com/<group>/<project>/-/settings/ci_cd в секции Test coverage parsing;
• логов — тех самых, которые генерирует GitLab при выполнении CI. Именно к ним будет применяться регулярка. Найденный процент покрытия будет отображаться в самих job'ах и соответствующих merge request'ах (если есть).

Итак, параметр job в конце адреса важен, чтобы найти правильные логи (к которым применяется регулярка), т.к. у каждого job'а они свои.

Свой бадж

Чтобы создать свой бадж, нам надо:

• добавить его на отображение в проекте;
• загрузить его куда-то;
• сгенерировать SVG-иконку.

Для генерации баджа можно использовать питоновское колесо anybadge. Загружать будем в GitLab'овские артефакты. А отображение уже настраивали выше.

1. Чтобы сгенерировать бадж, добавим CI job в .gitlab-ci.yml:

   Badge:
     stage: build
     image: python:3.6
     before_script:
       - echo "Python other dependencies installation"
       - pip install anybadge
     script:
       - anybadge -l "Last Commit" -v "$(date '+%d.%m.%Y %H:%M')" -f last-commit.svg -c green
     artifacts:
       paths:
         - last-commit.svg
       when: always
       expire_in: 4 weeks

2. Мы уже указали секцию artifacts в описании выше. GitLab автоматически загрузит бадж в своё хранилище. Время хранения артефактов можно поставить любое.
   
3. В настройках проекта по адресу https://gitlab.com/<project_path>/edit добавляем новый бадж:

   https://gitlab.com/%{project_path}/-/jobs/artifacts/<branch>/raw/last-commit.svg?job=Badge

   <branch> меняем на свой бранч.

Так можно вывести любую статистическую информацию по проекту и не только. У GitLab есть мощное API, которое расширяет границы статистики для баджей:

• Длинна проекта в попугаях и любая другая безумная метрика
• Количество коммитов / веток / тегов
• Количество мемберов
• Дата последнего деплоя на прод
• Последний коммитер
• Количество пайплайнов / merge request'ов / задач
• Количество разработчиков, коммитивших последний месяц