在早期要設計 GitLab CI/CD 的 pipeline 的時候，如果想要把常用的東西（變數、腳本）抽出來、讓這些東西可以跨專案共用的話，基本上是可以用「include」這個關鍵字（官方文件）、然後會滿多種使用情境可以選擇，其中比較常見的，應該是使用「template」了。
而在 GitLab 17 開始，GitLab 正式引進了更適合拿來當 CI/CD pipeline 的元件的設計：CI/CD component（官方文件）。
他基本上改用「inputs」作為明確的輸入參數、和「variables」做區隔，讓使用者更明確地知道該怎麼調整參數。
此外，透過加入「CI/CD Catalog」（官方文件）這個特殊的系統、來列出有發布的 CI/CD component、讓全站的使用者都可以知道有那些元件可以使用；這點在個人來看算是和之前相比更為方便的了！
使用 gitlab.com 的狀況
如果是使用 gitlab.com 來說，在 https://gitlab.com/explore/catalog 這個頁面，就可以看到各種 CI/CD component，其中有多是 GitLab 官方提供的。
而如果要進到這個頁面的話，操作步驟有點繁瑣：
- 點選左方面板的「Search or go to…」
- 點選「Explore」
- 點選左方面板的「CI/CD Catalog」
在這個介面中，點選自己需要的 component 後，則可以看到他的說明、使用方式、以及所有的輸入參數。
例如下面就是 SAST 這個元件的主要頁面（網頁），會有最基本的使用說明：
而切換到 Readme 的頁面，也會有更詳細的說明可以參考。
所以如果是在 gitlab.com 上的專案的話，在最簡單的狀況下，其實只要複製他給腳本、貼到自己的 .gitlab-ci.yml 裡面就可以了：
include:
- component: $CI_SERVER_FQDN/components/sast/sast@3.0.0
而如果有想要做進一步的控制，也可以參考網頁上的「inputs」來調整，例如：
include:
- component: $CI_SERVER_FQDN/components/sast/sast@3.0.0
inputs:
stage: extra_check
excluded_paths: "external, data, doc, xml"
這樣就可以修改他的 stage、指定他會在「extra_check」這個階段去執行；同時也可以排除某些資料夾不要去掃描。
而如果不想指定版本，想固定使用最新版的話，也可以把「3.0.0」改成「~latest」；但是可能就是得小心更新後參數可能也得要修改才能動的狀況了。
自己架設的 GitLab
至於自己架設的 GitLab 伺服器呢？如果直接進到 CI/CD Catalog 的頁面，應該會發現裡面是全空的，如果要使用還得自己弄…相較於此，早期使用官方內建的 template 好像比較方便？
而向上面的腳本雖然可以看到是有透過「$CI_SERVER_FQDN」來指定伺服器的網址，但是實際上他並不允許連到其他的 GitLab 伺服器，所以沒辦法直接給 gitlab.com 的 URL。
所以，如果想要在自己架設的 GitLab 伺服器上、使用官方提供的 component 的話，會需要自己去把官方的 component 複製一份回來到自己的 GitLab 伺服器上、並做對應的設定後、進行發布作業才行的；在官方文的《Use a GitLab.com component on GitLab Self-Managed》（連結），就有說明相關的流程。
不過，由於要 mirror 別的 GitLab 的專案並且讓他可以更新是「pull mirroring」、屬於付費功能；所以如果免費版要玩的話，就是要用其他變通方案了。
如果要玩的，流程基本上如下：
-
在自己的 GitLab 伺服器上，建立一個專門用來放 component 的群組；官方建議是取名叫做「components」，這樣之後會方便很多。
- 最好路徑完全和官方的相同，這樣就不用做後續的修改。
- 如果路徑有變的話，之後會需要修改專案內的
README.md內的路徑
-
到 gitlab.com 上面的 components 群組（連結）裡面，找到自己需要的 component。
-
在自己架設的 GitLab 上，透過「Create Project」中的「Import project」、把 gitlab.com 上的專案匯入。
- 預設沒有從 gitlab.com 匯入的選項，這邊可以用「Repository by URL」
- 「一定」要加入專案描述（Project description），建議可以直接複製官方的
-
等專案匯入完成後，在專案的「Settings」、「General」裡面，展開「Visibility, project features, permissions」後，勾選「CI/CD Catalog project」之後，按下「Save changes」來儲存設定。
-
手動針對最後的 tag 啟動一個 pipeline、將 component 發佈到 Catalog。
- 點選左邊的「Build」、「Pipelines」，然後點選右側的「New pipeline」按鈕
- 選擇最新的版本後、按下方的「New pipeline」按鈕
接下來如果設定都正確，也有 runner 可以執行工作（使用 Docker 的 Linux Runner）的話，在 pipeline 完成後，就可以完成 component 的發布了～
這時候，回到 Catalog 的頁面應該就可以看到 component 了。而之後，也就可以使用了。
不過這樣做的缺點，是之後官方有更新的時候，這邊不會自動更新，會需要自己處理。
這部分其實也可以透過 GitLab CI/CD 來自動化，但是就之後有機會再說吧。
個人覺得，這個新的 CI/CD component 的好處，主要應該還是更名確定去定義了元件的輸入參數，在使用上會更為明確。
而搭配 CI/CD Catalog 來使用，則是可以讓整個網站的使用者可以更簡單地知道有那些元件可以使用、方便重複利用。
至於本來的 template 呢？由於目前似乎也還沒有被標記成棄用（deprecated），所以應該也還是可以繼續用、不用急著轉換就是了。