вообще, в линуксе есть хитрый разделитель команд, который позволяет при ошибке предпринять действие. идея такая: бекапим файл, изменяем как нам нужно, запускаем рестарт службе, а при ошибке говорим, что  удали исходный файл, положи на его место бекапный и перезапусти службу. у меня было так, но было давно, схема рабочая. можно спасаться от синтаксических ошибках в конфигах

Всем привет тут есть кто использовал Rancher в проде?

привет Егор

да использую в проде, полет нормальный, удобная штука на самом деле.

Дженкинс хуже изнасилований (

почему?

заброшенные косорукие плагины, конструктор собери сам

Потому что ад с плагинами (а без плагинов он ничего не умеет). Потому что DSL вместо внятных коротких конфигов. И этот DSL поощряет охренительный уровень копипасты.

копипасту поощрает как раз yaml. А DSL отлично переиспользуется через shared lib. Там классы, методы, наследование, функции и т.д. Можно следовать принципу DRY. А в yaml максимум -  это якоря и ссылки на них

Плагины  у меня особо пролем не вызвают, поставил и забыл

В ямле ты берешь скрипт и пакуешь его в контейнер. В дженкинсе тоже можно, но этим пренебрегают из-за DSL и оно разрастается бесконечно. Ну и сам DSL заметно массивнее ямлов.
А еще тестируются эти пайплайн-либы просто "шикарно".

не смог в нормальный яп?

Ты про джаву и тесты либ?

в DSL берешь скрипт и пакуешь его в контейнер 🤷

> Ну и сам DSL заметно массивнее ямлов.
Нет

> А еще тестируются эти пайплайн-либы просто "шикарно".
Там unit тесты можно прикрутить. А как ты тестируешь yaml от github actions или gitlab?

Вот эти скрипты отдельно и тестирую. И да, юнит-тесты для пайплайн-либ есть, с моками дженкинсовских потрохов.

Если инструмент разрешает творить лютую дичь, то её будут творить. И я не соглашусь с тем, что "инструмент не виноват, виновата прослойка между ним и креслом". Потому что этими возможностями все равно пользуются.

Не понял тебя.
> И да, юнит-тесты для пайплайн-либ есть, с моками дженкинсовских потрохов.
Это же хорошо =)

> Это же хорошо =)
Но лучше, когда в этом нет нужды. Потому что это очень неудобно.

так этот инстумент и позицианируется как универсальный - буквально можно решить любую задачу. Считай фреймворк. А в gtilab/github actions, любые задачи придется решать своими скриптами на баше/python. Если что-то надо делать с объектами самой CI - то это уже API вызовы, да и то если есть такие методы в api.
А в jenkins для решения задач есть готовые объекты/либы и можно нативно общаться с объектами самого CI.

Не говорю что jenkins лучше, но чем он плох - я не понял. Своей универсальностью и мощностью? Ну и расшираймость пайплайнов и переиспользование как в нормальном ЯП, а не yaml