Компоненты - это include+. Ничего не мешает юзать компоненты так же, как и темплейты (кроме того, что темплачи в депрекейтед закинули). Как мне кажется, чаще всего параметризуют именно script. До появления компонентов можно было использовать только variables. Они, по сути, управляют поведением скрипта в рантайме - "динамика". И в целом хорошо, но разработчики решили добавить "статику"
Для меня это выглядит так, будто я всегда на JS писал var my_var, а теперь мне дали возможность написать const. Эдакое семантическое улучшение
Можно написать: inputs.message: "Автор коммита: $CI_COMMIT_AUTHOR" Значит сообщение будет разным для разных авторов коммита
А можно: inputs.message: "Автор коммита: компания ООО Тмыв Денег" Значит сообщение будет одинаковым для всех коммитов (в обоих случаях если не переопределять script/variables или где эта штука шаблонизируется)
Итого: компонент - это просто шаблонизатор, который запускается до исполнения скриптов. Он просто вставляет нужный текст в нужные места джобы.
ИМХО: направление развития хорошее, но кажется, что хочется чего-то большего для такого шаблонизатора. Хочу иметь возможность сделать что-то типа include-multiple.inputs_array: [input1, input2, input3]. Чтобы бесконечно не копипастить инклюды или не создавать генераторы .gitlab-ci.yml (как будто если юзать генератор, то и компоненты не нужны). Есть конечно parallel.matrix, но нюанс в том, что там меняются variables, когда хотелось бы менять инпуты. Компоненты - это про контракт создания джобы, а если юзать матрицу, то тебе НУЖНО лезть в реализацию компонента, чтобы понять, какие переменные нужно прокидывать в матрице
По поводу версионирования: темплейты можно версионировать
По поводу тестируемости: для тестирования ничего не добавили с виду - тебе все так же придется писать тесты в виде отдельных джоб или в after_script'е тестируемой джобы например. В целом, я не очень понимаю, что значит тестирование пайплайна, в доках особо ничего интересного не находил. Ради эксперимента пытался проверять компоненты на работоспособность, смотрел что выводят и запускаются ли в принципе в том же CI/CD каталоге. Вот то, что появилась структура каталога, мб интересно: есть разрабатываемый компонент: templates/<name>/template.yml. Рядом, например, можно положить templates/<name>/test.yml - использование компонента по каким-то сценариям и templates/<name>/Dockerfile.test (если например у меня компонент билдит образ). Я сделал так: в рутовом .gitlab-ci.yml добавил инклюд test.yml при определенных условиях. Например, если я релижусь - то я запускаю вообще все тесты. А если я хочу только 1 компонент тестить, то в енвах указываю, какой. Но все равно чувства смешанные
Там переменная v в принципе не нужна, потому что это итератор, возвращающий только 1 значение (по крайней мере я так понял замечание). И, соответственно, yield(i).
Вопрос о читаемости скорее про то, лучше или хуже станет код, когда в нем будут использоваться итераторы. И скорее акцент на "использоваться", нежели на то, как они будут реализованы. Ведь мы хотим написать способ обхода 1 раз, потому что он возможно какой-то сложный, чтобы его потом во многих местах использовать. Вот мы создали итератор, у него есть какое-то имя. По его имени можно будет предположить, что будет происходить, не вчитываясь во внутрянку. Или вчитаться 1 раз, а не каждый раз заново.
Компоненты - это include+. Ничего не мешает юзать компоненты так же, как и темплейты (кроме того, что темплачи в депрекейтед закинули). Как мне кажется, чаще всего параметризуют именно script. До появления компонентов можно было использовать только variables. Они, по сути, управляют поведением скрипта в рантайме - "динамика". И в целом хорошо, но разработчики решили добавить "статику"
Для меня это выглядит так, будто я всегда на JS писал var my_var, а теперь мне дали возможность написать const. Эдакое семантическое улучшение
Можно написать:
inputs.message: "Автор коммита: $CI_COMMIT_AUTHOR"
Значит сообщение будет разным для разных авторов коммита
А можно:
inputs.message: "Автор коммита: компания ООО Тмыв Денег"
Значит сообщение будет одинаковым для всех коммитов
(в обоих случаях если не переопределять script/variables или где эта штука шаблонизируется)
Итого: компонент - это просто шаблонизатор, который запускается до исполнения скриптов. Он просто вставляет нужный текст в нужные места джобы.
ИМХО: направление развития хорошее, но кажется, что хочется чего-то большего для такого шаблонизатора. Хочу иметь возможность сделать что-то типа include-multiple.inputs_array: [input1, input2, input3]. Чтобы бесконечно не копипастить инклюды или не создавать генераторы .gitlab-ci.yml (как будто если юзать генератор, то и компоненты не нужны). Есть конечно parallel.matrix, но нюанс в том, что там меняются variables, когда хотелось бы менять инпуты. Компоненты - это про контракт создания джобы, а если юзать матрицу, то тебе НУЖНО лезть в реализацию компонента, чтобы понять, какие переменные нужно прокидывать в матрице
По поводу версионирования: темплейты можно версионировать
По поводу тестируемости: для тестирования ничего не добавили с виду - тебе все так же придется писать тесты в виде отдельных джоб или в after_script'е тестируемой джобы например.
В целом, я не очень понимаю, что значит тестирование пайплайна, в доках особо ничего интересного не находил. Ради эксперимента пытался проверять компоненты на работоспособность, смотрел что выводят и запускаются ли в принципе в том же CI/CD каталоге. Вот то, что появилась структура каталога, мб интересно: есть разрабатываемый компонент: templates/<name>/template.yml. Рядом, например, можно положить templates/<name>/test.yml - использование компонента по каким-то сценариям и templates/<name>/Dockerfile.test (если например у меня компонент билдит образ).
Я сделал так: в рутовом .gitlab-ci.yml добавил инклюд test.yml при определенных условиях. Например, если я релижусь - то я запускаю вообще все тесты. А если я хочу только 1 компонент тестить, то в енвах указываю, какой. Но все равно чувства смешанные
В первой переменной передаем результат, во второй ошибку. В теле цикла ошибку обрабатываем. Если я правильно понял вопрос.
Там переменная v в принципе не нужна, потому что это итератор, возвращающий только 1 значение (по крайней мере я так понял замечание). И, соответственно,
yield(i).Это разные языки. У них разный синтаксис.
Вопрос о читаемости скорее про то, лучше или хуже станет код, когда в нем будут использоваться итераторы. И скорее акцент на "использоваться", нежели на то, как они будут реализованы. Ведь мы хотим написать способ обхода 1 раз, потому что он возможно какой-то сложный, чтобы его потом во многих местах использовать. Вот мы создали итератор, у него есть какое-то имя. По его имени можно будет предположить, что будет происходить, не вчитываясь во внутрянку. Или вчитаться 1 раз, а не каждый раз заново.