2016-05-13 1 views
3

У меня есть следующий случай использования:Дженкинс Трубопроводы: Повторное использование рабочего пространство при загрузке на внешнюю Дженкинс Трубопроводного сценария

  1. Checkout/Pull определенной ревизии Git, используя написанный трубопроводный сценарий
    (мне это нужно, потому что Я извлечь ревизию динамически)

  2. от этого пересмотра, загрузите Jenkins трубопроводный файл, расположенный среди ранее проверил файлы

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

Проблемы: Загруженный Дженкинс-конвейерный-файл запускается на выполнение в нового рабочего пространства. Но он пуст. Мне нужно, чтобы этот файл был выполнен в в том же старом рабочем пространстве.

Я думал, возможно, из-за окружающих node, потому что ключевое слово node создает рабочие пространства, как указано в документах. Но когда я попытался загрузить его за пределамиnode, Дженкинс запретил это из-за «ухода из песочницы».

Примечание: файл jenkins-pipe-file найден и действительно выполнен. Проблема заключается в во время исполнения.


Пожалуйста, посмотрите на примере коде:

встраиваемого трубопровод сценарий

node('master') { 
    def latestBuildableRevision = readFile '/my/LATEST-BUILDABLE-REVISION.txt' 

    checkout poll:false, 
    scm:[$class:'GitSCM', branches:[[name:latestBuildableRevision]], 
    doGenerateSubmoduleConfigurations:false, 
    extensions:[[$class: 'CleanBeforeCheckout']], submoduleCfg:[], 
    userRemoteConfigs:[[credentialsId:'...', url:'...']]] 

    load 'further-script-logic.jenkins' 
} 

Файл: дальше-скрипт-logic.jenkins

node('master') { 
    // make use of certain files 
    // assumption: pwd() is the *same* workspace which were checked-out before 
    // problem: it's not, it's a new empty workspace 
} 

ответ

2

Обходным решением является described here.

  1. Вы должны использовать {...}() брекеты в конце сценария по вызывающего
  2. Вы должны переписать называемый сценарий вернуть замыкание (лямбда)
    {-> /* former code */ }

Таким образом, вы не «отдаете» управление потоком программы исполняемому сценарию. Вместо этого вы используете свое возвращенное закрытие и «назовите его сами». Это не позволяет Дженкинсу создавать дополнительные рабочие пространства.

К сожалению, я не знаю, могло ли это решение разрешить объявление нескольких узлов в сценарии вызова и/или в вызываемом скрипте.

Я включил эти изменения в ваш примерный код.
Ищите строки с пометкой "<--- CHANGE".

встраиваемого сценарий трубопровод

node('master') { 
    def latestBuildableRevision = readFile '/my/LATEST-BUILDABLE-REVISION.txt' 

    checkout poll:false, 
    scm:[$class:'GitSCM', branches:[[name:latestBuildableRevision]], 
    doGenerateSubmoduleConfigurations:false, 
    extensions:[[$class: 'CleanBeforeCheckout']], submoduleCfg:[], 
    userRemoteConfigs:[[credentialsId:'...', url:'...']]] 

    load 'further-script-logic.jenkins' 
}() // <--- CHANGE 1 

Файл: дальше-скрипт-logic.jenkins

{-> // <--- CHANGE 2 
    node('master') { 
    // ..... 
    } 
} 
+0

Отлично! И, несколько узлов в вызываемом скрипте DO работают! :) – Iviator

+0

Эта «особенность» была невероятно трудно обнаружить ... Я в восторге от того, что я ее нашел, но должен быть лучше документирован, и нерестование нескольких исполнителей на один конвейер выглядит нелепо и почти глючит, если вы спросите меня, это должна быть функция флажка «прикованное выполнение скрипта» или что-то в этом направлении – sloven

Смежные вопросы