GitLab可以喺估佢唔到嘅地方爛

Document寫得太好都係竟然都係伏味指標？

是咁的，工作上目前嘅SCM (Source Code Management)+PM (Project Management)+CI (Continuous Integration)+CD (Continuous Delivery)流程有不足之處，而要改造當前嘅software stack — SCM:gitolite + PM:redmine + CI:jenkins + CD:custom scripts — 改到滿足所有需求亦好花工夫。

然後眼尾睄一睄GitLab (self-hosted)…好似係得得哋？所以就落手落腳去evaluate一下，但唔試由自可，一試把鬼火，佢真係會喺意想不到嘅地方爛…

時區

一個咁大、來自美國又有DST又盛、全球咁多人用、甚至支持多地域同步部署嘅software，時區應該唔會有問題吖。而且仲有成篇document教你點樣set，omnibus/chef嘅config example都寫得好明確要點樣改。

噉我咪由下至上，由左至右、1至49個號碼都用Asia/Hong_Kong時區囉。而無論server set乜timezone，個UI似乎會跟user嘅時區而做顯示，which is a good thing。

直到我試佢個CI — build緊嗰時睇到log，但一build完個log就好神奇地唔見咗亦load唔到。Debug過程中先知道原來build log係事後再以artifacts形式去保存，問題出自佢話拎唔到artifacts，但係gitlab-runner個upload artifacts又正常㗎喎。

然後睇artifacts個directory，啲files係以年月日+Job ID放，但嘩點解backup係嘗試open個job.log時係去搵2019–12–11，但實際上個job.log係擺喺2019–12–12入面？

再打開DB睇。

一個2019–12–12 15:40+8嘅job，喺DB嘅記錄係寫住2019–12–12 07:40+8，即係換算成UTC會變咗做2019–12–11 23:40Z。

等多20分鐘到下午4點，再跑條CI Pipeline，果然就一切正常。DB入面係寫2019–12–12 08:00+8，個artifact亦被正確定file落去2019–12–12，

如果噉都未夠嚇死人…睇睇個schema足以嚇死你:

竟然喺唔同嘅tables，都存在without/with time zone混合使用嘅columns。而所有with time zone嘅column都會出問題，反而without time zone就係正確…