VL
Jenkinsfile или пайплайн
Size: a a a
2020 October 13
DB
от Jenkinsfile тоже отказаться. ведь идея - держать пайплайны в одном месте?
HC
от Jenkinsfile тоже отказаться. ведь идея - держать пайплайны в одном месте?
как это реализовать?
// сорь, что встряю
// сорь, что встряю
VD
как это реализовать?
// сорь, что встряю
// сорь, что встряю
default Jenkinsfile
DB
джобы можно создавать не только через Jenkinsfile
есть jjb и job-dsl
они вполне вписываются в iac
есть jjb и job-dsl
они вполне вписываются в iac
HC
default Jenkinsfile
Это как? Есть пример?
У меня сейчас в каждом проекте лежит Jenkinsfile. И при глобальных изменениях в пайплайнах, правки превращаются в крестовые походы
У меня сейчас в каждом проекте лежит Jenkinsfile. И при глобальных изменениях в пайплайнах, правки превращаются в крестовые походы
M
V L
Коллеги. Есть какие то контраргументы против держать всю логику пайплайна в shaed library и из пайплайна ее только вызывать как функцию (ну может еще параметры пробрасывать в нее)?
Зависит от случая
если у тебя абсолютно все пайплайны идентичны и, если вдруг нужно будет что поменять из-за одного проекта, ты уверен в совместимости со всеми остальными проектами в компании — why not
если нет, то, ИМХО, имеет смысл выносить только рутину, которая вряд ли когда-нибудь изменится
если у тебя абсолютно все пайплайны идентичны и, если вдруг нужно будет что поменять из-за одного проекта, ты уверен в совместимости со всеми остальными проектами в компании — why not
если нет, то, ИМХО, имеет смысл выносить только рутину, которая вряд ли когда-нибудь изменится
HC
Зависит от случая
если у тебя абсолютно все пайплайны идентичны и, если вдруг нужно будет что поменять из-за одного проекта, ты уверен в совместимости со всеми остальными проектами в компании — why not
если нет, то, ИМХО, имеет смысл выносить только рутину, которая вряд ли когда-нибудь изменится
если у тебя абсолютно все пайплайны идентичны и, если вдруг нужно будет что поменять из-за одного проекта, ты уверен в совместимости со всеми остальными проектами в компании — why not
если нет, то, ИМХО, имеет смысл выносить только рутину, которая вряд ли когда-нибудь изменится
а если мультибранч?
M
а если мультибранч?
А какая разница?
HC
А какая разница?
Дженкинсфайл должен быть в ветке(репе)
HC
иначе, билда не будет
M
Дженкинсфайл должен быть в ветке(репе)
ну да
M
в чём проблема?
HC
я короч, понял. Надо всю логику выносить нафиг, и засунуть в shared
VD
Это как? Есть пример?
У меня сейчас в каждом проекте лежит Jenkinsfile. И при глобальных изменениях в пайплайнах, правки превращаются в крестовые походы
У меня сейчас в каждом проекте лежит Jenkinsfile. И при глобальных изменениях в пайплайнах, правки превращаются в крестовые походы
Поставить https://plugins.jenkins.io/pipeline-multibranch-defaults/
Сделать в https://вашхост/configfiles/editConfig?id=Jenkinsfile с содержимым
Сделать в https://вашхост/configfiles/editConfig?id=Jenkinsfile с содержимым
// Jenkinsfile
library 'my-shared-library'
buildAllJobs()
и в buildAllJobs уже решать что делать
I
Всем привет, у меня есть несколько pipeline’ов в которых дублируются шаги, ткните носом, пожалйуста, как это грамотно унифицировать, чтобы не копипастить в несколько мест.
Можно же шарить артефакты между нодами
HC
в чём проблема?
проблема в том, что реп 40+, и когда надо сделать какие-то правки, ты идёшь во все
DB
Дженкинсфайл должен быть в ветке(репе)
не обязательно
HC
не обязательно
да?
ну, у меня в UI не создалась отдельная ветка и билд не запустился. Билдились только те, в которых был Дженкинсфайл
ну, у меня в UI не создалась отдельная ветка и билд не запустился. Билдились только те, в которых был Дженкинсфайл
DB
все упёрлись в эти Jenkinsfile и не видят других путей