Pull to refresh

Comments 17

У Pipeline Shared Libraries в таком исполнении есть один существенный недостаток — они ломают концепцию Pipeline-as-Code, когда код хранится и версионируется вместе с пайплайном.

Согласен, но все же зависит от решаемой задачи. В нашем случае используется именно библиотека, потому что очень много команд. Поддерживать очень большой один файл было бы слишком сложно.
Следует все таки различать декларацию, что хотим получить, и имплементацию декларации.
Куча jenkins-плагинов, это как раз имплементация. Shared Library, из той же оперы.
Спасибо за статью, Андрей!

1) Скажите, пожалуйста, у вас получилось как-то подружить Идею с скриптами для Дженкинса?

У меня разразработка для Дженкинса в Идеи выглядит, как написание кода в IDE, в которой данный язык не поддерживается. Всё красное, никаких подсказок по классам. Оно и понятно, я не добавлял в класпас каких-либо jar-ников (которые я сходу не смог найти).

2) Вы пишите, что можно и Джаву использовать. У вас есть опыт? Ведь в дженкинсе вроде бы только на груви можно писать пайплайны?
Привет,
1. Я импортирую проект как новый модуль и добавляю groovy sdk. Мне этого достаточно
2. Спасибо за замечание — исправил. Более правильно добавить, что можно использовать любые библиотеки с помощью Grab
Импортну вам любую либу, только позовите :)

C аннотацией grab тоже не все так просто. Например я пробовал подключить таким образом google guava и при обращении к классам библиотеки получил исключение MethodNotFoundException. Было несложно догадаться и проверить, что код pipeline-а загружается в classloader-е наследнике какого-то classloader-а в Jenkins куда уже загружены библиотеки самого Jenkins. Это может вести к очень неприятным последствиям.

В скриптах можно использовать любые возможности языка

Oчень смелое заявление. Важно понимать, что это не groovy, а jenkins dsl. Со своим кастомным интерпретатором и своими багами. И с учётом их фишки CPS это даёт незабываемые ощущения при разработке. Так, что тут чем проще, тем меньше шансов наступить на грабли.
Добрый день. Можете привести пример конструкции groovy, которую нельзя использовать внутри функции в модуле vars?
(1..3).each

и надо еще не забывать, что в дженкинсе по умолчанию запрещено выполнение половины встроенных методов, и их надо разрешать отдельно.
Я обновил пример
И вот мой аутпут:
Enable balancer
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Check Status)
[Pipeline] echo
Check status
[Pipeline] echo
Number: 1
[Pipeline] echo
Number: 2
[Pipeline] echo
Number: 3
[Pipeline] }
[Pipeline] // stage
[Pipeline] End of Pipeline
Finished: SUCCESS

Можете привести другой пример?
я удивлен, но сейчас это действительно работает, когда пайплайн в дженкинсе только появился подобное работать отказывалсоь, и у меня до сих пор все старые библиотеки пестят конструкциями типа:
for (int i = 0; i < changeLogSets.size(); i++) {
или
@NonCPS
надо будет это переосмыслить
Это буквально недавно в новостях появилось. См. jenkins.io/blog/2017/09/08/enumerators-in-pipeline

Я правда пока не спешу обновлять сервера, есть недоверие что опять заработает только часть конструкций :)
это да, сначала пишешь все на груви, а потом еще день портируешь с груви на груви и без такой-то матери ниогда не обходится.
def collection = ['One Two Three'].collect{ it.split(' ') }
println "collection: " + collection
def result = ''
collection.each{ result += it }
println "result: " + result

Результат из Script Console:
collection: [[One, Two, Three]]
result: [One, Two, Three]

Результат из пайплайна:
[Pipeline] echo
collection: [[One, Two, Three]]
[Pipeline] echo
result: One
Sign up to leave a comment.

Articles