Pull to refresh

Comments 12

Сделайте онлайн трансляцию пожалуйста если есть возможность!

Тоже поддерживаю. Очень было бы интересно поговорить с людьми, которые делают Groovy Sandbox, ибо вопросов, в том числе матерных очень много.

А еще лучше возможность просмотреть в записи!
Алексей, спасибо за приятную новость.

Если вдруг будет дефицит вопросов (вряд ли конечно), то вот те, которые интересуют нашу команду:
— как разработчики Declarative Pipeline видят в будущем структуризацию groovy кода? Интересует как собираются решать текущие трудности с переиспользованием разных элементов (pipeline, stage, step) в нескольких разных пайплайнах. Текущее решение, использующее чекаут Git репозитория для подключения библиотек, многими воспринимается как неудобное и усложненное.

— подходит ли Pipeline концепт к мультирепозиторным проектам? Пример — когда модули одного проекта разбросаны по разным Git репозиториям, но при этом у них общий CI и CD. Или же Pipeline концептуально настаивает на монорепозиториях?

— есть ли планы более плотной интеграции с Gradle? Вопрос в связи с тем, что теперь по сути в репозитории появился еще один build-script файл (jenkins file). Но задача/ответственность по сути близка к скриптам Gradle и Maven.

— есть ли планы разработки плагинов для Intellij Idea с полноценной поддержкой Jenkinsfile?

Эти вопросы для нас очень важны, так как Pipeline с одной стороны серьезно отличается от традиционного подхода, с другой стороны весьма активно разрабатывается и быстро изменяется, эволюционирует. Знать в каком направлении планируют развивать продукт и решение разработчики — может помочь минимизировать риски выбора неверных дизайнерских решений на данном этапе для тех, кто уже начал миграцию.
Добрый вечер,

Начну с конца. 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, но на этом интеграции без хаков заканчиваются. Написать плагины можно (даже отладчик), были бы контрибьюторы.
Олег, спасибо за развернутый ответ!

С библиотеками пробовали руководствоваться этой статьей:
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)
...
}
Наиболее интересно звучит Folder-level libraries. Но в статье есть лишь упоминание, без конкретики и примеров.


Там особо много не расскажешь. Объявления делаются не глобально, а на уровне Folder'ов. Поведение примерно такое же. Но это позволяет управлять наборами библиотек/версий для проектов и при необходимости делать CI/CD для библиотек на том же инстансе. Я у себя глобальных библиотек не держу, только в фолдерах.

В идеале в Declarative Pipeline было бы полезно и удобно иметь возможность организовывать набор из стэйджев


Сейчас это можно сделать, если стейджи описаны на Scripted Pipeline (например, в той же библиотеке). Будет что-то типа:

stage("my stage") {
  steps {
    describe-environment()
  }
}

А можно попросить ссылочку на пример с использованием folder level libraries? :)
Вот тут есть пример, как через Groovy Boot Hook у меня для папки инициализируются несколько Pipeline Library. В UI всё примерно так же выглядит, просто ещё одна секция в конфиге.
Sign up to leave a comment.