Jenkins Pipeline - Comment utiliser l'option 'tool' pour spécifier un outil personnalisé?

Question

J'ai un outil personnalisé défini dans Jenkins via le plugin Custom Tools. Si je crée un projet freestyle, l'option Install custom tools trouve et utilise correctement l'outil (Salesforce DX) pendant l'exécution.

Cependant, je ne peux pas trouver un moyen de faire la même chose via un fichier pipeline. Je l'ai utilisé le générateur d'extrait de syntaxe de pipeline pour obtenir:

tool name: 'sfdx', type: 'com.cloudbees.jenkins.plugins.customtools.CustomTool'

J'ai mis cela dans ma définition de la scène:

stage('FetchMetadata') { print 'Collect Prod metadata via SFDX' tool name: 'sfdx', type: 'com.cloudbees.jenkins.plugins.customtools.CustomTool' sh('sfdx force:mdapi:retrieve -r metadata/ -u DevHub -k ./metadata/package.xml') }

mais je reçois un message d'erreur indiquant line 2: sfdx: command not found

Y a-t-il une autre façon d'utiliser cet extrait?

pleine Jenkinsfile pour info:

node { currentBuild.result = 'SUCCESS'

try { 
     stage('CheckoutRepo') { 
      print 'Get the latest code from the MASTER branch' 
      checkout scm 
     } 

     stage('FetchMetadata') { 
      print 'Collect Prod metadata via SFDX' 
      tool name: 'sfdx', type: 'com.cloudbees.jenkins.plugins.customtools.CustomTool' 
      sh('sfdx force:mdapi:retrieve -r metadata/ -u DevHub -k ./metadata/package.xml') 
     } 

     stage('ConvertMetadata') { 
      print 'Unzip retrieved metadata file' 
      sh('unzip unpackaged.zip .') 
      print 'Convert metadata to SFDX format' 
      sh('/usr/local/bin/sfdx force:mdapi:convert -r metadata/unpackaged/ -d force-app/') 
     } 

     stage('CommitChanges') { 
      sh('git add --all') 
      print 'Check if any changes need committing' 
      sh('if ! git diff-index --quiet HEAD --; then echo "changes found - pushing to repo"; git commit -m "Autocommit from Prod @ $(date +%H:%M:%S\' \'%d/%m/%Y)"; else echo "no changes found"; fi') 
      sshagent(['xxx-xxx-xxx-xxx']) { 
       sh('git push -u origin master') 
      } 
     } 
    } 
    catch (err) { 
     currentBuild.result = 'FAILURE' 
     print 'Build failed' 
     error(err) 
    } 

}

MISE À JOUR J'ai fait quelques progrès en utilisant this example Jenkinsfile Mon scène ressemble maintenant à ceci: stage('FetchMetadata') { print 'Collect Prod metadata via SFDX' def sfdxLoc = tool 'sfdx' sh script: "cd topLevel; ${sfdxLoc}/sfdx force:mdapi:retrieve -r metadata/ -u DevHub -k ./metadata/package.xml" }

Malheureusement, bien qu'il semble que Jenkins est maintenant de trouver et d'exécuter l'outil de sfdx, je reçois une nouvelle erreur:

TypeError: Cannot read property 'run' of undefined at Object.<anonymous> (/var/lib/jenkins/.cache/sfdx/tmp/heroku-script-509584048:20:4) at Module._compile (module.js:570:32) at Object.Module._extensions..js (module.js:579:10) at Module.load (module.js:487:32) at tryModuleLoad (module.js:446:12) at Function.Module._load (module.js:438:3) at Module.runMain (module.js:604:10) at run (bootstrap_node.js:394:7) at startup (bootstrap_node.js:149:9) at bootstrap_node.js:509:3

Answer 1

Vous pouvez avoir un problème en raison du chemin de votre sfdx de dossier d'installation si vous êtes sur Windows. Le Dreamhouse Jenkinsfile a été écrit pour un shell Linux ou un terminal Mac. Certaines modifications sont donc nécessaires pour le faire fonctionner sous Windows.

${sfdxLoc}/sfdx 

devrait être

\"${sfdxLoc}/sfdx\" 

Alors que la ligne de commande gère les espaces correctement.

https://wipdeveloper.com/2017/06/22/salesforce-dx-jenkins-jenkinsfile/

Answer 2

je suis tombé sur le même problème. Je suis arrivé à cette solution de contournement:

environment { 
    GROOVY_HOME = tool name: 'Groovy-2.4.9', type: 'hudson.plugins.groovy.GroovyInstallation' 
} 
stages { 
    stage('Run Groovy') { 
     steps { 
      bat "${groovy_home}/bin/groovy <script.name>" 
     } 
    } 
} 

D'une certaine façon le chemin de l'outil est ajouté à PATH par défaut (comme il était d'usage sur mon serveur Jenkins 1.6 installer). L'ajout de ${groovy_home} lors de l'exécution de la commande bat corrige cela pour moi. Cette façon d'appeler un outil est essentiellement empruntée à la syntaxe de pipeline scriptée. Je l'utilise pour tous mes outils personnalisés (pas seulement groovy).

La partie de l'outil:

tool name: 'Groovy-2.4.9', type: 'hudson.plugins.groovy.GroovyInstallation' 

a été générée par le générateur d'extrait comme vous l'avez fait.

Selon le Jenkins users mailing list, le travail est toujours en cours pour une solution définitive, donc ma solution est vraiment un travail.