jenkins操作手冊


 

1 引言

1.1 編寫目的

指導質量管理部,業務測試組同事進行Jenkins環境部署,通過Jenkins解決測試環境不可控,開發測試環境不一致等問題。

1.2 使用對象

質量管理部、基礎研發部,集成部署部及EMT

 

目標受眾:

本文的預期受眾是從事持續交付或持續自動測試工作的軟件工程師。要想按照本文中的步驟進行操作,您應該理解:

  • 腳本開發。
  • 軟件開發流程。

1.3 持續集成概述

1.3.1 什么是持續集成

隨着軟件開發復雜度的不斷提高,團隊開發成員間如何更好地協同工作以確保軟件開發的質量已經慢慢成為開發過程中不可回避的問題。尤其是近些年來,敏捷(Agile) 在軟件工程領域越來越紅火,如何能再不斷變化的需求中快速適應和保證軟件的質量也顯得尤其的重要。

持續集成正是針對這一類問題的一種軟件開發實踐。它倡導團隊開發成員必須經常集成他們的工作,甚至每天都可能發生多次集成。而每次的集成都是通過自動化的構建來驗證,包括自動編譯、發布和測試,從而盡快地發現集成錯誤,讓團隊能夠更快的開發內聚的軟件。

持續集成的核心價值在於:

  1. 持續集成中的任何一個環節都是自動完成的,無需太多的人工干預,有利於減少重復過程以節省時間、費用和工作量;
  2. 持續集成保障了每個時間點上團隊成員提交的代碼是能成功集成的。換言之,任何時間點都能第一時間發現軟件的集成問題,使任意時間發布可部署的軟件成為了可能;
  3. 持續集成還能利於軟件本身的發展趨勢,這點在需求不明確或是頻繁性變更的情景中尤其重要,持續集成的質量能幫助團隊進行有效決策,同時建立團隊對開發產品的信心。

1.3.2 持續集成的原則

業界普遍認同的持續集成的原則包括:

1)需要版本控制軟件保障團隊成員提交的代碼不會導致集成失敗。常用的版本控制軟件有 IBM Rational ClearCase、CVS、Subversion 等;

2)開發人員必須及時向版本控制庫中提交代碼,也必須經常性地從版本控制庫中更新代碼到本地;

3)需要有專門的集成服務器來執行集成構建。根據項目的具體實際,集成構建可以被軟件的修改來直接觸發,也可以定時啟動,如每半個小時構建一次;

4)必須保證構建的成功。如果構建失敗,修復構建過程中的錯誤是優先級最高的工作。一旦修復,需要手動啟動一次構建。

1.3.3 持續集成系統的組成

一個完整的構建系統必須包括:

  1. 一個自動構建過程,包括自動編譯、分發、部署和測試等。
  2. 一個代碼存儲庫,即需要版本控制軟件來保障代碼的可維護性,同時作為構建過程的素材庫。
  3. 一個持續集成服務器。本文中介紹的 Jenkins 就是一個配置簡單和使用方便的持續集成服務器。

1.4 Jenkins 簡介

Jenkins 是一個開源項目,提供了一種易於使用的持續集成系統,使開發者從繁雜的集成中解脫出來,專注於更為重要的業務邏輯實現上。同時 Jenkins 能實施監控集成中存在的錯誤,提供詳細的日志文件和提醒功能,還能用圖表的形式形象地展示項目構建的趨勢和穩定性。

主要用於:

  • 持續、自動地構建/測試軟件項目。
  • 監控一些定時執行的任務。

Jenkins擁有的特性包括:

  • 易於安裝-只要把jenkins.war部署到servlet容器,不需要數據庫支持。
  • 易於配置-所有配置都是通過其提供的web界面實現。
  • 集成RSS/E-mail通過RSS發布構建結果或當構建完成時通過e-mail通知。
  • 生成JUnit/TestNG測試報告。
  • 分布式構建支持Jenkins能夠讓多台計算機一起構建/測試。
  • 文件識別:Jenkins能夠跟蹤哪次構建生成哪些jar,哪次構建使用哪個版本的jar等。
  • 插件支持:支持擴展插件,您可以開發適合自己團隊使用的工具。

部署一個CI系統的最低要求是,一個可獲取源代碼的倉庫,一個包含構建腳本的項目。下圖概括了CI系統的基本結構

圖:CI系統的基本結構

 

Jenkins環境部署部署

2.1 Jenkins安裝

2.1.1 Java -jar安裝

  1. 從Jenkins官網下載jenkins.war文件。官網地址:http://jenkins-ci.org/,注意選擇最新版本的Long-Term Support Release
  2. 運行 java -jar jenkins.war(可添加命令 --httpPort=$HTTP_PORT,用來設置jenkins運行時的web端口)
    注意:Jenkins 最新war包需要運行 Java 7以及以上的版本。

2.1.2 servlet 安裝

.  1.從Jenkins官網下載jenkins.war文件。官網地址:http://jenkins-ci.org/,注意選擇最新版本的Long-Term Support Release

2. 將下載的war包文件部署到 servlet 容器,然后啟動容器,在瀏覽器的URL地址欄中輸入類似http://localhost:8080/jenkins/這樣的地址即可

2.2 Jenkins配置

2.2.1 系統管理

在已運行的Jenkins主頁中,點擊左側的系統管理進入如下界面:

圖:Jenkins系統管理

 

 

 

2.2.2 系統設置

在已運行的Jenkins主頁中,點擊左側的系統管理 —> 系統設置進入如下界面:

圖:系統設置頁面

 

2.2.2.1  JDK、Maven,SVN配置

2.2.2.1.1 JDK,Maven配置

配置一個JDK、Maven實例,請在每一節下面單擊Add(新增) 按鈕,這里將添加實例的名稱和絕對地址。

JDK別名:命名標示,可隨意取名。建議同安裝根目錄名保持一致

JAVA_HOME:本機JDK的安裝路徑(絕對路勁)

自動安裝:不推薦這個選項,會出現需要oracle用戶名,VPN等要求

后面Maven的配置是一樣的,JDK去oracle官網下載, Maven去apache官網下載

Ps:每個文本框后面都有個問號,點擊問號就會出現幫助信息

下圖描述了以上兩個部分。
圖:JDK配置界面

 

2.2.2.1.2 SVN配置

因為我們的SVN使用的1.8的客戶端版本,所以需要對Jenkins的SVN插件進行升級。

l 點擊系統管理 - > 管理插件。

圖:插件管理視圖

 

 

 

l 找到Subversion Plug-in插件,點擊下載並安裝。

l 下載插件,如下圖,檢測網絡連接是用的google的地址,因為沒有FQ,所以訪問不到是正常的,但是不影響下載安裝。
圖:Subversion Plug-in下載安裝界面

l 下載完成重啟Jenkins

Subversion Plug-in插件安裝完成后,在系統設置中找到對應模塊:
圖:SVN配置視圖

 


Subversion Workspace Version:Subversion 的版本號,選擇您對應的版本號就行了(1.8向下兼容)

2.2.2.2 郵件通知配置

l 配置發件人

 

System Admin e-mail address:Jenkins郵件發送地址。(必須配置,否則報錯 )

l 配置郵件通知
注意:SMTP認證郵箱必須與系統管理員郵件地址保持一致。
小技巧:可配置默認郵件后綴,以后您填寫郵件地址只需要輸出@之前內容就行了
圖:郵件通知配置視圖

 

2.2.3 Configure Global Security(安全設置)

在已運行的Jenkins主頁中,點擊左側的系統管理—>Configure Global Security進入如下界面:

圖:安全設置界面

 

 

設置如上圖,保存后系統管理中就出現管理用戶的選項。頁面右上角也會出現登錄/注冊的選項。


2.2.4 管理用戶設置

在右上角點擊注冊

圖:用戶注冊界面

 

 

注冊點擊sign up按鈕,提示您現在已經登錄.返回首頁. 登錄后和匿名賬號看到的首頁有幾點不同,如下圖紅框所示:

圖:用戶登錄頁面

 

 

2.2.5 管理插件設置

前文進行SVN配置時,已經接觸了相關插件安裝的內容。

Jenkins提供了大量的插件,插件管理器允許您安裝新的插件,和更新您Jenkins服務器上的插件。管理者將連接到聯機資料庫,檢索可用的和已更新的插件。如果您的Jenkins服務器 無法直接連接到外部資源,您可以從Jenkins網站上下載。點擊“管理插件”進入插件安裝界面。Jenkins的插件安裝管理配置都很簡單,通過web直接全能搞定。

插件管理界面如下圖所示:

圖:插件管理視圖

 

 

它包含四個標簽:

l 可更新:清單中列示了Jenkins為某些插件搜索到了可用的更新。列出的每個插件可以被選擇並應用更新。

l 可選插件:清單中列示了可用於安裝(而不是目前已安裝的)的所有插件。列出的每個插件都可以被選擇並安裝。

l 已安裝:清單中列示了已經安裝的插件。

l 高級:允許您通過設定HTTP代理的方式使Jenkins與在線插件庫建立連接。此外,還提供了一個上傳設備,可以安裝您在Jenkins以外已下載的那些插件。

 

各種Jenkins插件根據之前所記述的類型進行分門別類。可勾選任意想安裝的Jenkins插件,到頁面最下面有兩個按鈕“Install without restart” “Download now and install after restart”,根據需要點選提交開始安裝。

安裝后,所有插件以hpi作為后綴名放置在plugins文件夾下。如果是高級用戶還可以自行開發插件方便具體項目使用。

 

注意:安裝完成后需要重啟Jenkins部署的容器。這樣才能使用新裝的插件。

 

2.3 監控

當任務一旦運行,您將會看到這個任務正在隊列中的儀表板和當前工作主頁上運行。這兩種顯示如下。

圖:左圖構建歷史,右圖構建執行列表

 

 

 

一旦構建完成后,完成后的任務將會有三個地方進行顯示。

您可以在Jenkins的控制面板上看到它,如下圖。

圖:主頁面項目列表

 

 

在上面展示的截圖中,您將注意到有兩個圖標描述當前作業的狀態。S欄目代表着“最新構建狀態”,W欄目代表着“構建穩定性”。Jenkins使用這兩個概念來介紹一個作業的總體狀況:

構建狀態:下圖中分級符號概述了一個Job新近一次構建會產生的四種可能的狀態: 

l Successful:完成構建,且被認為是穩定的。

l Unstable:完成構建,但被認為不穩定。

l Failed:構建失敗。

l Disabled:構建已禁用。

圖:構建狀態界面

 

 

構建穩定性: 當一個Job中構建已完成並生成了一個未發布的目標構建,如果您准備評估此次構建的穩定性,Jenkins會基於一些后處理器任務為構建發 布一個穩健指數 (從0-100 ),這些任務一般以插件的方式實現。它們可能包括單元測試(JUnit)、覆蓋率(Cobertura )和靜態代碼分 析(FindBugs)。分數越高,表明構建越穩定。下圖中分級符號概述了穩定性的評分范圍。任何構建作業的狀態(總分100)低於80分就是不穩定的。
圖:構建穩定性界面

 

 

您也可以在當前Job主界面上看到它,如下圖左下部分

圖:項目構建界面

 

 

當前作業主頁上還包含了一些有趣的條目。左側欄的鏈接主要控制Job的配置、刪除作業、構建作業。右邊部分的鏈接指向最新的項目報告和構件。

通過點擊構建歷史(Build History)中某個具體的構建鏈接,您就能跳轉到Jenkins為這個構建實例而創建的構建主頁上。如下圖

圖:構建歷史界面

 

 

如果您想通過視圖輸出界面來監控當前任務的進展情況。您可以單擊Console Output(控制台輸出)。如果工作已完成,這將顯示構建腳本產生的靜態輸出;如果作業仍然在運行中,Jenkins將不斷刷新網頁的內容,以便您可以看到它運行時的輸出。如下圖:

圖:控制台輸出界面

 

 

Jenkins內置環境變量

l BUILD_NUMBER, 唯一標識一次build。例如23; 

l BUILD_ID,基本上等同於BUILD_NUMBER,但是是字符串,例如2011-11-15_16-06-21;

l JOB_NAME, job的名字,例如AppScan_mall_essence_test;

l BUILD_TAG, 作用同BUILD_ID,BUILD_NUMBER,用來全局地唯一標識一此build,例如jenkins- AppScan_mall_essence_test-23;

l EXECUTOR_NUMBER, 例如0;

l NODE_NAME,slave的名字,例如Master;

l NODE_LABELS,slave的label,標識slave的用處,例如Android打包;

l JAVA_HOME, java的home目錄,例如C:\Program Files\Java\jdk1.8.0_45;

l WORKSPACE,job的當前工作目錄,例如c:\jenkins\workspace\ AppScan_mall_essence_test;

l HUDSON_URL = JENKINS_URL, jenkins的url,例如http:// AppScan_mall_essence_test:8000/ ;

l BUILD_URL,build的url 例如http://localhost:8000/job/ AppScan_mall_essence_test /23/;

l JOB_URL, job的url,例如http://localhost:8000/job/ AppScan_mall_essence_test /;

l SVN_REVISION,svn 的revison
注意:項目可配置多個SVN變量說明:
The Subversion SCM plugin exports the svn revisions and URLs of the build's subversion modules as environment variables. These are $SVN_REVISION_n and $SVN_URL_n, where n is the 1-based index of the module in the configuration.

For backwards compatibility if there's only a single module, its values are also exported as $SVN_REVISION and $SVN_URL.

 

Jenkins 其他配置

4.1 Slave配置

Jenkins有個很強大的功能:分布式構建,分布式構建能夠讓同一套代碼在不同的環境(如:Windows和Linux系統)中編譯、測試等。而且Jenkins構建的代碼和產物最后自動拷貝到主節點。

注意:注意:如果節點主機上不存在JDK,Jenkins會去自動下載,但Oracle對程序自動下載做了限制,會導致下載失敗,然后一直循環這個問題。

建議:所有Unix/Mac/Linux或者Windows機器的環境路徑統一(如:JDK、Maven),便於管理、不易出現奇葩問題。

 

Jenkins版本:1.6.20(不同版本的配置可能不同)

進入節點配置界面:系統管理→管理節點→新建節點(左上角)

圖:Slave配置頁面

 

 

 

節點名稱:建議使用字母、數字或字母和數字的組合。最好見名知意。不建議使用標點符號和中文(中文命名沒有問題,但Job中無法引用)

Dumb Slave:新建一個節點

復制現有節點:從已存在的節點中復制一份配置(存在節點才會顯示)

l 點擊ok進入下一步配置
圖:Slave 節點配置

l Name:節點名稱

l Description:節點描述,支持中文

l # of executors:最大同時構建數量(根據機器的性能定,單顆四核cpu建議不要超過5)【必須為數字】

l Remote FS root:節點的根目錄(注意:如果目錄不存在,會自動創建目錄。你必須對該目錄有讀寫權限,不然會報錯:hudson.util.IOException2: Failed to copy xxxx)

l Labels:標記(又叫做標簽)用來對多節點分組,標記之間用空格分隔.例如'refression java6'將會把一個節點標記上 和'java6'.
舉例來說,如果你有多個Windows系統的構建節點並且你的Job也需要在Windows系統上運行,那么你可以配置所有的Windows系統節點都標 記為'windows', 然后把Job也標記為'windows'.這樣的話你的Job就不會運行在除了Windows節點以外的其它節點之上了.

l 用法:盡可能的使用這個節點/只允許運行綁定到這台機器的Job(根據你的需求,二選一)

l Launch method:運行方式有四個選項。建議選擇第1、2種方式配置。詳細如下:

n 【推薦】Launch slave agents on Unix machines via SSH   在Unix(包括Linux)機器上通過SSH通道連接節點 (適用於Unix和Linux)

u Host:節點主機的ip地址

u Credentials:憑據(如果為空或者不可選擇,請在系統管理→Manage Credentials中配置。Manage Credentials的配置非常簡單,這里就不在描述了。Manage Credentials配置完成后,需刷新節點配置頁面才會顯示。)

u Port:端口默認22

u JavaPath:[可選]JDK路徑,默認和master節點相同。路徑必須指定到Java程序,如:/path/bin/java

u JVM Options:[可選]JVM可選參數

u Prefix Start Slave Command:[可選]不知道干什么用的參數

u Suffix Start Slave Command:[可選]不知道干什么用的參數

u Connection Timeout in Seconds:[可選]鏈接超時設置

u Maximum Number of Retries:[可選]失敗重連數

u Seconds To Wait Between Retries:[可選]重連間隔時間

u 測試可以使用Unix命令,會自動拼接在[SSH] Starting slave process:[Prefix Start Slave Command] cd '/path' && /path/bin/java -jar slave.jar [Suffix Start Slave Command]

n 【推薦】Launch slave agents via Java Web Start   通過Java Web Start連接節點 (適用於所有支持Java程序的系統)

u Tunnel connection through:[可選]在端口轉發這種情況下使用

u JVM options:[可選]JVM可選參數

u 這種方法的缺點:如果該節點宕機了,主節點無法自動重啟它。

 

n Launch slave via execution of command on the Master  通過主節點的控制台連接節點

u Jenkins的開發者考慮到某些企業可能有N++ 個節點(N>=你猜!)。如果在界面配置,那么升級版本之類的操作會很麻煩。所以允許你使用shell腳本去配置管理節點(貌似很方便的樣子)。具體的腳本需要你自己寫。

u Launch command:Unix運行腳本的命令,如:sh aaa.sh

n 【不建議使用】Let Jenkins control this Windows slave as a Windows service   讓Jenkins節點添加到Windows服務中

u 這個選項比Launch slave agents via Java Web Start添加為服務更加穩定(幫助文檔描述)。采用這種運行方式,那么這個系統不能登錄任何用戶。這種配置方式是非常的麻煩和折騰。

u Administrator user name:域\管理員賬號

u Password:密碼

u Host:節點主機IP或者域名

u Run service as:

u Use Local System User:使用本地系統用戶

u Log on using a different account:使用不同的用戶登錄

u User name:賬號

u Password:密碼

u Use Administrator account given above:使用上面的用戶登錄

u Path to java executable:[可選]JDK路徑。必須指定到Java程序,如:C:\Windows\system32\java.exe

u JVM options:[可選]JVM可選參數

l Availability:

u Keep this slave on-line as much as possible:盡可能保持節點在線【推薦】

u Take this slave on-line according to a schedule:根據時間表在線(類似於Linux的定時任務)

l Startup Schedule:類似於Linux定時任務的時間,如下:

 

l # every fifteen minutes (perhaps at :07, :22, :37, :52)

l H/15 * * * *

l # every ten minutes in the first half of every hour (three times, perhaps at :04, :14, :24)

l H(0-29)/10 * * * *

l # once every two hours every weekday (perhaps at 10:38 AM, 12:38 PM, 2:38 PM, 4:38 PM)

l H 9-16/2 * * 1-5

l # once a day on the 1st and 15th of every month except December

l H H 1,15 1-11 *

l 如果使用 H Jenkins會自動提前一段時間連接節點,避免出現同一時間高並發的問題

 

l Scheduled Uptime:超過任務時間后延遲多少分鍾離線。如果此數值大於在線總時間(單位:分),就會一直保持在線【必須為數字】

l Keep on-line while jobs are running:當有Job在構建時(到達離線時間了)繼續保持在線

u Take this slave on-line when in demand and off-line when idle:讓Jenkins根據需求自動連接或者離線

l In demand delay:告訴Jenkins如果有Job需要在此節點構建,需要在任務隊列等待多長時間才會進入任務狀態進行構建【必須為數字】

l Idle delay:告訴Jenkins多少分鍾內如果沒有Job需要構建就離線【必須為數字】

l Node Properties:

u Environment variables:配置環境變量(可以在腳本中引用)

u Tool Locations:工具的目錄【推薦】。說明:可以替換系統設置的各種工具目錄。如:JDK目錄、Ant目錄、Maven目錄等。好處就是在不更改Job配置的情況下,不同環境(如:Windows和Linux) Job配置通用。

4.1.1 Windows Slave

4.1.1.1 Launch slave agents via Java Web Start

相應配置選擇完成后,進入需要控制的遠程機器上,一定要進入遠程的slave機器,而不是你的master機器。輸入對應的你的jenkins的地址,例如這里:

http://192.168.11.237:8080/computer/

點擊進入對應的該slave機器的圖標進入:

圖:Launch slave agents via Java Web Start配置完成界面

 

 

 

如上圖所示,有兩種方式可以啟動節點(都是JNLP方式。JNLP連接需要端口,默認連接端口是隨機的,端口更改 系統設置→Configure Global Security→JNLP節點代理的TCP端口)

你以下幾種方式啟動:

l Launch agent from browser on slave  下載文件slave-agent.jnlp文件,雙擊打開。

n 一般用在Windows系統上,需要javaws.exe(在Java的bin目錄中可以找到)程序才能打開。如果提示錯誤,請卸載JDK后重新安裝。

注意事項:

確認slave-agent.jnlp 是用javaws來運行的,而不是java.exe 或者是javaw.exe來運行,因為一般的機器默認是采用java.exe啟動的。

將slave-agent.jnlp用notepad打開后,確認其中的URL是可用的Jenkins地址。其中的配置可能是這樣的:

 

確認其中的url地址是正確的地址,而不是localhost或者127.0.0.1。

以上的配置完成后,如果點擊lanch按鈕,可能會報一下的錯誤:


Slave irshost12.tc.tb.com

Connection was broken

java.net.SocketException: Connection reset

at java.net.SocketInputStream.read(SocketInputStream.java:168)

at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

at java.io.BufferedInputStream.read(BufferedInputStream.java:237)

at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2252)

at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2545)

at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2555)

at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1294)

at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)

at hudson.remoting.Command.readFrom(Command.java:92)

at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:72)

at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)

Connect slave to Jenkins one of these ways:

 Launch agent from browser on slave

Run from slave command line:

javaws http://16.158.69.53:9999/jenkins/computer/irshost12.tc.com.com/slave-agent.jnlp

Or if the slave is headless:

java -jar slave.jar -jnlpUrl http://16.158.69.53:9999/jenkins/computer/irshost12.tc.com/slave-agent.jnlp

如果出現上面的問題,我們就不要在點擊launch按鈕起啟動了,采用命令行去啟動也是一樣的,這個時候選擇下面的啟動方式

l Run from slave command line
1.javaws  http://xxxx/slave-agent.jnlp  
如果你配置了權限那么后面還有一串看不懂的隨機Key

n 下載slave.jar到本地,然后進入存放slave.jar的目錄,復制粘貼並運行 java -jar slave.jar -jnlpUrl http://xxxxx  即可啟動。

l Or if the slave is headless:
java -jar slave.jar -jnlpUrl http://192.168.11.237:8080//computer/192.168.11.155_WIN7_ICE/slave-agent.jnlp

 

如果啟動成功,成功啟動如下圖所示:

圖:windows Slave Launch slave agents via Java Web Start 節點連接

 

點擊左上角的File選擇Install as a service就可以添加為Windows的服務了(默認開機自動啟動)。將當前的slave設置成一個服務,每次機器重啟的時候都自動啟動slave服務,這樣就不用每次都去啟動這個slave agent了。

 

注意:

如果上面的窗口中顯示Connected,可是一會有出現了Terminated的狀態,那么很可能是因為你的jenkins配置權限的時候沒有給匿名用戶啟動slave的權限。

具體操作是進入jenkins主界面,然后進入Manage Jenkins -> Configure Global Security ,勾選其中的anonymous用戶的slave部分的權限。

圖:anonymous Slave 啟動權限配置界面

 

 

4.1.1.2 Let Jenkins control this Windows slave as a Windows service

這種啟動方式比較繁瑣,此處不做贅述,可參考:http://blog.sina.com.cn/s/blog_87f0f17e0101iq8a.html

 

4.1.2 MAC/Linux Slave(待添加)

4.1.2.1 Launch slave agents on Unix machines via SSH

l 在jenkins上增加節點
圖:Jenkins增加節點配置界面

l 在Mac系統中將ssh的服務打開,在偏好設置-互聯網與無線 -共享中
圖:互聯網與無線配置界面

 

l 使用mac root用戶修改sshd-config的鑒權方式
首先獲取到root用戶登錄,然后vi /etc/ssd_config,修改PasswordAuthentication no 為PasswordAuthentication yes

l 此時在jenkins節點中點擊salve節點,Lauch。

注意:

1.Slave節點機器上必須配置好java環境,建議手工在Environment variables指定JAVA_HOME路徑信息
圖:Environment variables JAVA_HOME配置

 

2.命令行調用code sign時報錯:User interaction is not allowed

n 網上找了一些命令來用:

$security list-keychains

$unlock-keychain "-p" "keychainpassword"  "/Users/bixiaopeng/Library/Keychains/login.keychain”

但無法解決

 

於是乎用下面的方法解決了:

1.在應用程序里搜索Keychain Access,中文叫鑰匙串訪問權限

2.找到你的證書,右擊 — 顯示簡介 — 訪問控制 — 選中【允許所有應用程序訪問此項目】 — 存儲更攺 — 輸入密碼后保存更攺,解決問題。

n 如果上面的都無法解決,那就使用jenkins的Xcode插件吧
圖:Xcode配置界面

 

除了以上的連接方式,也可以采用私鑰的形式進行鏈接:SSH Username with private key

這種啟動方式比較繁瑣,此處不做贅述,可參考:http://blog.sina.com.cn/s/blog_87f0f17e0101iq8a.html

4.2 Manage and Assign Roles配置

Jenkins的默認權限控制過於簡單,用戶進行管理配置這塊推薦使用“Role-based Authorization Strategy”

4.2.1 Role-based Authorization Strategy安裝

點擊“系統管理”- > “管理插件” 進入插件安裝界面,按照上文“管理插件設置”選擇Role-based Authorization Strategy進行安裝

4.2.2 “Role-based Authorization Strategy”的啟用

點擊“系統管理”點擊“系統設置”,如下圖所示:“授權策略”選擇使用“Role-Based Strategy”。

配置完成save后在“系統管理”下新增選項“Manage and Assign Roles”。點擊“管理用戶”新建賬戶后即可進行賬戶,群組的安全策略配置。

圖:Role-Based Strategy配置界面

 

 

4.2.3 管理組權限設置,構建權限設置:

點擊“Manage and AssignRoles”,先選擇“Manage Roles”如下圖所示,在Global roles這里創建權限分組,如admin是最高管理員權限,擁有所有權限,guest只有讀權限等,這里可以根據具體情況設置多個分組,不同權限;然后設置“Project roles”,Role to add 填寫分組名稱,Pattern填寫分組的規則。例如這個分組叫TEST,他的規則就是構建名為“TEST.*”的所有構件,然后在“Job”區里勾選相關權限。設置完成點保存即可。

圖:Global roles設置界面

 

 

圖:Project roles設置界面

 

 

4.2.4 用戶權限分配

點擊“Assign Roles”如下圖所示,在“Global roles”下“User/group to add”欄中輸入添加的用戶名,然后勾選管理組。記得把默認的匿名用戶“Anonymous”的默認admin權限去掉,在添加管理員之后,否則不需登錄就能控制整個Jenkins的權限;在“Project roles”下“User/group to add”欄中輸入添加的用戶名,然后勾選對應構建權限名。設置完保存即可。

圖:Assign Roles配置界面

 

 

 

 

4.3 E-mail Notification配置

Jenkins默認提供了一個郵件通知,能在構建失敗、構建不穩定等狀態后發送郵件。但是它本身有很多局限性,比如它的郵件通知無法提供詳細的郵件內容、無法定義發送郵件的格式、無法定義靈活的郵件接收配置等等。在這樣的情況下,我們找到了Jenkins Email Extension Plugin。該插件能允許您自定義郵件通知的方方面面,比如在發送郵件時您可以自定義發送給誰,發送具體什么內容等等。

4.3.1 配置

E-mail Notification配置包含兩個部分:全局配置和項目配置。

4.3.2 全局配置

在一個項目中應用E-mail Notification插件之前,您必須做一些全局的配置。現在先跳轉到Jenkins的“系統設置”頁面。

找到標題為“Extended E-mail Notification”的片段,你就能配置一些全局的E-mail Notification屬性。這些屬性必須匹配你SMTP郵件服務器的設置。這一節不僅能配置成Jenkins原有郵件通知的鏡像(雖然有很多配置是一樣的,但這是個不同的擴展點),而且還增加了一些額外的功能。輸入框中名為 Default Subject 和 Default Content 的項允許你在全局級別配置郵件的內容。這樣做的話,可以使您為所有的項目按您的需求做更好的、更簡單的配置。如下圖。
圖:Extended E-mail Notification配置

 

 

釋放默認配置:

Default Subject:構建通知:$PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS!

Maximum Attachment Size:20

Default Content:

(本郵件是程序自動下發的,請勿回復!)

項目名稱:$PROJECT_NAME

構建編號:$BUILD_NUMBER

SVN版本號:${SVN_REVISION}

構建狀態:$BUILD_STATUS

觸發原因:${CAUSE}

構建日志地址:${BUILD_URL}

構建地址: $BUILD_URL

APP文件下載地址(Android/IOS):${JOB_URL}ws/version/

變更集: ${JELLY_SCRIPT,template="text"}

$PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS:

Check console output at $BUILD_URL to view the results.

4.3.2.1 E-mail Notification全局屬性詳解

E-mail Notification全局屬性詳解:

l Override Global Settings:如果不選,該插件將使用默認的E-mail Notification通知選項。反之,您可以通過指定不同於( 默認選項)的設置來進行覆蓋。

l Default Content Type:指定構建后發送郵件內容的類型,有Text和HTML兩種.

l Use List-ID Email Header:為所有的郵件設置一個List-ID的郵件信頭,這樣你就可以在郵件客戶端使用過濾。它也能阻止郵件發件人大部分的自動回復(諸如離開辦公室、休假等等)。你可以使用你習慣的任何名稱或者ID號,但是他們必須符合如下其中一種格式(真實的ID必須要包含在<和>標記里):

<ci-notifications.company.org>

Build Notifications <ci-notifications.company.org>

“Build Notifications” <ci-notifications.company.org>

l Add 'Precedence: bulk' Email Header:設置優先級.

l Default Recipients:自定義默認電子郵件收件人列表。如果沒有被項目配置覆蓋,該插件會使用這個列表。您可以在項目配置使用$ DEFAULT_RECIPIENTS參數包括此默認列表,以及添加新的地址在項目級別。添加抄送:cc:電子郵件地址例如,CC:someone@somewhere.com

l Reply To List:回復列表, A comma separated list of e-mail addresses to use in the Reply-To header of the email. This value will be available as $DEFAULT_REPLYTO in the project configuration.

l Emergency reroute:如果這個字段不為空,所有的電子郵件將被單獨發送到該地址(或地址列表)。

l Excluded Recipients:防止郵件被郵件系統認為是垃圾郵件,郵件列表應該沒有擴展的賬戶名(如:@domain.com),並且使用逗號分隔

l Default Subject:自定義郵件通知的默認主題名稱。該選項能在郵件的主題字段中替換一些參數,這樣你就可以在構建中包含指定的輸出信息。

l Maximum Attachment Size:郵件最大附件大小。

l Default Content:自定義郵件通知的默認內容主體。該選項能在郵件的內容中替換一些參數,這樣你就可以在構建中包含指定的輸出信息。

l Default Pre-send Script:默認發送前執行的腳本。

l Enable Debug Mode:啟用插件的調試模式。這將增加額外的日志輸出,構建日志以及Jenkins的日志。在調試時是有用的,但不能用於生產。

l Enable Security:啟用時,會禁用發送腳本的能力,直接進入Jenkins實例。如果用戶試圖訪問Jenkins管理對象實例,將拋出一個安全異常。

l Content Token Reference:郵件中可以使用的變量,所有的變量都是可選的。

4.3.2.2 全局郵件變量

E-mail Notification插件允許使用變量來動態插入數據到郵件的主題和內容主體中。變量是一個以$(美元符號)開始,並以空格結束的字符串。當一個郵件觸發時,主題和內容主體字段的所有變量都會通過真實的值動態地替換。同樣,變量中的“值”能包含其它的變量,都將被替換成真實的內容。

比如,項目配置頁的默認主題和內容分別對應的是全局配置頁面的DEFAULT_SUBJECT和DEFAULT_CONTENT,因此它會自動地使用全局的配置。同理,觸發器中的Subject和Content分別對應的是項目配置頁面的DEFAULT_SUBJECT和DEFAULT_CONTENT,所以它也會自動地使用項目的配置。由於變量中的“值”能包含其它的變量,所以就能為變量快速地創建不同的切入點:全局級別(所有項目),專屬級別(單一項目),觸發器級別(構建結果)。

如果你要查看所有可用的變量,你可以點擊配置頁的Content Token Reference的問號獲取詳細的信息。

所有的變量都是可選的,每個變量可以如下表示,字符串類型使用name=“value”,而布爾型和數字型使用name=value。如果{和}標記里面沒有變量,則不會被解析。示例:$TOKEN,${TOKEN},${TOKEN,count=100},${ENV,var=”PATH”}

提示:用英文逗號分隔變量的參數。

 

一些常用的屬性

l ${FILE,path="PATH"} 包括指定文件(路徑)的含量相對於工作空間根目錄。

n path文件路徑,注意:是工作區目錄的相對路徑。

l ${BUILD_NUMBER} 顯示當前構建的編號。

l ${JOB_DESCRIPTION} 顯示項目描述。

l ${SVN_REVISION} 顯示svn版本號。還支持Subversion插件出口的SVN_REVISION_n版本。

l ${CAUSE} 顯示誰、通過什么渠道觸發這次構建。

l ${CHANGES } -顯示上一次構建之后的變化。

n showPaths 如果為 true,顯示提交修改后的地址。默認false。

n showDependencies 如果為true,顯示項目構建依賴。默認為false

n format 遍歷提交信息,一個包含%X的字符串,其中%a表示作者,%d表示日期,%m表示消息,%p表示路徑,%r表示版本。注意,並不是所有的版本系統都支持%d和%r。如果指定showPaths將被忽略。默認“[%a] %m\\n”。

n pathFormat 一個包含“%p”的字符串,用來標示怎么打印路徑。

l ${BUILD_ID}顯示當前構建生成的ID。

l ${PROJECT_NAME} 顯示項目的全名。(見AbstractProject.getFullDisplayName)

l ${PROJECT_DISPLAY_NAME} 顯示項目的顯示名稱。(見AbstractProject.getDisplayName)

l ${SCRIPT} 從一個腳本生成自定義消息內容。自定義腳本應該放在"$JENKINS_HOME/email-templates"。當使用自定義腳本時會默認搜索$JENKINS_HOME/email-templatesdirectory目錄。其他的目錄將不會被搜索。

n script 當其使用的時候,僅僅只有最后一個值會被腳本使用(不能同時使用script和template)。

n template常規的simpletemplateengine格式模板。

l ${JENKINS_URL} 顯示Jenkins服務器的url地址(你可以再系統配置頁更改)。

l ${BUILD_LOG_MULTILINE_REGEX}按正則表達式匹配並顯示構建日志。

n regex java.util.regex.Pattern 生成正則表達式匹配的構建日志。無默認值,可為空。

n maxMatches 匹配的最大數量。如果為0,將匹配所有。默認為0。

n showTruncatedLines 如果為true,包含[...truncated ### lines...]行。默認為true。

n substText 如果非空,就把這部分文字(而不是整行)插入該郵件。默認為空。

n escapeHtml 如果為true,格式化HTML。默認為false。

n matchedSegmentHtmlStyle 如果非空,輸出HTML。匹配的行數將變為<b style=”your-style-value”> html escaped matched line </b>格式。默認為空。

l ${BUILD_LOG} 顯示最終構建日志。

n maxLines 日志最多顯示的行數,默認250行。

n escapeHtml 如果為true,格式化HTML。默認false。

l ${PROJECT_URL} 顯示項目的URL地址。

l ${BUILD_STATUS} -顯示當前構建的狀態(失敗、成功等等)

l ${BUILD_URL} -顯示當前構建的URL地址。

l ${CHANGES_SINCE_LAST_SUCCESS} -顯示上一次成功構建之后的變化。

n reverse在頂部標示新近的構建。默認false。

n format遍歷構建信息,一個包含%X的字符串,其中%c為所有的改變,%n為構建編號。默認”Changes for Build #%n\n%c\n”。

n showPaths,changesFormat,pathFormat分別定義如${CHANGES}的showPaths、format和pathFormat參數。

l ${CHANGES_SINCE_LAST_UNSTABLE} -顯示顯示上一次不穩固或者成功的構建之后的變化。

n reverse在頂部標示新近的構建。默認false。

n format遍歷構建信息,一個包含%X的字符串,其中%c為所有的改變,%n為構建編號。默認”Changes for Build #%n\n%c\n”。

n showPaths,changesFormat,pathFormat分別定義如${CHANGES}的showPaths、format和pathFormat參數。

l ${ENV} –顯示一個環境變量。

n var– 顯示該環境變量的名稱。如果為空,顯示所有,默認為空。

l ${FAILED_TESTS} -如果有失敗的測試,顯示這些失敗的單元測試信息。

l ${JENKINS_URL} -顯示Jenkins服務器的地址。(你能在“系統配置”頁改變它)。

l ${HUDSON_URL} -不推薦,請使用$JENKINS_URL

l ${PROJECT_URL} -顯示項目的URL。

l ${SVN_REVISION} -顯示SVN的版本號。

l ${JELLY_SCRIPT} -從一個Jelly腳本模板中自定義消息內容。有兩種模板可供配置:HTML和TEXT。你可以在$JENKINS_HOME/email-templates下自定義替換它。當使用自動義模板時,”template”參數的名稱不包含“.jelly”。

n template模板名稱,默認”html”。

l ${TEST_COUNTS} -顯示測試的數量。

n var– 默認“total”。

u total -所有測試的數量。

u fail -失敗測試的數量。

u skip -跳過測試的數量。




4.3.3 項目配置

要想在一個項目中使用email-ext插件,你首先必須在項目配置頁激活它。在構建后操作——“增加構建后操作步驟”選項中勾選”Editable Email Notification”標簽。

圖:E-mail Notification項目配置界面

 

 

4.3.3.1 項目基本配置

當插件激活后你就能編輯如下字段(只列出常用的字段):

 

l Project Recipient List:這是一個以逗號(或者空格)分隔的收件人郵件的郵箱地址列表。允許您為每封郵件指定單獨的列表。
Ps:如果你想在默認收件人的基礎上添加收件人:$DEFAULT_RECIPIENTS,<新的收件人>

n Default Subject:允許你配置此項目郵件的主題。

n Default Content:跟Default Subject的作用一樣,但是是替換郵件內容。

n Attach Build Log:附件構建日志。

u Compress Build Log before sending:發送前壓縮生成日志(zip格式)。

4.3.3.2 項目高級配置

要查看插件的高級配置,請點擊“ Advanced Settings...”按鈕。該選項允許您各種類型的郵件觸發器指定接收者。默認情況下,是沒有配置的觸發器,所以默認情況下不會發送郵件。要增加更多的觸發器,選擇“Add a Trigger”旁邊下拉列表中的類型,它會增加到控件上面的列表中。

配置說明:

l Send to Recipient List:如果勾選,郵件將發送到”Project Recipient List”中的所有郵件地址。

l Send to Committers:該郵件會發給上次構建時檢查過代碼的人員,該插件會基於提交者的ID和追加Jenkins配置頁面的(default email suffix)默認郵件后綴來生成一個郵件地址。譬如,上次提交代碼的人是”first.last”, 默認的電子郵件后綴為“@somewhere.com”,那么電子郵件將被發送到“first.last@ somewhere.com”。

l Send To Requester:如果勾選,郵件將發送給構建觸發者。

l Include Culprits:如果勾選,而且 “Send To Committers”勾選,郵件將包含最后成功構建的提交者。

l More Configuration:通過單擊”+(expand)”鏈接您能為每個郵件觸發器作更多單獨的設置。

n Recipient List:這是一個以逗號(或者空格)分隔的可接受郵件的郵箱地址列表。如果觸發就發送郵件到該列表。該列表會追加在”Global Recipient List”里。

n Subject:指定選擇郵件的主題。注意:高級選項中的郵件觸發器類型可覆蓋對它的配置。

n Content:指定選擇郵件的內容主體。注意:高級選項中的郵件觸發器類型可覆蓋對它的配置。

l Remove通過單擊指定觸發器當前行的“Delete”按鈕,你可以刪除該觸發器。

4.3.3.3 觸發器類型

配置發送需首先確定觸發器
注意:所有的觸發器都只能配置一次

l Failure:即時發送構建失敗的郵件。如果”Still Failing”觸發器已配置,而上一次構建的狀態是”Failure”,那么”Still Failing”觸發器將發送一封郵件來替代(它)。

l Unstable:即時發送構建不穩固的郵件。如果”Still Unstable”觸發器已配置,而上一次構建的狀態是”Unstable”,那么”Still Unstable”觸發器將發送一封郵件來替代(它)。

l Still Failing:如果兩次或兩次以上連續構建的狀態為”Failure”,發送該郵件。

l Success:如果構建的狀態為”Successful”發送郵件。如果”Fixed”已配置,而上次構建的狀態為“Failure”或“Unstable”,那么”Fixed”觸發器將發送一封郵件來替代(它)。

l Fixed:當構建狀態從“Failure”或“Unstable”變為”Successful”時發送郵件。

l Still Unstable:如果兩次或兩次以上連續構建的狀態為” Unstable “,發送該郵件。

l Before Build:當構建開始時發送郵件。

4.3.3.4 項目郵件變量

注意:這里只解釋全局配置頁面中缺少的變量。

 

l ${DEFAULT_SUBJECT}:這是Jenkins系統配置頁面默認配置的郵件主題

l ${DEFAULT_CONTENT}:這是Jenkins系統配置頁面默認配置的郵件內容主體

l ${PROJECT_DEFAULT_SUBJECT}:這是項目的默認郵件主題。高級配置中使用該令牌的結果要優先於Default Subject字段。警告:不要在Default Subject 或者Default Content中使用該令牌,它會產生一個未知的結果。

l ${PROJECT_DEFAULT_CONTENT}:這是項目的默認郵件內容主體。高級配置中使用該令牌的結果要優先於Default Content字段。警告:不要在Default Subject 或者Default Content中使用該令牌,它會產生一個未知的結果。

4.3.4 E-mail Notification郵件效果展示

圖:E-mail Notification郵件效果圖

 

 

Jenkins 使用流程

持續交付需要快速且自動地部署各種更改集。完成部署或交付工作需要多個步驟。標准的流程是:

  • 開發人員交付各種更改
  • 源代碼控制工具進行構建工作
  • 運行自動的測試工作
  • 安裝構建內容

Jenkins框架的部署拓撲結構(當前)

開發部署:開發人員向諸如 Subversion(SVN)等的源代碼控制服務器提交更改集

持續集成:添加 Jenkins 以后,會有一個 Jenkins 主機器。Subversion構建工具包已安裝在該服務器上。Jenkins使用該構建工具包並通過 Subversion下載源代碼,同時觸發構建工具包生成構建版本。所有的項目都在在 Jenkins 主機器上進行管理。Android打包,AppScan掃描,Web項目開發環境發布在Jenkins master機器上運行,IOS打包(192.168.1.90_Darwin_IOS)作為Jenkins 從機器提供服務。它們由 Jenkins 主機器控制,並運行安裝項目。

圖.Jenkins框架的部署拓撲結構

 

 

 

 

原文鏈接:基於jenkins搭建一個持續集成服務器 - YatHo - 博客園 (cnblogs.com)


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM