Свой бадж в GitLab

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

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

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

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

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

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

Он имеет путь https://gitlab.com/<namespace>/<project>/badges/<branch>/pipeline.svg. Здесь важный параметр - это <branch>. Так GitLab понимает для какой ветки искать последний pipline.

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

Стало немного понятней? Го дальше.

Пример Test coverage

Этот интересней - он имеет больше динамики и контроля. Может быть доступен по пути https://gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?job=<job>. Снова этот параметр <branch>, который определяет пайплайн, на который GitLab будет реагировать. Ещё там есть <job>, так как в каждом пайплане обычно несколько джобов.

Почему именно такой адрес важен станет понятней чуть позже.

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

• регулярки для поиска значения, которая указывается в настройках своего проекта https://gitlab.com//-/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/<адрес проекта>/edit добавляем новый бадж https://gitlab.com/%{project_path}/-/jobs/artifacts/<branch>/raw/last-commit.svg?job=Badge. <branch> меняем на свой бренч.

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

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