Files
gitea-docs/i18n/zh-tw/docusaurus-plugin-content-docs/current/usage/actions/design.md
Lunny Xiao 965c269495 Update zh tw languages and fix some broken links (#455)
---------

Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: silverwind <2021+silverwind@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/docs/pulls/455
Reviewed-by: silverwind <2021+silverwind@noreply.gitea.com>
2026-07-09 23:41:46 +00:00

5.1 KiB
Raw Blame History

date, slug, sidebar_position
date slug sidebar_position
2023-05-24T15:00:00+08:00 design 40

Gitea Actions設計

Gitea Actions由多個元件組成。本文件將對它們進行逐個描述。

Gitea Runner

Gitea Runner部分基於nektos/act的硬分支。

與其他CI Runner一樣我們將其設計為Gitea的外部部分這意味著它應該在與Gitea不同的伺服器上運行。

為了確保Runner連接到正確的Gitea實例我們需要使用令牌註冊它。 此外Runner通過聲明自己的標籤向Gitea報告它可以運行的Job類型。

之前,我們提到工作流文件中的 runs-on: ubuntu-latest 表示該Job將在具有ubuntu-latest標籤的Runner上運行。 但是Runner如何知道要運行 ubuntu-latest?答案在於將標籤映射到環境。 這就是為什麼在註冊過程中添加自訂標籤時,需要輸入一些複雜內容,比如my_custom_label:docker://centos:7。 這意味著Runner可以接受需要在my_custom_label上運行的Job並通過使用centos:7鏡像的Docker容器來運行它。

然而Docker不是唯一的選擇。 Runner 也支援直接在主機上運行Job。 這是通過像linux_arm:host這樣的標籤實現的。 這個標籤表示Runner可以接受需要在linux_arm上運行的Job並直接在主機上運行它們。

標籤的設計遵循格式label[:schema[:args]]。 如果省略了schema則預設為host

因此,

  • my_custom_label:docker://node:18:使用node:18 Docker鏡像運行帶有my_custom_label標籤的Job。
  • my_custom_label:host:在主機上直接運行帶有my_custom_label標籤的Job。
  • my_custom_label:等同於my_custom_label:host
  • my_custom_label:vm:ubuntu-latest:(僅為範例,未實現)使用帶有ubuntu-latest ISO的虛擬機運行帶有my_custom_label標籤的Job。

通信協議

由於 runner 是Gitea的獨立部分我們需要一種協議讓Runner與Gitea實例進行通信。 然而我們不認為讓Gitea監聽一個新端口是個好主意。 相反我們希望重用HTTP端口這意味著我們需要一個與HTTP相容的協議。 因此我們選擇使用基於HTTP的gRPC。

我們使用actions-proto-defactions-proto-go 進行連接。 有關 gRPC 的更多資訊,請前往其官方網站

網路架構

讓我們來看一下整體的網路架構。 這將幫助您解決一些問題並解釋為什麼使用迴環地址註冊Runner是個不好的主意。

network

圖片中標記了四個網路連接,並且箭頭的方向表示建立連接的方向。

連接 1 runner到Gitea實例

Runner 必須能夠連接到Gitea以接收任務併發送執行結果回來。

連接 2Job容器到Gitea實例

即使Job容器位於同一臺機器上它們的網路命名空間與Runner不同。 舉個例子,如果工作流中包含 actions/checkout@v4Job容器需要連接到Gitea來獲取程式碼。 獲取程式碼並不總是運行某些Job所必需的但在大多數情況下是必需的。

如果您使用迴環地址註冊Runner當Runner與Gitea在同一臺機器上時Runner可以連接到Gitea。 然而如果Job容器嘗試從本地主機獲取程式碼它將失敗因為Gitea不在同一個容器中。

連接 3runner到互聯網

當您使用諸如 actions/checkout@v4 的一些Actions時runner 下載的是腳本而不是Job容器。 預設情況下,它從github.com下載,因此需要訪問互聯網。如果您設定的是 self 那麼預設將從您的當前Gitea實例下載那麼此步驟不需要連接到互聯網。 它還預設從Docker Hub下載一些Docker鏡像這也需要互聯網訪問。

然而,互聯網訪問並不是絕對必需的。 您可以設定您的Gitea實例從您的內部網路設施中獲取 Actions 或鏡像。

實際上您的Gitea實例可以同時充當 Actions 市場和鏡像註冊表。 您可以將GitHub上的Actions儲存庫鏡像到您的Gitea實例並將其用作普通Actions。 而 Gitea 容器註冊表 可用作Docker鏡像註冊表。

連接 4Job容器到互聯網

當使用諸如actions/setup-go@v5的Actions時可能需要從互聯網下載資源以設定Job容器中的Go語言環境。 因此成功完成這些Actions需要訪問互聯網。

然而,這也是可選的。 您可以使用自訂的Actions來避免依賴互聯網訪問或者可以使用已安裝所有依賴項的打包的Docker鏡像來運行Job。

總結

使用Gitea Actions只需要確保Runner能夠連接到Gitea實例。 互聯網訪問是可選的,但如果沒有互聯網訪問,將需要額外的工作。 換句話說當Runner能夠自行查詢互聯網時它的工作效果最好但您不需要將其暴露給互聯網無論是單向還是雙向

如果您在使用Gitea Actions時遇到任何網路問題希望上面的圖片能夠幫助您進行故障排除。