когда говорим про variables, я бы сразу добавлял про inputs, гитлаб их активно продвигает как альтернативу variables, объявленных на уровне всего пайплайна. Inputs нельзя менять в ходе выполнения пайплайна, зато у них есть встроенные возможности для валидации, такие как строгое задание доступных значений или типа значения.
В rules:changes, как и во многих других местах, недоступен т.н. negative regex match. Соответственно нельзя написать рул, который будет по regex исключать job, когда изменились только несущественные файлы (например не запускать сборку если изменился только README.MD, но запускать если изменились и существенные и несущественные).
В статье неявно сказано, но я бы отдельно уточнил, что скрипт в before_script будет смержен с основным script, в отличии от after_script, который будет запущен независимо.
Файл должен называться строго .gitlab-ci.yml и находиться в корне репозитория.
Как будто бы уже довольно давно и название не обязательно такое, и лежать файл может во вложенных папках или вообще в другом проекте - https://docs.gitlab.com/ci/pipelines/settings/#specify-a-custom-cicd-configuration-file. Ключевым отличием будет то, что если файл конфигурации находится вне репозитория, то pipeline editor будет недоступен. Про него кстати в этом части не заметил упоминаний, хотя он позволяет валидировать конфигурацию и избегать многих синтаксических ошибок. Ну и дает больше представления о происходящем при использовании инклюдов, особенно для компонентов, которые имеют inputs, и нужно соблюдать нейминг.
Немного дополнений, возможно кому-то окажутся полезными:
Из workflow рулов часто еще бывает полезно не запускать пайплайн на ветке при пуше в нее, если есть MR с этой веткой
когда говорим про variables, я бы сразу добавлял про inputs, гитлаб их активно продвигает как альтернативу variables, объявленных на уровне всего пайплайна. Inputs нельзя менять в ходе выполнения пайплайна, зато у них есть встроенные возможности для валидации, такие как строгое задание доступных значений или типа значения.
В rules:changes, как и во многих других местах, недоступен т.н. negative regex match. Соответственно нельзя написать рул, который будет по regex исключать job, когда изменились только несущественные файлы (например не запускать сборку если изменился только README.MD, но запускать если изменились и существенные и несущественные).
В статье неявно сказано, но я бы отдельно уточнил, что скрипт в before_script будет смержен с основным script, в отличии от after_script, который будет запущен независимо.
Как будто бы уже довольно давно и название не обязательно такое, и лежать файл может во вложенных папках или вообще в другом проекте - https://docs.gitlab.com/ci/pipelines/settings/#specify-a-custom-cicd-configuration-file. Ключевым отличием будет то, что если файл конфигурации находится вне репозитория, то pipeline editor будет недоступен.
Про него кстати в этом части не заметил упоминаний, хотя он позволяет валидировать конфигурацию и избегать многих синтаксических ошибок. Ну и дает больше представления о происходящем при использовании инклюдов, особенно для компонентов, которые имеют inputs, и нужно соблюдать нейминг.