以下為了demo
我從前面課程建立的"my-multi-branch-pipeline"這個Job複製出新的
上圖Save後會立刻進行branch掃瞄確認是否有對應的JenkinsFile:
後面的目標就是將之前做好的Jenkinsfile-mbp裡面
可以共用的邏輯做成groovy專案的Shared Library
然後改寫到後面一併要建立的Jenkinsfile-Use-SL裡面用呼叫的方式
建立groovy — Shared Library專案:
在eclipse內已安裝groovy套件情況下:
開始建立groovy專案:
初始的結構如下:
主要groovy專案的使用結構是vars目錄(等下會建立)
vars目錄裡面放置各種.groovy檔案
這也是Jenkinsfile會引用共用函式(SL)的入口
而在後面還可以將vars目錄內建立的.groovy的函式內容共同放到src目錄內
(後面會演示)
目前先用簡單的vars目錄,先把它建立並開一個.groovy檔
i.e.最終順序是Jenkinsfile呼叫->vars下的.groovy或調用->src下的函式
1.這邊先把vars目錄建立出來:
2.在vars目錄內建立buildJar.groovy檔案:
然後就可以開始撰寫邏輯了:
其中要注意的是,上面的buildJar.groovy的名稱:buildJar
就將會是Jenkinsfile呼叫的函式名稱!
基本寫法如下:
但是有些開發工具會認不得.groovy檔,所以其實可以加入shebang宣告
第一支完成的內容如下:
同理再做一支打包image的來取代以下:
目前就先做這兩支SL來用用
3.接著要把它掛上github使用:
先到github上建立新的jenkins-shared-library的Repo!!
跳出相關的git命令可以參考:
接著在本機專案目錄打開git bash,執行git init:
連結github Repo專案,執行上面有提示的指令:
git remote add origin https://github.com/JavaNoobPig/jenkins-shared-library.git
接著把目前的code add/commit:
接著推上github,但是本機用的branch名稱是master,我希望推成遠端main
先切換branch名稱:
git branch -M main推上遠端main branch:
git push -u origin main
看到遠端github:
Jenkins Server引入該Shared Library專案:
在組態設定裡面的Global Pipeline Libraries內新增(記得這是整個Jenkins Job可供使用)
填入以下資訊後建立:
上述儲存後
以下github上的groovy library就可供所有的Jenkins pipeline使用了
改寫Jenkinsfile,準備調用,先來看看原本有使用到script.groovy的branch:
另外
而我前面複製出來的新的Jenkins Job使用的Jenkinsfile名稱是要:
所以我嘗試在jenkins-jobs-pipeline內建立新的叫Jenkinsfile-Use-SL:
內容先使用上面的Jenkinsfile拿來改:
當前內容先加入shebang後長以下這樣:
開始改造上述內容,另外我們可以注意到我目前只製作了兩個stage的函式
所以最後deploy還是會用到既有的肚子內的script.groovy內定義的
這非常合理,總有部分函式會根據專案或branch有各自的差異
沒辦法都用共用的函式
中間兩步驟要改使用共用的SL,要在開頭先import進去:
另外講師特別提醒,如果這個過程我們並沒有使用def gv的宣告時候
宣告@Library那一行的結尾必須要加入一個下底線!
類似像下面這樣:
接著改寫要替換的兩個步驟:
當前完整如下:
將內容commit進去:
執行Job測試:
接著回頭前面建立的新的Job測試,執行:
另外console log裡面也是正常,太長了就不放上來了
在dockerhub也可以看到結果:
這邊我做個短短的小結論:
我設定了全部Job都可以調用的groovy的shared library:
複製了一個multi-branch-pipeline:
使用全新的Jenkinsfile,名稱為:Jenkinsfile-Use-SL
也真的寫出來,並且裡面真的嘗試使用shared library的函式:
最終也真的成功!
進階改造,可以傳入參數的shared library:
當前我們有一個SL(共用)函式長以下這樣:
有一個明顯的缺點就是image名稱居然寫死的
還好改寫很簡單,如下(記得有變數的要改用雙引號):
因為現在是IDE內,所以直接改一改:
另外一個也可以改造,原本長這樣:
改一下帶個非傳入的變數:
然後用git工具推上去!
但是其實還可以更進一步改寫這個SL專案
在src目錄內,可以彙整整個vars目錄內的函式邏輯內容
所以還需要另外改寫為以下:
在這個package內建立Docker.groovy來統整函式邏輯:
接著貼上vars目錄上的函式內容:
但是其實這邊會有一個問題
在以下目錄底下的groovy其實無法辨識指令或變數:
這時候就要透過剛剛建構子的script來使用這些指令或變數
因為script代表著vars裡面的groovy物件:
完整如下:
而真正呼叫的vars目錄下的groovy檔案則改寫為以下
為了更清楚的辨別,我額外加幾個字:
然後就是add commit 推:
此時github上面的shared library的就準備好了,但是呼叫方的還沒改好
也有透過參數push上dockerhub:
小結一下:
目前就好像將vars目錄下的groovy檔案其名稱當作介面層
用以呼叫實際撰寫邏輯內容的src底下的groovy內容
同理可以在Docker.groovy內定義多個可以使用的函式:
完整如下:
改造vars目錄下的groovy檔案:
新增:
再建立新的dockerPush.groovy檔:
當然也再做一支打包的:
原本的大支的buildAndPushImage.groovy就放著不使用了
接著改寫Jenkinsfile-Use-SL內容,改呼叫剛剛上面新建立的,原本:
改為:
記得改到git上面:
剛剛改的SL專案也要推上去:
再次執行:
發現這個沒改到:
改成:
然後再跑一次就成功了:
<<<<心得:真的要很細心才有辦法這樣搞>>>>
最後由前面的SL學習到如何製作出所有Job都可以取用的SL(shared library)
但是如果有人小心眼一點,做了SL只想給自己的Job使用的話呢?
其實也有辦法!
首先:
移除儲存後
接著就要改變引用github上的SL的方式
也就是要改寫Jenkinsfile →Jenkinsfile-Use-SL
為了保留一份,我另外複製一個新的Jenkins Job出來
當下儲存依樣會自動掃描有沒有對應的Jenkinsfile
如上當然沒有,所以這時候就去github建立
要改寫為自己引入SL,改造成:
完整如下:
一樣commit進git內:
執行Job:
上圖結果i.e.是pipeline Job本身自己去git上面取用SL專案
而不是統一透過Jenkins取得SL專案內容
這整篇有點難度,課程內容很長,反覆看了幾遍才一次寫完
但是可以清楚理解其概念
