Comments 12
Сделайте онлайн трансляцию пожалуйста если есть возможность!
0
Тоже поддерживаю. Очень было бы интересно поговорить с людьми, которые делают Groovy Sandbox, ибо вопросов, в том числе матерных очень много.
0
А еще лучше возможность просмотреть в записи!
0
Трансляции не будет. Видеозапись будет через пару дней на нашем Youtube-канале.
+1
Алексей, спасибо за приятную новость.
Если вдруг будет дефицит вопросов (вряд ли конечно), то вот те, которые интересуют нашу команду:
— как разработчики Declarative Pipeline видят в будущем структуризацию groovy кода? Интересует как собираются решать текущие трудности с переиспользованием разных элементов (pipeline, stage, step) в нескольких разных пайплайнах. Текущее решение, использующее чекаут Git репозитория для подключения библиотек, многими воспринимается как неудобное и усложненное.
— подходит ли Pipeline концепт к мультирепозиторным проектам? Пример — когда модули одного проекта разбросаны по разным Git репозиториям, но при этом у них общий CI и CD. Или же Pipeline концептуально настаивает на монорепозиториях?
— есть ли планы более плотной интеграции с Gradle? Вопрос в связи с тем, что теперь по сути в репозитории появился еще один build-script файл (jenkins file). Но задача/ответственность по сути близка к скриптам Gradle и Maven.
— есть ли планы разработки плагинов для Intellij Idea с полноценной поддержкой Jenkinsfile?
Эти вопросы для нас очень важны, так как Pipeline с одной стороны серьезно отличается от традиционного подхода, с другой стороны весьма активно разрабатывается и быстро изменяется, эволюционирует. Знать в каком направлении планируют развивать продукт и решение разработчики — может помочь минимизировать риски выбора неверных дизайнерских решений на данном этапе для тех, кто уже начал миграцию.
Если вдруг будет дефицит вопросов (вряд ли конечно), то вот те, которые интересуют нашу команду:
— как разработчики Declarative Pipeline видят в будущем структуризацию groovy кода? Интересует как собираются решать текущие трудности с переиспользованием разных элементов (pipeline, stage, step) в нескольких разных пайплайнах. Текущее решение, использующее чекаут Git репозитория для подключения библиотек, многими воспринимается как неудобное и усложненное.
— подходит ли Pipeline концепт к мультирепозиторным проектам? Пример — когда модули одного проекта разбросаны по разным Git репозиториям, но при этом у них общий CI и CD. Или же Pipeline концептуально настаивает на монорепозиториях?
— есть ли планы более плотной интеграции с Gradle? Вопрос в связи с тем, что теперь по сути в репозитории появился еще один build-script файл (jenkins file). Но задача/ответственность по сути близка к скриптам Gradle и Maven.
— есть ли планы разработки плагинов для Intellij Idea с полноценной поддержкой Jenkinsfile?
Эти вопросы для нас очень важны, так как Pipeline с одной стороны серьезно отличается от традиционного подхода, с другой стороны весьма активно разрабатывается и быстро изменяется, эволюционирует. Знать в каком направлении планируют развивать продукт и решение разработчики — может помочь минимизировать риски выбора неверных дизайнерских решений на данном этапе для тех, кто уже начал миграцию.
0
Отвечает oleg-nenashev
0
Добрый вечер,
Начну с конца. Pipeline сейчас — не единый продукт, а open-source экосистема, которая делается многими компаниями и независимыми разработчиками. В «ядре» Pipeline есть вектор развития на стабилизацию/performance и Declarative, но на периферии все происходит довольно спонтанно. В особенности это касается Pipeline-интеграций в плагинах.
По вопросам:
Не берусь ответить за разработчиков Declarative. Есть идеи о поддержке Declarative-блоки внутри библиотек, я бы в ближайшем будущем не ожидал новых движков для шаринга кода. Собственно, а чем Вам неудобны библиотеки? Их не обязательно в Git держать, через другие плагины их можно хоть локально на мастере держать (через alpha-версию Filesystem SCM Plugin)
Подходит. В этом случае все равно надо где-то хранить код Pipeline (в самой задаче или в Jenkinsfile в одном из репозиториев), но другие репозитории могут подтягиваться через шаги типа git(). И webhook'и на все репозитории вешать можно. Более сложную логику триггеринга, конечно, будет писать тяжелее.
AFAIK планов в roadmap нет. Есть висящий pull-request в Gradle Plugin. Он близок к завершению, и любая помощь там приветствуется (ревью/тестирование). Форвардну вопрос тем, кто сейчас разработкой Pipeline занимается.
Публичных планов, к сожалению, нет. А вот потребность в этом есть. Я на митапе про интеграцию с IDE немного говорил (начало слайдов). Сейчас есть условно-рабочая поддержка автодополнения и документации через GDSL, но на этом интеграции без хаков заканчиваются. Написать плагины можно (даже отладчик), были бы контрибьюторы.
Начну с конца. Pipeline сейчас — не единый продукт, а open-source экосистема, которая делается многими компаниями и независимыми разработчиками. В «ядре» Pipeline есть вектор развития на стабилизацию/performance и Declarative, но на периферии все происходит довольно спонтанно. В особенности это касается Pipeline-интеграций в плагинах.
По вопросам:
как разработчики Declarative Pipeline видят в будущем структуризацию groovy кода?.. Текущее решение, использующее чекаут Git репозитория для подключения библиотек, многими воспринимается как неудобное и усложненное
Не берусь ответить за разработчиков Declarative. Есть идеи о поддержке Declarative-блоки внутри библиотек, я бы в ближайшем будущем не ожидал новых движков для шаринга кода. Собственно, а чем Вам неудобны библиотеки? Их не обязательно в Git держать, через другие плагины их можно хоть локально на мастере держать (через alpha-версию Filesystem SCM Plugin)
Подходит ли Pipeline концепт к мультирепозиторным проектам?
Подходит. В этом случае все равно надо где-то хранить код Pipeline (в самой задаче или в Jenkinsfile в одном из репозиториев), но другие репозитории могут подтягиваться через шаги типа git(). И webhook'и на все репозитории вешать можно. Более сложную логику триггеринга, конечно, будет писать тяжелее.
есть ли планы более плотной интеграции с Gradle?
AFAIK планов в roadmap нет. Есть висящий pull-request в Gradle Plugin. Он близок к завершению, и любая помощь там приветствуется (ревью/тестирование). Форвардну вопрос тем, кто сейчас разработкой Pipeline занимается.
Есть ли планы разработки плагинов для Intellij Idea с полноценной поддержкой Jenkinsfile?
Публичных планов, к сожалению, нет. А вот потребность в этом есть. Я на митапе про интеграцию с IDE немного говорил (начало слайдов). Сейчас есть условно-рабочая поддержка автодополнения и документации через GDSL, но на этом интеграции без хаков заканчиваются. Написать плагины можно (даже отладчик), были бы контрибьюторы.
+1
Олег, спасибо за развернутый ответ!
С библиотеками пробовали руководствоваться этой статьей:
https://jenkins.io/doc/book/pipeline/shared-libraries/
Global Shared libraries отпало, т.к. это нарушало саму идею, что весь код хранится целостно в одном месте (получается часть приходит из Git, часть добавлена руками в Jenkins). По поводу Filesystem SCM были не в курсе, в ближайшее время опробуем.
Наиболее интересно звучит Folder-level libraries. Но в статье есть лишь упоминание, без конкретики и примеров.
На данный момент всю логику стараемся вынести в shell скрипты наподобии:
clean-test-package
describe-environment
deploy-to-cloud
В идеале в Declarative Pipeline было бы полезно и удобно иметь возможность организовывать набор из стэйджев — и потом ссылаться на различные стейджи в тех пайплайнах где это необходимо. К примеру так:
С библиотеками пробовали руководствоваться этой статьей:
https://jenkins.io/doc/book/pipeline/shared-libraries/
Global Shared libraries отпало, т.к. это нарушало саму идею, что весь код хранится целостно в одном месте (получается часть приходит из Git, часть добавлена руками в Jenkins). По поводу Filesystem SCM были не в курсе, в ближайшее время опробуем.
Наиболее интересно звучит Folder-level libraries. Но в статье есть лишь упоминание, без конкретики и примеров.
На данный момент всю логику стараемся вынести в shell скрипты наподобии:
clean-test-package
describe-environment
deploy-to-cloud
В идеале в Declarative Pipeline было бы полезно и удобно иметь возможность организовывать набор из стэйджев — и потом ссылаться на различные стейджи в тех пайплайнах где это необходимо. К примеру так:
pipeline {
...
stage(describe-environment)
stage(clean-test-package)
stage(deploy-to-cloud)
...
}
0
Наиболее интересно звучит Folder-level libraries. Но в статье есть лишь упоминание, без конкретики и примеров.
Там особо много не расскажешь. Объявления делаются не глобально, а на уровне Folder'ов. Поведение примерно такое же. Но это позволяет управлять наборами библиотек/версий для проектов и при необходимости делать CI/CD для библиотек на том же инстансе. Я у себя глобальных библиотек не держу, только в фолдерах.
В идеале в Declarative Pipeline было бы полезно и удобно иметь возможность организовывать набор из стэйджев
Сейчас это можно сделать, если стейджи описаны на Scripted Pipeline (например, в той же библиотеке). Будет что-то типа:
stage("my stage") {
steps {
describe-environment()
}
}
0
Вот тут есть пример, как через Groovy Boot Hook у меня для папки инициализируются несколько Pipeline Library. В UI всё примерно так же выглядит, просто ещё одна секция в конфиге.
0
Sign up to leave a comment.
[Питер] Встреча JUG.ru с Олегом Ненашевым из CloudBees — Groovy DSL в Jenkins и Pipeline. Реализации и подводные грабли