Как заставить опрос SCM работать с плагином Jenkins Workflow

В обычном проекте фристайла я настраиваю подключаемый модуль SCM, чтобы он указывал на репозиторий Git, который я хочу выпустить, и включаю параметр «Опрос SCM», который позволяет мне настроить веб-перехватчик Stash, чтобы сообщать Дженкинсу о каждом изменении. к этому репозиторию. Таким образом, задание может запускаться всякий раз, когда в репозиторий вносится изменение.

Но когда я использую рабочий процесс вместо проекта фристайл, SCM кода, который мне нужно построить, указывается программно в сценарии рабочего процесса groovy, что означает, что он не прослушивает веб-перехватчик Stash. Вместо этого SCM, настроенный непосредственно в рабочем процессе, является SCM самого groovy-скрипта, который отличается от кодовой базы, которую я пытаюсь создать/выпустить, поэтому я не хочу, чтобы триггер основывался на этом.

node('docker_builder') {
    git url: serviceRepo
    releaseVersion = getVersion()
    pipelineSpec = getPipelineSpec()
    sh "./gradlew clean build pushDockerImage"
}

Любые идеи о том, как добиться опроса SCM при использовании плагина рабочего процесса?


person gburton    schedule 29.06.2015    source источник


Ответы (1)


Я решил этот вопрос с помощью множества исследований и экспериментов. Эта документация навела меня на правильный путь: https://github.com/jenkinsci/workflow-scm-step-plugin/blob/master/README.md. В нем говорится:

Опрос поддерживается в нескольких SCM (изменения в одном или нескольких вызовут новую сборку) и снова выполняется в соответствии с SCM, использованными в последней сборке рабочего процесса».

Это означает, что опрос SCM по-прежнему поддерживается рабочим процессом Jenkins, но, в отличие от обычного проекта Freestyle, его необходимо один раз запустить вручную, прежде чем он начнет прослушивать изменения SCM. Это имеет смысл, поскольку SCM определены в коде Groovy; они не известны, пока не запустятся один раз.

Одним из сложных элементов этого является то, что вы можете определить множество SCM в своем рабочем процессе. Например, у меня их три: один для самой службы, сценарий развертывания и DSL рабочего процесса Groovy. По умолчанию изменения в любом из этих трех SCM приводят к тому, что параметр «SCM poll» запускает сборку, что может быть нежелательно. К счастью, установка параметра «poll: false» на шаге «git» в коде Groovy отключит опрос в этом репо. Если вы читаете свой Groovy DSL из SCM, вы можете отключить опрос в этом репо, щелкнув «дополнительные варианты поведения» в пользовательском интерфейсе Jenkins и добавив «Не запускать сборку уведомлений о фиксации».

Еще один сложный элемент заключается в том, что плагин веб-хука Stash по умолчанию включает хэш-код SHA1 коммита в URL-адрес RESTful, с которым он обращается к Дженкинсу. К сожалению, Jenkins совершает ошибку, используя один и тот же код фиксации, когда пытается получить любой из нескольких SCM, которые вы, возможно, определили. Хэш-код, конечно, относится только к одному SCM, поэтому он ломается. Вы можете обойти это, установив «Опустить хэш-код SHA1» в плагине веб-хука Stash. Затем Jenkins просто будет использовать последнюю фиксацию для любой ветки, из которой вы строите в каждом из ваших SCM.

person gburton    schedule 30.06.2015