Я только что понял, что файл .yaml для CI — самая ненавистная область написания. Почему? Потому что вы не можете это проверить. Вы увидите, работает ли он в первый раз, когда запустите его (в своем CI!). Типов нет. Переменные CI и bash взаимосвязаны. Некоторые переменные устанавливаются CI, некоторые происходят из секретов, некоторые создаются сценарием CI.

Это ад, чтобы написать и поддержать. Любые «программистские» уловки внутри CI (повторное использование кода, общие блоки и т. д.) ухудшают ситуацию .

Чем больше CI-файл вы трогаете, чем лучше он оптимизирован, тем глубже ваш личный ад.

Нет, нет, нет.

CI-файл выглядит как yamlsembler. Ассемблер на Ямле. Валовой!

Как программисты могут создавать мегабайты громоздкого машинного кода, даже не читая его?

Компиляция!

Итак, идея: генерация.

Как только вы начнете замечать повторения в своих yaml-файлах, вместо того, чтобы писать их как «причудливые» &anchors, extends: или что-то в этом роде, просто переключитесь на генерацию кода. Ваши ямлы линейны и тривиальны для чтения. Никаких оптимизаций, никакой компактификации.

Генерируется фактическая конфигурация CI (эти «повторяющиеся части»). Они генерируются из шаблонов и параметров. Шаблон содержит повторяющуюся часть, параметры находятся в отдельном файле.

Затем вы создаете свой yaml CI и перекидываете его в git вместе с шаблонами и параметрами в одном коммите. Да, вы храните двоичный артефакт (файл CI) в git, но для этого есть особая причина, ваш CI выполняет его прямо оттуда.

Я попробовал этот подход и понял, что никогда не захочу вернуться к «умным трюкам CI».

Держите сценарий CI длинным, тупым и сгенерируйте его. (И нет, я не предлагаю какой-то конкретный инструмент. Найдите или напишите его).