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

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

И тут неожиданно осенило - ведь у gitlab есть API и там много всего интересного, например, есть редактирование 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 запускает проверки кода и образа на уязвимости
  • отчеты по проверкам прописываются ссылками в описании мерж реквеста
  • ревьювер одной кнопкой может их легко открыть и посмотреть содержимое
Автор
0 комментариев
Для комментирования необходимо авторизоваться