Pull to refresh

Comments 16

Чукча подслеповатый, можно простить)

годы работы в издательстве и типографии сломали мне мозг. Теперь не могу не замечать такие вещи

В следующем постараюсь исправить.

P.S. Вот у вас "профдеформация", а я со своей подслеповатостью не различаю написанного красным на чёрном, но почему-то многие любят такое делать... Вот где орать хочется)

Эт ладно.... а вот невалидный синтаксис типа

 rules:
    - if: '$CI_COMMIT_BRANCH  "main"'

сквозь всю статью (да, там куча их - статья-то не маленькая!) навевает на печальные мысли, что не человек делал её, а бездушная машина, которая не справилась с пониманием засунутого в неё текста.

Ради чего такой перевод документации? не лучше ли, если каждый страждущий сам засунет буржуйскую статью в переводчик и сделает эти ошибки сам, а не по воле автора?

Призываю всех сюда попавших с целью узнать что-то новое, проследовать в первоисточник!

Писал сам, да с докой и ИИшкой для стилизации/поиска в обнимку, но:

а вот невалидный синтаксис типа

С чего стал невалидным?

Скрин из документации:

С чего стал невалидным?

ну, мусье, вы сами цитируе доку скриншотом и не в состоянии сопоставить с моей цитатой? Ну, кхе... Пожалуйста, внимательнее, ведь метка "туториал" стоит. Кто-то будет пытаться учиться по этому, кхм, "учебнику"...

Это ошибка при экспорте из обсидиан, не обратил внимания. Поправлю.

«Сообщить об ошибке» - не, не слышал.

Основываясь на не лестной статистике, писать в каменты гораздо выгоднее. Личка у меня просто завалена ответами "спасибо, исправлю" и ноль эмоций даже спустя месяцы после моего сигнала.

Ну, и если уж вахтёрить, то по полной ведь? Идите, скажите первому комментатору про ваше ненаглядное "сообщить об ошибке" 😜

Я не такой душный )))) Надо будет, первый комментатор сам прочтет )))))

Так в названии статьи ж указано 2/3 :)

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

а можно в variables значение переменной сделать динамическим от значения другой переменной?
вроде такого
START=start
RESULT=${START}_me
?

Да, такое будет работать, но как мне кажется, генерировать динамические переменные лучше в before_script, но можно и в основном блоке variables

Немного дополнений, возможно кому-то окажутся полезными:

  • Из 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, который будет запущен независимо.

Sign up to leave a comment.

Articles