-
Общаемся на темы, посвященныe Jenkins Видео с митапов: http://youtube.com/jenkinsru Место активного общения разработчиков https://gitter.im/jenkinsci-ru/publiс Самые свежие новости https://twitter.com/jenkins_ru
отвечая самому себе— возможно как-то так 🧐
https://www.jvt.me/posts/2021/02/23/getting-started-jobdsl-standardised/
дескать, запилить грувёвый проект, определить в нём def ocherednoyShablonniyPipelin(...) и прочие полезности для переиспользования, в ходе выполнения seed job собрать из этого всего magic.jar с нужными символами, и подпихнуть его в classpath для jobDsl()
и якобы тогда в дслке можно писать не
pipelineJob('build/nightly/arm') {
displayName(...)
cron('H 0 0 * *')
definition { cpsScm { 'jenkins/ci.groovy' } }
...
}ocherednoyShablonniyPipelin('build/nightly/arm')load() разрешить совать внутрь дслки ...
Читать полностью…
Ну ОК. Не чини то что не сломано.
Тут вопрос в том хочешь ли ты сам из любви к прекрасному загнать разрабов в рамки или над тобой висит как-то менеджер.
Если висит менеджер - скорми ему разрабов: "я вот тут сразу да, а они саботируют процесс"
Если бед в чувстве прекрасного, то пора вспомнить что devops, он таки немножко dev и и игнорировать пожелания разработчиков плохо.
Если перевести стоимость хотелки разработчика в человеко-часы на реализацию и на поддержку обычно очень много вопросов снимается.
когда мы только-только экспроприировали сервер с дженкинсом из-под стола у старшего тестировщика, мы там сами лихо всё накликали через freestyle и странные плагины для шаблонизации
потом узнали про пипелины, прониклись, но переделывать было лень
(шёл ~2019 год)
потом с очередной обновкой что-то во фристайле сломалось... 🌚
ясно. весь стандартный набор.
не работает :(
всё упирается в что-то вроде "у нас же всё сейчас работает, зачем нам менять процесс". может быть сказанный другими словами и более красиво.
никогда не думал что я попаду в такую странную ситуацию.
но я всё ж вернусь к своему вопросу.
как людям голову "поменять". но так чтобы мягко и чтобы они от этого не испортились? я вот все эти вот умные слова сам много раз повторяю, а тут как на стену натыкаешься.
так что мой вопрос о том был ли кто в подобном положении и какие слова подобрал чтобы его изменить
всё так
пришлось на днях вылезать из уютного мирка pyproject.toml и курить build.gradle — зато теперь у нас появились хоть какие-то тесты к шаредлибе
когда-нибудь я напишу статейку об этом, чтобы консолидировать в текст опыт предыдущих поколений докладов на ютубе, да...
в общем приходится и python подтягивать, и groovy(а для начала java), а кто то плагины для redmine и т.п. на ruby пишет.
yaml-программированием в devops не обойдешься, упираешься всё равно в то, что не хватает функционала.
как бы gitlab так и взлетел (как и ansible) - потому что там сложно (и ВРЕДНО) погромировать.
Читать полностью…
тогда какой смысл вообще ставить туда Groovy/Jvm ? если скриптами все равно все писать, это неправильный подход
Читать полностью…
о! кстати - а починили ли uno-choice? а то в предыдущей версии его сломали и он так и был сломан месяца три, а щас новая версия вышла, я ещё не пробовал.
Читать полностью…
В том то и проблема, что это и в другую сторону работает.
Хочешь что-нибудь доработать например, что и так работает, но не совсем по лучшим практикам, это упростит жизнь немножко, но руководство посчитает это не окупаемым, "зачем что то улучшать, если и так нормально работает" - железный аргумент, с которым сложно спорить. Потому что всё должно быть окупаемо. Для руководства часто кажется, что это бесполезная работа. А посчитать реальную финансовую выгоду от этого очень сложно. Они видят только то, что ты на это потратишь целых N дней рабочего времени, это дорого, зачем это вообще делать.
На самом деле это прям философская дилемма. Внутренний перфекционист то от этого страдает.
Или иногда возникают идеи, желания что то реализовать, чего до этого никогда не реализовывал, и это кажется классным, внедрить новую систему какую то например, изучить как она работает за одно. Но заниматься автоматизацией ради автоматизации, как и разработкой ради разработки - это удовлетворять свои хотелки, а не потребности компании. Нужно думать о прибыли компании и о клиентах в первую очередь, это будет более профессиональным подходом. Но пытаться что то улучшить всё равно надо постоянно, главное руки не опускать, даже если руководство непробиваемое.
Я уже давно сделал для себя парадоксальный вывод, что чем ограниченнее функционал сервиса, тем лучше этот сервис считается.
И пример дженкинса vs гилаб тут показателен.
Постоянно вспоминаю мемную стриммершу с её "сложна, сложна!!!"
Мне кажется каждый с этим сталкивается. Надо стоять на своем, и аргументировать.
Мне как то тоже выдали "а зачем нам обновлять jenkins"? В новых обновах новые CVE и ошибки будут, давайте жить со старыми, мы к ним привыкли =)
ну и прекрасно, пускай работает на здоровье!
вот как сломается — так и будет повод переписать нахрен 👹
мне наверное везло, но мне не приходилось подбирать каких-то особых слов — в основном хватало стандартных умных
что ночные сборки != континуус интегрейшен
что в континуус интегрейшене ключевые слова — это "непрерывность" и "интегрирование"
долгоиграющие ПР и ветки — это плохо; закоммитил - собралось - смержилось
больше кастомных ручек для покрутить при сборке — больше ифов в коде — меньше покрытие при "стандартном" запуске
чем больше ручек надо крутить каждый раз — тем ленивее это делать
если что-то не запускать полгода — через год оно не запустится
если запускать всё подряд везде и сразу — то сразу покупайте мне пару суперкомпьютеров и второго билд-инженера
а если не пару суперкомпьютеров, а десяток обычно — то ещё и сисадмина на сдачу...
это если что-то нестандартное. если б для jenkins была такая стройная библиотека поддерживаемых модулей - возможно бы я смотрел на Jenkins иначе
Читать полностью…
ну сегодня 10\2, а завтра 10\3 =) когда разберешься. Если с этим работать, то придется разобраться.
Читать полностью…
см пункт выше про 10 vs 2
но да, если есть в штате завалялась пара джавистов — наверное можно и sh "magic.groovy" делать, я честно ни разу не пробовал 🧐
ну, на агенты ставить jvm стоит хотя бы ради запускания agent.jar...
"туда" — куда?
так-то даже облачные пчёлы, мейнтейнящие дженкинс, периодически жужжат на тему "не пишите заумные пипелины, не выполняйте сложный код на мастере, не программируйте на груви, выполняйте полезную нагрузку на агентах"
да для ансибла тоже приходится модули писать, как и для jenkins плагины
Читать полностью…
ну потому что питон знает 10 человек а яву 2
у нас даже менеджеры на питоне пописывают (с AI конечно, но как факт), а на java иногда кажется и разрабы не справляются.
ещё можно повыкидовать половну плагинов к чертям, заиметь штат дево-псов и питонистов (потом всё равно пригодится), и всё делать самим через православное sh "magic.py"
А еще недавно пришлось руками правки делать, чтобы форк плагина поднять на нужную версию, нам то конечно матерым дроид разрабам, которые прошли Java Core это не преграда, но сам факт того, что из коробки многого нет удручает
Читать полностью…