Я хочу настроить задание Jenkins с декларативным конвейером из Jenkinsfile, используя Subversion в качестве SCM, который должен
Поэтому я настроил задание Jenkins с параметром List Subversion tags (и другими), который собирает существующие ветки SVN из URL-адреса SVN и позволяет пользователю выбрать одну из них. Выбранное значение сохраняется в переменной, например $svnBranch, и я определил «багажник» в качестве значения по умолчанию.
Затем эта переменная используется для создания результирующего URL-адреса SCM, например
svn+ssh://svn.mydomain.org/Reponame/projectname/$svnBranch/componentname
Теперь вот проблема:
Эта настройка работает до тех пор, пока задание запускается вручную. Но если он запускается по расписанию cron, Jenkins продолжает обнаруживать изменения SCM каждый раз и всегда запускает новую сборку. Журнал опроса SCN показывает
Workspace doesn't contain Reponame/projectname/$svnBranch/componentname. Need a new build.
Таким образом, проблема, очевидно, вызвана тем, что Дженкинс не разрешает переменную при опросе SCM на наличие изменений. Чтобы проверить это предположение, я изменил задание на использование фиксированной строковой переменной, и снова произошло то же самое.
Мне было интересно, можно ли решить проблему, переместив логику опроса и проверки в Jenkinsfile. Идея заключалась бы в том, чтобы всегда опрашивать ствол, но проверять и строить на основе $svnBranch, но я не уверен, как это сделать. Можно ли определить разные URL-адреса SCM для опроса и проверки? Согласно моим исследованиям, все URL-адреса оформления заказа в Jenkinsfile будут автоматически использоваться для опроса, так как же это сделать?
Любое другое рабочее решение также приветствуется.
Обратите внимание, что есть похожий вопрос Jenkins Pipeline — опрос SVN, который наткнулся на ту же проблему, но не нашел решения, которое соответствовало бы моему сценарию.
Также обратите внимание, что в JENKINS-10628 сообщается о проблеме: триггер сборки SCM неправильно работает с переменными в URL-адресе SVN, который описывает мою проблему, но, как говорят, она решена с помощью новой версии плагина Subversion с 2015 года. Я обновился до последней версии 2.16.0, но это не решило проблему.
Это решение, которое я нашел (я открыт для лучших - например, я не доволен настройкой одного и того же URL-адреса SCM в двух разных местах):
Во-первых, в задании Jenkins в разделе Pipeline из SCM я настроил URL-адрес магистрали, который не содержит переменной. Этот URL-адрес будет использоваться для опроса изменений в транке.
svn+ssh://svn.mydomain.org/Reponame/projectname/trunk/componentname
Во-вторых, я создал эту функцию, чтобы заменить часть «магистраль» на имя ветки:
def call(Map param = [ : ]) {
if ( param.branch == null ) {
return param.trunkUrl
}
url = param.trunkUrl.replaceAll('/trunk(?=/|$)', '/'+param.branch) // replaces /trunk if followed by / or if at end of url
return url
}
Я переместил эту функцию в разделяемую библиотеку, чтобы использовать ее из любого конвейера.
Затем это используется для получения URL-адреса оформления заказа с выбранным svnBranch в пользовательском интерфейсе:
environment {
// Set actual checkout url, because SVN_URL_1 will always contain the fixed url of the trunk used for polling
checkoutUrl = composeSvnUrl(trunkUrl: env.SVN_URL_1, branch: env.svnBranch)
}
Наконец, я добавил этап оформления заказа (в качестве первого этапа) в свой Jenkinsfile:
stage('Checkout') {
steps {
/* Checkout for actual build (may be different if started manually) */
checkout(
poll: false, changelog: false, // = do not use this for polling
scm: [
$class: 'SubversionSCM',
quietOperation: false,
additionalCredentials: [],
excludedCommitMessages: '',
excludedRegions: '',
excludedRevprop: '',
excludedUsers: '',
filterChangelog: false,
ignoreDirPropChanges: false,
includedRegions: '',
locations: [[
credentialsId: 'id.from.jenkins.credentials',
depthOption: 'infinity',
ignoreExternalsOption: true,
local: '.',
remote: checkoutUrl,
workspaceUpdater: [$class: 'CheckoutUpdater']
]
)
}
}
Важными частями являются:
poll: false, changelog: false означает, что Дженкинс не должен использовать эту информацию о проверке для опроса. Как упоминалось в Pipeline: SCM Step — checkout: Check out from version control в самом низу страницы:
Если «Включить в опрос» отключено и «Включить в список изменений» отключено, то при проведении опроса изменения, обнаруженные в этом репозитории, будут игнорироваться.
workspaceUpdater: [$class: 'CheckoutUpdater'], вероятно, также важно, так как это очистит рабочее пространство перед повторной проверкой.