2017-04-07 9 views
1

Jenkinsfileを使用するいくつかのプロジェクトは実質的に同じです。唯一の違いは、チェックアウトしなければならないgitプロジェクトです。これは、彼らが同じものを共有できるものの、プロジェクトごとに1つのJenkinsfileを持つために私を強制的に:Jenkinsfileが定義済みの変数を使用するようにJenkins 2パイプラインを設定する方法

node{ 
    def mvnHome = tool 'M3' 
    def artifactId 
    def pomVersion 

    stage('Commit Stage'){ 
     echo 'Downloading from Git...' 
     git branch: 'develop', credentialsId: 'xxx', url: 'https://bitbucket.org/xxx/yyy.git' 
     echo 'Building project and generating Docker image...' 
     sh "${mvnHome}/bin/mvn clean install docker:build -DskipTests" 
    ... 

私は同じJenkinsfileを再利用することができますので、ジョブの作成時に変数としてGitの場所を事前設定する方法はありますか? >文字列パラメータ - - > GIT_REPO_LOCATION、デフォルト= http://xxxx、およびenv.GIT_REPO_LOCATIONでそれにアクセスするこのプロジェクトは、パラメータ化されている

... 
    stage('Commit Stage'){ 
     echo 'Downloading from Git...' 
     git branch: 'develop', credentialsId: 'xxx', url: env.GIT_REPO_LOCATION 
    ... 

私は私がこのようにそれを設定することができます知っています。

ユーザーにとっては、デフォルト値でビルドを開始するか、または変更することが約束されています。私はそれが彼には透明である必要があります。それを行う方法はありますか?代わりに、各GitのリポジトリにJenkinsfileを持つの

答えて

1

Pipeline Shared Groovy Library pluginを使用すると、すべてのプロジェクトがgitリポジトリで共有するライブラリを使用できます。 documentationでは詳細を読むことができます。

大部分が類似しているパイプラインがたくさんある場合、グローバル変数メカニズムは、類似性をキャプチャするより高レベルのDSLを構築するための便利なツールを提供します。いずれかのグローバル共有ライブラリ として、またはとしてロードされた

// vars/buildPlugin.groovy 
def call(body) { 
    // evaluate the body block, and collect configuration into the object 
    def config = [:] 
    body.resolveStrategy = Closure.DELEGATE_FIRST 
    body.delegate = config 
    body() 

    // now build, based on the configuration provided 
    node { 
     git url: "https://github.com/jenkinsci/${config.name}-plugin.git" 
     sh "mvn install" 
     mail to: "...", subject: "${config.name} plugin build", body: "..." 
    } 
} 

スクリプトを仮定すると、たとえば、すべてのジェンキンスのプラグインが組み込まれていると同じ方法で試験、私たちはbuildPluginという名前のステップを書くかもしれませんフォルダレベルの共有ライブラリたJenkinsfileは 劇的に簡単になります。

Jenkinsfile(スクリプトパイプライン)

buildPlugin { 
    name = 'git' 
} 

この例は、jenkinsfileがname = gitをライブラリに渡す方法を示しています。 私は現在同様の設定を使用しており、とても満足しています。

+0

提案してくれてありがとう、私は次の日にそれを試して、いくつかのフィードバックを返します。 – codependent

+0

マルチブランチパイプラインの使用を検討してください。次に、ジーンキンは各ブランチに別々のサブジョブを表示します。それはより良いビジュアライゼーションで、各ブランチの手動ビルドを開始できます。 – herm

0

は、あなたが共通Jenkinsfile取得する場所から追加のgitリポジトリを持つことができます - パイプライン型ジョブを使用してSCMからオプションパイプラインのスクリプトを選択するとき、これは動作します。このようにして、Jenkinsはユーザーリポジトリをチェックアウトする前に共通のJenkinsfileを持っているレポをチェックアウトします。

ジョブが自動的にトリガされる場合は、repoをパラメータとしてJenkinsパイプラインを呼び出す各gitリポジトリにポスト受信フックを作成して、手動でジョブを実行する必要はありませんパラメータとしてのリポジトリ(GIT_REPO_LOCATION)

ジョブを自動的にトリガーすることができない場合は、の選択パラメータに文字列パラメータの代わりにリポジトリのリストを指定することが考えられます。

関連する問題