2016-11-28 34 views

答えて

0

まず、あなたのコードにJenkinsfileが必要ないのはなぜですか?パイプラインは、ビルドファイルと同じくらいコードの一部です。

それ以外の場合は、groovyファイルをロードして、パイプラインスクリプトとして評価することができます。 from SCMオプションを使用して別の場所からこれを実行し、実際のコードをチェックアウトすることができます。しかし、これにより、あなたは手動でブランチビルドの世話をする必要があります。

もう1つのオプションは、単に外部パイプラインをチェックアウトする非常に基本的なJenkinsfileを持つことです。

node{ 
    deleteDir() 

    git env.flowScm 
    def flow = load 'pipeline.groovy' 
    stash includes: '**', name: 'flowFiles' 

    stage 'Checkout' 
    checkout scm // short hand for checking out the "from scm repository" 

    flow.runFlow() 
} 

pipeline.groovyファイルは次のようになり、実際のパイプラインが含まれます:私はあなたと同じ問題に遭遇した

def runFlow() { 
    // your pipeline code 

} 

// Has to exit with 'return this;' in order to be used as library 
return this; 
+0

をビルドスクリプトはビルド環境に依存しているため、オープンソースプロジェクトに含まれています。ツールへの絶対パスが含まれており、特定のOS /ツールのバージョンなどに依存しています。彼らはリポジトリでは全く役に立たないでしょう。CI-as-codeは、プロプライエタリな製品には最適です。 –

1

あなたはこのような何かを得るでしょう。ビルドプロセスをコードの一部として持つアイデアは良いですが、Jenkinsfileには、プロジェクトビルド自体に固有のものではなく、変更可能なビルド環境インスタンスに固有のものが含まれているという情報があります。

私はこれを達成する方法である:

  1. は、単一のスクリプト(build.py又はbuild.sh)内のコアビルドプロセスをカプセル化。これは等のメイク、CMakeの、アリ、などの具体的なビルドツールを呼び出すことが

  2. はグローバルジェンキンスはビルドを呼び出すための関数を構築定義する単一のグローバルライブラリに定義された関数を呼び出すためにJenkinsfile経由ジェンキンスに知らせます適切な環境設定でスクリプト(例:build.py)を実行します。たとえば、カスタムツールを使用してPATHを設定します。

ので、ステップ2のために、ちょうどラインPROJECTNAMEは、プロジェクトの名前に基づいて

build_PROJECTNAME() 

含むプロジェクト内Jenkinsfileを作成します。

その後Pipeline Shared Groovy Libraries Pluginを使用して環境を設定し、プロジェクトのビルドスクリプト(例えばbuild.py)を呼び出すコード含むvars/build_PROJECTNAME.groovyと呼ばれる共有ライブラリリポジトリ内のGroovyスクリプトを作成:私はしたくない

def call() { 
    node('linux') { 
     stage("checkout") { 
      checkout scm 
     } 
     stage("build") { 
      withEnv([ 
       "PATH+CMAKE=${tool 'CMake'}/bin", 
       "PATH+PYTHON=${tool 'Python-3'}", 
       "PATH+NINJA=${tool 'Ninja'}", 
      ]) { 
       execute 'python build.py' 
      } 
     } 
    } 
} 
関連する問題