Windows 的 GitLab Runner 可以在 Windows 11 使用 process 隔離的 Docker 了

之前 Heresy 就在《GitLab CI + Windows Docker 的一些紀錄 Part 2》抱怨過，GitLab Runner 如果要使用 Docker 作為 executor 的話，由於 Windows Runner 的作業系統版本會受限於 GitLab Runner 使用的 helper image 的支援度，這也導致如果要建立使用 Docker executor 模式的 Windows 版 GitLab runner 變得很麻煩。

像是之前 GitLab Runner 15.10 的時候，想在 Windows 11 的電腦上用 Docker executor 模式來跑 runner 的話，基本上就只會得到下面的錯誤：

ERROR: Preparation failed: detecting base image: unsupported Windows Version: 
Microsoft Windows Version 22H2 (OS Build 22621.1485)

而前一陣子，GitLab 更新到了 15.11 了（官方介紹），GitLab Runner 也同時更新到 15.11.0（changelog），這才終於更新了 Windows 版的 helper image，讓 Windows 11 的電腦可以使用 Docker executor 模式！

廣告

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

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

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

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

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

Heresy 在去年五月的時候，有寫一篇《刀劍神域記憶重組 公告變更記錄產生器》，算是幫自己寫的網站爬蟲／更新偵測器做個紀錄。

後來在今年三月，則也有去處理 GitLab 專案 CI/CD 的 artifact 占用過大空間的問題（參考）。

而這幾天，則是又抓時間改了一些以前就想做的東西。

清除 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。