Как загрузить еще один отличный скрипт в тот же узел Jenkins?

При загрузке сценария конвейера из другого сценария конвейера два конвейера не выполняются на одном и том же узле: первый выполняется на моем главном узле, а второй выполняется на подчиненном узле.

Я использую конвейеры Jenkins с опцией Pipeline Script from SCM для множества заданий таким образом:

  • Каждое из моих заданий определяет соответствующий URL-адрес репозитория Git с параметром Poll SCM, чтобы репозиторий автоматически опрашивался при внесении изменений в мой код (базовое использование задания).

  • Каждое из моих заданий определяет простой Jenkinsfile в корне своего репозитория, а сценарий конвейера внутри в основном не делает ничего, кроме загрузки более общего конвейера.

E.g. :

node {
    // --- Load the generic pipeline ---
    checkout scm: [$class: 'GitSCM', branches: [[name: '*/master']], extensions: [], submoduleCfg: [], userRemoteConfigs: [[url: 'http://github/owner/pipeline-repo.git']]]
    load 'common-pipeline.groovy'
}()

Мой конвейер common-pipeline.groovy выполняет фактическую работу, такую ​​как создание, выпуск или развертывание артефактов, например :

{ ->
    node() {
        def functions = load 'common/functions.groovy'

        functions.build()
        functions.release()
        functions.deploy()
    }
}

Теперь я не хочу форсировать узел для каждого задания, поэтому оба конвейера имеют node("master") или node("remote"), потому что я действительно не хочу обрабатывать это вручную, но я бы хотел, чтобы когда-то первый конвейер выполняется на определенном узле (либо master, slave1, slave2, slave3) выполняется второй / загруженный конвейер на том же узле, потому что в противном случае мой фактический код репозитория Git недоступен из рабочей области другого узла ...

Есть ли способ указать, что я хочу, чтобы мой второй конвейер выполнялся на том же узле, что и первый, или, может быть, передать аргумент при использовании шага load?


jenkins jenkins-pipeline jenkinsfile
person Pom12    schedule 10.08.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Как насчет сохранения рабочего пространства после оформления заказа и до загрузки скрипта ?:

e.g. 

stash includes: '**', name: "source"

а затем распаковать его в другом разделе node () {}:

e.g. unstash "source"

Таким образом, он будет доступен на другом узле.

Но не забудьте навести порядок на рабочем месте.

Или как насчет создания общей функции, которая также содержит логику для проверки (возможно, передавая ветки в качестве параметра). Затем вы можете отказаться от node () {} в файле Jenkins и просто использовать записи node () {} в вашем общем Groovy-скрипте?

например Jenkinsfile

load 'common-pipeline.groovy'
createWorlflow("*/master")

common-pipeline.groovy:

def createWorkflow(branches){
node() {
        def functions = load 'common/functions.groovy'
        functions.checkout(branches)
        functions.build()
        functions.release()
        functions.deploy()
    }
}
person GCDev    schedule 25.08.2016
comment
Stash / Unstash казался отличной идеей, к сожалению, по какой-то причине я не могу добраться до закрытия common-pipeline, команда загрузки не выполняется перед выполнением общего закрытия ... Загрузка второго скрипта как функции тоже хорошая идея, так как это обеспечит мне что оба шага выполняются на одном и том же узле, но проверка внутри функции createWorkflow означает, что я дублирую этап проверки (уже выполненный Jenkins с конфигурацией Poll SCM) ... Я думаю, что пытаюсь объединить ваши два решения: вызов функции и отключение моего начального рабочего пространства в моей загруженной функции ... - person Pom12; 29.08.2016
comment
На самом деле я никогда не смогу спрятать проверку кода из конфигурации Poll SCM, потому что, когда мой код конвейера выполняется, я уже (потенциально) выполняю код на другом узле, и у меня нет контроля над выполнением Jenkins Poll SCM ... - person Pom12; 29.08.2016

arrow_upward
1
arrow_downward

Вы можете создать параметризованное задание для второго конвейера и использовать параметр для управления узлом при запуске второго задания.

Второй конвейер будет выглядеть так:

node(runhereParam) {

}
person JE42    schedule 20.08.2016
comment
Я не понимаю, как это решит мою проблему? Во-первых, я не хочу иметь отдельное запускаемое задание, потому что это вызовет проблемы с параллелизмом (10 из моих служб, работающих одновременно, должны будут ждать последовательного выполнения второго параметризованного задания), и поэтому я использую конвейеры, чтобы иметь возможность выполнять один и тот же код из разных заданий. Во-вторых, даже используя ваше решение, где мне взять параметр runhereParam для второго задания? Мне нужно, чтобы две части моего конвейера выполнялись на одном и том же узле! - person Pom12; 22.08.2016