У меня есть метод библиотеки Jenkins Pipeline Library под названием branchExists.groovy
, который проверяет, существует ли ветка в удаленном (не локальном!) Репозитории.
Это код:
#!/usr/bin/env groovy
def call(String repoUrl, String branchName) {
// Use git ls-remote to verify branch existence
def sout = sh(returnStdout: true, script: "#!/bin/bash\ngit ls-remote --heads ${repoUrl} refs/heads/${branchName}").trim()
return sout.size() != 0
}
Итак, как видите, оболочка Bash запускается для выполнения команды git ls-remote
. Чтобы запустить оболочку, метод должен выполняться в контексте блока node{}
в конвейере, даже если я больше ничего не делаю на этом узле.
Есть ли способ, на языке Jenkins Pipeline, проверять удаленные ветки без необходимости запускать команду оболочки и тем самым не делать необходимости занимать node{}
?
РЕДАКТИРОВАТЬ: может быть, хорошо знать, что сервер Git — это сервер Atlassian Bitbucket, поэтому, может быть, я мог бы использовать API Bitbucket? Или для этого все еще потребуется узел?
Почему я не хочу занимать узел?
Причина, по которой меня беспокоит то, что я не занимаю узел, заключается в том, что исполнители-легковесные / легковесные и тяжеловесные. См. https://support.cloudbees.com/hc/en-us/articles/360012808951-Pipeline-Difference-between-flyweight-and-heavyweight-Executors
Легковесные исполнители — это просто потоки, работающие внутри JVM мастера Jenkins. Младшие исполнители не ограничены и будут создаваться автоматически при необходимости, в отличие от тяжеловесных исполнителей, которые ограничены в зависимости от конфигурации их узла.
Каждый сценарий конвейера сам запускается на главном сервере с использованием легковесного исполнителя (т. Е. Потока Java). Такие шаги конвейера, как sh и bat, будут выполняться на тяжелом исполнителе, если они заключены в блок узла, поэтому в хорошо спроектированном конвейере, где сложная логика возникает только на этих этапах, вспомогательный исполнитель должен бездействовать, пока шаги выполняются на удаленных агентах на протяжении большей части сборки.
Легковесные исполнители не будут блокировать очередь сборки и не будут заблокированы очередью сборки. Если все тяжеловесные исполнители заполнены, мой конвейер не будет продолжать работу до тех пор, пока исполнитель не станет доступен для запуска git ls-remote
.
Насколько я понимаю, все команды sh в любом случае запускаются на Master, поэтому, чтобы свести мои ресурсы к минимуму, я бы сделал выделенный (контейнерный) подчиненный сервер для тривиальных команд. Поскольку альтернативный узел («мастер») будет принудительно выполнять все выполнение на мастере, но это не всегда хорошая идея. — person Amedee Van Gasse schedule 16.06.2020
Речь идет не только о запуске на главном сервере (Дженкинс, пожалуйста, избавьтесь от этого расово заряженного слова как можно скорее!), Но еще и в том, что, пока ваш код не работает на узле, он работает в так называемом облегченном исполнителе, что означает что он не блокирует другие задания в очереди сборки И если все исполнители заняты другими заданиями, конвейер не будет продолжаться до тех пор, пока исполнитель не станет доступным. — person Amedee Van Gasse schedule 16.06.2020
Спасибо вам за разъяснение ! Похоже, я не могу отредактировать свой комментарий, чтобы заменить старую терминологию Дженкинса. — person Amedee Van Gasse schedule 16.06.2020
Не волнуйтесь, мой комментарий в скобках был адресован не вам. — person Amedee Van Gasse schedule 16.06.2020
Насколько я могу судить, ответ — нет. Я не могу найти в самом Jenkins ничего, что могло бы обеспечить эту функциональность.
Даже если вы попытаетесь поговорить с API BitBucket, вам все равно понадобится узел для обработки этого взаимодействия.
Единственный способ, которым, я думаю, вы могли бы достичь той функциональности, которую ищете, — это написать собственную библиотеку Java или Groovy, которую вы могли бы включить в свой Jenkinsfile, которая либо общалась бы с git изначально через такую библиотеку, как JGit или поговорите с BitBucket изначально, как bitbucket-rest.
Вы уверены в API Bitbucket Server? Это будет вызов REST с ответом JSON, а анализ этого JSON можно просто выполнить в потоке Java. Мы сделали нечто подобное с Jira API. Что-то вроде
def response = httpRequest httpMode: 'GET', url: jiraRestEndpointWithParameters, authentication: jiraAuthentication
, а затемdef jsonObj = readJSON text: response.content
. Это чистый Groovy, я проверил, где мы используем этот метод, и определенно не внутри блокаnode
. — person Amedee Van Gasse; 16.06.2020Я бы не стал называть трехстрочный метод в папке
vars
в библиотеке конвейеров пользовательской библиотекой Java или Groovy tbh … — person Amedee Van Gasse; 16.06.2020