Можно ли указать в yaml, массив в виде черного/белого списка

и в rules сделать условие по вхождению переменной в этот списко?

например:


.black_list:
- 1
- 34
- 45


.only_black_list:
rules:
- if: $VAR1 == `.black_list`


Чтобы перменная в списке проверялась в цикле

нет

может быть можно как-то через регулярку переменную проверить

Тоже не лаконично выйдет, явно множество if: $var = xxx пропишу генератором (чтобы все if блоки как логическое OR сработали)

так используйте || и будет логическое или

не читаемо будет 1 строкой в отличии от ``` rules: - if: $VAR = 1 - if: $VAR = 4 - when: never ```

а так дублирования много

да, поэтому циклы искал, может есть синтаксис какой-то по типу как в ansible yaml чтение и поддержка кода для меня важнее лаконичности

Лучшее - враг хорошего. Мб лучше несколько раз повторить один и тот же код, чем написать никому непонятную черную магию.

так я за это же, за лаконичность и понятность для чтения, чтбы это легче было поддерживать и разбираться другим ребятам Цикл из 3 строк будет куда проще, чем простыния из нескольких сотен строк

Какую проблему решаете, если не секрет? Имхо такие вещи в принципе не должны появляться на этапе шедулинга джобы

Нужно через черный/белый список job запускать на проектах. Например мы вводим новую job и не запускаем ее на всех старых проектах. Добавляя их в черный список, далее итерационно выкидываем из этого черного списка проекты по мере миграции их под новую job. В итоговой картине, когда-то все раскидаем будет простая job без условий. Это нужно чтобы сверху управлять job в CI множеством проектов.

это оч странная схема как пайп в проекте запускается?

pipe через стандартные тригеры запускается, например на merge_request тригер, но конфигурация беерется из remote git проекта

так берите для нужных проектов код из нужного коммита вашего проекта с ci

зачем так усложнять, и под разыне проекты иметь разные ревизии CI декларации. В таком случае все равно все руками описывать прилется, просто будет несколько сотен ревизий с декларацией CI и еще их нужно в сами репозиториее прорастить внутрь, на нужный ref remote конфига ссылаться, это ад будет

эм. Где усложнение?