2016-11-28 87 views

回答

0

首先,爲什麼你不想在代碼中使用Jenkinsfile?流水線和代碼文件一樣重要。

除此之外,你可以加載groovy文件作爲管道腳本進行評估。您可以從SCM選項的不同位置執行此操作,然後檢出實際的代碼。但這會迫使您手動處理分支構建。

另一種選擇是擁有一個非常基本的Jenkins文件,只檢出一個外部管道。

你會得到這樣的事情:

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作爲代碼非常適合專有產品,這絕對會*在企業環境中建立。 –

1

我也遇到同樣的問題,因爲你。儘管將構建過程作爲代碼的一部分的想法很好,但有信息表明Jenkinsfile包含的內容不是項目構建本身固有的,而是特定於可能更改的構建環境實例。

我做到了這一點的方法是:

  1. 封裝核心構建過程中的一個腳本(build.pybuild.sh)。這可以調用特定的構建工具,如製作,CMake的,螞蟻等

  2. 通過Jenkinsfile告訴詹金斯來調用一個全局庫中定義的函數

  3. 定義全局詹金斯建立函數來調用編譯腳本(例如build.py)與適當的環境設置。例如,使用自定義工具並設置PATH

所以對於第2步,在項目中創建一個Jenkinsfile只包含線

build_PROJECTNAME() 

其中PROJECTNAME是基於項目的名稱。

然後使用Pipeline Shared Groovy Libraries Plugin,並呼籲vars/build_PROJECTNAME.groovy包含設置環境和調用項目構建腳本的代碼(例如build.py)共享庫的儲存庫創建一個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' 
      } 
     } 
    } 
}