本節是建立在 流水線入門内容的基礎上，而且，應當被當作一個參考。 對于在實際示例中如何使用流水線文法的更多資訊, 請參閱本章在流水線插件的2.5版本中的 使用 Jenkinsfile部分, 流水線支援兩種離散的文法，具體如下對于每種的優缺點, 參見文法比較。
正如 本章開始讨論的, 流水線最基礎的部分是 "步驟"。基本上, 步驟告訴 Jenkins 要做什麼，以及作為聲明式和腳本化流水線文法的基本建構塊。
對于可用步驟的概述, 請參考 流水線步驟引用，它包含了一個建構到流水線的步驟和 插件提供的步驟的全面的清單。
聲明式流水線
聲明式流水線是最近添加到 Jenkins 流水線的 [1]，它在流水線子系統之上提供了一種更簡單，更有主見的文法。
所有有效的聲明式流水線必須包含在一個
pipeline
塊中, 比如:
pipeline {
/* insert Declarative Pipeline here */
}
在聲明式流水線中有效的基本語句和表達式遵循與 Groovy的文法同樣的規則， 有以下例外:
- 流水線頂層必須是一個 block, 特别地:
pipeline { }
- 沒有分号作為語句分隔符，，每條語句都必須在自己的行上。
- 塊隻能由 節段, 指令, 步驟, 或指派語句組成。 *屬性引用語句被視為無參方法調用。 例如, input被視為 input()
節段
聲明式流水線中的節段通常包含一個或多個 指令 或 步驟。
代理
agent
部分指定了整個流水線或特定的部分, 将會在Jenkins環境中執行的位置，這取決于
agent
區域的位置。該部分必須在
pipeline
塊的頂層被定義, 但是 stage 級别的使用是可選的。
| Required | Yes |
|---|---|
| Parameters | Described below |
| Allowed | In the top-level |
參數
為了支援作者可能有的各種各樣的用例流水線,
agent
部分支援一些不同類型的參數。這些參數應用在`pipeline`塊的頂層, 或
stage
指令内部。
- any
- 在任何可用的代理上執行流水線或階段。例如:
agent any
none - 當在
pipeline
stage
agent
agent none
label - 在提供了标簽的 Jenkins 環境中可用的代理上執行流水線或階段。 例如:
agent { label 'my-defined-label' }
node -
agent { node { label 'labelName' } }
agent { label 'labelName' }
node
customWorkspace
docker - 使用給定的容器執行流水線或階段。該容器将在預置的 node上，或在比對可標明義的`label` 參數上，動态的供應來接受基于Docker的流水線。
docker
args
docker run
alwaysPull
docker pull
agent { docker 'maven:3-alpine' }
agent { docker { image 'maven:3-alpine' label 'my-defined-label' args '-v /tmp:/tmp' } } dockerfile - 執行流水線或階段, 使用從源代碼庫包含的
Dockerfile
Jenkinsfile
Dockerfile
agent { dockerfile true }
Dockerfile
dir
agent { dockerfile {dir 'someSubDir' } }
Dockerfile
filename
docker build ...
additionalBuildArgs
agent { dockerfile {additionalBuildArgs '--build-arg foo=bar' } }
build/Dockerfile.build
version
agent { // Equivalent to "docker build -f Dockerfile.build --build-arg version=1.0.2 ./build/ dockerfile { filename 'Dockerfile.build' dir 'build' label 'my-defined-label' additionalBuildArgs '--build-arg version=1.0.2' } }
常見選項
有一些應用于兩個或更多
agent
的實作的選項。他們不被要求，除非特别規定。
- label
- 一個字元串。該标簽用于運作流水線或個别的
stage
。
該選項對
node
docker
dockerfile
customWorkspace - 一個字元串。在自定義工作區運作應用了
agent
stage
該選項對agent { node { label 'my-defined-label' customWorkspace '/some/other/path' } }node
docker
dockerfile
reuseNode -
一個布爾值, 預設為false。 如果是true, 則在流水線的頂層指定的節點上運作該容器, 在同樣的工作區, 而不是在一個全新的節點上。
這個選項對
docker
dockerfile
stage
agent
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent { docker 'maven:3-alpine' }
stages {
stage('Example Build') {
steps {
sh 'mvn -B clean verify'
}
}
}
}
在一個給定名稱和标簽( |
階段級别的
agent
部分 Jenkinsfile (Declarative Pipeline)
pipeline {
agent none
stages {
stage('Example Build') {
agent { docker 'maven:3-alpine' }
steps {
echo 'Hello, Maven'
sh 'mvn --version'
}
}
stage('Example Test') {
agent { docker 'openjdk:8-jre' }
steps {
echo 'Hello, JDK'
sh 'java -version'
}
}
}
}
在流水線頂層定義 |
| 使用鏡像在一個建立的容器中執行該階段的該步驟。 |
| 使用一個與之前階段不同的鏡像在一個建立的容器中執行該階段的該步驟。 |
post
post
部分定義一個或多個steps ，這些階段根據流水線或階段的完成情況而 運作(取決于流水線中
post
部分的位置).
post
支援以下 post-condition 塊中的其中之一:
always
,
changed
,
failure
,
success
,
unstable
, 和
aborted
。這些條件塊允許在
post
部分的步驟的執行取決于流水線或階段的完成狀态。
| Required | No |
|---|---|
| Parameters | None |
| Allowed | In the top-level |
Conditions
- 無論流水線或階段的完成狀态如何，都允許在
post
- 隻有目前流水線或階段的完成狀态與它之前的運作不同時，才允許在
post
- 隻有目前流水線或階段的完成狀态為"failure"，才允許在
post
- 隻有目前流水線或階段的完成狀态為"success"，才允許在
post
- 隻有目前流水線或階段的完成狀态為"unstable"，才允許在
post
- 隻有目前流水線或階段的完成狀态為"aborted"，才允許在
post
always
changed
failure
success
unstable
aborted
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
post {
always {
echo 'I will always say Hello again!'
}
}
}
按照慣例, |
| Post-condition 塊包含與 steps 部分相同的steps。 |
stages
包含一系列一個或多個 stage 指令,
stages
部分是流水線描述的大部分"work" 的位置。 建議
stages
至少包含一個 stage 指令用于連續傳遞過程的每個離散部分,比如建構, 測試, 和部署。
| Required | Yes |
|---|---|
| Parameters | None |
| Allowed | Only once, inside the |
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
|
steps
steps
部分在給定的
stage
指令中執行的定義了一系列的一個或多個steps。
| Required | Yes |
|---|---|
| Parameters | None |
| Allowed | Inside each |
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
|
指令
environment
environment
指令制定一個 鍵-值對序列，該序列将被定義為所有步驟的環境變量，或者是特定于階段的步驟， 這取決于
environment
指令在流水線内的位置。
該指令支援一個特殊的助手方法
credentials()
，該方法可用于在Jenkins環境中通過辨別符通路預定義的憑證。對于類型為 "Secret Text"的憑證,
credentials()
将確定指定的環境變量包含秘密文本内容。對于類型為 "SStandard username and password"的憑證, 指定的環境變量指定為
username:password
，并且兩個額外的環境變量将被自動定義 :分别為
MYVARNAME_USR
和
MYVARNAME_PSW
。
| Required | No |
|---|---|
| Parameters | None |
| Allowed | Inside the |
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
environment {
CC = 'clang'
}
stages {
stage('Example') {
environment {
AN_ACCESS_KEY = credentials('my-prefined-secret-text')
}
steps {
sh 'printenv'
}
}
}
}
頂層流水線塊中使用的 |
在一個 |
|
options
options
指令允許從流水線内部配置特定于流水線的選項。 流水線提供了許多這樣的選項, 比如
buildDiscarder
,但也可以由插件提供, 比如
timestamps
.
| Required | No |
|---|---|
| Parameters | None |
| Allowed | Only once, inside the |
可用選項
- buildDiscarder
- 為最近的流水線運作的特定數量儲存元件和控制台輸出。例如:
options { buildDiscarder(logRotator(numToKeepStr: '1')) }
disableConcurrentBuilds - 不允許同時執行流水線。 可被用來防止同時通路共享資源等。 例如:
options { disableConcurrentBuilds() }
overrideIndexTriggers - 允許覆寫分支索引觸發器的預設處理。 如果分支索引觸發器在多分支或組織标簽中禁用,
options { overrideIndexTriggers(true) }
options { overrideIndexTriggers(false) }
skipDefaultCheckout - 在`agent` 指令中，跳過從源代碼控制中檢出代碼的預設情況。例如:
options { skipDefaultCheckout() }
skipStagesAfterUnstable - 一旦建構狀态變得UNSTABLE，跳過該階段。例如:
options { skipStagesAfterUnstable() }
checkoutToSubdirectory - 在工作空間的子目錄中自動地執行源代碼控制檢出。例如:
options { checkoutToSubdirectory('foo') }
timeout - 設定流水線運作的逾時時間, 在此之後，Jenkins将中止流水線。例如:
options { timeout(time: 1, unit: 'HOURS') }
retry - 在失敗時, 重新嘗試整個流水線的指定次數。 For example:
options { retry(3) }
timestamps - 預謀所有由流水線生成的控制台輸出，與該流水線發出的時間一緻。 例如:
options { timestamps() }
Example
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
options {
timeout(time: 1, unit: 'HOURS')
}
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
| 指定一個小時的全局執行逾時, 在此之後，Jenkins 将中止流水線運作。 |
| 一個完整的可用選項清單正在等待完成第 INFRA-1503次。 |
階段選項
stage
的
options
指令類似于流水線根目錄上的
options
指令。然而，
stage
-級别
options
隻能包括
retry
,
timeout
, 或
timestamps
等步驟, 或與
stage
相關的聲明式選項，如
skipDefaultCheckout
。
在`stage`,
options
指令中的步驟在進入
agent
之前被調用或在
when
條件出現時進行檢查。
可選的階段選項
- skipDefaultCheckout
- 在
agent
options { skipDefaultCheckout() }
timeout - 設定此階段的逾時時間, 在此之後， Jenkins 會終止該階段。 例如:
options { timeout(time: 1, unit: 'HOURS') }
retry - 在失敗時, 重試此階段指定次數。 例如:
options { retry(3) }
timestamps - 預謀此階段生成的所有控制台輸出以及該行發出的時間一緻。例如:
options { timestamps() }
示例 Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
options {
timeout(time: 1, unit: 'HOURS')
}
steps {
echo 'Hello World'
}
}
}
}
指定 |
參數
parameters
指令提供了一個使用者在觸發流水線時應該提供的參數清單。這些使用者指定參數的值可通過
params
對象提供給流水線步驟, 了解更多請參考示例。
| Required | No |
|---|---|
| Parameters | None |
| Allowed | Only once, inside the |
可用參數
- string
- 字元串類型的參數, 例如:
parameters { string(name: 'DEPLOY_ENV', defaultValue: 'staging', description: '') }
booleanParam - 布爾參數, 例如:
parameters { booleanParam(name: 'DEBUG_BUILD', defaultValue: true, description: '') }
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
parameters {
string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')
}
stages {
stage('Example') {
steps {
echo "Hello ${params.PERSON}"
}
}
}
}
| 一份完整的可用參數清單正在等待 INFRA-1503的完成。 |
觸發器
triggers
指令定義了流水線被重新觸發的自動化方法。對于內建了源（ 比如 GitHub 或 BitBucket）的流水線, 可能不需要
triggers
，因為基于 web 的內建很肯能已經存在。 目前可用的觸發器是
cron
,
pollSCM
和
upstream
。
| Required | No |
|---|---|
| Parameters | None |
| Allowed | Only once, inside the |
- cron
- 接收 cron 樣式的字元串來定義要重新觸發流水線的正常間隔 ,比如:
triggers { cron('H */4 * * 1-5') }
pollSCM - 接收 cron 樣式的字元串來定義一個固定的間隔，在這個間隔中，Jenkins 會檢查新的源代碼更新。如果存在更改, 流水線就會被重新觸發。例如:
triggers { pollSCM('H */4 * * 1-5') }
upstream - 接受逗号分隔的工作字元串和門檻值。 當字元串中的任何作業以最小門檻值結束時，流水線被重新觸發。例如:
triggers { upstream(upstreamProjects: 'job1,job2', threshold: hudson.model.Result.SUCCESS) }
|
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
triggers {
cron('H */4 * * 1-5')
}
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
stage
stage
指令在
stages
部分進行，應該包含一個 實際上, 流水巷所做的所有實際工作都将封裝進一個或多個
stage
指令中。
| Required | At least one |
|---|---|
| Parameters | One mandatory parameter, a string for the name of the stage. |
| Allowed | Inside the |
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
工具
定義自動安裝和放置
PATH
的工具的一部分。如果
agent none
指定，則忽略該操作。
| Required | No |
|---|---|
| Parameters | None |
| Allowed | Inside the |
支援工具
- maven jdk gradle
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
tools {
maven 'apache-maven-3.0.1'
}
stages {
stage('Example') {
steps {
sh 'mvn --version'
}
}
}
}
| The tool name must be pre-configured in Jenkins under Manage Jenkins → Global Tool Configuration. |
input
stage
的
input
指令允許你使用
input
step提示輸入。 在應用了
options
後，進入
stage
的
agent
或評估
when
條件前，
stage
将暫停。 如果
input
被準許,
stage
将會繼續。 作為
input
送出的一部分的任何參數都将在環境中用于其他
stage
。
配置項
- message
- 必需的。 這将在使用者送出
input
id -
input
stage
ok - `input`表單上的"ok" 按鈕的可選文本。 submitter
- 可選的以逗号分隔的使用者清單或允許送出
input
submitterParameter - 環境變量的可選名稱。如果存在，用
submitter
parameters - 提示送出者提供的一個可選的參數清單。 更多資訊參見 [parameters]。
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
input {
message "Should we continue?"
ok "Yes, we should."
submitter "alice,bob"
parameters {
string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')
}
}
steps {
echo "Hello, ${PERSON}, nice to meet you."
}
}
}
}
when
when
指令允許流水線根據給定的條件決定是否應該執行階段。
when
指令必須包含至少一個條件。 如果
when
指令包含多個條件, 所有的子條件必須傳回True，階段才能執行。 這與子條件在
allOf
條件下嵌套的情況相同 (參見下面的示例)。
使用諸如
not
,
allOf
, 或
anyOf
的嵌套條件可以建構更複雜的條件結構 can be built 嵌套條件刻意潛逃到任意深度。
| Required | No |
|---|---|
| Parameters | None |
| Allowed | Inside a |
内置條件
- branch
- 當正在建構的分支與模式給定的分支比對時，執行這個階段, 例如:
when { branch 'master' }
environment - 當指定的環境變量是給定的值時，執行這個步驟, 例如:
when { environment name: 'DEPLOY_TO', value: 'production' }
expression - 當指定的Groovy表達式評估為true時，執行這個階段, 例如:
when { expression { return params.DEBUG_BUILD } }
not - 當嵌套條件是錯誤時，執行這個階段,必須包含一個條件，例如:
when { not { branch 'master' } }
allOf - 當所有的嵌套條件都正确時，執行這個階段,必須包含至少一個條件，例如:
when { allOf { branch 'master'; environment name: 'DEPLOY_TO', value: 'production' } }
anyOf - 當至少有一個嵌套條件為真時，執行這個階段,必須包含至少一個條件，例如:
when { anyOf { branch 'master'; branch 'staging' } }
在進入 stage
agent
when
stage
agent
when
預設情況下, 如果定義了某個階段的代理，在進入該`stage` 的
agent
後該
stage
的
when
條件将會被評估。但是, 可以通過在
when
塊中指定
beforeAgent
選項來更改此選項。 如果
beforeAgent
被設定為
true
, 那麼就會首先對
when
條件進行評估 , 并且隻有在
when
條件驗證為真時才會進入
agent
。
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
branch 'production'
}
steps {
echo 'Deploying'
}
}
}
}
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
branch 'production'
environment name: 'DEPLOY_TO', value: 'production'
}
steps {
echo 'Deploying'
}
}
}
}
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
allOf {
branch 'production'
environment name: 'DEPLOY_TO', value: 'production'
}
}
steps {
echo 'Deploying'
}
}
}
}
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
branch 'production'
anyOf {
environment name: 'DEPLOY_TO', value: 'production'
environment name: 'DEPLOY_TO', value: 'staging'
}
}
steps {
echo 'Deploying'
}
}
}
}
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
expression { BRANCH_NAME ==~ /(production|staging)/ }
anyOf {
environment name: 'DEPLOY_TO', value: 'production'
environment name: 'DEPLOY_TO', value: 'staging'
}
}
steps {
echo 'Deploying'
}
}
}
}
Jenkinsfile (Declarative Pipeline)
pipeline {
agent none
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
agent {
label "some-label"
}
when {
beforeAgent true
branch 'production'
}
steps {
echo 'Deploying'
}
}
}
}
并行
聲明式流水線的階段可以在他們内部聲明多隔嵌套階段, 它們将并行執行。 注意，一個階段必須隻有一個
steps
或
parallel
的階段。 嵌套階段本身不能包含進一步的
parallel
階段, 但是其他的階段的行為與任何其他
stage
相同。任何包含
parallel
的階段不能包含
agent
或
tools
階段, 因為他們沒有相關
steps
。
另外, 通過添加
failFast true
到包含
parallel`的 `stage
中， 當其中一個程序失敗時，你可以強制所有的
parallel
階段都被終止。
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Non-Parallel Stage') {
steps {
echo 'This stage will be executed first.'
}
}
stage('Parallel Stage') {
when {
branch 'master'
}
failFast true
parallel {
stage('Branch A') {
agent {
label "for-branch-a"
}
steps {
echo "On Branch A"
}
}
stage('Branch B') {
agent {
label "for-branch-b"
}
steps {
echo "On Branch B"
}
}
}
}
}
}
步驟
聲明式流水線可能使用在 流水線步驟引用中記錄的所有可用的步驟, 它包含一個完整的步驟清單, 其中添加了下面列出的步驟，這些步驟隻在聲明式流水線中 only supported 。
腳本
script
步驟需要 [scripted-pipeline]塊并在聲明式流水線中執行。 對于大多數用例來說,應該聲明式流水線中的“腳本”步驟是不必要的， 但是它可以提供一個有用的"逃生出口"。 非平凡的規模和/或複雜性的
script
塊應該被轉移到 共享庫 。
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
script {
def browsers = ['chrome', 'firefox']
for (int i = 0; i < browsers.size(); ++i) {
echo "Testing the ${browsers[i]} browser"
}
}
}
}
}
}
腳本化流水線
腳本化流水線, 與[declarative-pipeline]一樣的是, 是建立在底層流水線的子系統上的。與聲明式不同的是, 腳本化流水線實際上是由 Groovy建構的通用 DSL [2]。 Groovy 語言提供的大部分功能都可以用于腳本化流水線的使用者。這意味着它是一個非常有表現力和靈活的工具，可以通過它編寫持續傳遞流水線。
流控制
腳本化流水線從
Jenkinsfile
的頂部開始向下串行執行, 就像 Groovy 或其他語言中的大多數傳統腳本一樣。 是以，提供流控制取決于 Groovy 表達式, 比如
if/else
條件, 例如:
Jenkinsfile (Scripted Pipeline)
node {
stage('Example') {
if (env.BRANCH_NAME == 'master') {
echo 'I only execute on the master branch'
} else {
echo 'I execute elsewhere'
}
}
}
另一種方法是使用Groovy的異常處理支援來管理腳本化流水線流控制。當 步驟 失敗 ，無論什麼原因，它們都會抛出一個異常。處理錯誤的行為必須使用Groovy中的
try/catch/finally
塊 , 例如:
Jenkinsfile (Scripted Pipeline)
node {
stage('Example') {
try {
sh 'exit 1'
}
catch (exc) {
echo 'Something failed, I should sound the klaxons!'
throw
}
}
}
步驟
正如 本章開始所讨論的, 流水線最基礎的部分是"步驟"。從根本上說, 步驟告訴 Jenkins要做 what ，并作為聲明式和腳本化流水線已發的基本建構塊。
腳本化流水線 not 不引入任何特定于其文法的步驟; 流水線步驟引用 包括流水線和插件提供的步驟的完整清單。
差別普通 Groovy
為了提供 durability, 這意味着運作流水線可以在Jenkins master 重新開機後繼續運作，腳本化的流水順序列化資料到主伺服器。由于這個設計需求, 一些Groovy 習慣用語，比如
collection.each { item -> }
都不完全支援。詳情參見 JENKINS-27421 和 JENKINS-26481。
文法比較
當Jenkins 流水線第一次建構時, Groovy 被選為基礎。 Jenkins長期使用嵌入式 Groovy引擎來為管理者和使用者提供 進階腳本功能。另外, Jenkins流水線的實作者發現 Groovy是 建構現在成為 "腳本化流水線" DSL的堅實基礎 [2]。
由于它是一個功能齊全的程式設計環境, 腳本化流水線為Jenkins使用者提供了 大量的靈活性性和可擴充性。 Groovy學習曲線通常不适合給定團隊的所有成員, 是以創造了聲明式流水線來為編寫Jenkins流水線提供一種更簡單、更有主見的文法。
兩者本質上是相同的流水線子系統。 underneath. 他們都是 "流水線即代碼" 的持久實作。它們都能夠使用建構到流水線中或插件提供的步驟。它們都能夠使用 共享庫
但是它們的差別在于文法和靈活性。 聲明式限制了使用者使用更嚴格和預定義的結構， 使其成為更簡單的持續傳遞流水線的理想選擇。 腳本化提供了很少的限制, 以至于對腳本和文法的唯一限制往往是由Groovy子集本身定義的，而不是任何特定于流水線的系統, 這使他成為權利使用者和那些有更複雜需求的人的理想選擇。 顧名思義, 聲明式流水線鼓勵 聲明式程式設計模型。 [3] 而腳本化流水線遵循一個更指令式的程式設計模型 [4]
https://www.cnblogs.com/YatHo/p/7856556.html
http://www.cnblogs.com/fengjian2016/p/8227532.html
https://jenkins.io/zh/doc/book/pipeline/syntax/#%E6%B5%81%E6%B0%B4%E7%BA%BF%E8%AF%AD%E6%B3%95
轉載于:https://www.cnblogs.com/chengkanghua/p/10711169.html
![Java String.format方法的簡單使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)