60; remote.allowAnyHosts= true
writeFile file:'jemeter.sh', text: 'cd /ibm \n ls'
sshScript remote: remote,script: "jemeter.sh"
}
}
}
}
}
}
如何用Jenkins/Hudson創建真正的pipeline
這幾天嘗試用Jenkins/Hudson創建pipeline，發現網上的信息很少，所以寫一篇跟大家分享。
在開始之前，得告訴你被我的標題給忽悠了，不是Jenkins/Hudson，只是Jenkins！如果你還在用Hudson，那么我建議你立即切換到Jenkins。理由就不說了，看看這個投票就行。（此中，我吃盡了苦頭）
接下來，就讓我們一步一步用Jenkins搭建真正的pipeline吧。
第一步
第一步，我們先創建一個最簡單的pipeline。所謂pipeline，顧名思義，就是一個流水線，由多個步驟（steps）組成。每走完一步，就來到下一步。用Build Pipeline Plugin就可以很方便地實現。
實現的效果如下圖：
上例中，UnitTest是我們的初始任務。UnitTest結束之后，自動觸發AC Test。如果通過了AC Test，團隊可以有選擇地部署到任意測試環境。
在配置這個插件時，最重要的就是選擇Initial Job。
然后，在每一個step（job）中選擇downstream step。可以是自動觸發（Build Other Projects），也可以選擇手動觸發（Manually Execute Downstream Project）。
第二步
第一步中我們實現了一個流水線，但這個只是看上去的流水線而已。在工廠的流水線中，歷經流水線上游到下游的，應該是同一個產品。但上例中顯然不是，Unit Test和Acceptance Test所運行的可能是不同版本的代碼。
要讓幾個step的代碼運行在同一個版本，可以使用一個叫做Parameterized Trigger Plugin。如下圖：
選擇把Subversion revision傳到下面的steps，則接下來的Steps都會checkout同一個版本的代碼。但這個也有限制，就是這些Steps必須有相同的subversion URL配置。
另外，你應該還注意到我們還傳了另一個參數：PL_BUILD_NUMBER。這個參數會另有用途。
除了希望保持相同版本，我們很可能希望重用upstream step生成的artifact。比如，在AC Test step會生成一些artifacts，這些artifacts經過測試之后，希望可以用于Deploy步驟。一方面，這會節省重新構建artifact的時間；另一方面，這些artifact是已經經過測試的，是可用的，而重新構建生成的卻是未經測試的，可用與否未知。（雖然他們應該是一樣的，但誰知道呢。。）我們可以使用ArtifactDepolyerPlugin實現。
建議你這樣試試看：
在每個stage{ } 中, 用 post { } 上傳日志
再整個 pipeline{ } 末尾, 用 post{ } 上傳日志
這樣做的好處：
層次清晰
可以聚合各個 stage 的日志, 如 robotframework log, build log ......
By Xiak