GitLab CI + Windows Docker 的一些紀錄 Part 2

想不到有什麼簡短的標題,姑且就順著上次的《GitLab CI + Windows Docker 的一些紀錄》,把這篇當成 part 2 吧。

Heresy 這邊在 2019 年建立了工作環境的 GitLab server 後,也花了好一段時間把 GitLab CI/CD 的架構弄了一個雛型出來。中間有搞錯一些東西、也拿來玩了一些其它自己的東西

而老實說,在 Heresy 這邊碰到最多問題的,基本上應該還是 Windows Docker 上的問題了…

閱讀更多»

清除 GitLab 上所有 CI/CD 的 artifact

GitLab 的 CI/CD 功能在 Heresy 來看,算是相當便利的自動化功能,Heresy 現在不管是在工作,還是私人的東西,都有在透過這東西來做自動化的處理。

不過,前幾天…倒是發現自己之前的「刀劍神域記憶重組 公告變更記錄產生器」幹了件蠢事…

那就是 Heresy 沒有設定 artifact 的過期日,結果這些 artifact 都按照預設值,會保存四周。
而其結果,就是這個專案明明只有不到 400KB,卻佔用了 15GB 的空間…

閱讀更多»

GitLab 加入 Pipeline Editor 的功能

GitLab 基本上是一個有固定在更新的專案,每次更新也經常會出現一些實用的功能可以用。

像是在 12.2 的時候,引進了 「Directed Acyclic Graphs (DAG)」、13.7 的時候允許設定在手動執行 pipeline 的預輸入變數,個人都覺得算是滿實用的~

而這次 GitLab 更新到 13.8.0,則是加入了「pipeline editor」,讓使用者更容易地撰寫 GitLab CI/CD 的腳本了!

官方的更新公告是《GitLab 13.8 released with a Pipeline Editor and DORA metrics》。

閱讀更多»

GitLab 手動執行 pipeline 的預輸入變數

Heresy 這邊自從開始玩 GitLab CI/CD 後,發現其實它的應用範圍也還滿廣的,有的時候也可以拿來做一些額外的應用、服務的部屬;所以後來當 GitLab 更新的時候,都會注意一下有沒有什麼新功能可以玩。

而在去年底,GitLab 推出 13.7 的更新版的時候,是發現其中「Pre-filled variables when running pipelines manually」(連結)好像還算滿實用的?所以就稍微玩了一下。

這項功能官方之前也有一篇《How pre-filled CI/CD variables will make running pipelines easier》在介紹;相關的 issue 是《Generate Run Pipeline form with pre-filled variables from .gitlab-ci.yml》。

閱讀更多»

刀劍神域記憶重組 公告變更記錄產生器

之前有說過了,Heresy 為了自己在玩的手機遊戲《刀劍神域-記憶重組》另外弄了一個部落格來做紀錄(網址)。

而實際上,之前由於覺得遊戲內的公告由於不是照著更新時間排序、要找到哪個公告是新的實在很麻煩,所以就火大,自己試著想辦法去做公告的變更紀錄了。

搞了老半天,弄出了一個使用了兩個 Git repository 的奇怪架構系統,算是勉強做到堪用的程度了~

目前的成品是:https://kheresy.github.io/SAOMD-AA/changelog.html
而實際在運作的專案則是 https://gitlab.com/kheresy/saomd-announcement

閱讀更多»

在 Synology NAS 上跑 gitlab-runner

Heresy 自從在去年在工作的環境架設了 GitLab 之後,就開始很認真地在搞 CI/CD 這塊了;而為了自動化流程的需要,目前也有好幾台電腦、都拿來安裝 gitlab-runner 作為接 CI/CD 的工作機了~

由於 Heresy 這邊 CI/CD 的工作基本上都是大量編譯,所以也都是拿比較高檔的電腦來做為 runner;但是這次,因為想要試試看自動將網站的容器佈署到測試機器上,由於負載不會太高,所以才會考慮拿手邊的 Synology DS918+(官網)這台多功能的 NAS 來用。

不過,實際用起來,這才發現…要成功架設到能用的難度好高啊…

閱讀更多»

GitLab 的 feature flag 設定

最近 Heresy 還是繼續在玩 GitLab CI/CD 的應用。

之前 GitLab 推出了 DAG 的功能,透過 needs 這個標籤,可以多線同時進行工作,在某些場合算是相當方便的~

不過後來因為 Heresy 試著把工作拆分到很細,所以就採到他的一個問題,那就是 needs 的數量上限了。

在官方文件(連結)中也有提到,目前有針對 needs 中指定的工作數量做限制。下面是原文:

We are temporarily limiting the maximum number of jobs that a single job can need in the needs: array:

  • For GitLab.com, the limit is five. For more information, see our infrastructure issue.
  • For self-managed instances, the limit is:
  • Five by default (ci_dag_limit_needs feature flag is enabled).
  • 50 if the ci_dag_limit_needs feature flag is disabled.

 

閱讀更多»

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 都完成,才能進行測試。

閱讀更多»