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