所以真的一般在使用上實際都會使用"Pipeline Job"
Pipeline Job:
- 適合應用於CI/CD設計
- 主要設計其腳本(Script) — Pipeline as Code
下面開始演示如何設計Pipeline Job:
當使用到上圖中Pipeline script選項時,將在UI介面內直接撰寫Groovy腳本
並且可以注意到右邊有提供一些範例Script:
選取後會看到:
也有:
另外可以看到:
當上圖中的Use Groovy Sandbox項目勾起來時
代表可以使用有限的Groovy的Function,而不需要admin核准
但是以上的Pipeline並不是最佳的撰寫方式
在InfraStructure as Code的概念下的Best Practice
是要將Pipeline納入Git(Repository)版控
所以下面將選擇另一個選項:
SCM選擇git:
來到github:
建立git憑證帳號密碼資訊:
回頭繼續設定pipeline:
改成正確的憑證:
先將上面的pipeline設定儲存
並且注意到我目前尚未在Git Repo內放入Jenkinsfile
嘗試直接執行Job:
為了後面展示方便,我後面複製建立另一個git branch — jenkins-jobs
接著就是要開始寫一個Jenkinsfile的Script擺上去
一般標準來說名稱就會叫做:Jenkinsfile
並且大致有分做兩種格式:
- Scriped
- Declarative
Scriped:
- 為第一個Jenkinsfile語法,並有較高的彈性,但是相對也比較難
- 基本結構如下:
Declarative:
- 則是比較建議使用的,雖然沒上面的強,但是比較容易使用
- 結構如下,使用pre-defined結構:
可以簡單整理上面兩個兩不同語法結構來說
- 其中右邊Declarative開頭一定是先宣告”pipeline”
- 接著跟著的agent代表要執行的Jenkins agent是誰
- (如果有建立Jenkins Cluster(多台)的話)
- 其中上面寫到的any指的是下一個可執行的agent
- 這邊有比較多的解釋:
- 接著stages意指"工作事項"的發生
- 並在裡面定義許多的stage & steps,基本可能如下gist:
首先就先把上述的內容放到git Repo新建的檔案內:
進到Console log畫面內看到:
再次比較為何要使用pipeline而不是前面幾篇學的freestyle方式設置:
- 不用受限於UI設定,無法執行複數複雜tasks
- 若有很多參數要設置,透過UI可能無法提供新的選項
- 後面會講到pipeline可以設置條件condition
- freestyle極度依賴plugin的功能
- 後面還會講到pipeline可以設變數
- 並且freestyle比較偏向單一Step設置,多個Step是要靠連串式的執行
...etc
下一篇開始整理比較複雜的Jenkinsfile也就是pipeline寫法
