GitLab 開啟 LFS 與 hashed storage

這篇算是 Heresy 這邊透過 Docker 來架設 GitLab server 的一些後續,真要說的話,應該是之前《GitLab 升級到 13 的筆記》的延伸。

GitLab 在 13.0 的時候,把「Design Management」(官方文件)開放給免費的使用者使用了。這項功能的目的,主要應該就是讓使用者可以在 issue 中上傳圖檔,方便討論。

不過,對 Heresy 這種是從 GitLab 11 升級上來的人來說,這項功能預設是不能用的。而且還會在 issue 那邊顯示警告,看起來滿煩的。 XD

閱讀更多»

GitLab 升級到 13 的筆記

Heresy 這邊在去年架設好自己的 GitLab 後,都有固定在更新,同時也在試著研究之前沒用上的功能、看看到底有沒有幫助(例如 Gitlab CI/CD)。

由於自己採用的是 Docker 的形式(Omnibus GitLab),所以其實不管是安裝、升級,都算是相對簡單的;但是在升級到前幾天推出的 GitLab 13 的時候,倒是小出包了一下…

GitLab 13 的新功能,可以參考官方的《GitLab 13.0 released with Gitaly Clusters, Epic Hierarchy on Roadmaps, and Auto Deploy to ECS》這篇介紹。

而這邊踩到的地雷,則是他把預設的網頁伺服器,從 Unicorn 改成 Puma 了。

閱讀更多»

GitLab CI + Windows Docker 的一些紀錄

Docker(官網)這種比虛擬機器更輕量化的「容器」虛擬化技術,基本上算是這幾年來一個滿重要的技術。透過 Docker,他可以將需要的環境打包、建構出類似虛擬機器,但是更小、更彈性的可移植環境,在需要自動佈署的環境上,應該算是很實用的一種技術。(參考介紹參考介紹

不過由於工作的領域不同,所以 Heresy 其實之前都沒有去碰這一個技術;真的開始接觸到,是之前試著使用 Docker 來架設 GitLab Server 的時候開始的。

後來,Heresy 也很認真地開始搞整個 GitLab CI/CD 的架構,試著透過 GitLab 的系統來做一些程式開發的自動化建置、測試。最初,考慮到環境的熟系程度,Heresy 都是直接使用作業系統的 shell 來作為 gitlab-runner 的 executor。

閱讀更多»

GitLab CI/CD 支援 DAG、工作可以多線同時進行了~

Heresy 今年把新的 GitLab Server 架好後,就開始玩 CI/CD(Continuous Integration and Deployment)的功能、試著透過這個架構,來做一定程度的自動化了。

除了目前 C++ 專案的自動建置腳本已經算是完成了,其他一些特別的工作,也開始試著用 GitLab CI/CD 來玩,所以這段期間對這東西還算玩得滿認真的。

而從開始些 C++ 專案的跨平台建置開始,其實 Heresy 就覺得 GitLab CI/CD 的架構,有一點很討厭,就是他是基於「stage」來控制流程的,前面的 stage 沒有全部結束的話,後面的 stage 就不會進行。

所以如果整個 pipeline 有 build 和 test 兩個 stage 的情況下,就會變成要所有的 build 都完成,才能進行測試。

閱讀更多»

[濫用] GitLab CI/CD 的 cache 機制

感謝網友提醒,根據官方《Cache vs artifacts》的說法,看來 Heresy 這邊把 build 階段產生的檔案透過 cache 傳遞到 test 階段,應該是嚴重的誤解/誤用了。 XD


之前在《GitLab 簡單的 C++ 專案腳本範例》和《GitLab 的 C++ CI/CD 腳本:使用 PowerShell》這兩篇文章,有分享了 Heresy 這邊目前 GitLab CI/CD 的腳本寫法了。

而當時也有提到,在 build 階段到 test 階段,Heresy 沒有玩出比較正規的檔案傳遞方法。

最近 Heresy 又開始測試這部分的東西。理論上,要在不同的 job 間傳遞檔案,是要透過在 .gitlab-ci.yml 裡面加上 cache官網)來做。

在有加入 cache 的狀況下,GitLab Runner 會在 job 開始、透過 git 取得檔案後,就試著把 cahce 的檔案抓下來;而當腳本執行完後,則會再把 cache 指定的檔案打包,放到 Gitlab-runner 上。

Heresy 目前加上 cache 後的 .gitlab-ci.yml 大致上會像下面這樣:

閱讀更多»

GitLab 的 C++ CI/CD 腳本:使用 PowerShell

之前已經在《GitLab 簡單的 C++ 專案腳本範例》這篇文章裡面,大概整理了一下 Heresy 這邊針對自己的 C++ 專案、撰寫出來的 GitLab CI 自動建置的腳本了。

不過,當時在 Windows 平台下,Heresy 是使用「Windows Batch」(CMD)這個 shell 來進行操作的。

但是,GitLab 官方其實有說,從 11.11 開始,就將「Windows Batch executor」設定為棄用(deprecated),並將於 13.0 時移除(預計時間是 2020/06/22);而取而代之的,GitLab 將使用 PowerShell 來作為 Windows 上預設的 shell。(參考

而這篇記錄,就是簡單地記錄一下 Heresy 把之前 cmd 的 script、改寫成 PowerShell 版本的紀錄。

閱讀更多»

GitLab 簡單的 C++ 專案腳本範例

之前寫過《Gitlab CI/CD 簡單介紹》,大概介紹過 GitLab CI/CD 的架構了,而 Heresy 這邊,其實也針對工作用的 C++ 專案,撰寫了對應的腳本了。

雖然實際上還是有點問題,不過目前看來運作得好像也還算正常,就來稍微分享一下吧~

首先,在系統的配置上,Heresy 這邊是準備了兩台 VM 作為 GitLab Runner,一台是 Windows 10、一台是 Ubuntu,分別處理 Windows 和 Linux 的環境。

而在腳本上,則是分成了分析、建置、測試三個階段:

閱讀更多»

Gitlab CI/CD 簡單介紹

今年初,Heresy 算是終於把工作地方的 GitLab 重新架設起來了。而後來好一段時間,Heresy 則都是在研究他的 CI/CD(Continuous Integration and Deployment)到底該怎麼做,目前也算終於弄到可以動了,所以就在這邊紀錄一下吧~

不過,這篇主要是先就 Heresy 理解的概念來寫,也希望沒有理解錯誤就是了。

首先,Gitlab 的 CI/CD(官網)做的事情,實際上就是讓 Gitlab 系統,可以在特定的時候(通常是 push、merge、或是自己排程),根據所撰寫的腳本,去進行程式碼的自動化建置、測試、甚至佈署。

下面的圖,就是官方提供的 GitLab CI/CD 的示意流程圖。

閱讀更多»

GitLab 系統架設簡單紀錄

Git(官網)目前應該算是現在最受歡迎的程式碼版本控管系統之一,而 GitHub(官網)也堪稱全球最大的開放原始碼軟體的倉庫了。

不過,雖然 GitHub 的網頁介面非常地方便,也受到大多數人的青睞,但是他並沒有提供整個系統讓使用者自行架設;而如果要自己架設類似的管理系統的話,目前看來最合適的,似乎就是 GitLab(官網)了。

GitLab 除了和 GitHub 一樣,有提供免費/付費的線上服務外,和 GitHub 不同的是,他是開放原始碼,並且也提供套件,讓使用者可以自己架設 GitLab 的服務。

而這一篇文章,就是 Heresy 自己試著架設 GitLab CE(社群版)的紀錄。

閱讀更多»

Git 切割方法:subtree

之前在研究切割 Git Repository 的時候,曾經寫了一篇《分割 Git Repository》做紀錄,不過最近要再做處理的時候,才發現當時紀錄的方法,比較接近使用「filter-branch」這個指令來硬上;實際上 Git 本身還有提供其他的方法,可以更直覺地把 Repository 的一部分、切割出來成為一個獨立的 Repository。

這樣的功能,在 Git 裡面是所謂的 subtree。

如果要針對現有的 respository 做切割的話,基本上就是要使用 git subtree split 這個指令;例如:

git subtree split -P ModuleAPath -b "ModuleA"

上面的 git 指令的效果,就是建立出一個新的新的分支(branch)「ModuleA」,裡面只有「ModuleAPath」這個資料夾下的東西而已。

閱讀更多»