hudson中subversion HEAD check out 的問題及疑惑

hudson中subversion HEAD check out 的問題及疑惑

近期發現一個問題,hudson執行任務時,經常不能獲取到最新的代碼,從而導致出現各種問題。 

日常開發中的典型例子:發現一個bug,修改代碼,本地測試通過,提交代碼到subversion,手工激活hudson構建,原本期望hudson獲取到剛剛提交的代碼並測試/打包/發佈。結果事與願違,測試的結果發現剛剛做出的修改似乎沒有生效。正費解之時,再執行一次hudson構建,又成功了... 

經歷過幾次上述蹊蹺遭遇之後,發現這個問題不是偶然。之後檢查hudson的日誌,發現問題的發現在最開始update / check out subversion代碼時,明明已經提交的代碼,hudson做update / check out時,居然沒有update / check out下來!顯示的subversion版本號也和subversion上實際的最新版本不一致,hudson總是要小一些,換言之,hudson update / check out的代碼要比當前最新代碼老一些。 

google一番,發現這個問題之前就有人遭遇過,hudson上甚至已經有了好幾個關於這個問題的bug,比如 http://issues.hudson-ci.org/browse/HUDSON-1241 "force using HEAD SVN version for build"。問題的根源在於hudson 獲取subversion代碼的方式,hudson是通過時間戳的方式來獲取代碼,而不是我們一般認爲的"最新代碼"即"HEAD"。這種方式通常沒有問題,因爲獲取當前時間戳,然後要求update / checkout這個時間戳前的代碼,理論上也是可以拿到最新代碼的。 

但是,如果hudson所在的服務器和subversion服務器時間不一致,這個機制就會出現問題: 

我們假設subversion服務器的時間是準確的,再假設當時時間是15:10分,開發人員A提交代碼,subversion上當前這個最新提交的代碼時間戳爲15:10:00。然後開發人員A手工激活hudson進行構建。hudson在15:10:20時開始check out代碼。如果hudson時間無誤,則hudson會發出請求說要求獲取時間戳在15:10:20之前的代碼,這樣這個實際提交時間爲15:10:00的新代碼就可以如期的被check out。但是如果hudson的時鐘有誤,由於某些原因導致時鐘偏慢2分鐘,即在hudson上,"當前時間"爲"15:08:20",則hudson獲取代碼的請求爲:獲取時間戳爲15:08:20之前的代碼,此時時間戳爲15:10:00的新代碼就無法checkout。 

幾分鐘之後,疑惑的開發人員A再次激活hudson再次構建,假設此時時間時間是15:15:00,hudson慢兩分鐘爲15:13:00。此時hudson發出請求: 獲取時間戳爲15:13:00之前的代碼, 因此實際提交時間爲15:10:00的新代碼可以正常checkout,問題又在不知不覺被迴避了。 

總結說,hudson 獲取代碼的機制不是我們直覺中的獲取最新代碼(即subversion中HEAD checkout),而是基於時間戳。由於這個方式通常如HEAD般工作,因此我們總是容易誤解爲是獲取最新代碼。當hudson的時鐘晚於subversion時,悲劇就出現了。 

對這個問題,有幾點疑惑: 

1. 不明白爲什麼hudson不採用最直接最簡單最容易被人理解最不容易出誤解的HEAD checkout,而要基於時間戳 

2. 這個問題很早就發生了,上面提到的bug 08年就被人提出, "Created: 31/Jan/08 05:37 AM   Updated: 01/Jul/10 11:06 AM",三年了類似的bug被多次提出,但是就是始終沒有修復。 

修復的方式很簡單,就改一個類的一行代碼 

in Class: hudson.scm.SubversionSCM 

line 377: 
final SVNRevision revision = SVNRevision.create(timestamp); 
replace to: 
final SVNRevision revision = SVNRevision.HEAD; 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章