Comments 16

доставляет физический дискомфорт
Чукча подслеповатый, можно простить)
Эт ладно.... а вот невалидный синтаксис типа
rules:
- if: '$CI_COMMIT_BRANCH "main"'
сквозь всю статью (да, там куча их - статья-то не маленькая!) навевает на печальные мысли, что не человек делал её, а бездушная машина, которая не справилась с пониманием засунутого в неё текста.
Ради чего такой перевод документации? не лучше ли, если каждый страждущий сам засунет буржуйскую статью в переводчик и сделает эти ошибки сам, а не по воле автора?
Призываю всех сюда попавших с целью узнать что-то новое, проследовать в первоисточник!
Писал сам, да с докой и ИИшкой для стилизации/поиска в обнимку, но:
а вот невалидный синтаксис типа
С чего стал невалидным?
Скрин из документации:

С чего стал невалидным?
ну, мусье, вы сами цитируе доку скриншотом и не в состоянии сопоставить с моей цитатой? Ну, кхе... Пожалуйста, внимательнее, ведь метка "туториал" стоит. Кто-то будет пытаться учиться по этому, кхм, "учебнику"...
«Сообщить об ошибке» - не, не слышал.
Основываясь на не лестной статистике, писать в каменты гораздо выгоднее. Личка у меня просто завалена ответами "спасибо, исправлю" и ноль эмоций даже спустя месяцы после моего сигнала.
Ну, и если уж вахтёрить, то по полной ведь? Идите, скажите первому комментатору про ваше ненаглядное "сообщить об ошибке" 😜
Так в названии статьи ж указано 2/3 :)
Плановое выполнение - вообще тема) На гитхабе проще все делать, однако, тут больше возможностей, и для большинства проектов (серьезных) и компаний, это как раз самое то. У меня маленький сервак, все мечтаю обзавестись своим (в мечтах))), и поставлю там свой селфхост гитлаб, и все-все))
а можно в variables значение переменной сделать динамическим от значения другой переменной?
вроде такого
START=start
RESULT=${START}_me
?
Немного дополнений, возможно кому-то окажутся полезными:
Из workflow рулов часто еще бывает полезно не запускать пайплайн на ветке при пуше в нее, если есть MR с этой веткой
workflow:
rules:
- if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"'
when: neverкогда говорим про variables, я бы сразу добавлял про inputs, гитлаб их активно продвигает как альтернативу variables, объявленных на уровне всего пайплайна. Inputs нельзя менять в ходе выполнения пайплайна, зато у них есть встроенные возможности для валидации, такие как строгое задание доступных значений или типа значения.
В rules:changes, как и во многих других местах, недоступен т.н. negative regex match. Соответственно нельзя написать рул, который будет по regex исключать job, когда изменились только несущественные файлы (например не запускать сборку если изменился только README.MD, но запускать если изменились и существенные и несущественные).
В статье неявно сказано, но я бы отдельно уточнил, что скрипт в before_script будет смержен с основным script, в отличии от after_script, который будет запущен независимо.
GitLab: Основы написания Pipeline 2/3