У меня есть метод библиотеки 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/bashngit 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
Источник: