Passer Jenkins construire des paramètres de pipeline nœuds

J'ai créé un nouveau Jenkins pipeline. Le pipeline est (pour l'instant) paramétrés avec une seule option booléenne nommée VAR_A. Mon pipeline script est:

node ('windows') {
    echo "$VAR_A"
    bat 'env'
}

Quand je créer manuellement le projet avec VAR_A cochée, le "vrai" est fait l'écho, comme prévu. La liste des variables d'environnement, cependant, ne montre pas VAR_A=true.

Je suis en mesure d'obtenir env pour montrer VAR_A si je encapsuler l'appel à un withEnv bloc:

node ('windows') {
    echo "$VAR_A"
    withEnv(["VAR_A=$VAR_A"]) {
        bat 'env'
    }
}

Je vais plus de paramètres que cela, de sorte que la spécification de chaque paramètre individuellement n'est pas souhaitée. Est-il un moyen de transfert de construire tous les paramètres d'un nœud de l'environnement?

OriginalL'auteur Tim Cooper | 2016-05-06

  1. 10

    Le fait est que dans le Pipeline de scripts les paramètres de travail ne sont pas rejetées dans l'environnement automatiquement comme pour les emplois réguliers. Chaque paramètre est une variable de la Canalisation script la liaison. Donc vous pouvez y accéder directement par leur nom.

    Dans votre exemple echo "$VAR_A" variable de substitution est effectuée par groovy dans le cadre de votre script (voir Groovy de la doc sur les chaînes d'interpolation). C'est pourquoi vous ne le voyez pas dans la bat de sortie.

    Pour chaque paramètre que vous voulez injecter, vous devez ajouter une ligne comme ceci:
    env.VAR_A = VAR_A au début de votre script. Il peut être en dehors de node bloc parce que env est globale au sein de l'ensemble du script.

    Sinon il y a un moyen d'ajouter de tout le script de vars, y compris les paramètres et même Pipeline intégré à vars c'est à dire steps dans l'environnement. Malheureusement, il faudra un peu de la liste blanche pour s'exécuter dans un bac à sable:

    @NonCPS
def populateEnv(){ binding.variables.each{k,v -> env."$k" = "$v"} }
populateEnv()

    Exemple:
    VAR_A est un paramètre.
    Corps d'un Script: 

    def AAAA = 1 //such a definition doesn't put variable in the binding
BBBB = 2     //creates a binding variable. Absolutely the same behavior as for a job parameter.

@NonCPS
def populateEnv(){ binding.variables.each{k,v -> env."$k" = "$v"} }
populateEnv() //at this point injection happens

CCCC = 3      //created after the injection hence it won't appear in env.
node ('windows') {
    bat 'env'
}

    Dans le bat de sortie vous trouverez VAR_A et BBBB.

    De l'OMI, à moins que votre travail a des dizaines de paramètres définis env.VAR_A = VAR_A approche est privilégiée car de plus simple, simple, et ne nécessitant pas d'approbation.

    OriginalL'auteur izzekil