GG
и ты упираешься в типичную проблему зависимостей
Size: a a a
2020 September 07
GG
что-то поменял в бутстрап скрипте и у разрабов весь пайплайн упал
GG
хотя в целом идея ок
4
моя нирвана: все проекты конфигурируются тянуть bootstrap gitlab-ci.yml из внешнего хранилища по http, тот берет переменные окружения вроде имени проекта, ветки и проч и вызывает центральный open policy agent (OPA) , который генерирует пайплайны. при генерации может создавать временные секреты, брать из инвентори в какие кластеры задеплоить, какие ендпоинты юзать для конкретного окружения в конкретном кластере и проч.
если надо дать разработчикам волю чуток покастомизировать что-то, то bootstrap скрипт может взять какие то куски из репозитория и отправить open policy agent, который их интегрирует куда надо.
Любители тектона и прочих CRD тоже могут быть счастливы - OPA может подсасывать любые ресурсы через bundle api в том числе и из кубов
если надо дать разработчикам волю чуток покастомизировать что-то, то bootstrap скрипт может взять какие то куски из репозитория и отправить open policy agent, который их интегрирует куда надо.
Любители тектона и прочих CRD тоже могут быть счастливы - OPA может подсасывать любые ресурсы через bundle api в том числе и из кубов
непажимаю, везде можно делать шаблонизацию. в чем вау-фактор?
LB
Самый правильный путь, когда разработчики видят все что происходит внутри самой репы и могут это менять.
ага, особенно когда надо поменять как релизим прод и единственная возможность это протестировать, очевдино, это догнать этот комит до релиза. и вот мы уже мержим десяток фиксов и гоняем все пайпланы пока не заработает как надо
GG
ага, особенно когда надо поменять как релизим прод и единственная возможность это протестировать, очевдино, это догнать этот комит до релиза. и вот мы уже мержим десяток фиксов и гоняем все пайпланы пока не заработает как надо
++++ меня тоже от этого стремает
GG
а если мы разбиваем пайплайн на две части, как ты предлагаешь - мы попросту не сможем ретрайнуть пайплайн на старой версии gitlab-ci.yaml (он же генерится динамически)
GG
т.е. я себе вижу идеальнйы вариант как
LB
а если мы разбиваем пайплайн на две части, как ты предлагаешь - мы попросту не сможем ретрайнуть пайплайн на старой версии gitlab-ci.yaml (он же генерится динамически)
ретрайнуть можно, каждый запуск сгенерированного пайплана в хистори есть, ретрай сколько угодно
GG
есть внешнее хранилище пайплайнов. Из них ты можешь пайплайн подцепить к себе в репу. Определенной версии. И он выполняется. В момент инстанцирования пайплайна - у тебя сам пайплайн определенным образом зашивается в метаданные и все ок
GG
ретрайнуть можно, каждый запуск сгенерированного пайплана в хистори есть, ретрай сколько угодно
боюсь, что это не для сгенерированных пайпов, а для статически определенных
GG
есть внешнее хранилище пайплайнов. Из них ты можешь пайплайн подцепить к себе в репу. Определенной версии. И он выполняется. В момент инстанцирования пайплайна - у тебя сам пайплайн определенным образом зашивается в метаданные и все ок
если же тебе это поведение не нравится - ты всегда можешь через гуй выбрать условно новую версию пайпа и прокатать ее на старой версии коммита
LB
боюсь, что это не для сгенерированных пайпов, а для статически определенных
нет, сгененрированные точно так же появляются в истории и каждую их джобу можно повторить
GG
все довольны
GG
вроде как
GG
> каждую их джобу можно повторить
к сожалению - не всегда - мы артефакты чистим - и старые джобы перестают работать, но, да, это проблема сбоку, конечно
к сожалению - не всегда - мы артефакты чистим - и старые джобы перестают работать, но, да, это проблема сбоку, конечно
LB
непажимаю, везде можно делать шаблонизацию. в чем вау-фактор?
мало подставлять значения, нужно генерировать разные шаги в зависимости от ситуации. скажем при деблое в DR кластер не надо проводить миграции, при этом значение пайплан должен знать сам где сейчас основной кластер, а где DR
4
вау* фактор, ифы тоже везде есть
GG
внезапно выясняется, что гитлаб не нужен ) пускай оно само деплоится ))) аргой
LB
вау* фактор, ифы тоже везде есть
не работют ифы когда их много. всё путается и не понятно что конкретно будет запущено, симулятора пайпланов нет :) плюс любой сложный пайплан разработчики не осиливают,надо их централизованно держать и менеджить как-то