Comments 13
Думаю, стоит в статье указать, что финальный конфиг .gitlab-ci.yaml будет работать без tags, в случае если на стороне раннеров будет указано, что они могут запускать нетегированные джобы (включенный флаг `Run untagged jobs`).
Из-за этого попытки «сделать как в GitHub Actions» часто приводят к путанице и ошибкам.
Я перевел свои pipeline-ы на новый примитив: Gitlab CI/CD Functions (ранее назывались Steps).
Это переиспользуемые функции, с явно определенными входными и выходными параметрами без проброса всех векретов и переменных.
https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/gitlab_steps/
https://docs.gitlab.com/ci/steps/
Пока сыровато, ломающие изменения еще проскакивают.
Но для меня уже сильно удобнее чем шаблоны и компоненты.
Файл должен называться строго
.gitlab-ci.ymlи находиться в корне репозитория.
Как будто бы уже довольно давно и название не обязательно такое, и лежать файл может во вложенных папках или вообще в другом проекте - https://docs.gitlab.com/ci/pipelines/settings/#specify-a-custom-cicd-configuration-file. Ключевым отличием будет то, что если файл конфигурации находится вне репозитория, то pipeline editor будет недоступен.
Про него кстати в этом части не заметил упоминаний, хотя он позволяет валидировать конфигурацию и избегать многих синтаксических ошибок. Ну и дает больше представления о происходящем при использовании инклюдов, особенно для компонентов, которые имеют inputs, и нужно соблюдать нейминг.
Спасибо за толковую статью! 🤝
"Но есть нюанс..." (с) :
уважаемый Автор - кагбэ не очень явно, но всё-таки - восхваляет GitLab относительно GitHub'а
Не умаляя достоинств, кмк, стОит прямо упомянуть, что с GitLab'ом вы ВСЕГДА должны заморачиваться на СВОЮ инфраструктуру для запуска Runner'ов - тогда как на GitHub'е (благодаря runs-on, упомянутым в статье) многие (большинство?) разрабатывающие на Python, JavaScript (иже с ними), тестирующие SonarQube'ом и т.п., формирующие отчёты Allure'ом - и т.д., и т.д., и т.д. —
МОГУТ ПОЛНОСТЬЮ ПЕРЕЛОЖИТЬ ЭТОТ ГОЛОВНЯК НА ИНФРАСТРУКТУРУ GitHub !
(да, это может стоить денег, но во-первых, там достаточно хорошие лимиты, а во-вторых, сравните со стоимостью содержания своего)
Да, к сожалению, для некоторых стеков эта "радость" не прокатит полностью - например, для 1С (Платформа, Лицензии и вот это вот всё) - но всё же...
До более подробного описания раннеров ещё не дошли, и эта статья не превозносит гитлаб над гитхабом, она в первую очередь как шпаргалка для тех, кто переходит по той или иной причине. Про гитхаб у меня есть статья, упомянутая в самом начале, а сам я вообще использую Gitea, чем полностью доволен.
Автор упомянул прямо в начале статьи про GitLab, развёрнутый на собственных серверах. И в этой ситуации можно ранеров наклепать каких душе угодно. А еще есть встроенные instance-ранеры.
А как всё это хозяйство дебажить?
GitLab: Основы написания Pipeline 1/3