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

В продолжение прошлой заметки. Сохранение отчётов в пейджес и использование темплейта для 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 запускает проверки кода и образа на уязвимости
• отчёты по проверкам прописываются ссылками в описании мерж реквеста
• ревьювер одной кнопкой может их легко открыть и посмотреть содержимое