Jenkins Pipeline — где храните свой Jenkinsfile?

Question

[web_dev]

Здравствуйте,

господа, такой вопрос. Надеюсь поделитесь опытом.
Новые проекты начинаем с всевозможной автоматизации релиз процесса, а также каждодневных рутин.
Посему есть несколько Jenkins-pipelines файлов. Два файла Jenkins-feature и Jenkins-release относятся к проекту, также есть несколько общих которые просто лежат в отдельном репозитории.

[b]Вопрос: Как и где вы храните свои Jenkinsfile-s? Почему-то хочется все пайплайны загрузить в один репозиторий и всё. Чтоб не было часть в проекте, а часть нет. Да и кажется, проект это одно, а как мы его релизим немного другое... Но с другой стороны, во многих примерах Jenkinsfile лежит в корневой директории проекта...[/b]

Плюсы: если Jenkinsfile в проекте - у нас сохраняется один шаг. Jenkins Pipeline автоматически тянет проект.

Минусы: нужно дополнительно тянуть проект и ещё несколько, которые достаточно сложно объяснить

stage('Project Checkout Stage') {
            steps {
                stepInfo("${PROJECT}/${REPOSITORY}/${BRANCH} Checkout Stage START")
                git url: 'https://scm/${PROJECT}/${REPOSITORY}.git', branch: '${BRANCH}', credentialsId: 'bla'
                stepInfo("${PROJECT}/${REPOSITORY}/${BRANCH} Checkout END")
            }
        }

Спасибо, надеюсь мой вопрос понятен...

Answer 1

[Дмитрий Еремин]

Храним в отдельном репозитории все Jenkins-файлы. Для каждой джобы свой файл


Уже в файле пишем, откуда что выгружать и как собирать
Минусов особых нет. На один больше запросов к репозиторию? Ну так себе "минус"
Из плюсов - версионирование дженкинсфайла и сохранность

Comments

[web_dev]

Пасиб за ответ. Позвольте уточнить. Храните в отдельном репозитории или в репозитории с проектом?

[Дмитрий Еремин]

web_dev, в отдельном
Наверное, если у вас код в ветках продукта сильно отличается и какую-нибудь ветку А нужно собирать не так, как ветку В, то вам стоит держать в каждой ветке поп jenkins-файлу, чтобы там определить индивидуальную сборку для ветки
У нас все ветки собираются одинаково, гоняются одни и те же тесты. Разница только в том, что, если ветка release - после сборки готовимся к деплою
Но эта логика прописана прям в скрипте: отдельный jenkins-файл для ветки - эт уже перебор

[web_dev]

Дмитрий Еремин, Пасиб. Да, у нас так же. Все ветки собираются одинаково и для релиза отдельный пайплайн, только вот говорю - в примерах видел что Jenkins-файлы лежат в той же дирректории что и проект. Считаю, если нужно под каждую ветку подгонять процесс, то что-то делается неверно. ))

А подскажите - как решаете проблему, чтоб Jenkins Pipeline складывал всё в одну папку? Ведь если пайплайн в одном репозитории, проект в другом, то в воркспейсе создаётся 2 папки. Понимаете о чём я? Multi-branch-pipeline решает эту задачу?

[Дмитрий Еремин]

web_dev, да никак)
1. Выгружается с репозитория jenkinsfile
2. Скрипт анализируется и выполняется
3. Все. Дальше сам файл уже не нужен
4. У меня в эту же директорию выгружается в проект и собирается. Все норм)

[web_dev]

Дмитрий Еремин, Вот у меня такая проблемка. Есть скрипт который находится в отдельном файле, проверяет свободные порты. Если скрипт лежит в проекте, а Jenkinsfile отдельно, то я к нему могу достучаться так.

script {
                    SERVER_PORT = sh(returnStdout: true, script: "chmod +x " +
                            "src/main/resources/pipeline/mock-server/checkPorts.sh && " +
                            "./src/main/resources/pipeline/mock-server/checkPorts.sh").trim()
                }

Если же скрипт лежит в другом репозитории(в том же что и Jenkinsfile), то Jenkins Pipeline просто его не видит, получаю FileNotFound

Понимаете?

[Stanislav Pugachev]

Дмитрий Еремин,

я правильно понимаю что у вас отдлеьная репа где в мастере лежит куча jenkinsfile
и вы когда добавляете новый - создаете новую джобу для определенного пути к новому jenkinsfile?
не проще тогда сканировать все ветки и под каждый jenkinsfile создавать отдельную ветку?
тогда можно одной multipipeline джобой обойтись поидее

[Дмитрий Еремин]

Stanislav Pugachev, но мы не создаем больше джоб
есть джоба на сборку. есть на прогон тестов, есть на управление конфигами и на деплой
Лежат там себе и вызываются. Не куча - 5 штук.
Наверн, multipipeline проще. Чем - я не оч понял Проблем не испытываем

[Stanislav Pugachev]

Дмитрий Еремин,

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