mirror of
https://gitea.com/gitea/docs.git
synced 2026-11-07 18:40:32 +00:00
Add version v28 (#564)
<!-- cloudflare-preview --> Preview: https://pr-564.docs-gitea-com.pages.dev Reviewed-on: https://gitea.com/gitea/docs/pulls/564 Reviewed-by: bircni <[email protected]> Co-authored-by: Lunny Xiao <[email protected]>
This commit is contained in:
Lunny Xiao authored and 
bircni committed
1 parent
deb2f068d4
commit
ba60edbbda
338 files changed
+114457
-47
No files matched your search
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"label": "Actions",
|
||||
"position": 30,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"slug": "/usage/actions",
|
||||
"description": "Automating workflows with Actions"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "comparison"
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
# 與GitHub Actions的對比
|
||||
|
||||
Gitea Actions 旨在與 GitHub Actions 相容，差異如下。
|
||||
|
||||
## 額外功能
|
||||
|
||||
<a id="absolute-action-urls"></a>
|
||||
### Action URL絕對路徑
|
||||
|
||||
`uses:` 接受指向任意 Git 主機的絕對 URL，例如 `uses: https://gitea.com/actions/checkout@v4`。
|
||||
|
||||
<a id="action-prefixes"></a>
|
||||
### Action 前綴
|
||||
|
||||
`uses:` 接受以下前綴：
|
||||
|
||||
- `self:` 參照您自己的 Gitea 實例，例如 `uses: self:owner/repo@v1` 或 `uses: self:owner/repo/.gitea/workflows/build.yml@v1`
|
||||
- `builtin:` 執行 Gitea Runner 內建的 Action，無需下載，Job 映像檔中也不需要 Node，例如 `uses: builtin:checkout`
|
||||
|
||||
`builtin:checkout` 支援 `actions/checkout` 的 `repository`、`ref`、`token`、`path` 和 `fetch-depth` 輸入，預設值相同，其他輸入會使步驟失敗。
|
||||
|
||||
<a id="workflow-relative-actions"></a>
|
||||
### 相對於工作流的 Actions
|
||||
|
||||
`$/` 參照工作流（或外層複合 Action）所在的儲存庫與提交，例如 `uses: $/.gitea/actions/build`。
|
||||
與 `./` 不同，它不需要事先簽出程式碼。
|
||||
|
||||
### 使用Go編寫Actions
|
||||
|
||||
請參閱[建立 Go Actions](https://blog.gitea.com/creating-go-actions/)。
|
||||
|
||||
### 支援非標準的調度語法 @yearly, @monthly, @weekly, @daily, @hourly
|
||||
|
||||
`schedule` 也接受 `@yearly`、`@monthly`、`@weekly`、`@daily` 和 `@hourly`，[GitHub 則不支援](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule)。
|
||||
|
||||
## 不支援的工作流語法
|
||||
|
||||
### `jobs.<job_id>.environment`
|
||||
|
||||
[`jobs.<job_id>.environment`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment) 會被忽略。
|
||||
|
||||
### 複雜的`runs-on`
|
||||
|
||||
[`runs-on`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on) 支援：
|
||||
|
||||
- 靜態字串：`runs-on: self-hosted`
|
||||
- 標籤陣列：`runs-on: [linux, self-hosted]`
|
||||
- 字串表達式：`runs-on: ${{ github.event_name == 'push' && 'ubuntu-latest' || 'self-hosted' }}`
|
||||
- 包含表達式的陣列：`runs-on: [linux, "${{ github.event_name == 'push' && 'ubuntu-latest' || 'self-hosted' }}"]`
|
||||
|
||||
## 缺失的功能
|
||||
|
||||
### 套件儲存庫授權
|
||||
|
||||
`GITEA_TOKEN` 無法發佈到其所屬儲存庫的套件註冊表，例如無法推送 OCI 鏡像。
|
||||
請改用個人存取權杖，參見[這個工單](https://github.com/go-gitea/gitea/issues/23642#issuecomment-2119876692)。
|
||||
|
||||
### 問題匹配器
|
||||
|
||||
[問題匹配器](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md)會被忽略。
|
||||
|
||||
### 為錯誤建立註釋
|
||||
|
||||
[錯誤註釋](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-creating-an-annotation-for-an-error)會被忽略。
|
||||
|
||||
### 表達式
|
||||
|
||||
[表達式](https://docs.github.com/en/actions/learn-github-actions/expressions)支援 GitHub 的標準函式與上下文。
|
||||
|
||||
## 缺失的UI功能
|
||||
|
||||
### 預處理和後處理步驟
|
||||
|
||||
預處理和後處理步驟在 Job 日誌中沒有各自獨立的區塊。
|
||||
|
||||
### 服務步驟
|
||||
|
||||
服務步驟在 Job 日誌中沒有各自獨立的區塊。
|
||||
|
||||
## 不一樣的行為
|
||||
|
||||
### `permissions`和`jobs.<job_id>.permissions`
|
||||
|
||||
`permissions` 和 `jobs.<job_id>.permissions` 控制 `GITEA_TOKEN` 的權限，其權限受儲存庫與所有者設定的限制，對於來自 fork 的拉取請求和跨儲存庫存取還會進一步受限。
|
||||
不支援 `statuses`、`checks`、`deployments`、`id-token`、`security-events` 和 `pages` 等 GitHub 專屬範圍，而 Gitea 另外提供 `code`、`releases`、`wiki` 和 `projects`。
|
||||
請參閱 [Actions Job 令牌權限](token-permissions.md)。
|
||||
|
||||
### 下載Actions
|
||||
|
||||
未指定主機的 Actions，例如 `uses: actions/checkout@v4`，會從 `https://github.com` 下載，若 `[actions].DEFAULT_ACTIONS_URL` 為 `self`，則從您自己的實例下載。
|
||||
請參閱[設定速查表](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
其他來源請參閱 [Action URL絕對路徑](#absolute-action-urls)、[Action 前綴](#action-prefixes)和[相對於工作流的 Actions](#workflow-relative-actions)。
|
||||
|
||||
### 上下文可用性
|
||||
|
||||
不檢查[上下文可用性](https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability)，因此 `env` 等上下文可以在更多地方使用。
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "design"
|
||||
sidebar_position: 40
|
||||
---
|
||||
|
||||
# Gitea Actions設計
|
||||
|
||||
Gitea Actions由多個元件組成。本文件將對它們進行逐個描述。
|
||||
|
||||
## Gitea Runner
|
||||
|
||||
Gitea Runner部分基於[nektos/act](https://github.com/nektos/act)的硬分支。
|
||||
|
||||
與其他CI Runner一樣，我們將其設計為Gitea的外部部分，這意味著它應該在與Gitea不同的伺服器上運行。
|
||||
|
||||
為了確保Runner連接到正確的Gitea實例，我們需要使用令牌註冊它。
|
||||
此外，Runner通過聲明自己的標籤向Gitea報告它可以運行的Job類型。
|
||||
|
||||
之前，我們提到工作流文件中的 `runs-on: ubuntu-latest` 表示該Job將在具有`ubuntu-latest`標籤的Runner上運行。
|
||||
但是，Runner如何知道要運行 `ubuntu-latest`？答案在於將標籤映射到環境。
|
||||
這就是為什麼Runner的每個標籤都指定了一個環境，比如`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`。
|
||||
|
||||
## 通信協議
|
||||
|
||||
由於 runner 是Gitea的獨立部分，我們需要一種協議讓Runner與Gitea實例進行通信。
|
||||
然而，我們不認為讓Gitea監聽一個新端口是個好主意。
|
||||
相反，我們希望重用HTTP端口，這意味著我們需要一個與HTTP相容的協議。
|
||||
因此，我們選擇使用基於HTTP的gRPC。
|
||||
|
||||
協議定義於[actions-proto-def](https://gitea.com/gitea/actions-proto-def)，其Go程式碼位於[actionslib](https://gitea.com/gitea/actionslib)。
|
||||
有關 gRPC 的更多資訊，請前往[其官方網站](https://grpc.io/)。
|
||||
|
||||
## 網路架構
|
||||
|
||||
讓我們來看一下整體的網路架構。
|
||||
這將幫助您解決一些問題，並解釋為什麼使用迴環地址註冊Runner是個不好的主意。
|
||||
|
||||
|
||||
|
||||
圖片中標記了四個網路連接，並且箭頭的方向表示建立連接的方向。
|
||||
|
||||
### 連接 1， runner到Gitea實例
|
||||
|
||||
Runner 必須能夠連接到Gitea以接收任務併發送執行結果回來。
|
||||
|
||||
### 連接 2，Job容器到Gitea實例
|
||||
|
||||
即使Job容器位於同一臺機器上，它們的網路命名空間與Runner不同。
|
||||
舉個例子，如果工作流中包含 `actions/checkout@v4`，Job容器需要連接到Gitea來獲取程式碼。
|
||||
獲取程式碼並不總是運行某些Job所必需的，但在大多數情況下是必需的。
|
||||
|
||||
如果您使用迴環地址註冊Runner，當Runner與Gitea在同一臺機器上時，Runner可以連接到Gitea。
|
||||
然而，如果Job容器嘗試從本地主機獲取程式碼，它將失敗，因為Gitea不在同一個容器中。
|
||||
|
||||
### 連接 3，runner到互聯網
|
||||
|
||||
當您使用諸如 `actions/checkout@v4` 的一些Actions時，runner 下載的是腳本，而不是Job容器。
|
||||
預設情況下，它從[github.com](https://github.com/)下載，因此需要訪問互聯網。
|
||||
若將`DEFAULT_ACTIONS_URL`設定為`self`，或使用`uses: self:owner/repo@ref`，則改從您的Gitea實例下載。
|
||||
它還預設從Docker Hub下載一些Docker鏡像，這也需要互聯網訪問。
|
||||
|
||||
然而，互聯網訪問並不是絕對必需的。
|
||||
您可以設定您的Gitea實例從您的內部網路設施中獲取 Actions 或鏡像。
|
||||
|
||||
實際上，您的Gitea實例可以同時充當 Actions 市場和鏡像註冊表。
|
||||
您可以將GitHub上的Actions儲存庫鏡像到您的Gitea實例，並將其用作普通Actions。
|
||||
而 [Gitea 容器註冊表](usage/packages/container.md) 可用作Docker鏡像註冊表。
|
||||
|
||||
### 連接 4，Job容器到互聯網
|
||||
|
||||
當使用諸如`actions/setup-go@v5`的Actions時，可能需要從互聯網下載資源，以設定Job容器中的Go語言環境。
|
||||
因此，成功完成這些Actions需要訪問互聯網。
|
||||
|
||||
然而，這也是可選的。
|
||||
您可以使用自訂的Actions來避免依賴互聯網訪問，或者可以使用已安裝所有依賴項的打包的Docker鏡像來運行Job。
|
||||
|
||||
## 總結
|
||||
|
||||
使用Gitea Actions只需要確保Runner能夠連接到Gitea實例。
|
||||
互聯網訪問是可選的，但如果沒有互聯網訪問，將需要額外的工作。
|
||||
換句話說：當Runner能夠自行查詢互聯網時，它的工作效果最好，但您不需要將其暴露給互聯網（無論是單向還是雙向）。
|
||||
|
||||
如果您在使用Gitea Actions時遇到任何網路問題，希望上面的圖片能夠幫助您進行故障排除。
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "faq"
|
||||
sidebar_position: 100
|
||||
---
|
||||
|
||||
# Gitea Actions常見問題解答
|
||||
|
||||
本頁面包含一些關於Gitea Actions的常見問題和答案。
|
||||
|
||||
## 是否可以在我的實例中預設禁用新儲存庫的Actions？
|
||||
|
||||
是的，當您為實例啟用Actions時，您可以選擇預設啟用actions單元以適用於所有新儲存庫。
|
||||
|
||||
```ini
|
||||
[repository]
|
||||
; 去掉 repo.actions 將不會為新倉庫自動啟用actions
|
||||
DEFAULT_REPO_UNITS = ...,repo.actions
|
||||
```
|
||||
|
||||
## 在工作流文件中應該使用`${{ github.xyz }}`還是`${{ gitea.xyz }}`？
|
||||
|
||||
您可以使用`github.xyz`，Gitea將正常工作。
|
||||
如前所述，Gitea Actions的設計是與GitHub Actions相容的。
|
||||
然而，我們建議在工作流文件中使用`gitea.xyz`，以防止在工作流文件中出現不同類型的密鑰（因為您在Gitea上使用此工作流，而不是GitHub）。
|
||||
不過，這完全是可選的，因為目前這兩個選項的效果是相同的。
|
||||
|
||||
## 使用`actions/checkout@v4`等Actions時，Job容器會從何處下載腳本？
|
||||
|
||||
預設從 `https://github.com` 下載，若 `[actions].DEFAULT_ACTIONS_URL` 為 `self`，則從您自己的實例下載，參見[設定速查表](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
|
||||
若要使用其他來源的 Action，請指定其主機：
|
||||
|
||||
- `uses: https://gitea.com/owner/repo@ref`
|
||||
- `uses: http://your_gitea_instance.com/owner/repo@ref`
|
||||
- `uses: self:owner/repo@ref`，用於您自己的 Gitea 實例
|
||||
|
||||
## 如何限制Runner的權限？
|
||||
|
||||
Runner 只會連接到您的 Gitea 實例。
|
||||
對於每個 Job，Runner 會取得一個僅限於該 Job 所屬儲存庫的 `GITEA_TOKEN`，參見 [Actions Job 令牌權限](token-permissions.md)。
|
||||
若要讓 Job 存取更多私有儲存庫或外部系統，請向其傳遞[密鑰](usage/actions/secrets.md)。
|
||||
|
||||
## 如何避免被黑客攻擊？
|
||||
|
||||
有兩種可能的攻擊類型：未知的Runner竊取您的儲存庫中的程式碼或密鑰，或惡意腳本控制您的Runner。
|
||||
|
||||
避免前者意味著不允許您不認識的人為您的儲存庫、組織或實例註冊Runner。
|
||||
|
||||
後者要複雜一些。
|
||||
如果您為公司使用私有的Gitea實例，您可能不需要擔心安全問題，因為您信任您的同事，並且可以追究他們的責任。
|
||||
|
||||
對於公共實例，情況略有不同。
|
||||
以下是我們在 [gitea.com](http://gitea.com/)上的做法：
|
||||
|
||||
- 我們僅為 "gitea" 組織註冊Runner，因此我們的Runner不會執行來自其他儲存庫的Job。
|
||||
- 我們的Runner始終在隔離容器中運行Job。雖然可以直接在主機上進行這樣的操作，但出於安全考慮，我們選擇不這樣做。
|
||||
- 對於 fork 的拉取請求，需要獲得批准才能運行Actions。參見[#22803](https://github.com/go-gitea/gitea/pull/22803)。
|
||||
- 如果有人在[gitea.com](http://gitea.com/)為其儲存庫或組織註冊自己的Runner，我們不會反對，只是不會在我們的組織中使用它。然而，他們應該注意確保該Runner不被他們不認識的其他使用者使用。
|
||||
|
||||
## runner支援哪些操作系統？
|
||||
|
||||
官方發佈了 Linux、macOS 和 Windows 的二進制檔案。
|
||||
理論上，Go 和 Docker 支援的其他系統也能運作。
|
||||
|
||||
## 為什麼選擇GitHub Actions？為什麼不選擇與GitLab CI/CD相容的工具？
|
||||
|
||||
[@lunny](https://gitea.com/lunny)在實現Actions的[問題](https://github.com/go-gitea/gitea/issues/13539)中已經解釋過這個問題。
|
||||
此外，Actions不僅是一個CI/CD 系統，還是一個自動化工具。
|
||||
|
||||
在開源世界中，已經有許多[市場上的Actions](https://github.com/marketplace?type=actions)實現了。
|
||||
能夠重用它們是令人興奮的。
|
||||
|
||||
## 如果它在多個標籤上運行，例如 `runs-on: [label_a, label_b]`，會發生什麼？
|
||||
|
||||
Job 會在具有所有這些標籤的 Runner 上運行，與 [GitHub](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on) 相同。
|
||||
Runner 會使用它所具有的第一個標籤對應的環境。
|
||||
|
||||
## 代理標籤和自訂標籤對於Runner有什麼區別？
|
||||
|
||||
Gitea 已不再有自訂標籤。
|
||||
Runner 每次啟動時都會宣告其標籤，標籤來自 `runner.labels` 設定或註冊時指定的標籤，因此請在那裡修改並重新啟動 Runner。
|
||||
|
||||
## Gitea Actions runner會有更多的實現嗎？
|
||||
|
||||
雖然我們希望提供更多的選擇，但由於我們有限的人力資源， runner將是唯一受支援的官方Runner。
|
||||
然而，無論您如何決定，Gitea 和 runner都是完全開源的，所以任何人都可以建立一個新的/更好的實現。
|
||||
我們支援您的選擇，無論您如何決定。
|
||||
如果您選擇分支 runner 來建立自己的版本，請在您認為您的更改對其他人也有幫助的情況下貢獻這些更改。
|
||||
|
||||
## Gitea 支援哪些工作流觸發事件？
|
||||
|
||||
表格中列出的所有事件都是支援的，並且與 GitHub 相容。
|
||||
對於僅 GitHub 支援的事件，請參閱 GitHub 的[文件](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows)。
|
||||
|
||||
| 觸發事件 | 活動類型 |
|
||||
|-----------------------------|--------------------------------------------------------------------------------------------------------------------------|
|
||||
| create | 不適用 |
|
||||
| delete | 不適用 |
|
||||
| fork | 不適用 |
|
||||
| gollum | 不適用 |
|
||||
| push | 不適用 |
|
||||
| issues | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `milestoned`, `demilestoned`, `labeled`, `unlabeled` |
|
||||
| issue_comment | `created`, `edited`, `deleted` |
|
||||
| pull_request | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `synchronize`, `labeled`, `unlabeled` |
|
||||
| pull_request_review | `submitted`, `edited` |
|
||||
| pull_request_review_comment | `created`, `edited` |
|
||||
| release | `published`, `edited` |
|
||||
| registry_package | `published` |
|
||||
|
||||
> 對於 `pull_request` 事件，在 [GitHub Actions](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) 中 `ref` 是 `refs/pull/:prNumber/merge`，它指向這個拉取請求合併提交的一個預覽。但是 Gitea 沒有這種 reference。
|
||||
> 因此，Gitea Actions 中 `ref` 是 `refs/pull/:prNumber/head`，它指向這個拉取請求的頭分支而不是合併提交的預覽。
|
||||
|
||||
## 如何共享私有儲存庫中的 Actions 和可重複使用的工作流？
|
||||
|
||||
前往儲存庫的**設定** > **Actions** > **General** 頁面，添加協作所有者。
|
||||
協作所有者的私有儲存庫可以存取目前儲存庫中的 Actions 和工作流。
|
||||
|
||||
若要在同一使用者或組織內共享，請改為在該使用者或組織的**設定** > **Actions** > **General** > **Cross-Repository Access** 中添加這些私有儲存庫。
|
||||
參見[跨儲存庫存取](token-permissions.md#cross-repository-access)。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "overview"
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Overview
|
||||
|
||||
從Gitea **1.19**版本開始，Gitea Actions成為了內置的CI/CD解決方案。
|
||||
|
||||
## 名稱
|
||||
|
||||
Gitea Actions與[GitHub Actions](https://github.com/features/actions)相似且相容，它的名稱也受到了它的啟發。
|
||||
為了避免混淆，在這裡我們明確了拼寫方式：
|
||||
|
||||
- "Gitea Actions"（兩個單詞都大寫且帶有"s"）是Gitea功能的名稱。
|
||||
- "GitHub Actions"是GitHub功能的名稱。
|
||||
- "Actions"根據上下文的不同可以指代以上任意一個。在本文件中指代的是"Gitea Actions"。
|
||||
- "action"或"actions"指代一些要使用的腳本/外掛，比如"actions/checkout@v4"或"actions/cache@v3"。
|
||||
|
||||
## Runner
|
||||
|
||||
和其他CI/CD解決方案一樣，Gitea不會自己運行Job，而是將Job委託給Runner。
|
||||
Gitea Actions的Runner被稱為[Gitea Runner](https://gitea.com/gitea/runner)，它是一個獨立的程式，也是用Go語言編寫的。
|
||||
它的重要部分來自[nektos/act](http://github.com/nektos/act)的一個硬分支。
|
||||
|
||||
由於Runner是獨立部署的，可能存在潛在的安全問題。
|
||||
為了避免這些問題，請遵循兩個簡單的規則：
|
||||
|
||||
- 不要為你的儲存庫、組織或實例使用你不信任的Runner。
|
||||
- 不要為你不信任的儲存庫、組織或實例提供Runner。
|
||||
|
||||
對於內部使用的Gitea實例，比如企業或個人使用的實例，這兩個規則不是問題，它們自然而然就是如此。
|
||||
然而，對於公共的Gitea實例，比如[gitea.com](https://gitea.com)，在添加或使用Runner時應當牢記這兩個規則。
|
||||
|
||||
## 狀態
|
||||
|
||||
Gitea Actions仍然在開發中，因此可能存在一些錯誤和缺失的功能。
|
||||
並且在穩定版本（v1.20或更高版本）之前可能會進行一些重大的更改。
|
||||
|
||||
如果情況發生變化，我們將在此處進行更新。
|
||||
因此，請在其他地方找到過時文章時參考此處的內容。
|
||||
@@ -0,0 +1,131 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "quickstart"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# 快速入門
|
||||
|
||||
本頁面將指導您使用Gitea Actions的過程。
|
||||
|
||||
## 設定Gitea
|
||||
|
||||
首先，您需要一個Gitea實例。
|
||||
您可以按照[文件](installation/from-package.md) 來設定一個新實例或升級現有實例。
|
||||
無論您如何安裝或運行Gitea，只要版本號是1.19.0或更高即可。
|
||||
|
||||
從1.21.0開始，預設情況下，Actions是啟用的。如果您正在使用1.21.0之前的版本，您需要將以下內容添加到設定文件中以啟用它：
|
||||
|
||||
```ini
|
||||
[actions]
|
||||
ENABLED=true
|
||||
```
|
||||
|
||||
如果您想了解更多資訊或在設定過程中遇到任何問題，請參考[設定速查表](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
|
||||
### 設定Runner
|
||||
|
||||
Gitea Actions需要[runner](https://gitea.com/gitea/runner) 來運行Job。
|
||||
為了避免消耗過多資源並影響Gitea實例，建議您在與Gitea實例分開的機器上啟動Runner。
|
||||
|
||||
您可以使用[預構建的二進制文件](http://dl.gitea.com/gitea-runner)或[容器鏡像](https://hub.docker.com/r/gitea/runner/tags)來設定Runner。
|
||||
|
||||
在進一步操作之前，建議您先使用預構建的二進制文件以命令行方式運行它，以確保它與您的環境相容，尤其是如果您在本地主機上運行Runner。
|
||||
如果出現問題，這樣調試起來會更容易。
|
||||
|
||||
該Runner可以在隔離的Docker容器中運行Job，因此您需要確保已安裝Docker並且Docker守護進程正在運行。
|
||||
雖然這不是嚴格必需的，因為Runner也可以直接在主機上運行Job，這取決於您的設定方式。
|
||||
然而，建議使用Docker運行Job，因為它更安全且更易於管理。
|
||||
|
||||
在運行Runner之前，您需要使用以下命令將其註冊到Gitea實例中：
|
||||
|
||||
```bash
|
||||
./runner register --no-interactive --instance <instance> --token <token>
|
||||
```
|
||||
|
||||
需要兩個必需的參數：`instance` 和 `token`。
|
||||
|
||||
`instance`是您的Gitea實例的地址，如`http://192.168.8.8:3000`或`https://gitea.com`。
|
||||
Runner和Job容器（由Runner啟動以執行Job）將連接到此地址。
|
||||
這意味著它可能與用於Web訪問的`ROOT_URL`不同。
|
||||
使用迴環地址（例如 `127.0.0.1` 或 `localhost`）是一個不好的選擇。
|
||||
如果不確定使用哪個地址，通常選擇局域網地址即可。
|
||||
|
||||
`token` 用於身份驗證和標識，例如 `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`。
|
||||
它只能使用一次，並且不能用於註冊多個Runner。
|
||||
您可以從以下位置獲取不同級別的`token`,從而建立出相應級別的`runner`
|
||||
|
||||
- 實例級別：管理員設定頁面，例如 `<your_gitea.com>/admin/actions/runners`。
|
||||
- 組織級別：組織設定頁面，例如 `<your_gitea.com>/<org>/settings/actions/runners`。
|
||||
- 儲存庫級別：儲存庫設定頁面，例如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。
|
||||
|
||||
|
||||
|
||||
註冊後，當前目錄中將出現一個名為 `.runner` 的新文件，該文件儲存了註冊資訊。
|
||||
請不要手動編輯該文件。
|
||||
如果該文件丟失或損壞，只需刪除它然後重新註冊即可。
|
||||
|
||||
最後，是時候啟動Runner了：
|
||||
|
||||
```bash
|
||||
./runner daemon
|
||||
```
|
||||
|
||||
您可以在管理頁面上看到新的Runner：
|
||||
|
||||
|
||||
|
||||
您可以透過訪問[runner](runner) 獲取更多資訊。
|
||||
|
||||
### 使用Actions
|
||||
|
||||
即使對於啟用了Gitea實例的Actions，儲存庫仍預設禁用Actions。
|
||||
|
||||
要啟用它，請轉到儲存庫的設定頁面，例如`your_gitea.com/<owner>/repo/settings`，然後啟用`Enable Repository Actions`。
|
||||
|
||||
|
||||
|
||||
接下來的步驟可能相當複雜。
|
||||
您需要學習Actions的[工作流語法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)，並編寫您想要的工作流文件。
|
||||
|
||||
不過，我們可以從一個簡單的演示開始：
|
||||
|
||||
```yaml
|
||||
name: Gitea Actions Demo
|
||||
run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
Explore-Gitea-Actions:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event."
|
||||
- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!"
|
||||
- run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v4
|
||||
- run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner."
|
||||
- run: echo "🖥️ The workflow is now ready to test your code on the runner."
|
||||
- name: List files in the repository
|
||||
run: |
|
||||
ls ${{ gitea.workspace }}
|
||||
- run: echo "🍏 This job's status is ${{ job.status }}."
|
||||
```
|
||||
|
||||
您可以將上述範例上傳為一個以`.yaml`擴展名的文件，放在儲存庫的`.gitea/workflows/`目錄中，例如`.gitea/workflows/demo.yaml`。
|
||||
您可能會注意到，這與[GitHub Actions的快速入門](https://docs.github.com/en/actions/quickstart)非常相似。
|
||||
這是因為Gitea Actions在儘可能相容GitHub Actions的基礎上進行設計。
|
||||
|
||||
請注意，演示文件中包含一些表情符號。
|
||||
請確保您的資料庫支援它們，特別是在使用MySQL時。
|
||||
如果字符集不是`utf8mb4`，將出現錯誤，例如`Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`。
|
||||
有關更多資訊，請參閱[資料庫準備工作](../../installation/database-preparation.md#mysqlmariadb)。
|
||||
|
||||
或者，您可以從演示文件中刪除所有表情符號，然後再嘗試一次。
|
||||
|
||||
`on: [push]` 這一行表示當您向該儲存庫推送提交時，工作流將被觸發。
|
||||
然而，當您上傳 YAML 文件時，它也會推送一個提交，所以您應該在"Actions"標籤中看到一個新的任務。
|
||||
|
||||
|
||||
|
||||
做得好！您已成功開始使用Actions。
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "runner"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-tw/act-runner
|
||||
---
|
||||
|
||||
# Gitea Runner
|
||||
|
||||
本頁面將介紹[Gitea Runner](https://gitea.com/gitea/runner)，這是Gitea Actions的Runner。
|
||||
|
||||
:::tip
|
||||
詳細的安裝、設定和使用說明，請參閱 [Gitea Runner 文件](/runner/)。
|
||||
:::
|
||||
|
||||
## 獲取註冊令牌
|
||||
|
||||
### Runner級別
|
||||
|
||||
您可以在不同級別上註冊Runner，它可以是：
|
||||
|
||||
- 實例級別：Runner將為實例中的所有儲存庫運行Job。
|
||||
- 組織級別：Runner將為組織中的所有儲存庫運行Job。
|
||||
- 儲存庫級別：Runner將為其所屬的儲存庫運行Job。
|
||||
|
||||
請注意，即使儲存庫具有自己的儲存庫級別Runner，它仍然可以使用實例級別或組織級別Runner。未來的版本可能提供更多對此進行更好控制的選項。
|
||||
|
||||
Runner級別決定了從哪裡獲取註冊令牌。
|
||||
|
||||
- 實例級別：管理員設定頁面，例如 `<your_gitea.com>/admin/actions/runners`。
|
||||
- 組織級別：組織設定頁面，例如 `<your_gitea.com>/<org>/settings/actions/runners`。
|
||||
- 儲存庫級別：儲存庫設定頁面，例如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。
|
||||
|
||||
如果您無法看到設定頁面，請確保您具有正確的權限並且已啟用 Actions。
|
||||
|
||||
註冊令牌的格式是一個隨機字符串 `D0gvfu2iHfUjNqCYVljVyRV14fISpJxxxxxxxxxx`。
|
||||
|
||||
註冊令牌也可以透過 Gitea 的 [命令列](../../administration/command-line.md#actions-generate-runner-token) 獲得:
|
||||
|
||||
```
|
||||
gitea --config /etc/gitea/app.ini actions generate-runner-token
|
||||
```
|
||||
|
||||
使用者也可以使用 `GITEA_RUNNER_REGISTRATION_TOKEN` 或 `GITEA_RUNNER_REGISTRATION_TOKEN_FILE` 環境變量以在 Gitea 啟動時設定全域的註冊令牌，例如：
|
||||
|
||||
```
|
||||
openssl rand -hex 24 > /some-dir/runner-token
|
||||
export GITEA_RUNNER_REGISTRATION_TOKEN_FILE=/some-dir/runner-token
|
||||
./gitea --config ...
|
||||
```
|
||||
|
||||
來自環境變量的令牌在通過 Web 介面或 API 重置(重新建立新令牌)前將一直有效。
|
||||
|
||||
令牌可用於註冊多個 Runner，直到使用 Web 介面中的令牌重置鏈接將其撤銷並替換為新令牌。
|
||||
|
||||
獲取註冊令牌後，請參閱 [Gitea Runner 文件](/runner/) 了解如何安裝、設定和運行您的 Runner。
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
---
|
||||
date: "2026-06-26T00:00:00+00:00"
|
||||
slug: "scoped-workflows"
|
||||
sidebar_position: 60
|
||||
---
|
||||
|
||||
# 作用域工作流程
|
||||
|
||||
作用域工作流程（Scoped Workflows）讓你把 Actions 工作流程集中維護在一個**來源（source）**儲存庫中，並讓它們自動在許多其他儲存庫上執行，而無需把工作流程檔案複製到每個儲存庫裡。
|
||||
|
||||
提交到來源儲存庫作用域工作流程目錄下的工作流程檔案，會在該來源所適用的每個儲存庫（稱為**消費方（consuming）**儲存庫）上執行。每次執行都在**消費方儲存庫自身的環境**中進行：使用它的 runner、Secret、`GITEA_TOKEN` 和分支，而工作流程**內容則讀取自來源儲存庫**。這適用於在組織或實例範圍內強制推行共用 CI：程式碼檢查、安全掃描、合規或政策檢查等。
|
||||
|
||||
## 層級
|
||||
|
||||
來源儲存庫可以在兩個層級註冊：
|
||||
|
||||
- **擁有者層級（Owner level）**：由組織或使用者註冊。該來源的工作流程會在該組織或使用者擁有的每個儲存庫上執行。
|
||||
- **實例層級（Instance level）**：由網站管理員註冊。該來源的工作流程會在實例上的**每一個**儲存庫上執行。
|
||||
|
||||
同一個儲存庫可以同時在兩個層級註冊；對於每個符合的事件，它仍只會被評估一次。
|
||||
|
||||
:::note
|
||||
實例層級的來源適用於實例上的**每一個**儲存庫，且被設為必要（required）的來源無法被選擇退出（opt out）。偵測會在每個儲存庫的每次事件上執行。請審慎註冊。
|
||||
:::
|
||||
|
||||
## 設定
|
||||
|
||||
作用域工作流程存放在一個與一般工作流程分開的目錄中，由 `app.ini` 中 `[actions]` 區段的 `SCOPED_WORKFLOW_DIRS` 控制：
|
||||
|
||||
```ini
|
||||
[actions]
|
||||
SCOPED_WORKFLOW_DIRS = .gitea/scoped_workflows
|
||||
```
|
||||
|
||||
- 預設值為 `.gitea/scoped_workflows`。
|
||||
- 可以列出多個目錄（以逗號分隔）。
|
||||
- **不得與** `WORKFLOW_DIRS`（一般工作流程目錄，預設為 `.gitea/workflows` 和 `.github/workflows`）**重疊**。
|
||||
- 留空表示沒有任何目錄存放作用域工作流程，因此不會找到也不會執行任何作用域工作流程。設定頁面仍會顯示、來源仍可註冊，但不會有任何作用域工作流程執行。
|
||||
|
||||
把作用域工作流程放在它們自己的目錄中，表示來源儲存庫**自身**的 Actions 不受影響：只有 `SCOPED_WORKFLOW_DIRS` 下的檔案才會被當作作用域工作流程。
|
||||
|
||||
## 從一個儲存庫提供作用域工作流程
|
||||
|
||||
1. 在準備作為來源的儲存庫中，把工作流程檔案提交到其**預設分支**上的作用域工作流程目錄下，例如 `.gitea/scoped_workflows/lint.yaml`：
|
||||
|
||||
```yaml
|
||||
name: Lint
|
||||
on: [push, pull_request]
|
||||
jobs:
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- run: echo "lint the consuming repository here"
|
||||
```
|
||||
|
||||
2. 將該儲存庫註冊為來源：
|
||||
|
||||
- **組織**：*組織設定 -> Actions -> 作用域工作流程*
|
||||
- **使用者**：*使用者設定 -> Actions -> 作用域工作流程*
|
||||
- **實例（管理員）**：*網站管理 -> Actions -> 作用域工作流程*
|
||||
|
||||
搜尋並新增該儲存庫。此後，它的作用域工作流程便會適用於該層級下的消費方儲存庫。
|
||||
|
||||
來源儲存庫也在它自己的作用域內，因此它會像其他消費方一樣在自身上執行這些工作流程。
|
||||
|
||||
## 作用域工作流程如何執行
|
||||
|
||||
- 該執行屬於**消費方**儲存庫，使用它的 runner、Secret、`GITEA_TOKEN` 和 ref。它在那裡的行為與一般執行一致，包括重新執行、日誌和提交狀態。
|
||||
- 工作流程**內容讀取自來源**儲存庫，並釘選在事件發生時來源預設分支的 commit 上。
|
||||
- 偵測使用消費方儲存庫的事件，因此工作流程的 `on:` 觸發器（例如 `push` 和 `pull_request`）必須與該事件相符。
|
||||
|
||||
## 選擇退出（Opting out）
|
||||
|
||||
消費方儲存庫可以在其 **Actions** 頁面（該工作流程會顯示在其來源之下）停用一個它不想要的作用域工作流程。已被標記為**必要（required）**（見下文）的工作流程，消費方儲存庫永遠無法將其停用，也無法選擇退出。
|
||||
|
||||
## 必要工作流程與合併門檻
|
||||
|
||||
在作用域工作流程設定頁面上，你可以把個別工作流程標記為**必要（required）**，並為每個工作流程給定一個或多個**狀態檢查模式（status-check patterns）**（每行一個 glob）。一個必要的作用域工作流程：
|
||||
|
||||
- 無法被消費方儲存庫停用。
|
||||
- 會對合併請求（PR）形成合併門檻：消費方的 PR 只有在一個符合**每一個**模式的提交狀態都**通過**後才能合併（必須存在且通過，must-present-and-pass）。一個從不產生任何狀態的必要檢查會**阻擋**合併，而不是被靜默略過，因此在消費方停用 Actions 也無法繞過它。
|
||||
|
||||
作用域執行產生的狀態檢查 context 形如：
|
||||
|
||||
```
|
||||
<來源儲存庫全名>: <工作流程顯示名稱> / <job> (<event>)
|
||||
```
|
||||
|
||||
設定頁面會為每個工作流程預覽這些 “Expected status checks（預期狀態檢查）”，並標記出與你的模式相符的專案，便於你確認模式是否正確。一種常見模式是對 job 和 event 使用萬用字元，例如 `my-org/ci-repo: Lint / *`。
|
||||
|
||||
強制範圍：
|
||||
|
||||
- 必要檢查會在任何設有**分支保護規則**的目標分支上強制生效，即使該規則自身的狀態檢查處於關閉狀態。
|
||||
- **沒有**保護規則的目標分支不受門檻約束。
|
||||
|
||||
:::warning
|
||||
只有執行在會產生提交狀態的事件（`push`、`pull_request`、`pull_request_target`、`release`）上的工作流程才能被設為必要。僅執行在 `workflow_dispatch`、`schedule` 或 `workflow_call` 等事件上的工作流程不會產生任何狀態，因此把它設為必要會**永久**阻擋每一個消費方 PR 的合併。設定頁面在這種情況下會向你發出警告。
|
||||
:::
|
||||
|
||||
## 可重複使用的工作流程（`uses:`）
|
||||
|
||||
作用域工作流程可以呼叫可重複使用的工作流程：
|
||||
|
||||
- **本機**參照（`uses: ./...` 或 `uses: $/...`）會相對於**來源**儲存庫解析：即呼叫方工作流程內容的來源儲存庫，而非消費方儲存庫。
|
||||
- **跨儲存庫**參照（`uses: owner/repo/...@ref` 或 `uses: self:owner/repo/...@ref`）會以**消費方儲存庫的**讀取權限來解析。如果它指向一個私有儲存庫，請確保每個消費方儲存庫都能讀取它，否則工作流程會在那裡失敗。
|
||||
|
||||
可重複使用的工作流程可以放在來源儲存庫的 `SCOPED_WORKFLOW_DIRS`（或 `WORKFLOW_DIRS`）之下。
|
||||
|
||||
## 安全性注意事項
|
||||
|
||||
來源儲存庫的工作流程內容會在它所適用的每個儲存庫中執行，其步驟指令碼及其輸出會寫入該儲存庫的 Actions 日誌，任何能檢視消費方儲存庫 Actions 的人都能讀取這些日誌。
|
||||
|
||||
- 因此，將一個**私有**儲存庫註冊為來源，會透過這些日誌洩漏其工作流程邏輯。只應註冊那些其工作流程內容可以與每個消費方儲存庫共用的儲存庫。
|
||||
|
||||
## 限制
|
||||
|
||||
- 目前不支援將 `on: schedule` 和 `on: workflow_run` 作為作用域工作流程觸發器。
|
||||
- 作用域工作流程內容讀取自來源的預設分支；來源的其他分支不會被使用。
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "secrets"
|
||||
sidebar_position: 50
|
||||
---
|
||||
|
||||
# 密鑰管理
|
||||
|
||||
密鑰管理允許您在使用者、組織或儲存庫中儲存敏感資訊。
|
||||
密鑰管理在 Gitea 1.19+ 版本中可用。
|
||||
|
||||
## 設定密鑰名稱
|
||||
|
||||
以下規則適用於密鑰名稱：
|
||||
|
||||
- 密鑰名稱只能包含字母數字字符 (`[a-z]`, `[A-Z]`, `[0-9]`) 或下劃線 (`_`)。不允許使用空格。
|
||||
|
||||
- 密鑰名稱不能以 `GITHUB_` 和 `GITEA_` 前綴開頭。
|
||||
|
||||
- 密鑰名稱不能以數字開頭。
|
||||
|
||||
- 密鑰名稱不區分大小寫。
|
||||
|
||||
- 密鑰名稱在建立它們的級別上必須是唯一的。
|
||||
|
||||
例如，對於在儲存庫級別建立的密鑰，它在該儲存庫中必須具有唯一的名稱；對於在組織級別建立的密鑰，它在該級別上必須具有唯一的名稱。
|
||||
|
||||
如果在多個級別上存在具有相同名稱的密鑰，則最低級別的密鑰優先生效。例如，如果組織級別的密鑰與儲存庫級別的密鑰具有相同的名稱，則儲存庫級別的密鑰將優先生效。
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
date: "2026-03-19T00:00:00+01:00"
|
||||
slug: "token-permissions"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
# Actions Job 令牌權限（`GITEA_TOKEN`）
|
||||
|
||||
每個 Actions Job 都會取得一個內建令牌（`GITEA_TOKEN`），可用於存取 Gitea（透過 HTTP(S) 使用 Git、API 請求等）。
|
||||
本頁說明 Gitea 如何決定該令牌可以執行哪些操作。
|
||||
|
||||
在工作流中，可以透過 `${{ secrets.GITEA_TOKEN }}` 使用它。這些設定和 `permissions:` 只影響 `GITEA_TOKEN`（不影響個人存取權杖等其他密鑰）。API 呼叫請參閱 [API 認證](../../development/api-usage.md#authentication)。
|
||||
|
||||
<a id="where-permissions-come-from"></a>
|
||||
## 權限的來源
|
||||
|
||||
Gitea 依以下順序決定 Job 令牌權限：
|
||||
|
||||
1. Job 層級的 `permissions:`（`jobs.<job_id>.permissions`）
|
||||
2. 工作流層級的 `permissions:`（頂層）
|
||||
3. 設定中的預設權限（所有者或儲存庫）
|
||||
|
||||
接著，結果會再受到所設定的最大令牌權限**限縮**（見下文）。
|
||||
|
||||
<a id="supported-workflow-syntax"></a>
|
||||
## 支援的工作流語法
|
||||
|
||||
Gitea 支援與 GitHub Actions 相容的 `permissions:` 關鍵字。
|
||||
|
||||
<a id="scalar-values"></a>
|
||||
### 純量值
|
||||
|
||||
```yaml
|
||||
permissions: read-all # or: write-all
|
||||
```
|
||||
|
||||
<a id="scoped-mapping"></a>
|
||||
### 依範圍對應
|
||||
|
||||
```yaml
|
||||
permissions:
|
||||
contents: read
|
||||
issues: write
|
||||
pull-requests: none
|
||||
```
|
||||
|
||||
每個範圍的有效存取模式值為 `read`、`write` 和 `none`。
|
||||
|
||||
<a id="supported-scopes"></a>
|
||||
### 支援的範圍
|
||||
|
||||
- `contents`（適用於 `code` 和 `releases`）
|
||||
- `code`
|
||||
- `releases`
|
||||
- `issues`
|
||||
- `pull-requests`
|
||||
- `actions`
|
||||
- `wiki`
|
||||
- `projects`
|
||||
- `packages`（若目標功能支援）
|
||||
|
||||
如果同時指定 `contents` 和更細的範圍（例如 `code` 或 `releases`），該單元以更細的範圍為準。
|
||||
|
||||
<a id="compatibility-notes"></a>
|
||||
### 相容性說明
|
||||
|
||||
Gitea 支援 GitHub Actions 權限範圍的一個子集。
|
||||
Gitea Actions 目前不支援 `statuses`、`checks`、`deployments`、`id-token`、`security-events` 和 `pages` 等 GitHub 專屬範圍。
|
||||
|
||||
Gitea 另外提供一些儲存庫單元範圍，它們在 GitHub Actions 中並不是獨立的範圍：
|
||||
|
||||
- `code`
|
||||
- `releases`
|
||||
- `wiki`
|
||||
- `projects`
|
||||
|
||||
<a id="default-permission-mode"></a>
|
||||
## 預設權限模式
|
||||
|
||||
如果工作流和 Job 都沒有定義 `permissions:`，Gitea 會使用所設定的預設模式：
|
||||
|
||||
- **Permissive**（寬鬆）：對 Job 所屬儲存庫的大多數單元具有讀取和寫入權限（向下相容的預設值）。
|
||||
- **受限**（Restricted）：對 Job 所屬儲存庫的 `code`、`releases` 和 `packages` 具有唯讀權限，預設無法存取其他單元。
|
||||
|
||||
<a id="maximum-token-permissions-clamping"></a>
|
||||
## 最大令牌權限（限縮）
|
||||
|
||||
您可以為每個儲存庫單元設定最大權限。
|
||||
Job 的實際權限計算方式如下：
|
||||
|
||||
`effective = min(requested, maximum)`
|
||||
|
||||
也就是說，工作流可以降低 Job 的權限，但不能超過您所設定的最大值。
|
||||
如果未設定最大值，所有範圍的最大值預設為 `write`。
|
||||
|
||||
<a id="where-to-configure"></a>
|
||||
## 設定位置
|
||||
|
||||
您可以在以下位置設定預設值和最大值：
|
||||
|
||||
- **使用者 / 組織**：`Settings` → `Actions` → `General`
|
||||
- **儲存庫**：`Settings` → `Actions` → `General`
|
||||
- 對於組織內的儲存庫，儲存庫可以沿用所有者層級的設定，或透過 **Override owner-level configuration** 選擇退出。
|
||||
|
||||
注意：只有在啟用**儲存庫 Actions** 後，才會顯示儲存庫層級的令牌權限設定。
|
||||
|
||||
<a id="fork-pull-requests"></a>
|
||||
## 來自 fork 的拉取請求
|
||||
|
||||
基於安全考量，由來自 fork 的拉取請求觸發的工作流，對儲存庫內容一律只有唯讀權限，不受工作流 `permissions:` 或設定影響。
|
||||
|
||||
<a id="cross-repository-access"></a>
|
||||
## 跨儲存庫存取
|
||||
|
||||
預設情況下，`GITEA_TOKEN` 只能存取：
|
||||
|
||||
- Job 所屬的儲存庫（依計算出的權限）
|
||||
- 公開儲存庫（唯讀）
|
||||
|
||||
預設會拒絕存取其他私有儲存庫。
|
||||
使用者或組織可以在**設定** > **Actions** > **General** > **Cross-Repository Access** 中，允許唯讀存取選定的私有儲存庫。
|
||||
|
||||
私有儲存庫也可以在**設定** > **Actions** > **General** 中允許選定的協作所有者。
|
||||
這樣，這些所有者的私有儲存庫就能為了 Actions 用途讀取目前的私有儲存庫，例如私有 Actions 和可重複使用的工作流。
|
||||
|
||||
由來自 fork 的拉取請求觸發的工作流，永遠無法取得對私有儲存庫的跨儲存庫存取權，即使這些儲存庫已列入清單也一樣。
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
date: "2024-04-10T22:21:00+08:00"
|
||||
slug: "actions-variables"
|
||||
sidebar_position: 25
|
||||
---
|
||||
|
||||
# 變量
|
||||
|
||||
您可以建立使用者、組織和儲存庫級別的變量。變量的級別取決於建立它的位置。當建立變量時，變量的名稱會被
|
||||
轉換為大寫，在yaml文件中引用時需要使用大寫。
|
||||
|
||||
## 命名規則
|
||||
|
||||
以下規則適用於變量名：
|
||||
|
||||
- 變量名稱只能包含字母數字字符 (`[a-z]`, `[A-Z]`, `[0-9]`) 或下劃線 (`_`)。不允許使用空格。
|
||||
- 變量名稱不能以 `GITHUB_` 和 `GITEA_` 前綴開頭。
|
||||
- 變量名稱不能以數字開頭。
|
||||
- 變量名稱不區分大小寫。
|
||||
- 變量名稱在建立它們的級別上必須是唯一的。
|
||||
- 變量名稱不能為 `CI`。
|
||||
|
||||
## 使用
|
||||
|
||||
建立設定變量後，它們將自動填充到 `vars` 上下文中。您可以在工作流中使用類似 `${{ vars.VARIABLE_NAME }}` 這樣的表達式來使用它們。
|
||||
|
||||
## 優先級
|
||||
|
||||
如果同名變量存在於多個級別，則級別最低的變量優先。
|
||||
儲存庫級別的變量總是比組織或者使用者級別的變量優先被選中。
|
||||
Reference in new issue
Block a user