GitLab: Основы написания Pipeline 1/3

[Setplus]

Думаю, стоит в статье указать, что финальный конфиг .gitlab-ci.yaml будет работать без tags, в случае если на стороне раннеров будет указано, что они могут запускать нетегированные джобы (включенный флаг `Run untagged jobs`).

[proDream]

До раннеров ещё не дошли, но за замечание спасибо, добавлю!

[windymindy]

Из-за этого попытки «сделать как в 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/
Пока сыровато, ломающие изменения еще проскакивают.
Но для меня уже сильно удобнее чем шаблоны и компоненты.

[proDream]

Не видел такого применения, по сути это аналог Actions. Взял на заметку, спасибо!

[Allenhorst]

Файл должен называться строго .gitlab-ci.yml и находиться в корне репозитория.

Как будто бы уже довольно давно и название не обязательно такое, и лежать файл может во вложенных папках или вообще в другом проекте - https://docs.gitlab.com/ci/pipelines/settings/#specify-a-custom-cicd-configuration-file. Ключевым отличием будет то, что если файл конфигурации находится вне репозитория, то pipeline editor будет недоступен.
Про него кстати в этом части не заметил упоминаний, хотя он позволяет валидировать конфигурацию и избегать многих синтаксических ошибок. Ну и дает больше представления о происходящем при использовании инклюдов, особенно для компонентов, которые имеют inputs, и нужно соблюдать нейминг.

[proDream]

В следующий части будет продолжение про конфиг, т.к. тут ещё далеко не всё. Про название файла, действительно, можно переопределить, но это скорее для исключительных случаев и делается в настройках репозитория, для большинства же случаев в статье текст корректен.