本文經過簡單的pipeline的實例和詳細的講解,可以學習基本pipeline的groovy用法,而後開始實現本身的pipeline job。java
翻譯和修改自:https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.mdnode
文章來自:http://www.ciandcd.com
文中的代碼來自能夠從github下載: https://github.com/ciandcdlinux
1. 安裝java,maven,配置jenkinsgit
安裝java和maven:github
#install java jdk
sudo apt-get update
sudo apt-get install default-jdkubuntu
#install maven in ubuntu
sudo apt-get update
sudo apt-get install mavenwindows
#setting for maven
~/.bashrc
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64bash
#testing maven
/usr/share/maven/bin/mvn -v
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-24-generic", arch: "amd64", family: "unix"jvm
在jenkins的global tool configuration裏配置環境變量maven
2. 建立簡單的pipeline job
groovy代碼以下:
node {
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
def mvnHome = tool 'M3'
sh "${mvnHome}/bin/mvn -B verify"
}
上面的代碼實現了從github checkout源代碼,而後經過maven來構建, 代碼中包含了測試用例,有可能會隨機的失敗, 若是有測試用例失敗,則整個pipeline job將會標記爲失敗。
若是是windows系統,須要修改成bat "${mvnHome}\\bin\\mvn -B verify"。
groovy的node用來選擇運行的機器,只要node還有可用的executor,node裏的step任務將會在選中的機器上運行,且會在選中的機器上建立workspace。
許多的step必須在node裏執行,例如git,sh等必須在node環境裏執行。
不像用戶定義的函數,pipeline step老是接受命名參數,括號能夠省略,也可使用標準的groovy語法傳入map做爲參數,例如等價用法:
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git', branch: 'master'
git([url: 'https://github.com/jglick/simple-maven-project-with-tests.git', branch: 'master'])
若是隻有一個強制的參數,則能夠省略參數名字,以下兩種等價效果:
sh 'echo hello'
sh([script: 'echo hello'])
def能夠定義groovy變量,tool能夠檢查指定名字的工具是否存在且能夠訪問,在雙引號裏使用變量,變量將會被替換爲真實的值:
def mvnHome = tool 'M3'
"${mvnHome}/bin/mvn -B verify"
3. 環境變量的使用
最簡單的使用工具的方式是將工具路徑加入到PATH中,經過env能夠修改node對應機器的環境變量,後面的steps能夠看到環境變量的修改。
node {
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
def mvnHome = tool 'M3'
env.PATH = "${mvnHome}/bin:${env.PATH}"
sh 'mvn -B verify'
}
jenkins的job有一些內置的默認的環境變量,能夠經過http://jenkins-server/job/javahelloworld/pipeline-syntax/globals來查看job默認的環境變量。 以下:
BRANCH_NAME
CHANGE_ID
CHANGE_URL
CHANGE_TITLE
CHANGE_AUTHOR
CHANGE_AUTHOR_DISPLAY_NAME
CHANGE_AUTHOR_EMAIL
CHANGE_TARGET
BUILD_NUMBER
BUILD_ID
BUILD_DISPLAY_NAME
JOB_NAME
JOB_BASE_NAME
BUILD_TAG
EXECUTOR_NUMBER
NODE_NAME
NODE_LABELS
WORKSPACE
JENKINS_HOME
JENKINS_URL
BUILD_URL
JOB_URL
例如你能夠在node中的step中使用env.BUILD_TAG。
一樣地,若是你使用參數化build,則同名的參數在groovy裏可使用。
4. 記錄測試結果和構建產物
當有測試用例失敗的時候,你可能須要保存失敗的用例結果和構建產物用於人工排查錯誤。
node {
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
def mvnHome = tool 'M3'
sh "${mvnHome}/bin/mvn -B -Dmaven.test.failure.ignore verify"
step([$class: 'ArtifactArchiver', artifacts: '**/target/*.jar', fingerprint: true])
step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
}
上面的例子中,-Dmaven.test.failure.ignore將忽略測試用例的失敗,jenkins將正常執行後面的step而後退出。
上面的兩個step調用至關於調用傳統的jenkins的steps將構建產物和測試結構保存。
如下兩個是等價做用,第一個是簡寫:
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
checkout scm: [$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'https://github.com/jglick/simple-maven-project-with-tests']]
5. slave機器的選擇、
groovy中經過node的參數labels來選擇slave,用法跟jenkins1裏的同樣,咱們須要先定義jenkins node,且給jenkins node定義label,而後在groovy裏使用node加label來選擇slave。
例如以下node選擇同時定義了unix和64bit的slave。
node('unix && 64bit') { // as before }
6. 暫停pipeline
新建pipeline job,修改groovy腳本以下:
node {
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
def mvnHome = tool 'M3'
sh "${mvnHome}/bin/mvn -B -Dmaven.test.failure.ignore verify"
input 'save artifacts and unit results?'
// rest as before
step([$class: 'ArtifactArchiver', artifacts: '**/target/*.jar', fingerprint: true])
step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
}
在job的運行頁面能夠看到
而後點擊proceed,pipelinejob就繼續執行了。貌似job console output中的 proceed/Abort鏈接點了沒有用。必需要要點擊pause for input的proceed/abort按鈕才能夠。
7. 分配workspace
當node執行steps的時候會自動分配workspace,用於checkout代碼,運行命令和其餘任務。在step執行的時候workspace是被lock的,workspace只能同時被一個build使用。若是多個build須要使用同一個node的workspace,新的workspace將會被自動分配。
例如你同時運行你的同一個job兩次,則第二個job log中能夠看到使用了不一樣的workspace:
並行的job若是在新的workspace,則須要從新checkout代碼,能夠查看job log來證明。下一節將學習更復雜的groovy用法。Running on <yourslavename> in /<slaveroot>/workspace/<jobname>@2