кста, ктонибудь нахлобучку blueocean на jenkins использует?

кста, ктонибудь нахлобучку blueocean на jenkins использует?

страшно

слишком много плагинов за собой тянет

как показала практика, чем меньше плагинов в женьке, тем стабильнее его обновления

И тормозит ощутимо

в идеале оставлять только pipeline

и все ими делать

на грувях

эх, если бы

все и так работает хоршо, но этот blueocean прям вжух вжух - красивый.

столько лет jenkins выглядел как jenkins, а тут - на тебе

да пайпы тоже неплохи\

всмысле внешнего вида

все равно они jenkins'оватые

https://jenkins.io/projects/blueocean/roadmap/

+ очень много еще нереализовано в них

кро дрона юзает?

чо как он? drone.io

чо как он? drone.io

мы импользуем, но я не девопсер, а бекендщик

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

еще есть коммьюнити в гиттере, где всегда могут помочь

это saas?

на грувях

вы пробовали это делать? бггг я столько боли натерпелся с этими groovy скриптом там как бы проблема такая, там не груви, а чувак в плагине нарисовал свой лексический парсер, еще один велосипед и когда я активно его трогал зимой, и делал ООП на грувях начинается самые приколы, например в конструкторе класса вызов собственного приватного метода ведет к бесконечной рекурсии которую сложно отдебажить я к автору этого плагина в irc пришел, раз, второй, третий, он как бы говорил, что итерироваться по списоку элементов for'ом нельзя бггг и прочие прохладные истории в итоге на четвертый раз я его спросил, как жи вы эту боль терпите, на что он ответил, что это не продакшн реди

Пробовали, но без ООП

Работает отлично

А что за плагин был?

только for'ом и можно гарантированно проитерировать список https://issues.jenkins-ci.org/browse/JENKINS-26481 эта дрянь до сих пор не пофикшена в лтс

а уж дебаг пайплайнов - отдельная увлекательная история

А что за плагин был?

groovy-pipeline плугин жи

Не, выгружаешь, правишь, загружаешь.

virsh net-update может это, без выгрузки, правки и загрузки ключи —live и —config

А что за плагин был?

https://issues.jenkins-ci.org/browse/JENKINS-46145?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%27workflow-cps-plugin%27

А, я то думал из под грувей с каким то другим плагином работал

как бэ

я реально с ним боли натерпелся

и главное что автор говорит что это еще не пока продакш реди (инфа конец зимы этого года)

в итоге вместо баша который был стал баш обернутый в груви

а уж дебаг пайплайнов - отдельная увлекательная история

Это из серии "почему я в машине домкрат не вожу. Я ее ездить купил или чинить?"))

Баш обернутый в груви это нормально ИМХО

Там как бы соль в том, что у тебя в репе есть Jenkinsfile, и у тебя получается IaS

зачем тогда груви? баш, обернутый в груви не верифицируется стайл-чекерами

основная проблема по словам автора плагина в том, что дженкинс выставляет некую state control machine, через которую идет интеграция с groovy-plguinином это типа дженкинс выполняет джобу, на каждом шагу сохраняет стейт, если дженкинс повалится или перезапустится, типа джоба пойдет с того этапа, на котором дженкинс наебнулся

в этом концептуальная проблема groovy-cps-plugin'а

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

все это печально

кстати >если дженкинс повалится или перезапустится в 10% случаев джобы виснут по непонятной причине

пруфы на ишуи - выше

кстати >если дженкинс повалится или перезапустится в 10% случаев джобы виснут по непонятной причине

дададада, хотели как лучше, получается как всегда

:-)

я пробовал для кубернетеса написать ООП объект, который его деплоит, оно в каком-то виде даже работало, но я потратил нереальное количество времени на это, и в итоге ООП был хромой на одну ногу, т.к. нельзя его использовать как есть, а подстравиться под ограничения cps плагина

Нюансы в написании скриптов на груви в женьке конечно есть, не отрицаю, но все в итоге работает как надо, если не усложнять сборку ООП'ом, процедурного стиля хватает за глаза там

Нюансы в написании скриптов на груви в женьке конечно есть, не отрицаю, но все в итоге работает как надо, если не усложнять сборку ООП'ом, процедурного стиля хватает за глаза там

https://issues.jenkins-ci.org/browse/JENKINS-43974?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%27workflow-cps-plugin%27 https://issues.jenkins-ci.org/browse/JENKINS-43389?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%27workflow-cps-plugin%27 https://issues.jenkins-ci.org/browse/JENKINS-41896?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%27workflow-cps-plugin%27

это на вскидку там еще отдельная тема, что есть groovy pipeline library, которая позволяет перед запуском джобы безусловно забирать пайплайн library из SCM так вот писечка вся в том, что код который подтягивается из SCM, и код который написан в теле джобы выполняется в разных CPS контекстах

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

наелся я этого говна достаточно, и не советую

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

Нас они изо дня в день радуют

В хорошем смысле

Точнее, мы планируем их выложить, но надо причесать сначала

https://issues.jenkins-ci.org/browse/JENKINS-34645 вот например посмотрите как люди не могут в массив после сплита

или вот https://stackoverflow.com/questions/27509344/groovy-each-only-iterates-one-time

с @NoNCPS - это отдельная и долгая история

вот, я и говорю >classic for loop наше всё шаг в сторону - здравствуй грабли

Массивы это сложно для пайплайнов

ERROR: S client not available

Не нужны они там

https://issues.jenkins-ci.org/browse/JENKINS-34645 вот например посмотрите как люди не могут в массив после сплита

Массив это когда больше одной переменной внутри переменной?

например нельзя в грувях использовать regex'ы без обертки @NonCPS, так парсинг regex'а уже выходит за рамки CPS машины

да, и люди которые все таки рискую использовать этот workflow-cps-plugin, в большинстве своем так и говорят, что лучше не выебываться, и делать просто

в этом случае для меня ускользает громадная доля смысла к прикручиваю groovy к дженкинсу

Смысл пайпов в дженкинсе, это иметь возможность управлять сборкой из кода

Без надобности заходить и руками чото тыкать в женьке

Имхо

Согласитесь, оно того стоит?

wut? в правильном CI/CD руками тыкают очень мало, и то только тогда, когда что-то идет не так

на практике конечно, это редко встречается

wut? в правильном CI/CD руками тыкают очень мало, и то только тогда, когда что-то идет не так

Не совсем понимаю как этого добиться в дженкинсе на фристайловых джобах

имхо, мешать ci с кодом - плохая идея. во-первых дерево коммитов засирается, а во-вторых ci, размазанный по 100500 проектов - это не менеджится

а что можно почитать на тему teamcity + capistrano ?

IaS замечательно реализуется через jjb без этих ваших пайплайнов

Почему засирается?

имхо, мешать ci с кодом - плохая идея. во-первых дерево коммитов засирается, а во-вторых ci, размазанный по 100500 проектов - это не менеджится

wuuuuuuuuuuuuuuuut

Отлаживать сборку можно без Jenkinsfile, и закомитить в него только когда все ок работает

я имею ввиду код продукта с кодом инфры

Эм

Докерфайл тоже в репе хранить не надо?

по идеи, часть модного направления, деливерить кастомеру не продукт, а CI/CD для продукта, который сам на мощностях кастомера крутится и периодически синкается с апстимом

если он не имеет отношения к коду, зачем от там? отдельный проект под IaS

Чото парни комитят файл gitlab-ci.yml и не жалуются

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

Нам норм, и проектов много

У меня есть теория, что один из признаков нормальной инфры, это когда она может разделить раздеплоить саму себя

3 чая этому господину!