AK
в файле храни
тоже получается "прибивание гвоздями к ветке".
думал насчет отдельной репы под таски ci. из плюсов - там можно хоть ансиблом все окостылись с другой мне почему-то этот вариант тоже несильно нравится.
Size: a a a
2021 May 20
AK
любой вариант будет прибивание гвоздями в твоём случае. Но в случае развесистых конфигов их надо хранить в структурированном файле, а через env vars передавать только секреты и имя файла или имя секции в фйле
AK
это нормальная практика
AK
я к сожалению понимаю что все будет костылями. но теплится надежда что есть более прямой путь просто я его не вижу.
AK
в курсе. но вот с реализацией проблема.
все варианты которые пришли мне в голову с той или иной стороны мне не нравятся.
все варианты которые пришли мне в голову с той или иной стороны мне не нравятся.
AK
пока более склоняюсь к варианту отдельной репы с кодом деплоя которую подтягивать в процессе.
при том что реп с однотипным деплоем несколько это в том числе позволит универсализировать его и в случае необходимости правок инвентарей делать их в одном месте.
и вот тут уже просится тот же ансибл для более структурированой работы с конфигами.
при том что реп с однотипным деплоем несколько это в том числе позволит универсализировать его и в случае необходимости правок инвентарей делать их в одном месте.
и вот тут уже просится тот же ансибл для более структурированой работы с конфигами.
AK
> пока более склоняюсь к варианту отдельной репы с кодом деплоя которую подтягивать в процессе.
чем
чем
git clone deploy-config.repo будет отличаться от cd deploy-config?AK
ты добавляешь лишний слой абстракции, совершенно не выигрывая в гибкости и универсальности
AK
начни с файлов - если это вдруг окажется неудобным, то потом это можно будет вынести
AK
у меня схожие проблемы в решении: сначала долго думаю, как сделать идеально, потом уже времени остаётся мало и делаю "как быстрее". А можно же сразу делать "как быстрее" а потом улучшать
AK
корректной работой с разными ветками которых тоже к сожалению много как и разработчиков.
т.е. при изменениях в инвентаре не придется пинать кучу разработчиков чтобы они подпулились - базовый код в том же репозитории не трогается.
так же решается вопрос с одновременной консистентной правкой кучи репозиториев
т.е. при изменениях в инвентаре не придется пинать кучу разработчиков чтобы они подпулились - базовый код в том же репозитории не трогается.
так же решается вопрос с одновременной консистентной правкой кучи репозиториев
AK
потому что даже когда придумаешь "идеальный" вариант и начинаешь его реализовывать, вылезают всякие неожиданности, которые упустил. А если сразу делать простое решение, то все эти неожиданности раньше вылезают
AK
в моем случае к сожалению окажется. разработчиков много и большей части им не интересно "что там девопсы придумали" у них есть код "но CI не работает"
AK
> т.е. при изменениях в инвентаре не придется пинать кучу разработчиков чтобы они подпулились - базовый код в том же репозитории не трогается.
я сделал проще: любой билд на ветке, который не засинкан с мастером (merge/rebase) - падает с ошибкой
я сделал проще: любой билд на ветке, который не засинкан с мастером (merge/rebase) - падает с ошибкой
AK
большими буквами "СДЕЛАЙ git fetch && git merge origin/master"
AK
в курсе. 😊
простое решение есть. грабли собраны. есть понимание что развивать текущий вариант приведет только к лавинообразному увеличению трудозатрат на саппорт.
простое решение есть. грабли собраны. есть понимание что развивать текущий вариант приведет только к лавинообразному увеличению трудозатрат на саппорт.
AK
хороший вариант. возможно имеет смысл внедрить даже отдельно от моих задач. но это нужно организационно продавить в команду разработки. спасибо. интересная идея.
AK
на всякий случай оставлю здесь
```
```
```
if [[ ${BUILDKITE_PULL_REQUEST} != "false" ]]; then
git fetch origin ${BUILDKITE_PULL_REQUEST_BASE_BRANCH}
if ! git merge-base --is-ancestor origin/${BUILDKITE_PULL_REQUEST_BASE_BRANCH} HEAD; then
buildkite-agent annotate --style error "PR ${BUILDKITE_PULL_REQUEST} is out-of-date"
exit 1
fi
fi```
AK
о! спасибо!