カスタムツールプラグインを介してJenkins内で定義されたカスタムツールがあります。フリースタイルプロジェクトを作成すると、Install custom tools
オプションが実行中にツール(Salesforce DX)を正しく検出して使用します。
ただし、パイプラインファイルを介して同じことを行う方法を見つけることができません。パイプライン構文スニペットジェネレーターを使用して、以下を取得しました。
tool name: 'sfdx', type: 'com.cloudbees.jenkins.plugins.customtools.CustomTool'
私はそれを私のステージ定義に入れました:
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')
}
しかし、line 2: sfdx: command not found
というエラーメッセージが表示されます
このスニペットを使用する他の方法はありますか?
情報のための完全なJenkinsfile:
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)
}
}
[〜#〜] update [〜#〜]この例のJenkinsfile を使用してある程度の進歩を遂げました私のステージは次のようになります。
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"
}
残念ながら、Jenkinsがsfdxツールを見つけて実行しているように見えますが、新しいエラーが発生します。
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
私は同じ問題に遭遇しました。私はこの回避策にたどり着きました:
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>"
}
}
}
どういうわけか、ツールパスはデフォルトでPATH
に追加されません(私の1.6 Jenkinsサーバーのインストールで慣例であったように)。 batコマンドの実行時に${groovy_home}
を追加すると、修正されます。ツールを呼び出すこの方法は、基本的にスクリプト化されたパイプライン構文から貸与されます。私はこれをすべてのカスタムツール(グルービーだけでなく)に使用しています。
ツール部分:
tool name: 'Groovy-2.4.9', type: 'hudson.plugins.groovy.GroovyInstallation'
あなたがしたようにスニペットジェネレータによって生成されました。
Jenkinsユーザーのメーリングリスト によると、決定的な解決策の作業はまだ進行中であるため、私の解決策は実際には回避策です。
スタックオーバーフローについてコメントするのはこれが初めてですが、私はこの答えを数日間探していて、潜在的な解決策があると思います。 Fholstの回答を確認して、さらに詳しく説明したいと思います。その環境スタンザは宣言型構文で機能すると思いますが、スクリプトパイプラインでは、同等のwithEnv()を使用し、gStringを介してツールを渡す必要があります:つまり、$ {tool'nameOfToolDefinedInGlobalTools '}。私の特定のユースケースでは、私の制御が及ばない理由で、jenkinsホストマシンにMavenがインストールされていませんが、グローバルツール構成内に定義されているものがあります。これは、ステップ内でshコマンドを実行する前に、パスにmvnを追加する必要があることを意味します。私ができることはこれです:
withEnv(["PATH+MVN=${tool 'NameOfMavenTool'}/bin"]){
sh '''
echo "PATH = ${PATH}"
'''
}
これにより、必要なものが得られるはずです。 sh行の三重一重引用符は無視してください。実際にはいくつかの環境変数がロードされており、それらをスニペットから削除しただけです。
これが何日もこのソリューションを探している人に役立つことを願っています。あなたの痛みが分かります。宣言型パイプラインスクリプトのコンソール出力(tools {}スタンザを使用する場合は、それらの環境変数を構築し、後続の宣言型ステップをラップする方法を示します)と次のリンクを調べて、これをまとめました: https: //go.cloudbees.com/docs/cloudbees-documentation/use/automating-projects/jenkinsfile/
Windowsを使用している場合は、sfdxインストールフォルダへのパスが原因で問題が発生している可能性があります。 Dreamhouse JenkinsfileはLinuxシェルまたはMacターミナル用に作成されているため、Windowsで動作させるにはいくつかの変更が必要です。
${sfdxLoc}/sfdx
する必要があります
\"${sfdxLoc}/sfdx\"
コマンドラインがスペースを適切に処理できるようにします。
https://wipdeveloper.com/2017/06/22/salesforce-dx-jenkins-jenkinsfile/