Pipeline vs Задачи со свободной конфигурацией

#1

Не смог создать новую тему в курсе, поэтому здесь. Если модераторы решат перенести, велкам.

Для себя не смог ответить на вопрос чем же пайплайн лучше задач со свободной конфигурацией. Что в нем есть такого, чего нет в “свободных” задачах? В чем преимущества?

  • Конструкции из pipeline syntax вроде как должны быстро позволить подключить все, что нужно, а по факту все равно руками допиливаются. Отладчика нет, соответственно, все равно по очереди шаги тестировать и выкладывать в общий jenkinsfile. Т.е. также как и с командной строкой.
  • Ветвление есть и там и там.
  • Язык groovy. Кто не знает - придется освоить. Когда Никита подключал строчки versionContent = readFile encoding: ‘UTF-8’, file: ‘src/cf/VERSION’ или env.BUILD_NUMBER.endsWith тут вообще надо было перелопатить соседние языки. Я могу использовать oscript для обеих задач и командную строку.
  • Запуск параллельного задания в “свободной” - есть Multijob Plugin

Пока для себя выделил только два удобства:

  • в пайплайне все разбито на стадии и при взгляде на джобу можно сразу понять, что упало. Но в логи все равно лезть придется как и в “свободной”
  • все в едином jenkinsfile. Ну или почти все. Если несколько git - снова плагин и т.д. Т.е. об едином конфигурационном пространстве можно сказать с натяжкой.
#2

Имхо основное преимущество pipeline в том, что это код…

#3

У меня еще возникла идея, что с помощью pipeline можно просто запускать оскрипт, который будет лежать в репозитории и версионироваться с проектом. Тогда практически не будет никакого groovy, а только 1c(bsl).
Т.е. получиться, как Лустин еще пару лет назад говорил на infostart event: не можете писать на java/python/etc, - пишите на OneScript.

#4

На свободной конфигурации я делаю просто батник, который как раз и выполняет все остальные onescript-ы.

#5

призываю @trainers (если в этом форуме так можно)

#6

Для меня pipeline ценен в первую очередь за parallel. Я реализовал через несколько задач со свободной конфигурацией прогон тестов VB. Но как результат - занял все очереди. А другие команды ждут пока они освободятся. Плюс можно легко ответить на вопрос “Как долго работают тесты”. Хотя делать цепочки из свободных конфигураций проще.

#7

Мы все проходили батники и много где юзаем, но pipeline удобнее
Преимущества pipeline

  • куча разных инструментов для работы с джобами - параллельное выполнение, отбор нод, отчеты выполнения/тестирования, автоматическое прерывание работы, артефакты, работа с репо и т.п.
    • в случае батников и собственных скриптов придется многое из этого делать руками
  • главное - один файл, в котором находятся все нужные действия, этот файл лежит в гите
    • легко повторить на любой ноде
    • конечно, когда в файле используется куча инструментов, которые отдельно ставятся на ноду, сложнее развертывать, но и это можно решить.
#8

Основная проблема батников и свободной конфигурации - из них нельзя взаимодействовать с дженкинсом. хочешь опубликовать аллюр? отдельный пост-шаг. junit? отдельный пост шаг. какая-нибудь очередная непонятная плагино-хрень? тоже отдельный шаг.
в итоге оно все вырождается в длинную простыню квадратиков с тучей настроек и галочек. еще и веб-морда дженкинса подтормаживает. и не версионируется толком.

Конструкции из pipeline syntax вроде как должны быстро позволить подключить все, что нужно, а по факту все равно руками допиливаются. Отладчика нет, соответственно, все равно по очереди шаги тестировать и выкладывать в общий jenkinsfile. Т.е. также как и с командной строкой.

Есть отладчик через jenkins cli. Я его лично не использую, но знаю, что @pumbaE в своей работе им активно пользуется. Правда до него сейчас не достучаться.

Ветвление есть и там и там.

есть. но имхо оно в плане UI громоздкое.

Язык groovy. Кто не знает - придется освоить. Когда Никита подключал строчки versionContent = readFile encoding: ‘UTF-8’, file: ‘src/cf/VERSION’ или env.BUILD_NUMBER.endsWith тут вообще надо было перелопатить соседние языки. Я могу использовать oscript для обеих задач и командную строку.

Минус - новый язык (хотя это и не минус, имхо). плюсы - все же весь код по сборке в одном месте, это обычно удобнее, чем ворох несвязанных батников. груви (впрочем как и оскрипт) в отличие от батников платформонезависим.

Запуск параллельного задания в “свободной” - есть Multijob Plugin

есть, не спорю :slight_smile:

Лично для меня киллер-фича Jenkinsfile - это multibranch pipeline. Единственная настройка задачи и корректный дженкинс-файл позволяют реализовывать очень прикольные и полезные сценарии.

А плагины - их в любом случае ставить, от этого никуда не деться. Разве что утилиты командной строки можно в prepare-шаге себе локально подготовить.

1 Симпатия
#9

Как опубликовать Allure с помощью Pipeline syntax?

#10

Можно подробнее про киллер-фичу multibranch pipeline. Желательно с целью и реализацией.

#11

А вот обнаружил и неудобства. Я использую CatLight чтобы получать уведомления в трее. Когда каждый тест в отдельной задаче - я точно вижу что сейчас исполняется и что упало. Когда pipeline - только общую задачу.

#12

allure config: [
commandline: ‘Maven_Allure’,
includeProperties: false,
jdk: ‘’,
properties: [],
reportBuildPolicy: ‘ALWAYS’,
results: [[path: ‘./out/allure’]]
]

Примерно так. Но на данный момент почему-то не работает

#13

уже работает

#14

Реально крутая штука, только вот не хочет пока отдавать ответ на GinLab. НО запускается по событиям с GinLab четко :slight_smile:

#15

Работает “из каробки”, или пришлось шаманить чтобы заработало?
Можете показать скриншот?

#16

У меня не работает. Пишет:
Непредвиденное появление: \Jenkins\tools\ru.yandex.qatools.allure.jenkins.tools.AllureCommandlineInstallation\allure.

#17

В понедельник скину скрин и конфиг.
Обновите до последней версии аллюра и дженкинса.

#18

Итак, обещанный пример

stage('Автотестирование'){
		allure([includeProperties: false, jdk: '', properties: [], reportBuildPolicy: 'ALWAYS', results: [[path: 'allure-reports']]])
	}

ну и скрин
Раз

image.png471×546 40 KB

два

image.png723×533 21.4 KB

2 Симпатий
#19

Видимо какая-то другая версия pipeline. У меня не дает определять stage без steps. И allure команду уже не распознает:
WorkflowScript: 60: Invalid parameter “includeProperties”, did you mean “config”? @ line 60, column 25.
allure([includeProperties: false, jdk: ‘’, properties: [], reportBuildPolicy: ‘ALWAYS’, results: [[path: ‘Build/out/allurereport’]]])
^

WorkflowScript: 60: Invalid parameter “jdk”, did you mean “config”? @ line 60, column 51.
re([includeProperties: false, jdk: ‘’, p
^

WorkflowScript: 60: Invalid parameter “properties”, did you mean “config”? @ line 60, column 60.
deProperties: false, jdk: ‘’, properties
^

WorkflowScript: 60: Invalid parameter “reportBuildPolicy”, did you mean “config”? @ line 60, column 76.
lse, jdk: ‘’, properties: [], reportBuil
^

WorkflowScript: 60: Invalid parameter “results”, did you mean “config”? @ line 60, column 105.
reportBuildPolicy: ‘ALWAYS’, results: [
^

#20

а так

node('master') {
currentBuild.result = "SUCCESS"
checkout scm	
    algen()
}

def algen((){
try {
	stage('Автотестирование'){
 // здесь надо написать вызов генерации файлов для аллюра
 // .....

 // генерация отчета  
 allure([includeProperties: false, jdk: '', properties: [], reportBuildPolicy: 'ALWAYS', results: [[path: 'allure-reports']]])
	}
}
catch (err) {
	send_err(err)
}
}

def send_err(err){
currentBuild.result = "FAILED"
sendEmailDevelopers(
	"<p>Ошибка выполнения задачи <a href=${BUILD_URL}>${JOB_NAME} (${BUILD_NUMBER})</a></p>", 
	"Ошибка выполнения задачи ${JOB_NAME} (${BUILD_NUMBER})")
throw err
}

def sendEmailDevelopers(textBody, textSubj){
emailext body: textBody, 
recipientProviders: [[$class: 'DevelopersRecipientProvider']], 
subject: textSubj, 
to: 'me@mydomain.ru'
}