Использование Gitlab API | OTUS
💥 Пока ты ждешь — другие качаются!
Мы создали лучшие условия, чтобы ты начал учиться прямо сейчас. Пиши в чат и получи скидку ➞
Написать в чат

Курсы

Программирование
Web-разработчик на Python
-20%
Разработчик Python
-20%
Разработчик на Spring Framework Разработчик Golang
-20%
iOS Разработчик. Продвинутый курс v 2.0.
-20%
PostgreSQL
-20%
Разработчик игр на Unity React.js разработчик Архитектура и шаблоны проектирования Fullstack разработчик JavaScript Android-разработчик. Продвинутый курс Разработчик Java Разработчик Node.js Scala-разработчик Backend-разработка на Kotlin Symfony Framework Framework Laravel Базы данных ReactJS/React Native-разработчик Cloud Solution Architecture CI/CD Интенсив «Оптимизация в Java»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Использование Gitlab API

DevOps_Deep_9.11-5020-b9cd39.png

В продолжение прошлой заметки. Сохранение отчётов в пейджес и использование темплейта для merge request всё-таки не совсем удобно. Ибо нужно разработчику не забывать выбирать темплейт, и если несколько разных веток, то редактировать индексную страницу в пейджес. И тут неожиданно осенило — ведь у Gitlab есть API и там много всего интересного, например, есть редактирование merge request.

Таким образом, финальный пайплайн, который теперь будет запускаться на создание merge request, сформировался в следующую последовательность: - собираем докер образ - проверяем сныком, отчёт в артифакты - образ пушим в харбор - пушим из артифактов отчёт сныка в пэйджес - и редактируем merge request

Демонстрирую финальный стэйдж:

pages:
  stage: pages
  script:
    - mkdir public
    - REPORTS="[Snyk](${CI_PAGES_URL}/snyk_${CI_COMMIT_REF_NAME}.html)<br>[CVE](${CVE_URI})"
    - cp artifacts/snyk.html public/snyk_${CI_COMMIT_REF_NAME}.html
    - curl -X PUT "$MERGE_URI" -H "$GITOKEN" -H "$JSON_CONTENT" --data '{"description":"'$REPORTS'"}'
  tags:
    - harbor
  artifacts:
    paths:
      - public
  only:
    - merge_requests

вот обращение к API для редактирования поля desscription в merge request

curl -X PUT "$MERGE_URI" -H "$GITOKEN" -H "$JSON_CONTENT" --data '{"description":"'$REPORTS'"}'

Поясняю, что в переменных:

  JSON_CONTENT: 'Content-Type: application/json'
  GITOKEN: "PRIVATE-TOKEN:${gitlab_token}"
  MERGE_URI: "https://${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}"

встроенные переменные: - CI_SERVER_HOST - хост вашего гитлаба - CI_PROJECT_ID - ид вашего проекта - CI_MERGE_REQUEST_IID - ид вашего мерж реквеста

переменные в секции settings/ci-cd/variables gitlab_token - предварительно заведённый в гитлабе токен для доступа к API

Отдельная боль и печаль — передача JSON в курле:

    - REPORTS="[Snyk](${CI_PAGES_URL}/snyk_${CI_COMMIT_REF_NAME}.html)<br>[CVE](${CVE_URI})"
    - curl -X PUT "$MERGE_URI" -H "$GITOKEN" -H "$JSON_CONTENT" --data '{"description":"'$REPORTS'"}'

Обратите внимание на кавычки для интеграции переменной $REPORTS в --data, т.к. то, что в --data должно быть в одинарных кавычках. И да, попытки внутри содержимого REPORTS добавить пробелы делало что-то страшное с парсингом, поэтому я заменил пробелы на \<br\>.

Итог

  • разработчик отправляет merge request
  • pipeline запускает проверки кода и образа на уязвимости
  • отчёты по проверкам прописываются ссылками в описании мерж реквеста
  • ревьювер одной кнопкой может их легко открыть и посмотреть содержимое

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться
🎁 Дарим сертификаты на скидку!
Запишитесь на июньскую трансляцию интересного вам дня открытых дверей и получите скидочный сертификат ➞