本文同步自個人部落格Android Jenkins引數化配置
在我們的專案組裡,構建Jenkins打包平臺的初衷是讓測試人員用這個打包平臺,開發人員寫完提測郵件之後,測試人員自行去打包,然後進行測試,開發就可以繼續去開車了。
Jenkins安裝
本文不打算寫手把手安裝Jenkins教程,如果你還不瞭解怎麼安裝Jenkins,請自行百度,或者檢視這裡的官網教程: pkg.jenkins.io/redhat/。
Jenkins引數化配置
Jenkins引數化配置主要有2個步驟:
- 在
gradle.properties
中配置需要動態修改的引數,並在build.gradle
中使用。 - 在Jenkins中新增這些引數,進行引數化構建。
一般我們需要動態修改的引數有versionName、versionCode,是否測試環境等,同時我們可以提供一些額外配置,如選擇需要構建的分支,打包的渠道號等,以提高打包靈活性。我們把需要Jenkins修改的引數放到gradle.properties
檔案下,如:
# Jenkins配置
IS_JENKINS=false
VERSION_NAME=3.4
VERSION_CODE=30400002
IS_TEST_ENV=true
複製程式碼
接下來就是重點了。我們在新建任務的時候選擇“構建一個自由風格的軟體專案”
接下來選擇“引數化構建過程”新增引數配置:
Git伺服器
可以看到在構建分支裡我們使用了上面的BRANCH
引數,這樣我們就可以動態的選擇需要構建的分支了。
Gradle構建
** 這裡最重要的地方就是標記部分,只有勾選該選項,gradle.properties
的引數才能被Jenkins修改。**
如果你在github上下載過Android程式碼,你會發現一般專案中都會保留gradle wrapper
資料夾,這樣做的好處是升級gradle版本的時候不需要更新ci,這裡我們也一樣,勾選“Use Gradle Wrapper”,然後新增你需要的tasks,這裡需要說明一下的是assemble'${PRODUCT_FLAVORS}''${BUILD_TYPES}'
,如果你平時打包的時候有留意過gradle執行的task的時候你會發現gradle為每個productFlavors
建立2個task,一個是debug版本的,一個是release版本的。利用這個規則我們就可以使用引數動態改變task了。這裡有一個取巧的地方,細心的你會發現PRODUCT_FLAVORS
第一個選項是空的,當選擇該選項時,task的名稱就變成assemblerelease
或者assembledebug
了,這種情況下就會打全渠道包,注意這裡不能把空放在最後一個選項,放在最後的話會變成一個空格,導致task名稱錯誤。
到這裡Jenkins引數化構建的配置就已經完成了,但是我知道你肯定不會只滿足於此。
上傳蒲公英
在構建框的底部我們選擇增加構建步驟->Execute shell,使用蒲公英的Api來上傳apk。
curl -F "file=@${WORKSPACE}/app/build/outputs/apk/${PRODUCT_FLAVORS}/${BUILD_TYPES}/gg-${BUILD_TYPES}-${PRODUCT_FLAVORS}-${VERSION_NAME}-${VERSION_CODE}.apk" -F "_api_key=${PGYER_API_KEY}" https://www.pgyer.com/apiv2/app/upload -F 'buildInstallType=2' -F "buildPassword=${PGYER_APK_PASSWORD}"
複製程式碼
注意這裡apk的名稱的規則需要與專案生成的apk的名稱規則一致,否則會找不到apk。另外,當我們打全渠道包的時候不上傳到蒲公英,我們可以編寫簡單的shell指令碼,判斷是否PRODUCT_FLAVORS
是否為空,如果空就是打多渠道包,不上傳蒲公英。
if [-n "${PRODUCT_FLAVORS}"]
then
curl -F "file=@${WORKSPACE}/app/build/outputs/apk/${PRODUCT_FLAVORS}/${BUILD_TYPES}/gg-${BUILD_TYPES}-${PRODUCT_FLAVORS}-${VERSION_NAME}-${VERSION_CODE}.apk" -F "_api_key=${PGYER_API_KEY}" https://www.pgyer.com/apiv2/app/upload -F 'buildInstallType=2' -F "buildPassword=${PGYER_APK_PASSWORD}"
fi
複製程式碼
WORKSPACE
是Jenkins內建的環境變數,想檢視更多內建環境變數可檢視:wiki.jenkins.io/display/JEN…
更新Build Name
在構建專案的左下角,Jenkins會為我們列出構建歷史,預設以#${BUILD_NUMBER}
的形式展示的,所以我們會看到#1,#2,#3這樣的名稱,為了瘋狂暗示,我們可以修改這個構建名稱,我們需要先下載build-name-setter
外掛,然後選擇增加構建步驟->Update build name進行配置。
構建完成後的效果如下:
BUILD_NUMBER
是Jenkins內建的環境變數,想檢視更多內建環境變數可檢視:wiki.jenkins.io/display/JEN…
收整合果
在構建專案的首頁會列出我們構建後的成果(apk),但是這需要我們配置一下成果的路徑。
選擇增加構建後操作步驟->Archive the artifacts來進行配置:
如果你沒有多渠道包的需要,建議你使用完整的路徑:
app/build/outputs/apk/${PRODUCT_FLAVORS}/${BUILD_TYPES}/*.apk
複製程式碼
為了收集全渠道包所以這裡直接使用**/*.apk
來匹配/apk
資料夾下的所有.apk
檔案。
刪除舊的構建
Jenkins預設會保留所有構建,可以在構建歷史裡檢視,當我們構建次數多了之後,硬碟就會慢慢被塞滿,這時候我們可以刪除一些比較舊的構建,構建的目錄在/var/lib/jenkins/jobs/構建專案名稱/builds/構建序號
,你可以手動進行刪除,也可以使用外掛。接下來我們就說下如何使用外掛來自動刪除舊的構建。這裡我們需要藉助Discard Old Build
外掛。安裝外掛後選擇增加構建後操作步驟->Discard Old Builds來進行配置:
這裡我選擇了保留7天內的構建。詳細可檢視外掛說明:Discard Old Build
Jenkins許可權控制
如前所述,我們希望讓測試人員自行打包,但是我們並不希望測試人員或者其他對Jenkins不瞭解的人員有過大的許可權,避免誤操作,所以我們限制一下許可權,讓他們只能進行構建等簡單操作。
實現許可權管理功能我們使用Role-based Authorization Strategy
外掛,安裝完外掛後進入系統管理->全域性安全配置->授權策略中選擇Role-Based Strategy。接下來就可以配置使用者許可權了。
- 系統管理->Manage and Assign Roles->Manage Roles
首先我們建立2個角色:dev
,test
。dev是分配給開發人員,可以對專案進行配置,test分配給測試人員,只能進行打包等簡單操作。我們可以把滑鼠游標移到許可權名稱上面,會顯示許可權描述。這裡就不說明每個許可權的作用了。
- 系統管理->Manage and Assign Roles->Assign Roles
為不同使用者分配不同的許可權。確保該使用者存在,如果使用者還沒建立,可以在系統管理->管理使用者進行建立。
切換不同的使用者,你會發現他們可以操作的功能不同,如測試人員只能進行構建和檢視基本的構建資訊:
結語
本文截圖比較多,感謝你抽空閱讀,本文主要記錄自己配置Jenkins引數化的過程和一些遇到的問題,希望對你有所幫助。Jenkins能做的事很多,不僅僅是用來打包,如為git伺服器新增hook,進行一些規範檢查,程式碼檢查等,提升專案質量。希望大家都能用做工程的想法來做專案。