【基礎(chǔ)幫助理解】學(xué)習(xí)Jenkins官方文檔

本文是閱讀了英文的Jenkins文檔后的筆記以及我的一些理解和小實(shí)踐。

1. Getting Started with Pipeline

official link:?https://www.jenkins.io/doc/book/pipeline/getting-started/#directive-generator

創(chuàng)建pipeline的三種方式:第一種通過Blue ocean,第二種是通過jenkins的UI直接寫腳本,第三種是通過SCM,先手動寫好一個(gè)Jenkinsfile,然后commit到repository中。

通過Blue Ocean

blue ocean可以幫助建立流水線,并且自動的幫忙寫pipeline,比如寫Jenkinsfile。在Blue ocean中創(chuàng)建流水線,Jenkins會和工程的source contro repository建立安全的連接,通過blue ocean改變的Jenkinsfile的修改都會自動保存和commit到source control中。

文檔:get started with Blue Ocean

安裝blue ocean

用帶有管理員權(quán)限的賬號登陸你的Jenkins,然后主頁上找到Manage Jenkins--->找到manage plugins--->可選插件(available)--->看是否會出來blue ocean,如果無,則在搜索欄輸入blue ocean,然后勾選blue ocean前面的框,先后選擇下載待重啟后安裝(推薦),這里重啟指的是重啟jenkins。

重啟Jenkins之后,會在主頁的左側(cè)出現(xiàn),打開blue ocean的一欄,則安裝成功。安裝成功之后,blue ocean不需要其他的配置。

進(jìn)入blue ocean

點(diǎn)擊“打開blue ocean”進(jìn)入blue ocean,如果在安裝blue ocean之前已經(jīng)創(chuàng)建了流水線,那么在blue ocean的主頁上會直接顯示出來創(chuàng)建的流水線。

使用blue ocean創(chuàng)建pipeline

在主頁點(diǎn)擊“創(chuàng)建流水線”,會首先需要選擇source control,比如是git,或者github,git repository支持local和remote的。在windows使用local repository在路徑上會有更多的要求,措意更加推薦在blue ocean中使用remote repository。

如果需要在直接給github上的工程創(chuàng)建pipeline,那么需要用到GitHub access token,可以重新創(chuàng)建添加進(jìn)去,或者使用已有的令牌。refer to “For a repository on GitHub” in this link: https://www.jenkins.io/doc/book/blueocean/creating-pipelines/

Pipeline editor

用戶可以用這個(gè)編輯器來修改聲明式流水線,添加stage和并行任務(wù)等。修改完成之后,編輯器會把Pipeline存為Jenkinsfile放在source code repository中。

使用這個(gè)編輯器的前提是,用戶必須先使用Blue ocean創(chuàng)建了一個(gè)流水線或者Jekins已經(jīng)有存在的流水線了。如果是修改已經(jīng)存在的流水線,那么需要這個(gè)流水線必須要允許將更改推送到repository中。

使用這個(gè)editor有一些限制:

SCM-based Declarative Pipelines only

Credentials must have write permission

Does not have full parity with Declarative Pipeline

Pipeline re-ordered and comments removed

(詳細(xì)使用步驟略....

經(jīng)過閱讀以上的文檔,我了解得到的是Blue ocean對幫助管理復(fù)雜的集成過程的流水線有很大的幫助,它可以可視化顯示流水線的運(yùn)行狀態(tài),出錯(cuò)時(shí),也能幫助到分析錯(cuò)到哪一步,同時(shí)它還能和repository相連接,盡管我認(rèn)為這對于公司內(nèi)部的項(xiàng)目來說,好處不大,因?yàn)椴淮罂赡苤苯釉贐lue ocean修改就把修改直接推送到repository中。

more information at?https://www.jenkins.io/doc/book/blueocean/

通過Jenkins的傳統(tǒng)UI

通過傳統(tǒng)UI創(chuàng)建的Jenkinsfile會通過Jenkins自己存儲,存在Jenkins的home directory中。創(chuàng)建基本條件:

1. 登錄到Jenkins

2. 新建item中創(chuàng)建pipeline,在創(chuàng)建時(shí)填入pipeline名字時(shí),避免使用空格等符號,因?yàn)镴enkins會用這個(gè)item名字來創(chuàng)建文件夾。

3. 在以下領(lǐng)域直接編寫Jenkinsfile,可以寫聲明式流水線或者腳本式流水線,我寫的是腳本式流水線,寫完之后保存,然后自動會回到該流水線主頁,可以選擇build now看看運(yùn)行結(jié)果。運(yùn)行結(jié)束之后可以點(diǎn)擊console output查看運(yùn)行的log輸出和結(jié)果。

腳本式流水線

Notes:

通過傳統(tǒng)UI定義流水線對于測試pipeline代碼片段、處理簡單的流水線或者是不需要從一個(gè)repository中checkout或者clone源代碼的流水線來說是很方便的。如上所述,與通過Blue Ocean或在源代碼管理中定義的Jenkins文件不同,傳統(tǒng)UI上編寫的Jenkinsfile由Jenkins自己存儲在Jenkins home目錄中。因此,為了更好地控制和靈活性您的管道,特別是對于源代碼管理中可能會增加復(fù)雜性的項(xiàng)目,建議使用Blue Ocean或源代碼管理來定義您的文件。

通過SCM

復(fù)雜的腳本難以用過Jenkins UI 完成。因此我們想要的Jenkinsfile可以在文本編輯器或者IDE中寫好,然后commit到source control中(可以選擇性的包含Jenkins會build的application)。Jenkins就可以從從source control中checkout Jenkinsfile,然后執(zhí)行pipeline。創(chuàng)建SCM中的Pipeline,首先在傳統(tǒng)UI上創(chuàng)建pipeline,然后在寫腳本的時(shí)候選擇如下界面中的選項(xiàng):

script from SCM

在SCM中選擇包含寫好的jenkinsfile的repository,在腳本路徑中,明確指出Jenkinsfile的位置或者是文件名,位置是Jenkins從repository中checkout或者clone Jenkinsfiile的位置,這個(gè)位置填寫需要遵循repository的文件結(jié)構(gòu)。腳本路徑的默認(rèn)值是默認(rèn)你的文件名是Jenkinsfile,并且默認(rèn)的位置是這個(gè)repository的根目錄。

更新指定的倉庫時(shí),只要配置了Pipeline的輪詢觸發(fā)器,就會trigger a new build。

tips:

由于流水線代碼(特別是腳本化管道)是用類似Groovy的語法編寫的,如果IDE語法不正確,那么請嘗試插入行#!/usr/bin/env groovy位于jenkins文件的頂部,[4]footnotegroovy\u shebang:[shebang line(groovy語法)],這可能會糾正這個(gè)問題。

內(nèi)置文檔(Built-in Documentation)

Pipeline附帶了內(nèi)置的文檔功能,可以更輕松地創(chuàng)建各種復(fù)雜的管道。這個(gè)內(nèi)置文檔是根據(jù)Jenkins實(shí)例中安裝的插件自動生成和更新的。

代碼段生成器(Snippet Generator)

內(nèi)置的代碼段生成器單元可以幫助生成某個(gè)步驟的代碼,發(fā)現(xiàn)插件提供的新步驟或者是測試某一步的不同參數(shù)。通過代碼段生成器生成一個(gè)步驟:

1. 找到“流水線語法”鏈接,點(diǎn)進(jìn)去選擇代碼段生成器

代碼段生成器

2. 在實(shí)例步驟中選擇一個(gè)想要的步驟,比如window bat script,然后在實(shí)例步驟的下一空白面中輸入想要寫的bat代碼的內(nèi)容,填入成功之后選擇生成流水線腳本。

代碼段生成器

全局變量引用(Global Variable Reference)

除了Snippet Generator(只顯示步驟)之外,Pipeline還提供了一個(gè)內(nèi)置的“全局變量引用”。與Snippet Generator一樣,它也由插件動態(tài)填充。但是,與代碼段生成器不同的是,全局變量引用僅包含管道或插件提供的變量文檔,這些變量可用于Pipeline。Pipeline中默認(rèn)提供的變量有:

env:

公開環(huán)境變量,例如:?for example:?env.PATH or env.BUILD_ID。請參閱${YOUR_JENKINS_URL}/pipeline syntax/globals#env上的內(nèi)置全局變量參考,以獲取流水線中可用環(huán)境變量的完整且最新的列表。

params:

將為管道定義的所有參數(shù)公開為只讀映射,例如:for example: params.MY_PARAM_NAME.

currentBuild:

可用于發(fā)現(xiàn)有關(guān)當(dāng)前正在執(zhí)行Pipeline的信息,其屬性如: currentBuild.result, currentBuild.displayName, etc. 請參閱${YOUR_JENKINS_URL}/pipeline-syntax/globals上的內(nèi)置全局變量參考,以獲取currentBuild上可用的完整且最新的屬性列表。

全局變量參考

聲明式指令生成器(Declarative Directive Generator)

代碼段生成器幫助流水線生成steps和stages,但是不包括用于定義聲明式流水線的?sections?and?directives,聲明式指令生成器就因此產(chǎn)生的。和代碼段生成器類似,聲明式指令生成器可以選擇一個(gè)Declarative directive,然后在一個(gè)表格中配置它,并且為這個(gè)directive生成配置。用聲明式指令生成器生成Declarative directive:

1. 打開“流水線語法”鏈接,然后找到Declarative Directive? Generator

2. 選擇想要的directive,然后填入必要的信息,點(diǎn)擊generate

Declarative Directive? Generator

以上便是1. Getting Started with Pipeline這個(gè)文檔的主要內(nèi)容,我閱讀下來,對于我掌握J(rèn)enkins的架構(gòu)還是有一些作用的,因?yàn)樵趯?shí)踐中,存在的很多漏洞在與閱讀文檔之后,還是有補(bǔ)上,但是這對于我做小項(xiàng)目還是不夠用的,因此我會參考官網(wǎng)文檔中further reading部分,繼續(xù)閱讀幾個(gè)文檔。

2. Using a Jenkinsfile

這個(gè)文檔是需要在閱讀1. Getting Started with Pipeline這個(gè)文檔的基礎(chǔ)之上的,會介紹更多有用的steps,通用模板,并且演示some?non-trivial Jenkinsfile examples.

official link:https://www.jenkins.io/doc/book/pipeline/jenkinsfile/

盡管也可以直接在Jenkins的傳統(tǒng)UI上定義一個(gè)Pipeline,但創(chuàng)建一個(gè)存入repository的Jenkinsfile還是最好的實(shí)踐,

Pipeline支持兩種語法,即是聲明式流水線和腳本式流水線(Declarative and Scripted Pipeline)。

創(chuàng)建流水線

聲明式流水線,必須包含agent關(guān)鍵字,缺乏這個(gè)關(guān)鍵字配置的流水線不是有效的,不會產(chǎn)生任何作用。stages還有steps也是需要的,它們指示Jenkins應(yīng)該執(zhí)行什么和在哪一個(gè)stage應(yīng)該執(zhí)行。

更高級的用法是使用腳本式流水線,對于這個(gè)流水線,node關(guān)鍵字是非常重要的第一步,它會這個(gè)Pipeline連接一個(gè)executor和workspace,么有node關(guān)鍵字,這個(gè)流水線不會有任何作用。有了node之后,第一任務(wù)應(yīng)該是checkout這個(gè)repository工程的source code,因?yàn)檫@個(gè)jenkinsfile就是從這個(gè)工程中拉下來的,所以對于流水線來說,它能更快更容易的獲得source code的正確版本。

Build

對于很多工程來說,流水線的第一步就是build階段,在這個(gè)階段source code會被組裝(assemble),編譯和打包。

Jenkins有很多插件來觸發(fā)不同平臺上的build,比如Linux/Unix上的make指令或者windows上的bat指令執(zhí)行的編譯。

Test

自動化測試對于持續(xù)繼承來說是很重要的,Jenkins支持一些系列的支持測試記錄,報(bào)告和可視化的工具的插件來做這件事。比如使用?junit?step。

Test

Deploy

根據(jù)項(xiàng)目或組織的需求,部署可能意味著各種步驟,可以是從將構(gòu)建的工件發(fā)布到工件服務(wù)器,到將代碼推送到生產(chǎn)系統(tǒng)的任何步驟。

腳本化流水線可以包括條件測試、循環(huán)、try/catch/finally塊甚至函數(shù)。

3. Working?with your Jenkinsfile

Using environment variables

Jenkins管道通過全局變量env公開環(huán)境變量,環(huán)境變量在Jenkinsfile的任何位置都是可用的??蓮腏enkins Pipleline中訪問的環(huán)境變量的完整列表記錄在${YOUR_Jenkins_URL}/Pipeline syntax/globals#env中,其中包括:

BUILD_ID:當(dāng)前的build ID,?identical to BUILD_NUMBER for builds created in Jenkins versions 1.597+

BUILD_NUMBER:當(dāng)前的build NUM,比如“153”

BUILD_TAG:jenkins的字符串-${JOB\u NAME}-${BUILD\u NUMBER}。方便地放入資源文件、jar文件等以便于識別

BUILD_URL:The URL where the results of this build can be found

JAVA_HOME:If your job is configured to use a specific JDK, this variable is set to the JAVA_HOME of the specified JDK. When this variable is set, PATH is also updated to include the bin subdirectory of JAVA_HOME

NODE_NAME:?The name of the node the current build is running on. Set to 'master' for the Jenkins controller.

WORKSPACE:The absolute path of the workspace

示例:

Jenkinsfile (Declarative Pipeline)

pipeline {? ??

? ? ? ? ?agent any? ??

? ? ? ? ?stages {? ? ? ??

? ? ? ? ? ? ? ?stage('Example') {? ? ? ? ? ??

? ? ? ? ? ? ? ? ? ? steps {? ? ? ? ? ? ? ??

? ? ? ? ? ? ? ? ? ? ? ? ? ?echo"Running ${env.BUILD_ID} on ${env.JENKINS_URL}"}? ? ? ??

? ? ? ? ? ? ? ? ? ? ? ?}? ??

? ? ? ? ? ? ? ? ?}

? ? }

Setting environment variables

在Jenkins Pipeline中設(shè)置環(huán)境變量的方式有所不同,這取決于使用的是聲明式流水線還是腳本式流水線。

聲明式流水線支持environment指令(supports an environment directive),而腳本式的流水線必須使用withEnv。

聲明式流水線environment

Notes:

An?environment?directive used in the top-level?pipeline?block will apply to all steps within the Pipeline.

An?environment?directive defined within a?stage?will only apply the given environment variables to steps within the?stage.

Setting environment variables dynamically

環(huán)境變量可以在運(yùn)行時(shí)設(shè)置,并且可以由shell腳本(sh)、Windows批處理腳本(bat)和PowerShell腳本(PowerShell)使用。每個(gè)腳本可以returnStatus或returnStdout。More information on scripts.

Handling credentials

####(這部分看完了之后暫時(shí)不知道具體意義體現(xiàn),暫時(shí)不做筆記,日后有了一定的實(shí)踐之后再來反復(fù)閱讀理解。)

字符串插值(String interpolation)

Jenkins使用的是和Groovy一直的規(guī)則。Groovy的字符串插值支持可能會讓許多語言新手感到困惑。Groovy支持用單引號或雙引號聲明字符串,?for example:

def singlyQuoted ='Hello'

def doublyQuoted ="World"

只有后一個(gè)字符串支持基于美元符號($)的字符串插值,例如,只有第二種echo輸出才會有讀到$后的內(nèi)容:

Groovy的字符串插值

字符串插值這部分主要介紹了單引號還有雙引號的一些差別和在不同場景的作用,暫時(shí)不多介紹了。

Handling parameters

聲明式pipeline支持out-of-the-box的參數(shù),Pipeline可以在運(yùn)行時(shí)通過parameters指令接受用戶指定的參數(shù)。使用腳本式Pipeline配置參數(shù)是通過“屬性”步驟(properties)完成的,該步驟可以在代碼段生成器中找到。(可以通過代碼段生成器來查看如何寫properties)

代碼段生成器之properties

如果使用build with parameters選項(xiàng)將Pipeline配置為接受參數(shù),則可以作為params變量的成員訪問這些參數(shù)。

將輸出:Hello World!

Handling failure

聲明式pipeline默認(rèn)情況下通過其post部分支持的故障處理,post部分允許聲明許多不同的“post條件”,例如:always、unstable、success、failure和changed。

聲明式流水線的故障處理

腳本式流水線依賴于Groovy內(nèi)置的try/catch/finally語義來處理流水線執(zhí)行期間的失敗。

Using multiple agents

Jenkins支持多個(gè)agent。

在下面的示例中,“構(gòu)建”階段將在一個(gè)代理上執(zhí)行,并且在“測試”階段期間,構(gòu)建結(jié)果將在兩個(gè)后續(xù)代理(分別標(biāo)記為“l(fā)inux”和“windows”)上重用。

Mutiple agents

Optional step arguments

Pipeline遵循Groovy語言的慣例,允許在方法參數(shù)周圍省略括號。

許多Pipeline步驟還使用命名參數(shù)語法(the named-parameter)作為在Groovy中創(chuàng)建映射的縮寫,Groovy使用語法[key1:value1,key2:value2]。做出如下功能等效的陳述:

示例

為方便起見,當(dāng)調(diào)用僅使用一個(gè)參數(shù)(或僅使用一個(gè)強(qiáng)制參數(shù))的步驟時(shí),可以省略參數(shù)名稱,例如:

示例

Advanced Scripted Pipeline

腳本式流水線是一種基于Groovy的領(lǐng)域?qū)S谜Z言(domain-specific language),大多數(shù)Groovy語法可以在腳本式流水線中使用,無需修改。

Parallel execution

Mutiple agents的示例代碼顯示以線性序列的形式跨兩個(gè)不同的平臺運(yùn)行測試。實(shí)際上,如果make check執(zhí)行需要30分鐘才能完成,“Test”階段現(xiàn)在需要60分鐘才能完成!但是Pipeline內(nèi)置了并行執(zhí)行腳本式Pipeline部分的功能,這個(gè)功能在parallel步驟中實(shí)現(xiàn)。

parallel step

以上代碼不再在“l(fā)inux”和“windows”標(biāo)記的節(jié)點(diǎn)上串行執(zhí)行測試,而是假設(shè)Jenkins環(huán)境中存在必要的容量,測試將并行執(zhí)行。

4. Branches and Pull Requests

暫略

5. Using Docker with Pipeline

許多組織使用Docker跨機(jī)器統(tǒng)一其構(gòu)建和測試環(huán)境,并提供部署應(yīng)用程序的有效機(jī)制。從Pipeline版本2.5和更高版本開始,Pipeline內(nèi)置了從文件中與Docker交互的支持。

暫略(因?yàn)楝F(xiàn)在不考慮用這個(gè))

6. Extending with Shared Libraries?

隨著一個(gè)組織中越來越多的項(xiàng)目采用Pipeline,很可能會出現(xiàn)通用模式。通常,在不同的項(xiàng)目之間共享Pipeline的一部分是有用的,這樣可以減少冗余并保持代碼“DRY”(reduce redundancies and keep code "DRY" )。

Pipeline支持創(chuàng)建“共享庫”,這些庫可以在外部源代碼管理存儲庫中定義并加載到現(xiàn)有Pipeline中。

7. Defining Shared Libraries

共享庫由名稱、源代碼檢索方法(如由SCM)和默認(rèn)版本(可選)定義。名稱應(yīng)該是一個(gè)簡短的標(biāo)識符,因?yàn)樗鼘⒃谀_本中使用。版本可以是該SCM可以理解的任何內(nèi)容;例如,分支、標(biāo)記和commits( branches, tags, and commit hashes )都適用于Git。您還可以聲明腳本是否需要顯式請求該庫,或者默認(rèn)情況下是否存在該庫。此外,如果在Jenkins配置中指定一個(gè)版本,可以阻止腳本選擇不同的版本。指定SCM的最佳方法是使用SCM插件,這個(gè)插件現(xiàn)在已經(jīng)有獨(dú)立的更新。在撰寫本文時(shí),最新版本的Git和Subversion插件支持這種模式;其他插件也應(yīng)該支持這種模式。如果SCM插件尚未集成,可以選擇Legacy SCM并選擇任何提供的插件。在這種情況下,需要在SCM配置中包括 $ {library.yourLibName.version} 以便在checkout 插件時(shí)通過這個(gè)變量選擇所需的版本。

例如,對于Subversion,可以將存儲庫URL設(shè)為?svnserver/project/${library.yourLibName.version},然后使用trunk或branchs/dev或tags/1.0等版本。

Directory structure

shared directory

暫略(內(nèi)容略深,需要時(shí)再回顧)


8. Pipeline Syntax (流水線語法)

Differences between top and stage level Agents

Top Level Agents

在流水線的最外層定義了agent,在進(jìn)入到這個(gè)agent之后調(diào)用選項(xiàng),例如,這個(gè)timeout是在myAgent的這個(gè)agent上執(zhí)行的

top-level agent

Stage Agents

聲明在stage內(nèi)的agent,調(diào)用選項(xiàng)會在進(jìn)入到這個(gè)這個(gè)agent之前或者檢查任何when條件之前執(zhí)行。例如,會在進(jìn)入到這個(gè)agent之前執(zhí)行timeout

stage-level agent

此timeout將包括agent設(shè)置時(shí)間,所以在agent分配延遲的情況下,管道可能會失敗。

Parameters

any

none

label:?A string. The label or label condition on which to run the Pipeline or individual?stage.

node: agent { node { label 'labelName' } }?behaves the same as?agent { label 'labelName' }, but?node?allows for additional options (such as?customWorkspace).

timestamps: 在流水線運(yùn)行生成的所有控制臺輸出前面加上打印該行的時(shí)間。例如:options{timestamps()}

timeout:為某個(gè)stages設(shè)置一個(gè)超時(shí)時(shí)間段,在此之后Jenkins應(yīng)該中止這個(gè)stage。例如:options{timeout(time:1,unit:'HOURS')}

retry:如果失敗,按指定次數(shù)重試此步驟。例如:options{retry(3)}

paramters:

paramters

Jenkins cron syntax:Jenkins cron語法遵循cron實(shí)用程序的語法(略有不同)。具體來說,每行由5個(gè)字段組成,用制表符或空格分隔,for example,

cron語法

stage:stage指令位于stages部分,應(yīng)該包含steps部分、可選agent部分或其他特定于階段的指令。實(shí)際上,流水線完成的所有實(shí)際工作都將封裝在一個(gè)或多個(gè)stage指令中。

parallel:流水線中的Stages中可以有一個(gè)并行部分,其中包含了要并行運(yùn)行的列表。需要注意的是,一個(gè)stage必須只有steps、stage、parallel或matrix中的一個(gè)。如果stage指令嵌套在parallel或matrix塊中,則無法在stage指令中嵌套parallel或matrix塊。但是,parallel或matrix塊中的stage指令可以使用stage的所有其他功能,包括agent、tool、when等。通過將failFast true添加到包含并行進(jìn)程的進(jìn)程中,可以在任何一個(gè)進(jìn)程失敗時(shí)強(qiáng)制所有并行進(jìn)程中止。添加failfast的另一個(gè)選項(xiàng)是向管道定義添加一個(gè)選項(xiàng):parallelsAlwaysFailFast()。

stash/unstash:暫時(shí)將文件存儲起來以便在node/workspace的中使用,后需通過unstash方式調(diào)用,stash會將文件打包成一個(gè)tar包來,所以大文件時(shí)會耗CPU,而且stash有文件大小限制,盡量在100M以下。除了stash方法,還有一個(gè)archive的方法也可以存文件。在Jenkins 2.x以上,已經(jīng)改為archiveArtifacts命令。

archiveArtifacts:archiveArtifacts捕獲與include模式(**/target/*.jar)匹配的構(gòu)建文件,并將其保存到Jenkins控制器以供以后檢索。

archive命令

但是這二者區(qū)別是:

?stash會在pipeline任務(wù)結(jié)束后將文件全部刪除,而archive會一直保存文件,且在jenkins頁面上顯示

Scripted Pipiline(腳本式流水線)

腳本式流水線與聲明式流水線一樣,構(gòu)建在底層流水線子系統(tǒng)之上。與聲明式流水線不同,腳本式流水線實(shí)際上是用Groovy構(gòu)建的通用DSL[2]。Groovy語言提供的大部分功能都提供給腳本式流水線的用戶,這意味著它可以是一個(gè)非常有表現(xiàn)力和靈活性的工具,用戶可以使用它來編寫連續(xù)交付流水線。

Flow Control

像Groovy或其他語言中的大多數(shù)傳統(tǒng)腳本一樣,腳本式流水線是從jenkins文件的頂部向下順序執(zhí)行的。因此,提供流控制依賴于Groovy表達(dá)式,例如if/else條件語句。例如:

if/else 語句

另一種管理腳本式流水線流控制的方法是使用Groovy的異常處理支持。當(dāng)步驟由于任何原因失敗時(shí),可以拋出異常。錯(cuò)誤處理行為必須使用Groovy中的try/catch/finally塊,例如:

try/catch/finally

9. Pipeline Best Practices

1.?使用Groovy代碼連接一組操作,而不是作為流水線的主要功能。換句話說,不要依賴流水線功能(Groovy或管道步驟)來推動構(gòu)建過程,而是使用單個(gè)步驟(如sh)來完成構(gòu)建的多個(gè)部分。隨著流水線復(fù)雜性的增加(Groovy代碼的數(shù)量、使用的步驟的數(shù)量等),流水線需要控制器上更多的資源(CPU、內(nèi)存、存儲)。將流水線視為完成構(gòu)建的工具,而不是構(gòu)建的核心。

2. 避免在流水線中使用復(fù)雜的Groovy語法。如避免使用JsonSlurper和HttpRequest等。

3. 減少相似步驟的重復(fù)。盡可能多地將流水線上步驟組合成單個(gè)步驟,以減少管道執(zhí)行引擎本身造成的開銷。例如,如果連續(xù)運(yùn)行三個(gè)shell步驟,則必須啟動和停止其中的每一個(gè)步驟,這需要?jiǎng)?chuàng)建和清理代理和控制器上的連接和資源。但是,如果將所有命令放在一個(gè)shell步驟中,則只需要啟動和停止一個(gè)步驟。

4. 不要調(diào)用Jenkins.getInstance。

5.?Using shared libraries

6. Do not override built-in Pipeline steps

7. Avoiding large global variable declaration files,擁有大型變量聲明文件可能需要大量內(nèi)存,但幾乎沒有好處,因?yàn)闊o論是否需要用到變量,都會為每個(gè)流水線加載該文件。建議創(chuàng)建只包含與當(dāng)前執(zhí)行相關(guān)的變量的小變量文件

8. Avoiding very large shared libraries

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容