mirror of
https://gitea.com/gitea/docs.git
synced 2026-11-14 22:03:44 +00:00
Update zh tw languages and fix some broken links (#455)
--------- Co-authored-by: silverwind <[email protected]> Co-authored-by: silverwind <[email protected]> Reviewed-on: https://gitea.com/gitea/docs/pulls/455 Reviewed-by: silverwind <[email protected]>
This commit is contained in:
committed
1 parent
c0f8a04185
commit
965c269495
652 files changed
+30864
-30792
No files matched your search
+4
-4
@@ -12,19 +12,19 @@ aliases:
|
||||
|
||||
## 獲取頁面
|
||||
|
||||
Gitea 源代碼附帶示例頁面，位於 `contrib/legal` 目錄中。將它們複製到 `custom/public/assets/`。例如，要添加隱私政策：
|
||||
Gitea 源程式碼附帶範例頁面，位於 `contrib/legal` 目錄中。將它們複製到 `custom/public/assets/`。例如，要添加隱私政策：
|
||||
|
||||
```bash
|
||||
wget -O /path/to/custom/public/assets/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/legal/privacy.html.sample
|
||||
```
|
||||
|
||||
現在您需要編輯頁面以符合您的要求。特別是您必須更改電子郵件地址、網站地址和“您的 Gitea 實例”的引用以匹配您的情況。
|
||||
現在您需要編輯頁面以符合您的要求。特別是您必須更改電子電子郵件地址、網站地址和“您的 Gitea 實例”的引用以匹配您的情況。
|
||||
|
||||
您絕對不能放置一般的服務條款或隱私聲明，暗示 Gitea 項目對您的服務器負責。
|
||||
您絕對不能放置一般的服務條款或隱私聲明，暗示 Gitea 專案對您的伺服器負責。
|
||||
|
||||
## 使其可見
|
||||
|
||||
創建或附加到 `/path/to/custom/templates/custom/extra_links_footer.tmpl`：
|
||||
建立或附加到 `/path/to/custom/templates/custom/extra_links_footer.tmpl`：
|
||||
|
||||
```go
|
||||
<a class="item" href="{{AppSubUrl}}/assets/privacy.html">隱私政策</a>
|
||||
|
||||
+74
-74
@@ -10,7 +10,7 @@ aliases:
|
||||
|
||||
## LDAP（輕量級目錄訪問協議）
|
||||
|
||||
LDAP via BindDN 和簡單身份驗證 LDAP 共享以下字段：
|
||||
LDAP via BindDN 和簡單身份驗證 LDAP 共享以下欄位：
|
||||
|
||||
- 授權名稱 **（必填）**
|
||||
|
||||
@@ -18,110 +18,110 @@ LDAP via BindDN 和簡單身份驗證 LDAP 共享以下字段：
|
||||
|
||||
- 主機 **（必填）**
|
||||
|
||||
- 可以訪問 LDAP 服務器的地址。
|
||||
- 可以訪問 LDAP 伺服器的地址。
|
||||
- 例如：`mydomain.com`
|
||||
|
||||
- 端口 **（必填）**
|
||||
|
||||
- 連接到服務器時使用的端口。
|
||||
- 連接到伺服器時使用的端口。
|
||||
- 例如：`389` 用於 LDAP 或 `636` 用於 LDAP SSL
|
||||
|
||||
- 啟用 TLS 加密（可選）
|
||||
|
||||
- 是否在連接到 LDAP 服務器時使用 TLS。
|
||||
- 是否在連接到 LDAP 伺服器時使用 TLS。
|
||||
|
||||
- 管理員過濾器（可選）
|
||||
|
||||
- 指定用戶是否應被授予管理員權限的 LDAP 過濾器。如果用戶帳戶通過過濾器，用戶將被授予管理員權限。
|
||||
- 指定使用者是否應被授予管理員權限的 LDAP 過濾器。如果使用者帳戶通過過濾器，使用者將被授予管理員權限。
|
||||
- 例如：`(objectClass=adminAccount)`
|
||||
- Microsoft Active Directory（AD）的示例：`(memberOf=CN=admin-group,OU=example,DC=example,DC=org)`
|
||||
- Microsoft Active Directory（AD）的範例：`(memberOf=CN=admin-group,OU=example,DC=example,DC=org)`
|
||||
|
||||
- 用戶名屬性（可選）
|
||||
- 使用者名稱屬性（可選）
|
||||
|
||||
- 包含用戶名的用戶 LDAP 記錄的屬性。給定屬性值將在首次成功登錄後用於新 Gitea 帳戶用戶名。留空以使用登錄表單中給定的登錄名。
|
||||
- 當提供的登錄名與多個屬性匹配時，這很有用，但應僅使用單個特定屬性作為 Gitea 帳戶名，請參閱“用戶過濾器”。
|
||||
- 包含使用者名稱的使用者 LDAP 記錄的屬性。給定屬性值將在首次成功登入後用於新 Gitea 帳戶使用者名稱。留空以使用登入表單中給定的登入名。
|
||||
- 當提供的登入名與多個屬性匹配時，這很有用，但應僅使用單個特定屬性作為 Gitea 帳戶名，請參閱“使用者過濾器”。
|
||||
- 例如：`uid`
|
||||
- Microsoft Active Directory（AD）的示例：`sAMAccountName`
|
||||
- Microsoft Active Directory（AD）的範例：`sAMAccountName`
|
||||
|
||||
- 名字屬性（可選）
|
||||
|
||||
- 包含用戶名字的用戶 LDAP 記錄的屬性。這將用於填充其帳戶信息。
|
||||
- 包含使用者名稱字的使用者 LDAP 記錄的屬性。這將用於填充其帳戶資訊。
|
||||
- 例如：`givenName`
|
||||
|
||||
- 姓氏屬性（可選）
|
||||
|
||||
- 包含用戶姓氏的用戶 LDAP 記錄的屬性。這將用於填充其帳戶信息。
|
||||
- 包含使用者姓氏的使用者 LDAP 記錄的屬性。這將用於填充其帳戶資訊。
|
||||
- 例如：`sn`
|
||||
|
||||
- 電子郵件屬性 **（必填）**
|
||||
- 包含用戶電子郵件地址的用戶 LDAP 記錄的屬性。這將用於填充其帳戶信息。
|
||||
- 包含使用者電子電子郵件地址的使用者 LDAP 記錄的屬性。這將用於填充其帳戶資訊。
|
||||
- 例如：`mail`
|
||||
|
||||
### LDAP via BindDN
|
||||
|
||||
添加以下字段：
|
||||
添加以下欄位：
|
||||
|
||||
- 綁定 DN（可選）
|
||||
|
||||
- 綁定到 LDAP 服務器時使用的 DN。這可以留空以執行匿名搜索。
|
||||
- 綁定到 LDAP 伺服器時使用的 DN。這可以留空以執行匿名搜索。
|
||||
- 例如：`cn=Search,dc=mydomain,dc=com`
|
||||
|
||||
- 綁定密碼（可選）
|
||||
|
||||
- 上面指定的綁定 DN 的密碼（如果有）。_注意：密碼使用服務器上的 SECRET_KEY 加密存儲。仍然建議確保綁定 DN 具有盡可能少的權限。_
|
||||
- 上面指定的綁定 DN 的密碼（如果有）。_注意：密碼使用伺服器上的 SECRET_KEY 加密儲存。仍然建議確保綁定 DN 具有盡可能少的權限。_
|
||||
|
||||
- 用戶搜索基礎 **（必填）**
|
||||
- 使用者搜索基礎 **（必填）**
|
||||
|
||||
- 將搜索用戶帳戶的 LDAP 基礎。
|
||||
- 將搜索使用者帳戶的 LDAP 基礎。
|
||||
- 例如：`ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 用戶過濾器 **（必填）**
|
||||
- 聲明如何查找嘗試進行身份驗證的用戶記錄的 LDAP 過濾器。`%[1]s` 匹配參數將替換為登錄表單中給定的登錄名。
|
||||
- 使用者過濾器 **（必填）**
|
||||
- 聲明如何查找嘗試進行身份驗證的使用者記錄的 LDAP 過濾器。`%[1]s` 匹配參數將替換為登入表單中給定的登入名。
|
||||
- 例如：`(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))`
|
||||
- Microsoft Active Directory（AD）的示例：`(&(objectCategory=Person)(memberOf=CN=user-group,OU=example,DC=example,DC=org)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))`
|
||||
- 要多次替換，應使用 `%[1]s`，例如當匹配提供的登錄名與多個屬性（例如用戶標識符、電子郵件甚至電話號碼）時。
|
||||
- Microsoft Active Directory（AD）的範例：`(&(objectCategory=Person)(memberOf=CN=user-group,OU=example,DC=example,DC=org)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))`
|
||||
- 要多次替換，應使用 `%[1]s`，例如當匹配提供的登入名與多個屬性（例如使用者標識符、電子郵件甚至電話號碼）時。
|
||||
- 例如：`(&(objectClass=Person)(|(uid=%[1]s)(mail=%[1]s)(mobile=%[1]s)))`
|
||||
- 啟用用戶同步
|
||||
- 此選項啟用定期任務，將 Gitea 用戶與 LDAP 服務器同步。默認週期為每 24 小時，但可以在 app.ini 文件中更改。請參閱 [sample app.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) 中的 _cron.sync_external_users_ 部分以獲取有關該部分的詳細評論。上面描述的 _User Search Base_ 和 _User Filter_ 設置將限制哪些用戶可以使用 Gitea 以及哪些用戶將被同步。首次運行時，任務將創建所有符合給定設置的 LDAP 用戶，因此在處理大型企業 LDAP 目錄時請小心。
|
||||
- 啟用使用者同步
|
||||
- 此選項啟用定期任務，將 Gitea 使用者與 LDAP 伺服器同步。預設週期為每 24 小時，但可以在 app.ini 文件中更改。請參閱 [sample app.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) 中的 _cron.sync_external_users_ 部分以獲取有關該部分的詳細評論。上面描述的 _User Search Base_ 和 _User Filter_ 設定將限制哪些使用者可以使用 Gitea 以及哪些使用者將被同步。首次運行時，任務將建立所有符合給定設定的 LDAP 使用者，因此在處理大型企業 LDAP 目錄時請小心。
|
||||
|
||||
### 使用簡單身份驗證的 LDAP
|
||||
|
||||
添加以下字段：
|
||||
添加以下欄位：
|
||||
|
||||
- 用戶 DN **（必填）**
|
||||
- 使用者 DN **（必填）**
|
||||
|
||||
- 用作用戶 DN 的模板。`%s` 匹配參數將替換為登錄表單中給定的登錄名。
|
||||
- 用作使用者 DN 的模板。`%s` 匹配參數將替換為登入表單中給定的登入名。
|
||||
- 例如：`cn=%s,ou=Users,dc=mydomain,dc=com`
|
||||
- 例如：`uid=%s,ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 用戶搜索基礎（可選）
|
||||
- 使用者搜索基礎（可選）
|
||||
|
||||
- 將搜索用戶帳戶的 LDAP 基礎。
|
||||
- 將搜索使用者帳戶的 LDAP 基礎。
|
||||
- 例如：`ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 用戶過濾器 **（必填）**
|
||||
- 聲明何時允許用戶登錄的 LDAP 過濾器。`%[1]s` 匹配參數將替換為登錄表單中給定的登錄名。
|
||||
- 使用者過濾器 **（必填）**
|
||||
- 聲明何時允許使用者登入的 LDAP 過濾器。`%[1]s` 匹配參數將替換為登入表單中給定的登入名。
|
||||
- 例如：`(&(objectClass=posixAccount)(|(cn=%[1]s)(mail=%[1]s)))`
|
||||
- 例如：`(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))`
|
||||
|
||||
### 驗證 LDAP 中的組成員資格
|
||||
|
||||
使用以下字段：
|
||||
使用以下欄位：
|
||||
|
||||
- 組搜索基礎 DN（可選）
|
||||
|
||||
- 用於組的 LDAP DN。
|
||||
- 例如：`ou=group,dc=mydomain,dc=com`
|
||||
|
||||
- 包含用戶列表的組屬性（可選）
|
||||
- 包含使用者列表的組屬性（可選）
|
||||
|
||||
- 列出/包含組成員的組對象的屬性。
|
||||
- 例如：`memberUid` 或 `member`
|
||||
|
||||
- 組中列出的用戶屬性（可選）
|
||||
- 組中列出的使用者屬性（可選）
|
||||
|
||||
- 用於在組對象中引用用戶的用戶屬性。
|
||||
- 例如：如果組對象包含 `member: bender` 並且用戶對象包含 `uid: bender`，則為 `uid`。
|
||||
- 用於在組對象中引用使用者的使用者屬性。
|
||||
- 例如：如果組對象包含 `member: bender` 並且使用者對象包含 `uid: bender`，則為 `uid`。
|
||||
- 例如：如果組對象包含 `member: uid=bender,ou=users,dc=planetexpress,dc=com`，則為 `dn`。
|
||||
|
||||
- 驗證 LDAP 中的組成員資格（可選）
|
||||
@@ -129,31 +129,31 @@ LDAP via BindDN 和簡單身份驗證 LDAP 共享以下字段：
|
||||
- 聲明如何在上述 DN 中查找有效組的 LDAP 過濾器。
|
||||
- 例如：`(|(cn=gitea_users)(cn=admins))`
|
||||
|
||||
## PAM（可插拔身份驗證模塊）
|
||||
## PAM（可插拔身份驗證模組）
|
||||
|
||||
此過程啟用 PAM 身份驗證。用戶仍然可以使用用戶管理手動添加到系統中。PAM 提供了一種機制，可以通過測試它們來自動將用戶添加到當前數據庫中。要使用普通的 Linux 密碼，運行 Gitea 的用戶還必須具有對 `/etc/shadow` 的讀取訪問權限，以便在使用公鑰登錄時檢查帳戶的有效性。
|
||||
此過程啟用 PAM 身份驗證。使用者仍然可以使用使用者管理手動添加到系統中。PAM 提供了一種機制，可以透過測試它們來自動將使用者添加到當前資料庫中。要使用普通的 Linux 密碼，運行 Gitea 的使用者還必須具有對 `/etc/shadow` 的讀取存取權限，以便在使用公鑰登入時檢查帳戶的有效性。
|
||||
|
||||
**注意**：如果用戶已將 SSH 公鑰添加到 Gitea 中，則使用這些密鑰 _可能_ 會繞過登錄檢查系統。因此，如果您希望禁用使用 PAM 身份驗證的用戶，您 _應該_ 也使用內置用戶管理器手動禁用 Gitea 中的帳戶。
|
||||
**注意**：如果使用者已將 SSH 公鑰添加到 Gitea 中，則使用這些密鑰 _可能_ 會繞過登入檢查系統。因此，如果您希望禁用使用 PAM 身份驗證的使用者，您 _應該_ 也使用內置使用者管理器手動禁用 Gitea 中的帳戶。
|
||||
|
||||
1. 配置和準備安裝。
|
||||
- 建議您創建一個管理用戶。
|
||||
1. 設定和準備安裝。
|
||||
- 建議您建立一個管理使用者。
|
||||
- 可能還需要取消選擇自動註冊。
|
||||
1. 數據庫初始化後，以新創建的管理用戶身份登錄。
|
||||
1. 導航到用戶設置（右上角的圖標），然後選擇 `站點管理` -> `身份驗證源`，然後選擇 `添加身份驗證源`。
|
||||
1. 填寫以下字段：
|
||||
1. 資料庫初始化後，以新建立的管理使用者身份登入。
|
||||
1. 導航到使用者設定（右上角的圖標），然後選擇 `站點管理` -> `身份驗證源`，然後選擇 `添加身份驗證源`。
|
||||
1. 填寫以下欄位：
|
||||
- `身份驗證類型`：`PAM`
|
||||
- `名稱`：此處的任何值都應有效，如果您願意，可以使用“系統身份驗證”。
|
||||
- `PAM 服務名稱`：選擇 `/etc/pam.d/` 下列出的執行所需身份驗證的文件。[^1]
|
||||
- `PAM 電子郵件域`：附加到用戶身份驗證的電子郵件後綴。例如，如果登錄系統期望用戶名為 `gituser`，並且此字段設置為 `mail.com`，則 Gitea 將期望經過身份驗證的 GIT 實例的 `用戶電子郵件` 字段為 `[email protected]`。[^2]
|
||||
- `PAM 電子郵件域`：附加到使用者身份驗證的電子郵件後綴。例如，如果登入系統期望使用者名稱為 `gituser`，並且此欄位設定為 `mail.com`，則 Gitea 將期望經過身份驗證的 GIT 實例的 `用戶電子郵件` 欄位為 `[email protected]`。[^2]
|
||||
|
||||
**注意**：PAM 支持是通過 [構建時標誌](installation/from-source.md#build) 添加的，官方提供的二進制文件未啟用此功能。PAM 需要必要的 libpam 動態庫可用，並且需要編譯器可以訪問必要的 PAM 開發標頭。
|
||||
**注意**：PAM 支援是通過 [構建時標誌](installation/from-source.md#build) 添加的，官方提供的二進制文件未啟用此功能。PAM 需要必要的 libpam 動態庫可用，並且需要編譯器可以訪問必要的 PAM 開發標頭。
|
||||
|
||||
[^1]: 例如，使用 Debian "Bullseye" 上的標準 Linux 登錄，使用 `common-session-noninteractive` - 此值可能對其他版本的 Debian（包括 Ubuntu 和 Mint）有效，請參閱您的發行版文檔。
|
||||
[^2]: **這是 PAM 的必填字段**。請注意：在上述示例中，用戶將以 `gituser` 而不是 `[email protected]` 登錄 Gitea Web 界面。
|
||||
[^1]: 例如，使用 Debian "Bullseye" 上的標準 Linux 登入，使用 `common-session-noninteractive` - 此值可能對其他版本的 Debian（包括 Ubuntu 和 Mint）有效，請參閱您的發行版文件。
|
||||
[^2]: **這是 PAM 的必填欄位**。請注意：在上述範例中，使用者將以 `gituser` 而不是 `[email protected]` 登入 Gitea Web 介面。
|
||||
|
||||
## SMTP（簡單郵件傳輸協議）
|
||||
|
||||
此選項允許 Gitea 以 Gitea 用戶身份登錄到 SMTP 主機。要配置此項，請設置以下字段：
|
||||
此選項允許 Gitea 以 Gitea 使用者身份登入到 SMTP 主機。要設定此項，請設定以下欄位：
|
||||
|
||||
- 授權名稱 **（必填）**
|
||||
|
||||
@@ -170,18 +170,18 @@ LDAP via BindDN 和簡單身份驗證 LDAP 共享以下字段：
|
||||
|
||||
- 端口 **（必填）**
|
||||
|
||||
- 連接到服務器時使用的端口。
|
||||
- 連接到伺服器時使用的端口。
|
||||
- 例如：`587`
|
||||
|
||||
- 允許的域
|
||||
|
||||
- 如果使用公共 SMTP 主機或具有多個域的 SMTP 主機，則限制哪些域可以登錄。
|
||||
- 如果使用公共 SMTP 主機或具有多個域的 SMTP 主機，則限制哪些域可以登入。
|
||||
- 例如：`gitea.com,mydomain.com,mydomain2.com`
|
||||
|
||||
- 強制 SMTPS
|
||||
|
||||
- 默認情況下，將使用 SMTPS 連接到端口 465，如果您希望對其他端口使用 SMTPS，請設置此值。
|
||||
- 否則，如果服務器提供 `STARTTLS` 擴展，將使用此擴展。
|
||||
- 預設情況下，將使用 SMTPS 連接到端口 465，如果您希望對其他端口使用 SMTPS，請設定此值。
|
||||
- 否則，如果伺服器提供 `STARTTLS` 擴展，將使用此擴展。
|
||||
|
||||
- 跳過 TLS 驗證
|
||||
|
||||
@@ -192,9 +192,9 @@ LDAP via BindDN 和簡單身份驗證 LDAP 共享以下字段：
|
||||
|
||||
## FreeIPA
|
||||
|
||||
- 為了使用 FreeIPA 憑據登錄 Gitea，需要為 Gitea 創建一個綁定帳戶：
|
||||
- 為了使用 FreeIPA 憑據登入 Gitea，需要為 Gitea 建立一個綁定帳戶：
|
||||
|
||||
- 在 FreeIPA 服務器上，創建一個 `gitea.ldif` 文件，將 `dc=example,dc=com` 替換為您的 DN，並提供適當的安全密碼：
|
||||
- 在 FreeIPA 伺服器上，建立一個 `gitea.ldif` 文件，將 `dc=example,dc=com` 替換為您的 DN，並提供適當的安全密碼：
|
||||
|
||||
```sh
|
||||
dn: uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com
|
||||
@@ -207,7 +207,7 @@ LDAP via BindDN 和簡單身份驗證 LDAP 共享以下字段：
|
||||
nsIdleTimeout: 0
|
||||
```
|
||||
|
||||
- 導入 LDIF（如果需要，將 localhost 更改為 IPA 服務器）。將提示輸入目錄管理員密碼：
|
||||
- 導入 LDIF（如果需要，將 localhost 更改為 IPA 伺服器）。將提示輸入目錄管理員密碼：
|
||||
|
||||
```sh
|
||||
ldapmodify -h localhost -p 389 -x -D \
|
||||
@@ -222,56 +222,56 @@ LDAP via BindDN 和簡單身份驗證 LDAP 共享以下字段：
|
||||
|
||||
- 注意：有關 IPA 憑據的錯誤，請運行 `kinit admin` 並提供域管理員帳戶密碼。
|
||||
|
||||
- 以管理員身份登錄 Gitea，然後單擊管理面板下的“身份驗證”。然後單擊 `添加新源` 並填寫詳細信息，根據需要更改所有內容。
|
||||
- 以管理員身份登入 Gitea，然後單擊管理面板下的“身份驗證”。然後單擊 `添加新源` 並填寫詳細資訊，根據需要更改所有內容。
|
||||
|
||||
## SPNEGO 與 SSPI（Kerberos/NTLM，僅適用於 Windows）
|
||||
|
||||
Gitea 支持通過 Windows 中內置的安全支持提供程序接口（SSPI）為服務器的 Web 部分進行 SPNEGO 單點登錄身份驗證（RFC4559 定義的方案）。SSPI 僅在 Windows 環境中工作 - 當服務器和客戶端都運行 Windows 時。
|
||||
Gitea 支援通過 Windows 中內置的安全支援提供程式介面（SSPI）為伺服器的 Web 部分進行 SPNEGO 單點登入身份驗證（RFC4559 定義的方案）。SSPI 僅在 Windows 環境中工作 - 當伺服器和客戶端都運行 Windows 時。
|
||||
|
||||
在激活 SSPI 單點登錄身份驗證（SSO）之前，您必須準備好環境：
|
||||
在激活 SSPI 單點登入身份驗證（SSO）之前，您必須準備好環境：
|
||||
|
||||
- 在活動目錄中創建一個單獨的用戶帳戶，該帳戶下將運行 `gitea.exe` 進程（例如，域 `domain.local` 下的 `user`）：
|
||||
- 在活動目錄中建立一個單獨的使用者帳戶，該帳戶下將運行 `gitea.exe` 進程（例如，域 `domain.local` 下的 `user`）：
|
||||
|
||||
- 為運行 `gitea.exe` 的主機創建一個類別為 `HTTP` 的服務主體名稱：
|
||||
- 為運行 `gitea.exe` 的主機建立一個類別為 `HTTP` 的服務主體名稱：
|
||||
|
||||
- 以特權域用戶（例如域管理員）身份啟動 `命令提示符` 或 `PowerShell`
|
||||
- 運行以下命令，將 `host.domain.local` 替換為運行 Web 應用程序的服務器的完全限定域名（FQDN），將 `domain\user` 替換為上一步中創建的帳戶名稱：
|
||||
- 以特權域使用者（例如域管理員）身份啟動 `命令提示符` 或 `PowerShell`
|
||||
- 運行以下命令，將 `host.domain.local` 替換為運行 Web 應用程式的伺服器的完全限定域名（FQDN），將 `domain\user` 替換為上一步中建立的帳戶名稱：
|
||||
|
||||
```sh
|
||||
setspn -A HTTP/host.domain.local domain\user
|
||||
```
|
||||
|
||||
- 使用創建的用戶登錄（如果已登錄，請登出）
|
||||
- 使用建立的使用者登入（如果已登入，請登出）
|
||||
|
||||
- 確保 `custom/conf/app.ini` 的 `[server]` 部分中的 `ROOT_URL` 是運行 Web 應用程序的服務器的完全限定域名 - 與創建服務主體名稱時使用的相同（例如 `host.domain.local`）
|
||||
- 確保 `custom/conf/app.ini` 的 `[server]` 部分中的 `ROOT_URL` 是運行 Web 應用程式的伺服器的完全限定域名 - 與建立服務主體名稱時使用的相同（例如 `host.domain.local`）
|
||||
|
||||
- 啟動 Web 服務器（`gitea.exe web`）
|
||||
- 啟動 Web 伺服器（`gitea.exe web`）
|
||||
|
||||
- 通過在 `站點管理 -> 身份驗證源` 中添加 `SPNEGO 與 SSPI` 身份驗證源來啟用 SSPI 身份驗證
|
||||
|
||||
- 使用任何域用戶登錄到同一域中的客戶端計算機（客戶端計算機，不同於運行 `gitea.exe` 的服務器）
|
||||
- 使用任何域使用者登入到同一域中的客戶端計算機（客戶端計算機，不同於運行 `gitea.exe` 的伺服器）
|
||||
|
||||
- 如果您使用的是 Chrome 或 Edge，請將 Web 應用程序的 URL 添加到本地內部網站（`Internet 選項 -> 安全 -> 本地內部網站 -> 網站`）
|
||||
- 如果您使用的是 Chrome 或 Edge，請將 Web 應用程式的 URL 添加到本地內部網站（`Internet 選項 -> 安全 -> 本地內部網站 -> 網站`）
|
||||
|
||||
- 啟動 Chrome 或 Edge 並導航到 Gitea 的 FQDN URL（例如 `http://host.domain.local:3000`）
|
||||
|
||||
- 單擊儀表板上的 `登錄` 按鈕，選擇 SSPI 以使用當前登錄到計算機的相同用戶自動登錄
|
||||
- 單擊儀錶板上的 `登錄` 按鈕，選擇 SSPI 以使用當前登入到計算機的相同使用者自動登入
|
||||
|
||||
- 如果不起作用，請確保：
|
||||
- 您未在運行 Gitea 的同一服務器上運行 Web 瀏覽器。您應該在域加入的計算機（客戶端）上運行 Web 瀏覽器，該計算機與服務器不同。如果客戶端和服務器都在同一計算機上運行，NTLM 將優先於 Kerberos。
|
||||
- 您未在運行 Gitea 的同一伺服器上運行 Web 瀏覽器。您應該在域加入的計算機（客戶端）上運行 Web 瀏覽器，該計算機與伺服器不同。如果客戶端和伺服器都在同一計算機上運行，NTLM 將優先於 Kerberos。
|
||||
- 主機只有一個 `HTTP/...` SPN
|
||||
- SPN 僅包含主機名，不包含端口
|
||||
- 您已將 Web 應用程序的 URL 添加到 `本地內部網站區域`
|
||||
- 服務器和客戶端的時鐘不應相差超過 5 分鐘（取決於組策略）
|
||||
- 您已將 Web 應用程式的 URL 添加到 `本地內部網站區域`
|
||||
- 伺服器和客戶端的時鐘不應相差超過 5 分鐘（取決於組策略）
|
||||
- Internet Explorer 中應啟用 `集成 Windows 身份驗證`（在 `高級設置` 下）
|
||||
|
||||
## 反向代理
|
||||
|
||||
Gitea 支持反向代理標頭身份驗證，它將讀取標頭作為受信任的登錄用戶名或用戶電子郵件地址。默認情況下未啟用此功能，您可以通過以下方式啟用它
|
||||
Gitea 支援反向代理標頭身份驗證，它將讀取標頭作為受信任的登入使用者名稱或使用者電子電子郵件地址。預設情況下未啟用此功能，您可以透過以下方式啟用它
|
||||
|
||||
```ini
|
||||
[service]
|
||||
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
|
||||
```
|
||||
|
||||
默認登錄用戶名在 `X-WEBAUTH-USER` 標頭中，您可以通過更
|
||||
預設登入使用者名稱在 `X-WEBAUTH-USER` 標頭中，您可以透過更
|
||||
+31
-31
@@ -14,11 +14,11 @@ Gitea 目前有一個 `dump` 命令，可以將安裝保存到 ZIP 文件中。
|
||||
|
||||
為了確保 Gitea 實例的一致性，必須在備份期間關閉它。
|
||||
|
||||
Gitea 由數據庫、文件和 git 存儲庫組成，這些都會在使用時發生變化。例如，當遷移正在進行時，數據庫中會創建一個事務，同時 git 存儲庫正在被複製。如果備份發生在遷移過程中，git 存儲庫可能不完整，儘管數據庫聲稱它是完整的，因為它是在之後轉儲的。避免此類競爭條件的唯一方法是在備份期間停止 Gitea 實例。
|
||||
Gitea 由資料庫、文件和 git 儲存庫組成，這些都會在使用時發生變化。例如，當遷移正在進行時，資料庫中會建立一個事務，同時 git 儲存庫正在被複製。如果備份發生在遷移過程中，git 儲存庫可能不完整，儘管資料庫聲稱它是完整的，因為它是在之後轉儲的。避免此類競爭條件的唯一方法是在備份期間停止 Gitea 實例。
|
||||
|
||||
## 備份命令 (`dump`)
|
||||
|
||||
切換到運行 Gitea 的用戶：`su git`。在 Gitea 安裝目錄中運行 `./gitea dump -c /path/to/app.ini`。應該會有類似以下的輸出：
|
||||
切換到運行 Gitea 的使用者：`su git`。在 Gitea 安裝目錄中運行 `./gitea dump -c /path/to/app.ini`。應該會有類似以下的輸出：
|
||||
|
||||
```log
|
||||
2016/12/27 22:32:09 Creating tmp work dir: /tmp/gitea-dump-417443001
|
||||
@@ -31,18 +31,18 @@ Gitea 由數據庫、文件和 git 存儲庫組成，這些都會在使用時發
|
||||
|
||||
在 `gitea-dump-1482906742.zip` 文件中，將包含以下內容：
|
||||
|
||||
- `app.ini` - 如果最初存儲在默認的 `custom/` 目錄之外，則為配置文件的可選副本
|
||||
- `custom/` - `custom/` 中的所有配置或自定義文件。
|
||||
- `data/` - 數據目錄（APP_DATA_PATH），如果您使用文件會話，則不包括會話。此目錄包括 `attachments`、`avatars`、`lfs`、`indexers`，如果您使用 SQLite，則包括 SQLite 文件。
|
||||
- `repos/` - 存儲庫目錄的完整副本。
|
||||
- `gitea-db.sql` - 數據庫的 SQL 轉儲
|
||||
- `app.ini` - 如果最初儲存在預設的 `custom/` 目錄之外，則為設定文件的可選副本
|
||||
- `custom/` - `custom/` 中的所有設定或自訂文件。
|
||||
- `data/` - 資料目錄（APP_DATA_PATH），如果您使用文件會話，則不包括會話。此目錄包括 `attachments`、`avatars`、`lfs`、`indexers`，如果您使用 SQLite，則包括 SQLite 文件。
|
||||
- `repos/` - 儲存庫目錄的完整副本。
|
||||
- `gitea-db.sql` - 資料庫的 SQL 轉儲
|
||||
- `log/` - 各種日誌。它們在恢復或遷移時不需要。
|
||||
|
||||
中間備份文件創建在臨時目錄中，可以通過 `--tempdir` 命令行參數或 `TMPDIR` 環境變量指定。
|
||||
中間備份文件建立在臨時目錄中，可以透過 `--tempdir` 命令行參數或 `TMPDIR` 環境變量指定。
|
||||
|
||||
## 備份數據庫
|
||||
## 備份資料庫
|
||||
|
||||
由 `gitea dump` 創建的 SQL 轉儲使用 XORM，Gitea 管理員可能更喜歡使用原生的 MySQL 和 PostgreSQL 轉儲工具。使用 XORM 轉儲數據庫時仍然存在一些未解決的問題，這些問題可能會在嘗試恢復時引起問題。
|
||||
由 `gitea dump` 建立的 SQL 轉儲使用 XORM，Gitea 管理員可能更喜歡使用原生的 MySQL 和 PostgreSQL 轉儲工具。使用 XORM 轉儲資料庫時仍然存在一些未解決的問題，這些問題可能會在嘗試恢復時引起問題。
|
||||
|
||||
```sh
|
||||
# mysql
|
||||
@@ -57,21 +57,21 @@ pg_dump -U $USER $DATABASE > gitea-db.sql
|
||||
|
||||
該命令必須以 `gitea/conf/app.ini` 中指定的 `RUN_USER = <OS_USERNAME>` 執行；並且，為了在沒有權限錯誤的情況下壓縮備份文件夾，必須在 `--tempdir` 內執行 `docker exec` 命令。
|
||||
|
||||
示例：
|
||||
範例：
|
||||
|
||||
```bash
|
||||
docker exec -u <OS_USERNAME> -it -w <--tempdir> $(docker ps -qf 'name=^<NAME_OF_DOCKER_CONTAINER>$') bash -c '/usr/local/bin/gitea dump -c </path/to/app.ini>'
|
||||
```
|
||||
|
||||
\*注意：`--tempdir` 是指 Gitea 使用的 docker 環境的臨時目錄；如果您未指定自定義 `--tempdir`，則 Gitea 使用 `/tmp` 或 docker 容器的 `TMPDIR` 環境變量。對於 `--tempdir`，請相應地調整您的 `docker exec` 命令選項。
|
||||
\*注意：`--tempdir` 是指 Gitea 使用的 docker 環境的臨時目錄；如果您未指定自訂 `--tempdir`，則 Gitea 使用 `/tmp` 或 docker 容器的 `TMPDIR` 環境變量。對於 `--tempdir`，請相應地調整您的 `docker exec` 命令選項。
|
||||
|
||||
結果應該是一個文件，存儲在指定的 `--tempdir` 中，類似於：`gitea-dump-1482906742.zip`
|
||||
結果應該是一個文件，儲存在指定的 `--tempdir` 中，類似於：`gitea-dump-1482906742.zip`
|
||||
|
||||
## 恢復命令 (`restore`)
|
||||
|
||||
目前不支持恢復命令。這是一個手動過程，主要涉及將文件移動到正確的位置並恢復數據庫轉儲。
|
||||
目前不支援恢復命令。這是一個手動過程，主要涉及將文件移動到正確的位置並恢復資料庫轉儲。
|
||||
|
||||
示例：
|
||||
範例：
|
||||
|
||||
```sh
|
||||
unzip gitea-dump-1610949662.zip
|
||||
@@ -92,19 +92,19 @@ psql -U $USER -d $DATABASE < gitea-db.sql
|
||||
service gitea restart
|
||||
```
|
||||
|
||||
如果安裝方法更改（例如，二進制 -> Docker），或者 Gitea 安裝到與以前不同的目錄，則應重新生成存儲庫 Git Hooks。
|
||||
如果安裝方法更改（例如，二進制 -> Docker），或者 Gitea 安裝到與以前不同的目錄，則應重新生成儲存庫 Git Hooks。
|
||||
|
||||
在 Gitea 運行並從 Gitea 二進制文件所在的目錄中，執行：`./gitea admin regenerate hooks`
|
||||
|
||||
這確保存儲庫 Git Hooks 中的應用程序和配置文件路徑與當前安裝一致且適用。如果這些路徑未更新，存儲庫 `push` 操作將失敗。
|
||||
這確保儲存庫 Git Hooks 中的應用程式和設定文件路徑與當前安裝一致且適用。如果這些路徑未更新，儲存庫 `push` 操作將失敗。
|
||||
|
||||
如果您仍然有問題，請考慮運行 `./gitea doctor check` 以檢查可能的錯誤（或使用 `--fix` 選項運行）。
|
||||
|
||||
### 使用 Docker (`restore`)
|
||||
|
||||
在基於 Docker 的 gitea 實例中也不支持恢復命令。恢復過程包含與前一部分中描述的相同步驟，但使用不同的路徑。
|
||||
在基於 Docker 的 gitea 實例中也不支援恢復命令。恢復過程包含與前一部分中描述的相同步驟，但使用不同的路徑。
|
||||
|
||||
示例：
|
||||
範例：
|
||||
|
||||
```sh
|
||||
# 在容器中打開 bash 會話
|
||||
@@ -114,7 +114,7 @@ unzip gitea-dump-1610949662.zip
|
||||
cd gitea-dump-1610949662
|
||||
# 恢復 gitea 數據
|
||||
mv data/* /data/gitea
|
||||
# 恢復存儲庫本身
|
||||
# 恢復儲存庫本身
|
||||
mv repos/* /data/git/gitea-repositories/
|
||||
# 調整文件權限
|
||||
chown -R git:git /data
|
||||
@@ -122,7 +122,7 @@ chown -R git:git /data
|
||||
/usr/local/bin/gitea -c '/data/gitea/conf/app.ini' admin regenerate hooks
|
||||
```
|
||||
|
||||
gitea 容器中的默認用戶是 `git`（1000:1000）。請將 `2a83b293548e` 替換為您的 gitea 容器 ID 或名稱。
|
||||
gitea 容器中的預設使用者是 `git`（1000:1000）。請將 `2a83b293548e` 替換為您的 gitea 容器 ID 或名稱。
|
||||
|
||||
### 使用 Docker-rootless (`restore`)
|
||||
|
||||
@@ -138,7 +138,7 @@ cd gitea-dump-1610949662
|
||||
mv data/conf/app.ini /etc/gitea/app.ini
|
||||
# 恢復 gitea 數據
|
||||
mv data/* /var/lib/gitea
|
||||
# 恢復存儲庫本身
|
||||
# 恢復儲存庫本身
|
||||
mv repos/* /var/lib/gitea/git/gitea-repositories
|
||||
# 調整文件權限
|
||||
chown -R git:git /etc/gitea/app.ini /var/lib/gitea
|
||||
@@ -146,19 +146,19 @@ chown -R git:git /etc/gitea/app.ini /var/lib/gitea
|
||||
/usr/local/bin/gitea -c '/etc/gitea/app.ini' admin regenerate hooks
|
||||
```
|
||||
|
||||
### 使用 `gitea dump` 轉換數據庫類型
|
||||
### 使用 `gitea dump` 轉換資料庫類型
|
||||
|
||||
`gitea dump` 命令可以生成一個 SQL 文件，可以由另一種數據庫類型讀取，這在您在第一次安裝期間未選擇正確的數據庫時很有用。
|
||||
`gitea dump` 命令可以生成一個 SQL 文件，可以由另一種資料庫類型讀取，這在您在第一次安裝期間未選擇正確的資料庫時很有用。
|
||||
|
||||
請注意，此轉換過程尚未經過充分測試，因此建議在第一次安裝期間選擇最終的數據庫類型，而不要嘗試之後更改。
|
||||
請注意，此轉換過程尚未經過充分測試，因此建議在第一次安裝期間選擇最終的資料庫類型，而不要嘗試之後更改。
|
||||
|
||||
停止 Gitea 服務器，然後確保您擁有原始數據庫的完整備份。
|
||||
停止 Gitea 伺服器，然後確保您擁有原始資料庫的完整備份。
|
||||
|
||||
在嘗試轉換之前，確保原始數據庫是乾淨的。運行 `gitea doctor check --all --fix` 和 `gitea doctor recreate-table` 以解決常見問題。
|
||||
在嘗試轉換之前，確保原始資料庫是乾淨的。運行 `gitea doctor check --all --fix` 和 `gitea doctor recreate-table` 以解決常見問題。
|
||||
|
||||
使用 `--database` 標誌獲取目標格式的 Gitea 轉儲，在此示例中為 PostgreSQL：`gitea dump --database postgres`，然後從生成的 ZIP 文件中提取 `gitea-db.sql` 文件。
|
||||
使用 `--database` 標誌獲取目標格式的 Gitea 轉儲，在此範例中為 PostgreSQL：`gitea dump --database postgres`，然後從生成的 ZIP 文件中提取 `gitea-db.sql` 文件。
|
||||
|
||||
創建 PostgreSQL Gitea 用戶和 Gitea 數據庫。然後，使用以下命令將 SQL 文件作為 Gitea 用戶導入到 Gitea 數據庫中：
|
||||
建立 PostgreSQL Gitea 使用者和 Gitea 資料庫。然後，使用以下命令將 SQL 文件作為 Gitea 使用者導入到 Gitea 資料庫中：
|
||||
|
||||
```sh
|
||||
sudo -u postgres psql -d gitea
|
||||
@@ -167,6 +167,6 @@ gitea=# SET on_error_stop TO on
|
||||
gitea=# \i gitea-db.sql
|
||||
```
|
||||
|
||||
禁用 `synchronous_commit` 使 PostgreSQL 對崩潰的抵抗力降低，但使導入速度更快。由於我們已經有原始數據庫的備份，並且我們可以檢查導入是否成功完成，因此這應該是一個不錯的權衡。
|
||||
禁用 `synchronous_commit` 使 PostgreSQL 對崩潰的抵抗力降低，但使導入速度更快。由於我們已經有原始資料庫的備份，並且我們可以檢查導入是否成功完成，因此這應該是一個不錯的權衡。
|
||||
|
||||
導入完成後，設置 Gitea 以使用 PostgreSQL 並重新啟動 Gitea 服務器。祝你好運！
|
||||
導入完成後，設定 Gitea 以使用 PostgreSQL 並重新啟動 Gitea 伺服器。祝你好運！
|
||||
+12
-12
@@ -6,14 +6,14 @@ aliases:
|
||||
- /zh-tw/cmd-embedded
|
||||
---
|
||||
|
||||
# 嵌入式數據提取工具
|
||||
# 嵌入式資料提取工具
|
||||
|
||||
Gitea 的可執行文件包含運行所需的所有資源：模板、圖像、樣式表和翻譯。可以通過將替換文件放置在 `custom` 目錄中的匹配路徑中來覆蓋其中的任何資源（請參閱 [自定義 Gitea](../administration/customizing-gitea.md)）。
|
||||
Gitea 的可執行文件包含運行所需的所有資源：模板、圖像、樣式表和翻譯。可以透過將替換文件放置在 `custom` 目錄中的匹配路徑中來覆蓋其中的任何資源（請參閱 [自訂 Gitea](../administration/customizing-gitea.md)）。
|
||||
|
||||
要獲取嵌入資源的副本以供編輯，可以從操作系統的 shell 界面使用 CLI 的 `embedded` 命令。
|
||||
要獲取嵌入資源的副本以供編輯，可以從操作系統的 shell 介面使用 CLI 的 `embedded` 命令。
|
||||
|
||||
:::note
|
||||
嵌入式數據提取工具包含在 Gitea 1.12 及更高版本中。
|
||||
嵌入式資料提取工具包含在 Gitea 1.12 及更高版本中。
|
||||
:::
|
||||
|
||||
## 列出資源
|
||||
@@ -26,7 +26,7 @@ gitea embedded list [--include-vendored] [patterns...]
|
||||
|
||||
`--include-vendored` 標誌使命令包括供應商文件，這些文件通常被排除在外；即，Gitea 所需的外部庫中的文件（例如 [octicons](https://octicons.github.com/) 等）。
|
||||
|
||||
可以提供文件搜索模式列表。Gitea 使用 [gobwas/glob](https://github.com/gobwas/glob) 進行其 glob 語法。以下是一些示例：
|
||||
可以提供文件搜索模式列表。Gitea 使用 [gobwas/glob](https://github.com/gobwas/glob) 進行其 glob 語法。以下是一些範例：
|
||||
|
||||
- 列出所有模板文件，在任何虛擬目錄中：`**.tmpl`
|
||||
- 列出所有郵件模板文件：`templates/mail/**.tmpl`
|
||||
@@ -36,7 +36,7 @@ gitea embedded list [--include-vendored] [patterns...]
|
||||
|
||||
如果未提供任何模式，則列出所有文件。
|
||||
|
||||
### 示例：列出所有嵌入文件
|
||||
### 範例：列出所有嵌入文件
|
||||
|
||||
列出所有路徑中包含 `openid` 的嵌入文件：
|
||||
|
||||
@@ -60,23 +60,23 @@ templates/user/settings/security_openid.tmpl
|
||||
gitea [--config {file}] embedded extract [--destination {dir}|--custom] [--overwrite|--rename] [--include-vendored] {patterns...}
|
||||
```
|
||||
|
||||
`--config` 選項告訴 Gitea `app.ini` 配置文件的位置（如果它不在默認位置）。此選項僅與 `--custom` 標誌一起使用。
|
||||
`--config` 選項告訴 Gitea `app.ini` 設定文件的位置（如果它不在預設位置）。此選項僅與 `--custom` 標誌一起使用。
|
||||
|
||||
`--destination` 選項告訴 Gitea 文件必須提取到的目錄。默認是當前目錄。
|
||||
`--destination` 選項告訴 Gitea 文件必須提取到的目錄。預設是當前目錄。
|
||||
|
||||
`--custom` 標誌告訴 Gitea 將文件直接提取到 `custom` 目錄中。為了使其工作，命令需要知道 `app.ini` 配置文件的位置（`--config`），並且根據配置，從 Gitea 通常啟動的目錄運行。詳情請參閱 [自定義 Gitea](../administration/customizing-gitea.md)。
|
||||
`--custom` 標誌告訴 Gitea 將文件直接提取到 `custom` 目錄中。為了使其工作，命令需要知道 `app.ini` 設定文件的位置（`--config`），並且根據設定，從 Gitea 通常啟動的目錄運行。詳情請參閱 [自訂 Gitea](../administration/customizing-gitea.md)。
|
||||
|
||||
`--overwrite` 標誌允許覆蓋目標目錄中的任何現有文件。
|
||||
|
||||
`--rename` 標誌告訴 Gitea 將目標目錄中的任何現有文件重命名為 `filename.bak`。以前的 `.bak` 文件將被覆蓋。
|
||||
|
||||
必須提供至少一個文件搜索模式；請參閱上面的 `list` 子命令以了解模式語法和示例。
|
||||
必須提供至少一個文件搜索模式；請參閱上面的 `list` 子命令以瞭解模式語法和範例。
|
||||
|
||||
### 重要通知
|
||||
|
||||
確保**僅提取那些需要自定義的文件**。`custom` 目錄中存在的文件不會被 Gitea 的升級過程升級。當 Gitea 升級到新版本（通過替換可執行文件）時，許多嵌入文件將發生變化。Gitea 將尊重並使用 `custom` 目錄中找到的任何文件，即使它們是舊的且不兼容。
|
||||
確保**僅提取那些需要自訂的文件**。`custom` 目錄中存在的文件不會被 Gitea 的升級過程升級。當 Gitea 升級到新版本（通過替換可執行文件）時，許多嵌入文件將發生變化。Gitea 將尊重並使用 `custom` 目錄中找到的任何文件，即使它們是舊的且不相容。
|
||||
|
||||
### 示例：提取郵件模板
|
||||
### 範例：提取郵件模板
|
||||
|
||||
將郵件模板提取到臨時目錄：
|
||||
|
||||
|
||||
+96
-96
@@ -10,33 +10,33 @@ aliases:
|
||||
|
||||
## 用法
|
||||
|
||||
`gitea [全局選項] 命令 [命令或全局選項] [參數...]`
|
||||
`gitea [全域選項] 命令 [命令或全域選項] [參數...]`
|
||||
|
||||
## 全局選項
|
||||
## 全域選項
|
||||
|
||||
所有全局選項都可以放在命令級別。
|
||||
所有全域選項都可以放在命令級別。
|
||||
|
||||
- `--help`, `-h`: 顯示幫助文本並退出。可選。
|
||||
- `--version`, `-v`: 顯示版本並退出。可選。（示例：`Gitea version 1.1.0+218-g7b907ed built with: bindata, sqlite`）。
|
||||
- `--work-path path`, `-w path`: Gitea 的工作路徑。可選。（默認：二進制文件的路徑或 `$GITEA_WORK_DIR`）
|
||||
- `--custom-path path`, `-C path`: Gitea 的自定義文件夾路徑。可選。（默認：`WorkPath`/custom 或 `$GITEA_CUSTOM`）。
|
||||
- `--config path`, `-c path`: Gitea 配置文件路徑。可選。（默認：`CustomPath`/conf/app.ini）。
|
||||
- `--version`, `-v`: 顯示版本並退出。可選。（範例：`Gitea version 1.1.0+218-g7b907ed built with: bindata, sqlite`）。
|
||||
- `--work-path path`, `-w path`: Gitea 的工作路徑。可選。（預設：二進制文件的路徑或 `$GITEA_WORK_DIR`）
|
||||
- `--custom-path path`, `-C path`: Gitea 的自訂文件夾路徑。可選。（預設：`WorkPath`/custom 或 `$GITEA_CUSTOM`）。
|
||||
- `--config path`, `-c path`: Gitea 設定文件路徑。可選。（預設：`CustomPath`/conf/app.ini）。
|
||||
|
||||
注意：默認的 custom-path、config 和 work-path 也可以在構建時更改（如果需要）。
|
||||
注意：預設的 custom-path、config 和 work-path 也可以在構建時更改（如果需要）。
|
||||
|
||||
## 命令
|
||||
|
||||
### web
|
||||
|
||||
啟動服務器：
|
||||
啟動伺服器：
|
||||
|
||||
- 選項：
|
||||
- `--port number`, `-p number`: 端口號。可選。（默認：3000）。覆蓋配置文件。
|
||||
- `--install-port number`: 運行安裝頁面的端口號。可選。（默認：3000）。覆蓋配置文件。
|
||||
- `--port number`, `-p number`: 端口號。可選。（預設：3000）。覆蓋設定文件。
|
||||
- `--install-port number`: 運行安裝頁面的端口號。可選。（預設：3000）。覆蓋設定文件。
|
||||
- `--pid path`, `-P path`: Pidfile 路徑。可選。
|
||||
- `--quiet`, `-q`: 只在控制台上發出致命日誌，適用於日誌設置之前的日誌。
|
||||
- `--verbose`: 在控制台上發出跟踪日誌，適用於日誌設置之前的日誌。
|
||||
- 示例：
|
||||
- `--quiet`, `-q`: 只在控制檯上發出致命日誌，適用於日誌設定之前的日誌。
|
||||
- `--verbose`: 在控制檯上發出跟蹤日誌，適用於日誌設定之前的日誌。
|
||||
- 範例：
|
||||
- `gitea web`
|
||||
- `gitea web --port 80`
|
||||
- `gitea web --config /etc/gitea.ini --pid /some/custom/gitea.pid`
|
||||
@@ -51,144 +51,144 @@ aliases:
|
||||
- `user`:
|
||||
- `list`:
|
||||
- 選項：
|
||||
- `--admin`: 僅列出管理員用戶。可選。
|
||||
- 描述：列出所有存在的用戶
|
||||
- 示例：
|
||||
- `--admin`: 僅列出管理員使用者。可選。
|
||||
- 描述：列出所有存在的使用者
|
||||
- 範例：
|
||||
- `gitea admin user list`
|
||||
- `delete`:
|
||||
- 選項：
|
||||
- `--email`: 要刪除的用戶的電子郵件。
|
||||
- `--username`: 要刪除的用戶名。
|
||||
- `--id`: 要刪除的用戶 ID。
|
||||
- `--email`: 要刪除的使用者的電子郵件。
|
||||
- `--username`: 要刪除的使用者名稱。
|
||||
- `--id`: 要刪除的使用者 ID。
|
||||
- 需要提供 `--id`、`--username` 或 `--email` 之一。如果提供了多個，則所有都必須匹配。
|
||||
- 示例：
|
||||
- 範例：
|
||||
- `gitea admin user delete --id 1`
|
||||
- `create`:
|
||||
- 選項：
|
||||
- `--name value`: 用戶名。必需。從 Gitea 1.9.0 開始，使用 `--username` 標誌代替。
|
||||
- `--username value`: 用戶名。必需。Gitea 1.9.0 中的新功能。
|
||||
- `--name value`: 使用者名稱。必需。從 Gitea 1.9.0 開始，使用 `--username` 標誌代替。
|
||||
- `--username value`: 使用者名稱。必需。Gitea 1.9.0 中的新功能。
|
||||
- `--password value`: 密碼。必需。
|
||||
- `--email value`: 電子郵件。必需。
|
||||
- `--admin`: 如果提供，這將使用戶成為管理員。可選。
|
||||
- `--access-token`: 如果提供，將為用戶創建訪問令牌。可選。（默認：false）。
|
||||
- `--must-change-password`: 創建的用戶在首次登錄後需要設置新密碼，默認：true。可以通過 `--must-change-password=false` 禁用。
|
||||
- `--random-password`: 如果提供，將使用隨機生成的密碼作為創建用戶的密碼。`--password` 的值將被丟棄。可選。
|
||||
- `--random-password-length`: 如果提供，將用於配置隨機生成的密碼的長度。可選。（默認：12）
|
||||
- 示例：
|
||||
- `--admin`: 如果提供，這將使使用者成為管理員。可選。
|
||||
- `--access-token`: 如果提供，將為使用者建立存取權杖。可選。（預設：false）。
|
||||
- `--must-change-password`: 建立的使用者在首次登入後需要設定新密碼，預設：true。可以透過 `--must-change-password=false` 禁用。
|
||||
- `--random-password`: 如果提供，將使用隨機生成的密碼作為建立使用者的密碼。`--password` 的值將被丟棄。可選。
|
||||
- `--random-password-length`: 如果提供，將用於設定隨機生成的密碼的長度。可選。（預設：12）
|
||||
- 範例：
|
||||
- `gitea admin user create --username myname --password asecurepassword --email [email protected]`
|
||||
- `change-password`:
|
||||
- 選項：
|
||||
- `--username value`, `-u value`: 用戶名。必需。
|
||||
- `--username value`, `-u value`: 使用者名稱。必需。
|
||||
- `--password value`, `-p value`: 新密碼。必需。
|
||||
- `--must-change-password`: 用戶在登錄後需要設置新密碼，默認：true。可以通過 `--must-change-password=false` 禁用。
|
||||
- 示例：
|
||||
- `--must-change-password`: 使用者在登入後需要設定新密碼，預設：true。可以透過 `--must-change-password=false` 禁用。
|
||||
- 範例：
|
||||
- `gitea admin user change-password --username myname --password asecurepassword`
|
||||
- `must-change-password`:
|
||||
- 參數：
|
||||
- `[username...]`: 必須更改密碼的用戶
|
||||
- `[username...]`: 必須更改密碼的使用者
|
||||
- 選項：
|
||||
- `--all`, `-A`: 強制所有用戶更改密碼
|
||||
- `--exclude username`, `-e username`: 排除給定的用戶。可以多次設置。
|
||||
- `--unset`: 撤銷給定用戶的強制密碼更改
|
||||
- `--all`, `-A`: 強制所有使用者更改密碼
|
||||
- `--exclude username`, `-e username`: 排除給定的使用者。可以多次設定。
|
||||
- `--unset`: 撤銷給定使用者的強制密碼更改
|
||||
- `generate-access-token`:
|
||||
- 選項：
|
||||
- `--username value`, `-u value`: 用戶名。必需。
|
||||
- `--username value`, `-u value`: 使用者名稱。必需。
|
||||
- `--token-name value`, `-t value`: 令牌名稱。必需。
|
||||
- `--scopes value`: 逗號分隔的範圍列表。範圍遵循格式 `[read|write]:<block>` 或 `all`，其中 `<block>` 是可見組之一，您可以在打開顯示可用路由的 API 頁面時看到（例如 `repo`）。
|
||||
- 示例：
|
||||
- 範例：
|
||||
- `gitea admin user generate-access-token --username myname --token-name mytoken`
|
||||
- `gitea admin user generate-access-token --help`
|
||||
- `regenerate`
|
||||
- 選項：
|
||||
- `hooks`: 為所有存儲庫重新生成 Git 鉤子
|
||||
- `hooks`: 為所有儲存庫重新生成 Git 鉤子
|
||||
- `keys`: 重新生成 authorized_keys 文件
|
||||
- 示例：
|
||||
- 範例：
|
||||
- `gitea admin regenerate hooks`
|
||||
- `gitea admin regenerate keys`
|
||||
- `auth`:
|
||||
- `list`:
|
||||
- 描述：列出所有存在的外部身份驗證源
|
||||
- 示例：
|
||||
- 範例：
|
||||
- `gitea admin auth list`
|
||||
- `delete`:
|
||||
- 選項：
|
||||
- `--id`: 要刪除的源的 ID。必需。
|
||||
- 示例：
|
||||
- 範例：
|
||||
- `gitea admin auth delete --id 1`
|
||||
- `add-oauth`:
|
||||
- 選項：
|
||||
- `--name`: 應用程序名稱。
|
||||
- `--name`: 應用程式名稱。
|
||||
- `--provider`: OAuth2 提供者。
|
||||
- `--key`: 客戶端 ID（密鑰）。
|
||||
- `--secret`: 客戶端密鑰。
|
||||
- `--auto-discover-url`: OpenID Connect 自動發現 URL（僅在使用 OpenID Connect 作為提供者時需要）。
|
||||
- `--use-custom-urls`: 使用自定義 URL 用於 GitLab/GitHub OAuth 端點。
|
||||
- `--custom-tenant-id`: 使用自定義租戶 ID 用於 OAuth 端點。
|
||||
- `--custom-auth-url`: 使用自定義授權 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-token-url`: 使用自定義令牌 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-profile-url`: 使用自定義配置文件 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-email-url`: 使用自定義電子郵件 URL（GitHub 的選項）。
|
||||
- `--icon-url`: 自定義圖標 URL 用於 OAuth2 登錄源。
|
||||
- `--use-custom-urls`: 使用自訂 URL 用於 GitLab/GitHub OAuth 端點。
|
||||
- `--custom-tenant-id`: 使用自訂租戶 ID 用於 OAuth 端點。
|
||||
- `--custom-auth-url`: 使用自訂授權 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-token-url`: 使用自訂令牌 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-profile-url`: 使用自訂設定文件 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-email-url`: 使用自訂電子郵件 URL（GitHub 的選項）。
|
||||
- `--icon-url`: 自訂圖標 URL 用於 OAuth2 登入源。
|
||||
- `--skip-local-2fa`: 允許源覆蓋本地 2FA。（可選）
|
||||
- `--scopes`: 為此 OAuth2 源請求的其他範圍。（可選）
|
||||
- `--required-claim-name`: 必須設置的聲明名稱，以允許用戶使用此源登錄。（可選）
|
||||
- `--required-claim-value`: 必須設置的聲明值，以允許用戶使用此源登錄。（可選）
|
||||
- `--required-claim-name`: 必須設定的聲明名稱，以允許使用者使用此源登入。（可選）
|
||||
- `--required-claim-value`: 必須設定的聲明值，以允許使用者使用此源登入。（可選）
|
||||
- `--group-claim-name`: 為此源提供組名稱的聲明名稱。（可選）
|
||||
- `--admin-group`: 管理員用戶的組聲明值。（可選）
|
||||
- `--restricted-group`: 受限用戶的組聲明值。（可選）
|
||||
- `--admin-group`: 管理員使用者的組聲明值。（可選）
|
||||
- `--restricted-group`: 受限使用者的組聲明值。（可選）
|
||||
- `--group-team-map`: 組與組織團隊之間的 JSON 映射。（可選）
|
||||
- `--group-team-map-removal`: 根據組啟用自動團隊成員刪除。（可選）
|
||||
- 示例：
|
||||
- 範例：
|
||||
- `gitea admin auth add-oauth --name external-github --provider github --key OBTAIN_FROM_SOURCE --secret OBTAIN_FROM_SOURCE`
|
||||
- `update-oauth`:
|
||||
- 選項：
|
||||
- `--id`: 要更新的源的 ID。必需。
|
||||
- `--name`: 應用程序名稱。
|
||||
- `--name`: 應用程式名稱。
|
||||
- `--provider`: OAuth2 提供者。
|
||||
- `--key`: 客戶端 ID（密鑰）。
|
||||
- `--secret`: 客戶端密鑰。
|
||||
- `--auto-discover-url`: OpenID Connect 自動發現 URL（僅在使用 OpenID Connect 作為提供者時需要）。
|
||||
- `--use-custom-urls`: 使用自定義 URL 用於 GitLab/GitHub OAuth 端點。
|
||||
- `--custom-tenant-id`: 使用自定義租戶 ID 用於 OAuth 端點。
|
||||
- `--custom-auth-url`: 使用自定義授權 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-token-url`: 使用自定義令牌 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-profile-url`: 使用自定義配置文件 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-email-url`: 使用自定義電子郵件 URL（GitHub 的選項）。
|
||||
- `--icon-url`: 自定義圖標 URL 用於 OAuth2 登錄源。
|
||||
- `--use-custom-urls`: 使用自訂 URL 用於 GitLab/GitHub OAuth 端點。
|
||||
- `--custom-tenant-id`: 使用自訂租戶 ID 用於 OAuth 端點。
|
||||
- `--custom-auth-url`: 使用自訂授權 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-token-url`: 使用自訂令牌 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-profile-url`: 使用自訂設定文件 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-email-url`: 使用自訂電子郵件 URL（GitHub 的選項）。
|
||||
- `--icon-url`: 自訂圖標 URL 用於 OAuth2 登入源。
|
||||
- `--skip-local-2fa`: 允許源覆蓋本地 2FA。（可選）
|
||||
- `--scopes`: 為此 OAuth2 源請求的其他範圍。
|
||||
- `--required-claim-name`: 必須設置的聲明名稱，以允許用戶使用此源登錄。（可選）
|
||||
- `--required-claim-value`: 必須設置的聲明值，以允許用戶使用此源登錄。（可選）
|
||||
- `--required-claim-name`: 必須設定的聲明名稱，以允許使用者使用此源登入。（可選）
|
||||
- `--required-claim-value`: 必須設定的聲明值，以允許使用者使用此源登入。（可選）
|
||||
- `--group-claim-name`: 為此源提供組名稱的聲明名稱。（可選）
|
||||
- `--admin-group`: 管理員用戶的組聲明值。（可選）
|
||||
- `--restricted-group`: 受限用戶的組聲明值。（可選）
|
||||
- 示例：
|
||||
- `--admin-group`: 管理員使用者的組聲明值。（可選）
|
||||
- `--restricted-group`: 受限使用者的組聲明值。（可選）
|
||||
- 範例：
|
||||
- `gitea admin auth update-oauth --id 1 --name external-github-updated`
|
||||
- `add-smtp`:
|
||||
- 選項：
|
||||
- `--name`: 應用程序名稱。必需。
|
||||
- `--auth-type`: SMTP 身份驗證類型（PLAIN/LOGIN/CRAM-MD5）。默認為 PLAIN。
|
||||
- `--name`: 應用程式名稱。必需。
|
||||
- `--auth-type`: SMTP 身份驗證類型（PLAIN/LOGIN/CRAM-MD5）。預設為 PLAIN。
|
||||
- `--host`: SMTP 主機。必需。
|
||||
- `--port`: SMTP 端口。必需。
|
||||
- `--force-smtps`: SMTPS 始終用於端口 465。設置此選項以在其他端口上強制使用 SMTPS。
|
||||
- `--force-smtps`: SMTPS 始終用於端口 465。設定此選項以在其他端口上強制使用 SMTPS。
|
||||
- `--skip-verify`: 跳過 TLS 驗證。
|
||||
- `--helo-hostname`: 與 HELO 一起發送的主機名。留空以發送當前主機名。
|
||||
- `--disable-helo`: 禁用 SMTP helo。
|
||||
- `--allowed-domains`: 留空以允許所有域。用逗號（','）分隔多個域。
|
||||
- `--skip-local-2fa`: 跳過 2FA 登錄。
|
||||
- `--skip-local-2fa`: 跳過 2FA 登入。
|
||||
- `--active`: 此身份驗證源已激活。
|
||||
備註：
|
||||
`--force-smtps`、`--skip-verify`、`--disable-helo`、`--skip-loca-2fs` 和 `--active` 選項可以使用以下形式：
|
||||
- `--option`、`--option=true` 以啟用
|
||||
- `--option=false` 以禁用
|
||||
如果未指定這些選項，則在 `update-smtp` 中不會更改值，或在 `add-smtp` 中使用默認 `false` 值
|
||||
- 示例：
|
||||
如果未指定這些選項，則在 `update-smtp` 中不會更改值，或在 `add-smtp` 中使用預設 `false` 值
|
||||
- 範例：
|
||||
- `gitea admin auth add-smtp --name ldap --host smtp.mydomain.org --port 587 --skip-verify --active`
|
||||
- `update-smtp`:
|
||||
- 選項：
|
||||
- `--id`: 要更新的源的 ID。必需。
|
||||
- 其他選項與 `add-smtp` 共享
|
||||
- 示例：
|
||||
- 範例：
|
||||
- `gitea admin auth update-smtp --id 1 --host smtp.mydomain.org --port 587 --skip-verify=false`
|
||||
- `gitea admin auth update-smtp --id 1 --active=false`
|
||||
- `add-ldap`: 添加新的 LDAP（通過 Bind DN）身份驗證源
|
||||
@@ -197,24 +197,24 @@ aliases:
|
||||
- `--not-active`: 停用身份驗證源。
|
||||
- `--security-protocol value`: 安全協議名稱。必需。
|
||||
- `--skip-tls-verify`: 禁用 TLS 驗證。
|
||||
- `--host value`: LDAP 服務器的地址。必需。
|
||||
- `--port value`: 連接到 LDAP 服務器時使用的端口。必需。
|
||||
- `--user-search-base value`: 將搜索用戶帳戶的 LDAP 基礎。必需。
|
||||
- `--user-filter value`: 聲明如何查找嘗試身份驗證的用戶記錄的 LDAP 過濾器。必需。
|
||||
- `--admin-filter value`: 指定用戶是否應被授予管理員權限的 LDAP 過濾器。
|
||||
- `--restricted-filter value`: 指定用戶是否應被授予受限狀態的 LDAP 過濾器。
|
||||
- `--username-attribute value`: 包含用戶名的用戶 LDAP 記錄的屬性。
|
||||
- `--firstname-attribute value`: 包含用戶名的用戶 LDAP 記錄的屬性。
|
||||
- `--surname-attribute value`: 包含用戶姓氏的用戶 LDAP 記錄的屬性。
|
||||
- `--email-attribute value`: 包含用戶電子郵件地址的用戶 LDAP 記錄的屬性。必需。
|
||||
- `--public-ssh-key-attribute value`: 包含用戶公鑰的用戶 LDAP 記錄的屬性。
|
||||
- `--avatar-attribute value`: 包含用戶頭像的用戶 LDAP 記錄的屬性。
|
||||
- `--bind-dn value`: 在搜索用戶時綁定到 LDAP 服務器的 DN。
|
||||
- `--bind-password value`: 綁定 DN 的密碼（如果有）。注意：密碼使用服務器上的 SECRET_KEY 加密存儲。仍然建議確保 Bind DN 具有盡可能少的權限。
|
||||
- `--host value`: LDAP 伺服器的地址。必需。
|
||||
- `--port value`: 連接到 LDAP 伺服器時使用的端口。必需。
|
||||
- `--user-search-base value`: 將搜索使用者帳戶的 LDAP 基礎。必需。
|
||||
- `--user-filter value`: 聲明如何查找嘗試身份驗證的使用者記錄的 LDAP 過濾器。必需。
|
||||
- `--admin-filter value`: 指定使用者是否應被授予管理員權限的 LDAP 過濾器。
|
||||
- `--restricted-filter value`: 指定使用者是否應被授予受限狀態的 LDAP 過濾器。
|
||||
- `--username-attribute value`: 包含使用者名稱的使用者 LDAP 記錄的屬性。
|
||||
- `--firstname-attribute value`: 包含使用者名稱的使用者 LDAP 記錄的屬性。
|
||||
- `--surname-attribute value`: 包含使用者姓氏的使用者 LDAP 記錄的屬性。
|
||||
- `--email-attribute value`: 包含使用者電子電子郵件地址的使用者 LDAP 記錄的屬性。必需。
|
||||
- `--public-ssh-key-attribute value`: 包含使用者公鑰的使用者 LDAP 記錄的屬性。
|
||||
- `--avatar-attribute value`: 包含使用者頭像的使用者 LDAP 記錄的屬性。
|
||||
- `--bind-dn value`: 在搜索使用者時綁定到 LDAP 伺服器的 DN。
|
||||
- `--bind-password value`: 綁定 DN 的密碼（如果有）。注意：密碼使用伺服器上的 SECRET_KEY 加密儲存。仍然建議確保 Bind DN 具有盡可能少的權限。
|
||||
- `--attributes-in-bind`: 在綁定 DN 上下文中獲取屬性。
|
||||
- `--synchronize-users`: 啟用用戶同步。
|
||||
- `--synchronize-users`: 啟用使用者同步。
|
||||
- `--page-size value`: 搜索頁面大小。
|
||||
- 示例：
|
||||
- 範例：
|
||||
- `gitea admin auth add-ldap --name ldap --security-protocol unencrypted --host mydomain.org --port 389 --user-search-base "ou=Users,dc=mydomain,dc=org" --user-filter "(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))" --email-attribute mail`
|
||||
- `update-ldap`: 更新現有的 LDAP（通過 Bind DN）身份驗證源
|
||||
- 選項：
|
||||
@@ -223,8 +223,8 @@ aliases:
|
||||
- `--not-active`: 停用身份驗證源。
|
||||
- `--security-protocol value`: 安全協議名稱。
|
||||
- `--skip-tls-verify`: 禁用 TLS 驗證。
|
||||
- `--host value`: LDAP 服務器的地址。
|
||||
- `--port value`: 連接到 LDAP 服務器時使用的端口。
|
||||
- `--user-search-base value`: 將搜索用戶帳戶的 LDAP 基礎。
|
||||
- `--user-filter value`: 聲明如何查找嘗試身份驗證的用戶記錄的 LDAP 過濾器。
|
||||
- `--admin-filter value`: 指定用戶是否應被授予管理員權限的 LDAP
|
||||
- `--host value`: LDAP 伺服器的地址。
|
||||
- `--port value`: 連接到 LDAP 伺服器時使用的端口。
|
||||
- `--user-search-base value`: 將搜索使用者帳戶的 LDAP 基礎。
|
||||
- `--user-filter value`: 聲明如何查找嘗試身份驗證的使用者記錄的 LDAP 過濾器。
|
||||
- `--admin-filter value`: 指定使用者是否應被授予管理員權限的 LDAP
|
||||
+66
-65
@@ -6,133 +6,134 @@ aliases:
|
||||
- /zh-tw/config-cheat-sheet
|
||||
---
|
||||
|
||||
# 配置備忘單
|
||||
# 設定備忘單
|
||||
|
||||
這是一份 Gitea 配置文件的備忘單。它包含了大多數可以配置的設置以及它們的默認值。
|
||||
這是一份 Gitea 設定文件的備忘單。它包含了大多數可以設定的設定以及它們的預設值。
|
||||
|
||||
對 Gitea 配置文件的任何更改應該在 `custom/conf/app.ini` 或任何相應的位置進行。從發行版安裝時，通常會在 `/etc/gitea/conf/app.ini` 中找到。
|
||||
對 Gitea 設定文件的任何更改應該在 `custom/conf/app.ini` 或任何相應的位置進行。從發行版安裝時，通常會在 `/etc/gitea/conf/app.ini` 中找到。
|
||||
|
||||
這裡提供的默認值是最佳努力（不是自動生成的）。它們在 [app.example.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) 中準確記錄（s/main/\<tag|release\>）。任何格式為 `%(X)s` 的字符串都是由 [ini](https://github.com/go-ini/ini/#recursive-values) 提供的功能，用於遞歸讀取值。
|
||||
這裡提供的預設值是最佳努力（不是自動生成的）。它們在 [app.example.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) 中準確記錄（s/main/\<tag|release\>）。任何格式為 `%(X)s` 的字符串都是由 [ini](https://github.com/go-ini/ini/#recursive-values) 提供的功能，用於遞歸讀取值。
|
||||
|
||||
在下面的默認值中，形式為 `$XYZ` 的值指的是環境變量。（但是，請參閱 `environment-to-ini`。）形式為 _`XxYyZz`_ 的值指的是作為默認配置一部分列出的值。這些符號形式不會在您自己的 `app.ini` 文件中工作，僅在此處作為文檔列出。
|
||||
在下面的預設值中，形式為 `$XYZ` 的值指的是環境變量。（但是，請參閱 `environment-to-ini`。）形式為 _`XxYyZz`_ 的值指的是作為預設設定一部分列出的值。這些符號形式不會在您自己的 `app.ini` 文件中工作，僅在此處作為文件列出。
|
||||
|
||||
包含 `#` 或 `;` 的值必須使用 `` ` `` 或 `"""` 引號。
|
||||
|
||||
:::info
|
||||
Gitea 配置更改需要完全重啟才能生效。
|
||||
Gitea 設定更改需要完全重啟才能生效。
|
||||
:::
|
||||
|
||||
## 默認配置（非 `app.ini` 配置）
|
||||
## 預設設定（非 `app.ini` 設定）
|
||||
|
||||
這些值是環境依賴的，但構成了許多值的基礎。它們將在運行 `gitea help` 或啟動時作為默認配置的一部分報告。它們在那裡發出的順序略有不同，但我們將在這裡按設置順序列出它們。
|
||||
這些值是環境依賴的，但構成了許多值的基礎。它們將在運行 `gitea help` 或啟動時作為預設設定的一部分報告。它們在那裡發出的順序略有不同，但我們將在這裡按設定順序列出它們。
|
||||
|
||||
- _`AppPath`_：這是運行 gitea 二進制文件的絕對路徑。
|
||||
- _`AppWorkPath`_：這指的是 `gitea` 二進制文件的“工作路徑”。它是通過使用以下層次結構中的第一個設置來確定的：
|
||||
- _`AppWorkPath`_：這指的是 `gitea` 二進制文件的“工作路徑”。它是通過使用以下層次結構中的第一個設定來確定的：
|
||||
- `app.ini` 中的 `WORK_PATH` 選項
|
||||
- 傳遞給二進制文件的 `--work-path` 標誌
|
||||
- 環境變量 `$GITEA_WORK_DIR`
|
||||
- 構建時設置的內置值（請參閱從源代碼構建）
|
||||
- 否則，它默認為 _`AppPath`_ 的目錄
|
||||
- 構建時設定的內置值（請參閱從源程式碼構建）
|
||||
- 否則，它預設為 _`AppPath`_ 的目錄
|
||||
- 如果上述任何一個是相對路徑，則它們將相對於 _`AppPath`_ 的目錄變為絕對路徑
|
||||
- _`CustomPath`_：這是自定義模板和其他選項的基本目錄。
|
||||
它是通過使用以下層次結構中的第一個設置來確定的：
|
||||
- _`CustomPath`_：這是自訂模板和其他選項的基本目錄。
|
||||
它是通過使用以下層次結構中的第一個設定來確定的：
|
||||
- 傳遞給二進制文件的 `--custom-path` 標誌
|
||||
- 環境變量 `$GITEA_CUSTOM`
|
||||
- 構建時設置的內置值（請參閱從源代碼構建）
|
||||
- 否則，它默認為 _`AppWorkPath`_`/custom`
|
||||
- 構建時設定的內置值（請參閱從源程式碼構建）
|
||||
- 否則，它預設為 _`AppWorkPath`_`/custom`
|
||||
- 如果上述任何一個是相對路徑，則它們將相對於 _`AppWorkPath`_ 的目錄變為絕對路徑
|
||||
- _`CustomConf`_：這是 `app.ini` 文件的路徑。
|
||||
- 傳遞給二進制文件的 `--config` 標誌
|
||||
- 構建時設置的內置值（請參閱從源代碼構建）
|
||||
- 否則，它默認為 _`CustomPath`_`/conf/app.ini`
|
||||
- 構建時設定的內置值（請參閱從源程式碼構建）
|
||||
- 否則，它預設為 _`CustomPath`_`/conf/app.ini`
|
||||
- 如果上述任何一個是相對路徑，則它們將相對於 _`CustomPath`_ 的目錄變為絕對路徑
|
||||
|
||||
此外，還有 _`StaticRootPath`_，可以在構建時設置為內置值，但否則默認為 _`AppWorkPath`_
|
||||
此外，還有 _`StaticRootPath`_，可以在構建時設定為內置值，但否則預設為 _`AppWorkPath`_
|
||||
|
||||
## 總體（`DEFAULT`）
|
||||
|
||||
- `APP_NAME`：**Gitea: Git with a cup of tea**：應用程序名稱，用於頁面標題。
|
||||
- `RUN_USER`：**_當前操作系統用戶名_/`$USER`/`$USERNAME` 例如 git**：Gitea 將以此用戶運行。
|
||||
這應該是一個專用的系統（非用戶）帳戶。不正確設置此項將導致 Gitea 無法啟動。
|
||||
- `RUN_MODE`：**prod**：應用程序運行模式，影響性能和調試：`dev` 或 `prod`，默認為 `prod`。模式 `dev` 使 Gitea 更易於開發和調試，除 `dev` 以外的值被視為 `prod`，適用於生產使用。
|
||||
- `APP_NAME`：**Gitea: Git with a cup of tea**：應用程式名稱，用於頁面標題。
|
||||
- `RUN_USER`：**_當前操作系統使用者名稱_/`$USER`/`$USERNAME` 例如 git**：Gitea 將以此使用者運行。
|
||||
這應該是一個專用的系統（非使用者）帳戶。不正確設定此項將導致 Gitea 無法啟動。
|
||||
- `RUN_MODE`：**prod**：應用程式運行模式，影響性能和調試：`dev` 或 `prod`，預設為 `prod`。模式 `dev` 使 Gitea 更易於開發和調試，除 `dev` 以外的值被視為 `prod`，適用於生產使用。
|
||||
- `WORK_PATH`：**_the-work-path_**：工作目錄，請參閱上面的 AppWorkPath 註釋。
|
||||
|
||||
## 存儲庫（`repository`）
|
||||
<a id="repository-repository"></a>
|
||||
## 儲存庫（`repository`）
|
||||
|
||||
- `ROOT`：**%(APP_DATA_PATH)s/gitea-repositories**：存儲所有存儲庫數據的根路徑。
|
||||
- `ROOT`：**%(APP_DATA_PATH)s/gitea-repositories**：儲存所有儲存庫資料的根路徑。
|
||||
相對路徑解釋為 **_`AppWorkPath`_/%(ROOT)s**。
|
||||
- `SCRIPT_TYPE`：**bash**：此服務器支持的腳本類型。通常這是 `bash`，
|
||||
但有些用戶報告只有 `sh` 可用。
|
||||
- `SCRIPT_TYPE`：**bash**：此伺服器支援的腳本類型。通常這是 `bash`，
|
||||
但有些使用者報告只有 `sh` 可用。
|
||||
- `DETECTED_CHARSETS_ORDER`：**UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, ISO-8859, windows-1252, ISO-8859, windows-1250, ISO-8859, ISO-8859, ISO-8859, windows-1253, ISO-8859, windows-1255, ISO-8859, windows-1251, windows-1256, KOI8-R, ISO-8859, windows-1254, Shift_JIS, GB18030, EUC-JP, EUC-KR, Big5, ISO-2022, ISO-2022, ISO-2022, IBM424_rtl, IBM424_ltr, IBM420_rtl, IBM420_ltr**：檢測到的字符集的優先順序 - 如果檢測到的字符集具有相同的置信度，則列表中較早的字符集將優先於較晚的字符集。添加 `defaults` 將在該點放置未命名的字符集。
|
||||
- `ANSI_CHARSET`：**_empty_**：默認的 ANSI 字符集，用於覆蓋非 UTF-8 字符集。
|
||||
- `FORCE_PRIVATE`：**false**：強制每個新存儲庫為私有。
|
||||
- `DEFAULT_PRIVATE`：**last**：創建新存儲庫時的默認私有設置。
|
||||
- `ANSI_CHARSET`：**_empty_**：預設的 ANSI 字符集，用於覆蓋非 UTF-8 字符集。
|
||||
- `FORCE_PRIVATE`：**false**：強制每個新儲存庫為私有。
|
||||
- `DEFAULT_PRIVATE`：**last**：建立新儲存庫時的預設私有設定。
|
||||
\[last, private, public\]
|
||||
- `DEFAULT_PUSH_CREATE_PRIVATE`：**true**：使用推送創建時的默認私有設置。
|
||||
- `MAX_CREATION_LIMIT`：**-1**：每個用戶的全局最大創建限制，
|
||||
- `DEFAULT_PUSH_CREATE_PRIVATE`：**true**：使用推送建立時的預設私有設定。
|
||||
- `MAX_CREATION_LIMIT`：**-1**：每個使用者的全域最大建立限制，
|
||||
`-1` 表示無限制。
|
||||
- `PREFERRED_LICENSES`：**Apache License 2.0,MIT License**：首選許可證，放在列表頂部。名稱必須與 options/license 或 custom/options/license 中的文件名匹配。
|
||||
- `DISABLE_HTTP_GIT`：**false**：禁用通過 HTTP 協議與存儲庫交互的功能。
|
||||
- `USE_COMPAT_SSH_URI`：**false**：在使用默認 SSH 端口時強制使用 ssh:// 克隆 URL 而不是 scp 風格的 URI。
|
||||
- `GO_GET_CLONE_URL_PROTOCOL`：**https**：`go get` 請求返回存儲庫 URL 的協議，默認為 https。
|
||||
- `DISABLE_HTTP_GIT`：**false**：禁用通過 HTTP 協議與儲存庫交互的功能。
|
||||
- `USE_COMPAT_SSH_URI`：**false**：在使用預設 SSH 端口時強制使用 ssh:// 克隆 URL 而不是 scp 風格的 URI。
|
||||
- `GO_GET_CLONE_URL_PROTOCOL`：**https**：`go get` 請求返回儲存庫 URL 的協議，預設為 https。
|
||||
- `ACCESS_CONTROL_ALLOW_ORIGIN`：**_empty_**：Access-Control-Allow-Origin 標頭的值，
|
||||
默認不顯示。
|
||||
預設不顯示。
|
||||
|
||||
:::warning
|
||||
如果您未給出正確的值，這可能對您的網站有害。
|
||||
:::
|
||||
|
||||
- `DEFAULT_CLOSE_ISSUES_VIA_COMMITS_IN_ANY_BRANCH`：**false**：如果非默認分支上的提交標記為已關閉，則關閉問題。
|
||||
- `ENABLE_PUSH_CREATE_USER`：**false**：允許用戶將本地存儲庫推送到 Gitea 並自動為用戶創建它們。
|
||||
- `ENABLE_PUSH_CREATE_ORG`：**false**：允許用戶將本地存儲庫推送到 Gitea 並自動為組織創建它們。
|
||||
- `DISABLED_REPO_UNITS`：**_empty_**：全局禁用的存儲庫單元的逗號分隔列表。允許的值：\[repo.issues, repo.ext_issues, repo.pulls, repo.wiki, repo.ext_wiki, repo.projects, repo.packages, repo.actions\]
|
||||
- `DEFAULT_REPO_UNITS`：**repo.code,repo.releases,repo.issues,repo.pulls,repo.wiki,repo.projects,repo.packages,repo.actions**：默認的新存儲庫單元的逗號分隔列表。允許的值：\[repo.code, repo.releases, repo.issues, repo.pulls, repo.wiki, repo.projects, repo.packages, repo.actions\]。注意：目前無法停用代碼和版本。如果您指定默認存儲庫單元，您應該仍然列出它們以確保未來的兼容性。外部 wiki 和問題跟踪器無法默認啟用，因為它需要額外的設置。無論是否在默認列表中，禁用的存儲庫單元都不會添加到新存儲庫中。
|
||||
- `DEFAULT_FORK_REPO_UNITS`：**repo.code,repo.pulls**：默認的分叉存儲庫單元的逗號分隔列表。允許的值和規則與 `DEFAULT_REPO_UNITS` 相同。
|
||||
- `DEFAULT_MIRROR_REPO_UNITS`：**repo.code,repo.releases,repo.issues,repo.wiki,repo.projects,repo.packages**：默認的鏡像存儲庫單元的逗號分隔列表。允許的值和規則與 `DEFAULT_REPO_UNITS` 相同。
|
||||
- `DEFAULT_TEMPLATE_REPO_UNITS`：**repo.code,repo.releases,repo.issues,repo.pulls,repo.wiki,repo.projects,repo.packages**：默認的模板存儲庫單元的逗號分隔列表。允許的值和規則與 `DEFAULT_REPO_UNITS` 相同。
|
||||
- `PREFIX_ARCHIVE_FILES`：**true**：通過將它們放在以存儲庫命名的目錄中來為存檔文件添加前綴。
|
||||
- `DEFAULT_CLOSE_ISSUES_VIA_COMMITS_IN_ANY_BRANCH`：**false**：如果非預設分支上的提交標記為已關閉，則關閉問題。
|
||||
- `ENABLE_PUSH_CREATE_USER`：**false**：允許使用者將本地儲存庫推送到 Gitea 並自動為使用者建立它們。
|
||||
- `ENABLE_PUSH_CREATE_ORG`：**false**：允許使用者將本地儲存庫推送到 Gitea 並自動為組織建立它們。
|
||||
- `DISABLED_REPO_UNITS`：**_empty_**：全域禁用的儲存庫單元的逗號分隔列表。允許的值：\[repo.issues, repo.ext_issues, repo.pulls, repo.wiki, repo.ext_wiki, repo.projects, repo.packages, repo.actions\]
|
||||
- `DEFAULT_REPO_UNITS`：**repo.code,repo.releases,repo.issues,repo.pulls,repo.wiki,repo.projects,repo.packages,repo.actions**：預設的新儲存庫單元的逗號分隔列表。允許的值：\[repo.code, repo.releases, repo.issues, repo.pulls, repo.wiki, repo.projects, repo.packages, repo.actions\]。注意：目前無法停用程式碼和版本。如果您指定預設儲存庫單元，您應該仍然列出它們以確保未來的相容性。外部 wiki 和問題跟蹤器無法預設啟用，因為它需要額外的設定。無論是否在預設列表中，禁用的儲存庫單元都不會添加到新儲存庫中。
|
||||
- `DEFAULT_FORK_REPO_UNITS`：**repo.code,repo.pulls**：預設的分叉儲存庫單元的逗號分隔列表。允許的值和規則與 `DEFAULT_REPO_UNITS` 相同。
|
||||
- `DEFAULT_MIRROR_REPO_UNITS`：**repo.code,repo.releases,repo.issues,repo.wiki,repo.projects,repo.packages**：預設的鏡像儲存庫單元的逗號分隔列表。允許的值和規則與 `DEFAULT_REPO_UNITS` 相同。
|
||||
- `DEFAULT_TEMPLATE_REPO_UNITS`：**repo.code,repo.releases,repo.issues,repo.pulls,repo.wiki,repo.projects,repo.packages**：預設的模板儲存庫單元的逗號分隔列表。允許的值和規則與 `DEFAULT_REPO_UNITS` 相同。
|
||||
- `PREFIX_ARCHIVE_FILES`：**true**：通過將它們放在以儲存庫命名的目錄中來為存檔文件添加前綴。
|
||||
- `DISABLE_MIGRATIONS`：**false**：禁用遷移功能。
|
||||
- `DISABLE_STARS`：**false**：禁用星標功能。
|
||||
- `DEFAULT_BRANCH`：**main**：所有存儲庫的默認分支名稱。
|
||||
- `ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`：**false**：允許非管理員用戶採用未採用的存儲庫
|
||||
- `ALLOW_DELETION_OF_UNADOPTED_REPOSITORIES`：**false**：允許非管理員用戶刪除未採用的存儲庫
|
||||
- `DISABLE_DOWNLOAD_SOURCE_ARCHIVES`：**false**：不允許從 UI 下載源代碼存檔文件
|
||||
- `ALLOW_FORK_WITHOUT_MAXIMUM_LIMIT`：**true**：允許無最大數量限制的分叉存儲庫
|
||||
- `DEFAULT_BRANCH`：**main**：所有儲存庫的預設分支名稱。
|
||||
- `ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`：**false**：允許非管理員使用者採用未採用的儲存庫
|
||||
- `ALLOW_DELETION_OF_UNADOPTED_REPOSITORIES`：**false**：允許非管理員使用者刪除未採用的儲存庫
|
||||
- `DISABLE_DOWNLOAD_SOURCE_ARCHIVES`：**false**：不允許從 UI 下載源程式碼存檔文件
|
||||
- `ALLOW_FORK_WITHOUT_MAXIMUM_LIMIT`：**true**：允許無最大數量限制的分叉儲存庫
|
||||
|
||||
### 存儲庫 - 編輯器（`repository.editor`）
|
||||
### 儲存庫 - 編輯器（`repository.editor`）
|
||||
|
||||
- `LINE_WRAP_EXTENSIONS`：**.txt,.md,.markdown,.mdown,.mkd,.livemd,**：在 Monaco 編輯器中應換行的文件擴展名列表。用逗號分隔擴展名。要換行沒有擴展名的文件，只需放置一個逗號
|
||||
- `PREVIEWABLE_FILE_MODES`：**markdown**：具有預覽 API 的有效文件模式，例如 `api/v1/markdown`。用逗號分隔值。如果文件擴展名不匹配，則不會顯示編輯模式中的預覽選項卡。
|
||||
|
||||
### 存儲庫 - 拉取請求（`repository.pull-request`）
|
||||
### 儲存庫 - 拉取請求（`repository.pull-request`）
|
||||
|
||||
- `WORK_IN_PROGRESS_PREFIXES`：**WIP:,\[WIP\]**：用於拉取請求標題中標記為進行中的前綴列表。這些是大小寫不敏感的匹配。
|
||||
- `CLOSE_KEYWORDS`：**close**, **closes**, **closed**, **fix**, **fixes**, **fixed**, **resolve**, **resolves**, **resolved**：用於拉取請求評論中自動關閉相關問題的關鍵字列表
|
||||
- `REOPEN_KEYWORDS`：**reopen**, **reopens**, **reopened**：用於拉取請求評論中自動重新打開相關問題的關鍵字列表
|
||||
- `DEFAULT_MERGE_STYLE`：**merge**：設置存儲庫創建的默認合併樣式，有效選項：`merge`, `rebase`, `rebase-merge`, `squash`, `fast-forward-only`
|
||||
- `DEFAULT_MERGE_MESSAGE_COMMITS_LIMIT`：**50**：在默認的合併消息中，包含最多這麼多的提交。設置為 `-1` 以包含所有提交
|
||||
- `DEFAULT_MERGE_MESSAGE_SIZE`：**5120**：在默認的合併消息中，限制提交消息的大小。設置為 `-1` 以無限制。僅在 `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES` 為 `true` 時使用。
|
||||
- `DEFAULT_MERGE_MESSAGE_ALL_AUTHORS`：**false**：在默認的合併消息中，遍歷所有提交以包含所有作者，否則僅使用有限列表中的作者
|
||||
- `DEFAULT_MERGE_MESSAGE_MAX_APPROVERS`：**10**：在默認的合併消息中，限制列為 `Reviewed-by:` 的審批者數量。設置為 `-1` 以包含所有。
|
||||
- `DEFAULT_MERGE_MESSAGE_OFFICIAL_APPROVERS_ONLY`：**true**：在默認的合併消息中，僅包括正式允許審查的審批者。
|
||||
- `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES`：**false**：在默認的壓縮合併消息中，包含組成拉取請求的所有提交的提交消息。
|
||||
- `DEFAULT_MERGE_STYLE`：**merge**：設定儲存庫建立的預設合併樣式，有效選項：`merge`, `rebase`, `rebase-merge`, `squash`, `fast-forward-only`
|
||||
- `DEFAULT_MERGE_MESSAGE_COMMITS_LIMIT`：**50**：在預設的合併消息中，包含最多這麼多的提交。設定為 `-1` 以包含所有提交
|
||||
- `DEFAULT_MERGE_MESSAGE_SIZE`：**5120**：在預設的合併消息中，限制提交消息的大小。設定為 `-1` 以無限制。僅在 `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES` 為 `true` 時使用。
|
||||
- `DEFAULT_MERGE_MESSAGE_ALL_AUTHORS`：**false**：在預設的合併消息中，遍歷所有提交以包含所有作者，否則僅使用有限列表中的作者
|
||||
- `DEFAULT_MERGE_MESSAGE_MAX_APPROVERS`：**10**：在預設的合併消息中，限制列為 `Reviewed-by:` 的審批者數量。設定為 `-1` 以包含所有。
|
||||
- `DEFAULT_MERGE_MESSAGE_OFFICIAL_APPROVERS_ONLY`：**true**：在預設的合併消息中，僅包括正式允許審查的審批者。
|
||||
- `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES`：**false**：在預設的壓縮合併消息中，包含組成拉取請求的所有提交的提交消息。
|
||||
- `ADD_CO_COMMITTER_TRAILERS`：**true**：如果提交者與作者不匹配，則在合併提交消息中添加共同作者和共同提交者的尾部。
|
||||
- `TEST_CONFLICTING_PATCHES_WITH_GIT_APPLY`：**false**：PR 補丁使用三方合併方法進行測試，以發現是否存在衝突。如果此設置設置為 **true**，則將使用 `git apply` 重新測試衝突的補丁 - 這是 1.18（及更早版本）中的先前行為，但效率較低。如果您發現需要此設置，請報告。
|
||||
- `RETARGET_CHILDREN_ON_MERGE`：**true**：在合併父拉取請求時，將子拉取請求重新定位到父拉取請求分支目標。僅適用於目標相同存儲庫的合併 PR。
|
||||
- `TEST_CONFLICTING_PATCHES_WITH_GIT_APPLY`：**false**：PR 補丁使用三方合併方法進行測試，以發現是否存在衝突。如果此設定設定為 **true**，則將使用 `git apply` 重新測試衝突的補丁 - 這是 1.18（及更早版本）中的先前行為，但效率較低。如果您發現需要此設定，請報告。
|
||||
- `RETARGET_CHILDREN_ON_MERGE`：**true**：在合併父拉取請求時，將子拉取請求重新定位到父拉取請求分支目標。僅適用於目標相同儲存庫的合併 PR。
|
||||
|
||||
### 存儲庫 - 問題（`repository.issue`）
|
||||
### 儲存庫 - 問題（`repository.issue`）
|
||||
|
||||
- `LOCK_REASONS`：**Too heated,Off-topic,Resolved,Spam**：可以鎖定拉取請求或問題的原因列表
|
||||
- `MAX_PINNED`：**3**：每個存儲庫的最大固定問題數量。設置為 0 以禁用固定問題。
|
||||
- `MAX_PINNED`：**3**：每個儲存庫的最大固定問題數量。設定為 0 以禁用固定問題。
|
||||
|
||||
### 存儲庫 - 上傳（`repository.upload`）
|
||||
### 儲存庫 - 上傳（`repository.upload`）
|
||||
|
||||
- `ENABLED`：**true**：是否啟用存儲庫文件上傳
|
||||
- `ENABLED`：**true**：是否啟用儲存庫文件上傳
|
||||
- `TEMP_PATH`：**data/tmp/uploads**：上傳的路徑（內容在 Gitea 重啟時會被刪除）
|
||||
- `ALLOWED_TYPES`：**_empty_**：允許的文件擴展名（`.zip`）、MIME 類型（`text/plain`）或通配符類型（`image/*`、`audio/*`、`video/*`）的逗號分隔列表。空值或 `*/*` 允許所有類型。
|
||||
- `FILE_MAX_SIZE`：**50**：每個文件的最大大小（以 MB 為單位）。
|
||||
- `MAX_FILES`：**5**：每次上傳的最大文件數量
|
||||
|
||||
### 存儲庫 - 發行（`repository.release`）
|
||||
### 儲存庫 - 發行（`repository.release`）
|
||||
|
||||
- `ALLOWED_TYPES`：**_empty_**：允許的文件擴展名（`.zip`）、MIME 類型（`text/plain`）
|
||||
+43
-43
@@ -6,60 +6,60 @@ aliases:
|
||||
- /zh-tw/customizing-gitea
|
||||
---
|
||||
|
||||
# 自定義 Gitea
|
||||
# 自訂 Gitea
|
||||
|
||||
自定義 Gitea 通常使用 `CustomPath` 文件夾進行 - 默認情況下，這是工作目錄（WorkPath）中的 `custom` 文件夾，但如果您的構建設置不同，則可能會有所不同。這是覆蓋配置設置、模板等的中心位置。您可以使用 `gitea help` 檢查 `CustomPath`。您還可以在 _站點管理_ 頁面的 _配置_ 標籤中找到路徑。您可以通過設置 `GITEA_CUSTOM` 環境變量或使用 `gitea` 二進制文件上的 `--custom-path` 選項來覆蓋 `CustomPath`。（該選項將覆蓋環境變量。）
|
||||
自訂 Gitea 通常使用 `CustomPath` 文件夾進行 - 預設情況下，這是工作目錄（WorkPath）中的 `custom` 文件夾，但如果您的構建設定不同，則可能會有所不同。這是覆蓋設定設定、模板等的中心位置。您可以使用 `gitea help` 檢查 `CustomPath`。您還可以在 _站點管理_ 頁面的 _設定_ 標籤中找到路徑。您可以透過設定 `GITEA_CUSTOM` 環境變量或使用 `gitea` 二進制文件上的 `--custom-path` 選項來覆蓋 `CustomPath`。（該選項將覆蓋環境變量。）
|
||||
|
||||
如果 Gitea 是從二進制文件部署的，則所有默認路徑都將相對於 Gitea 二進制文件。如果從發行版安裝，這些路徑可能會修改為 Linux 文件系統標準。Gitea 將嘗試創建所需的文件夾，包括 `custom/`。發行版可能會使用 `/etc/gitea/` 提供 `custom` 的符號鏈接。
|
||||
如果 Gitea 是從二進制文件部署的，則所有預設路徑都將相對於 Gitea 二進制文件。如果從發行版安裝，這些路徑可能會修改為 Linux 文件系統標準。Gitea 將嘗試建立所需的文件夾，包括 `custom/`。發行版可能會使用 `/etc/gitea/` 提供 `custom` 的符號鏈接。
|
||||
|
||||
應用程序設置可以在 `CustomConf` 文件中找到，默認情況下為 `$GITEA_CUSTOM/conf/app.ini`，但如果您的構建設置不同，則可能會有所不同。同樣，`gitea help` 將允許您查看此變量，您可以使用 `gitea` 二進制文件上的 `--config` 選項來覆蓋它。
|
||||
應用程式設定可以在 `CustomConf` 文件中找到，預設情況下為 `$GITEA_CUSTOM/conf/app.ini`，但如果您的構建設定不同，則可能會有所不同。同樣，`gitea help` 將允許您查看此變量，您可以使用 `gitea` 二進制文件上的 `--config` 選項來覆蓋它。
|
||||
|
||||
- [快速備忘單](../administration/config-cheat-sheet.md)
|
||||
- [完整列表](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
|
||||
|
||||
如果無法找到 `CustomPath` 文件夾，請檢查 `gitea help`，請檢查 `GITEA_CUSTOM` 環境變量；這可以用於覆蓋默認路徑到其他位置。例如，`GITEA_CUSTOM` 可能由啟動腳本設置。您可以在站點管理頁面的“配置”標籤下檢查是否設置了該值。
|
||||
如果無法找到 `CustomPath` 文件夾，請檢查 `gitea help`，請檢查 `GITEA_CUSTOM` 環境變量；這可以用於覆蓋預設路徑到其他位置。例如，`GITEA_CUSTOM` 可能由啟動腳本設定。您可以在站點管理頁面的“設定”標籤下檢查是否設定了該值。
|
||||
|
||||
- [環境變量列表](../administration/environment-variables.md)
|
||||
|
||||
:::note
|
||||
Gitea 必須完全重啟才能看到配置更改。
|
||||
Gitea 必須完全重啟才能看到設定更改。
|
||||
:::
|
||||
|
||||
## 提供自定義公共文件
|
||||
## 提供自訂公共文件
|
||||
|
||||
要使 Gitea 提供自定義公共文件（如頁面和圖像），請使用文件夾 `$GITEA_CUSTOM/public/` 作為 webroot。將遵循符號鏈接。
|
||||
要使 Gitea 提供自訂公共文件（如頁面和圖像），請使用文件夾 `$GITEA_CUSTOM/public/` 作為 webroot。將遵循符號鏈接。
|
||||
目前，僅提供以下文件：
|
||||
|
||||
- `public/robots.txt`
|
||||
- `public/.well-known/` 文件夾中的文件
|
||||
- `public/assets/` 文件夾中的文件
|
||||
|
||||
例如，存儲在 `$GITEA_CUSTOM/public/assets/` 中的文件 `image.png` 可以通過 url `http://gitea.domain.tld/assets/image.png` 訪問。
|
||||
例如，儲存在 `$GITEA_CUSTOM/public/assets/` 中的文件 `image.png` 可以透過 url `http://gitea.domain.tld/assets/image.png` 訪問。
|
||||
|
||||
## 更改徽標
|
||||
|
||||
要構建自定義徽標和/或圖標，克隆 Gitea 源代碼庫，替換 `assets/logo.svg` 和/或 `assets/favicon.svg`，然後運行 `make generate-images`。`assets/favicon.svg` 僅用於圖標。這將更新以下輸出文件，然後您可以將它們放置在服務器上的 `$GITEA_CUSTOM/public/assets/img` 中：
|
||||
要構建自訂徽標和/或圖標，克隆 Gitea 源程式碼庫，替換 `assets/logo.svg` 和/或 `assets/favicon.svg`，然後運行 `make generate-images`。`assets/favicon.svg` 僅用於圖標。這將更新以下輸出文件，然後您可以將它們放置在伺服器上的 `$GITEA_CUSTOM/public/assets/img` 中：
|
||||
|
||||
- `public/assets/img/logo.svg` - 用於站點圖標、應用程序圖標
|
||||
- `public/assets/img/logo.svg` - 用於站點圖標、應用程式圖標
|
||||
- `public/assets/img/logo.png` - 用於 Open Graph
|
||||
- `public/assets/img/avatar_default.png` - 用作默認頭像圖像
|
||||
- `public/assets/img/avatar_default.png` - 用作預設頭像圖像
|
||||
- `public/assets/img/apple-touch-icon.png` - 用於 iOS 設備的書籤
|
||||
- `public/assets/img/favicon.svg` - 用於圖標
|
||||
- `public/assets/img/favicon.png` - 用於不支持 SVG 圖標的瀏覽器
|
||||
- `public/assets/img/favicon.png` - 用於不支援 SVG 圖標的瀏覽器
|
||||
|
||||
如果源圖像不是矢量格式，您可以嘗試使用工具（如[這個](https://www.aconvert.com/image/png-to-svg/)）將光柵圖像轉換為矢量圖像。
|
||||
|
||||
## 自定義 Gitea 頁面和資源
|
||||
## 自訂 Gitea 頁面和資源
|
||||
|
||||
Gitea 的可執行文件包含運行所需的所有資源：模板、圖像、樣式表和翻譯。可以通過將替換文件放置在 `custom` 目錄中的匹配路徑中來覆蓋其中的任何資源。例如，要替換為 C++ 存儲庫提供的默認 `.gitignore`，我們需要替換 `options/gitignore/C++`。為此，必須將替換文件放置在 `$GITEA_CUSTOM/options/gitignore/C++` 中（請參閱本文檔頂部有關 `CustomPath` 目錄位置的說明）。
|
||||
Gitea 的可執行文件包含運行所需的所有資源：模板、圖像、樣式表和翻譯。可以透過將替換文件放置在 `custom` 目錄中的匹配路徑中來覆蓋其中的任何資源。例如，要替換為 C++ 儲存庫提供的預設 `.gitignore`，我們需要替換 `options/gitignore/C++`。為此，必須將替換文件放置在 `$GITEA_CUSTOM/options/gitignore/C++` 中（請參閱本文件頂部有關 `CustomPath` 目錄位置的說明）。
|
||||
|
||||
Gitea 的每個頁面都可以更改。動態內容是使用 [go 模板](https://pkg.go.dev/html/template) 生成的，可以通過將替換文件放置在 `$GITEA_CUSTOM/templates` 目錄下來修改。
|
||||
Gitea 的每個頁面都可以更改。動態內容是使用 [go 模板](https://pkg.go.dev/html/template) 生成的，可以透過將替換文件放置在 `$GITEA_CUSTOM/templates` 目錄下來修改。
|
||||
|
||||
要獲取任何嵌入文件（包括模板），可以使用 [`gitea embedded` 工具](../administration/cmd-embedded.md)。或者，它們可以在 Gitea 源代碼的 [`templates`](https://github.com/go-gitea/gitea/tree/main/templates) 目錄中找到（注意：示例鏈接來自 `main` 分支。確保使用與您使用的版本兼容的模板）。
|
||||
要獲取任何嵌入文件（包括模板），可以使用 [`gitea embedded` 工具](../administration/cmd-embedded.md)。或者，它們可以在 Gitea 源程式碼的 [`templates`](https://github.com/go-gitea/gitea/tree/main/templates) 目錄中找到（注意：範例鏈接來自 `main` 分支。確保使用與您使用的版本相容的模板）。
|
||||
|
||||
請注意，任何包含在 `{{` 和 `}}` 之間的語句都是 Gitea 的模板語法，應在完全理解這些組件之前不要觸摸。
|
||||
請注意，任何包含在 `{{` 和 `}}` 之間的語句都是 Gitea 的模板語法，應在完全理解這些元件之前不要觸摸。
|
||||
|
||||
### 自定義起始頁/首頁
|
||||
### 自訂起始頁/首頁
|
||||
|
||||
從 `templates` 為您的 Gitea 版本複製 [`home.tmpl`](https://github.com/go-gitea/gitea/blob/main/templates/home.tmpl) 到 `$GITEA_CUSTOM/templates`。
|
||||
根據需要進行編輯。
|
||||
@@ -67,7 +67,7 @@ Gitea 的每個頁面都可以更改。動態內容是使用 [go 模板](https:/
|
||||
|
||||
### 添加鏈接和標籤
|
||||
|
||||
如果您只想在頂部導航欄或頁腳中添加額外的鏈接，或在存儲庫視圖中添加額外的標籤，可以將它們放在 `extra_links.tmpl`（添加到導航欄的鏈接）、`extra_links_footer.tmpl`（添加到頁腳左側的鏈接）和 `extra_tabs.tmpl` 中，放置在您的 `$GITEA_CUSTOM/templates/custom/` 目錄中。
|
||||
如果您只想在頂部導航欄或頁腳中添加額外的鏈接，或在儲存庫視圖中添加額外的標籤，可以將它們放在 `extra_links.tmpl`（添加到導航欄的鏈接）、`extra_links_footer.tmpl`（添加到頁腳左側的鏈接）和 `extra_tabs.tmpl` 中，放置在您的 `$GITEA_CUSTOM/templates/custom/` 目錄中。
|
||||
|
||||
例如，假設您在德國，必須添加著名的法律要求的“Impressum”/關於頁面，列出誰對網站內容負責：
|
||||
只需將其放置在您的 "$GITEA_CUSTOM/public/assets/" 目錄下（例如 `$GITEA_CUSTOM/public/assets/impressum.html`），並將鏈接放置在 `$GITEA_CUSTOM/templates/custom/extra_links.tmpl` 或 `$GITEA_CUSTOM/templates/custom/extra_links_footer.tmpl` 中。
|
||||
@@ -75,17 +75,17 @@ Gitea 的每個頁面都可以更改。動態內容是使用 [go 模板](https:/
|
||||
為了匹配當前樣式，鏈接應具有類名“item”，您可以使用 `{{AppSubUrl}}` 獲取基本 URL：
|
||||
`<a class="item" href="{{AppSubUrl}}/assets/impressum.html">Impressum</a>`
|
||||
|
||||
有關更多信息，請參閱 [添加法律頁面](../administration/adding-legal-pages.md)。
|
||||
有關更多資訊，請參閱 [添加法律頁面](../administration/adding-legal-pages.md)。
|
||||
|
||||
您可以以相同的方式添加新標籤，將它們放在 `extra_tabs.tmpl` 中。
|
||||
匹配其他標籤樣式所需的確切 HTML 位於文件 `templates/repo/header.tmpl` 中
|
||||
（[GitHub 中的源代碼](https://github.com/go-gitea/gitea/blob/main/templates/repo/header.tmpl)）
|
||||
（[GitHub 中的源程式碼](https://github.com/go-gitea/gitea/blob/main/templates/repo/header.tmpl)）
|
||||
|
||||
### 頁面的其他添加
|
||||
|
||||
除了 `extra_links.tmpl` 和 `extra_tabs.tmpl`，還有其他有用的模板，您可以將它們放在 `$GITEA_CUSTOM/templates/custom/` 目錄中：
|
||||
|
||||
- `header.tmpl`，在 `<head>` 標籤結束之前，您可以添加自定義 CSS 文件。
|
||||
- `header.tmpl`，在 `<head>` 標籤結束之前，您可以添加自訂 CSS 文件。
|
||||
- `body_outer_pre.tmpl`，在 `<body>` 開始之後。
|
||||
- `body_inner_pre.tmpl`，在頂部導航欄之前，但已經在主容器 `<div class="full height">` 內。
|
||||
- `body_inner_post.tmpl`，在主容器結束之前。
|
||||
@@ -94,18 +94,18 @@ Gitea 的每個頁面都可以更改。動態內容是使用 [go 模板](https:/
|
||||
|
||||
### 使用 Gitea 變量
|
||||
|
||||
可以在自定義模板中使用各種 Gitea 變量。
|
||||
可以在自訂模板中使用各種 Gitea 變量。
|
||||
|
||||
首先，_臨時_ 啟用開發模式：在您的 `app.ini` 中將 `RUN_MODE = prod` 更改為 `RUN_MODE = dev`。然後將 `{{ $ | DumpVar }}` 添加到任何模板中，重啟 Gitea 並刷新該頁面；這將轉儲所有可用變量。
|
||||
|
||||
找到您需要的數據，並使用相應的變量；例如，如果您需要存儲庫的名稱，則可以使用 `{{.Repository.Name}}`。
|
||||
找到您需要的資料，並使用相應的變量；例如，如果您需要儲存庫的名稱，則可以使用 `{{.Repository.Name}}`。
|
||||
|
||||
如果您需要以某種方式轉換這些數據，並且不熟悉 Go，一個簡單的解決方法是將數據添加到 DOM 並添加一個小的 JavaScript 腳本塊來操作數據。
|
||||
如果您需要以某種方式轉換這些資料，並且不熟悉 Go，一個簡單的解決方法是將資料添加到 DOM 並添加一個小的 JavaScript 腳本塊來操作資料。
|
||||
|
||||
### 示例：PlantUML
|
||||
### 範例：PlantUML
|
||||
|
||||
您可以使用 PlantUML 服務器將 [PlantUML](https://plantuml.com/) 支持添加到 Gitea 的 markdown 中。
|
||||
數據被編碼並發送到 PlantUML 服務器，該服務器生成圖片。有一個在線演示服務器位於 http://www.plantuml.com/plantuml，但如果您（或您的用戶）有敏感數據，您可以設置自己的 [PlantUML 服務器](https://plantuml.com/server)。要設置 PlantUML 渲染，從 https://gitea.com/davidsvantesson/plantuml-code-highlight 複製 JavaScript 文件並將它們放在您的 `$GITEA_CUSTOM/public/assets/` 文件夾中。然後將以下內容添加到 `custom/footer.tmpl`：
|
||||
您可以使用 PlantUML 伺服器將 [PlantUML](https://plantuml.com/) 支援添加到 Gitea 的 markdown 中。
|
||||
資料被編碼並發送到 PlantUML 伺服器，該伺服器生成圖片。有一個在線演示伺服器位於 http://www.plantuml.com/plantuml，但如果您（或您的使用者）有敏感資料，您可以設定自己的 [PlantUML 伺服器](https://plantuml.com/server)。要設定 PlantUML 渲染，從 https://gitea.com/davidsvantesson/plantuml-code-highlight 複製 JavaScript 文件並將它們放在您的 `$GITEA_CUSTOM/public/assets/` 文件夾中。然後將以下內容添加到 `custom/footer.tmpl`：
|
||||
|
||||
```html
|
||||
<script>
|
||||
@@ -134,11 +134,11 @@ Alice -> Bob: Another authentication Request
|
||||
Alice <-- Bob: Another authentication Response
|
||||
```
|
||||
|
||||
該腳本將檢測帶有 `class="language-plantuml"` 的標籤，但您可以通過提供第二個參數給 `parsePlantumlCodeBlocks` 來更改此設置。
|
||||
該腳本將檢測帶有 `class="language-plantuml"` 的標籤，但您可以透過提供第二個參數給 `parsePlantumlCodeBlocks` 來更改此設定。
|
||||
|
||||
### 示例：STL 預覽
|
||||
### 範例：STL 預覽
|
||||
|
||||
您可以通過添加以下內容直接在 Gitea 中顯示 STL 文件：
|
||||
您可以透過添加以下內容直接在 Gitea 中顯示 STL 文件：
|
||||
|
||||
```html
|
||||
<script>
|
||||
@@ -232,21 +232,21 @@ $GITEA_CUSTOM/public/assets/
|
||||
|
||||
然後重啟 Gitea 並在您的 Gitea 實例上打開 STL 文件。
|
||||
|
||||
## 自定義 Gitea 郵件
|
||||
## 自訂 Gitea 郵件
|
||||
|
||||
`$GITEA_CUSTOM/templates/mail` 文件夾允許更改 Gitea 的每封郵件的正文。
|
||||
可以在 Gitea 源代碼的 [`templates/mail`](https://github.com/go-gitea/gitea/tree/main/templates/mail) 目錄中找到要覆蓋的模板。
|
||||
可以在 Gitea 源程式碼的 [`templates/mail`](https://github.com/go-gitea/gitea/tree/main/templates/mail) 目錄中找到要覆蓋的模板。
|
||||
通過在 `$GITEA_CUSTOM/templates/mail` 下製作文件副本來覆蓋，使用與源相匹配的完整路徑結構。
|
||||
|
||||
任何包含在 `{{` 和 `}}` 之間的語句都是 Gitea 的模板語法，應在完全理解這些組件之前不要觸摸。
|
||||
任何包含在 `{{` 和 `}}` 之間的語句都是 Gitea 的模板語法，應在完全理解這些元件之前不要觸摸。
|
||||
|
||||
## 向 Gitea 添加分析
|
||||
|
||||
可以向 Gitea 添加 Google Analytics、Matomo（以前稱為 Piwik）和其他分析服務。要添加跟踪代碼，請參閱本文檔的“頁面的其他添加”部分，並將 JavaScript 添加到 `$GITEA_CUSTOM/templates/custom/header.tmpl` 文件中。
|
||||
可以向 Gitea 添加 Google Analytics、Matomo（以前稱為 Piwik）和其他分析服務。要添加跟蹤程式碼，請參閱本文件的“頁面的其他添加”部分，並將 JavaScript 添加到 `$GITEA_CUSTOM/templates/custom/header.tmpl` 文件中。
|
||||
|
||||
## 自定義 gitignores、標籤、許可證、本地化和 readmes
|
||||
## 自訂 gitignores、標籤、許可證、本地化和 readmes
|
||||
|
||||
將自定義文件放置在 `custom/options` 下的相應子文件夾中。
|
||||
將自訂文件放置在 `custom/options` 下的相應子文件夾中。
|
||||
|
||||
:::note
|
||||
文件不應具有文件擴展名，例如 `Labels` 而不是 `Labels.txt`
|
||||
@@ -254,15 +254,15 @@ $GITEA_CUSTOM/public/assets/
|
||||
|
||||
### gitignores
|
||||
|
||||
要添加自定義 .gitignore，請將包含現有 [.gitignore 規則](https://git-scm.com/docs/gitignore) 的文件添加到 `$GITEA_CUSTOM/options/gitignore`
|
||||
要添加自訂 .gitignore，請將包含現有 [.gitignore 規則](https://git-scm.com/docs/gitignore) 的文件添加到 `$GITEA_CUSTOM/options/gitignore`
|
||||
|
||||
## 自定義 git 配置
|
||||
## 自訂 git 設定
|
||||
|
||||
從 Gitea 1.20 開始，您可以通過 `git.config` 部分自定義 git 配置。
|
||||
從 Gitea 1.20 開始，您可以透過 `git.config` 部分自訂 git 設定。
|
||||
|
||||
### 啟用簽名 git 推送
|
||||
|
||||
要啟用簽名 git 推送，請設置以下兩個選項：
|
||||
要啟用簽名 git 推送，請設定以下兩個選項：
|
||||
|
||||
```ini
|
||||
[git.config]
|
||||
@@ -270,7 +270,7 @@ receive.advertisePushOptions = true
|
||||
receive.certNonceSeed = <randomstring>
|
||||
```
|
||||
|
||||
`certNonceSeed` 應設置為隨機字符串並保持秘密。
|
||||
`certNonceSeed` 應設定為隨機字符串並保持祕密。
|
||||
|
||||
### 標籤
|
||||
|
||||
|
||||
+22
-22
@@ -6,20 +6,20 @@ aliases:
|
||||
- /zh-tw/email-setup
|
||||
---
|
||||
|
||||
# 電子郵件設置
|
||||
# 電子郵件設定
|
||||
|
||||
Gitea 具有發送交易電子郵件（如註冊確認）的郵件功能。它可以配置為使用 Sendmail（或兼容的 MTA，如 Postfix 和 msmtp）或直接使用 SMTP 服務器。
|
||||
Gitea 具有發送交易電子郵件（如註冊確認）的郵件功能。它可以設定為使用 Sendmail（或相容的 MTA，如 Postfix 和 msmtp）或直接使用 SMTP 伺服器。
|
||||
|
||||
## 使用 Sendmail
|
||||
|
||||
使用 `sendmail` 命令作為郵件程序。
|
||||
使用 `sendmail` 命令作為郵件程式。
|
||||
|
||||
:::note
|
||||
要在官方 Gitea Docker 映像中使用，請配置為 SMTP 版本（請參閱以下部分）。
|
||||
要在官方 Gitea Docker 映像中使用，請設定為 SMTP 版本（請參閱以下部分）。
|
||||
:::
|
||||
|
||||
:::note
|
||||
對於面向互聯網的網站，請參閱您的 MTA 文檔以獲取有關通過 TLS 發送電子郵件的說明。還設置 SPF、DMARC 和 DKIM DNS 記錄，以使發送的電子郵件被各種電子郵件提供商接受為合法。
|
||||
對於面向互聯網的網站，請參閱您的 MTA 文件以獲取有關通過 TLS 發送電子郵件的說明。還設定 SPF、DMARC 和 DKIM DNS 記錄，以使發送的電子郵件被各種電子郵件提供商接受為合法。
|
||||
:::
|
||||
|
||||
```ini title="app.ini"
|
||||
@@ -33,7 +33,7 @@ SENDMAIL_ARGS = "--" ; 大多數 "sendmail" 程序接受選項，"--" 將防止
|
||||
|
||||
## 使用 SMTP
|
||||
|
||||
直接使用 SMTP 服務器作為中繼。此選項適用於您不想在實例上設置 MTA，但您在電子郵件提供商處有帳戶的情況。
|
||||
直接使用 SMTP 伺服器作為中繼。此選項適用於您不想在實例上設定 MTA，但您在電子郵件提供商處有帳戶的情況。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
@@ -46,18 +46,18 @@ USER = [email protected]
|
||||
PASSWD = `password`
|
||||
```
|
||||
|
||||
重新啟動 Gitea 以使配置更改生效。
|
||||
重新啟動 Gitea 以使設定更改生效。
|
||||
|
||||
要發送測試電子郵件以驗證設置，請轉到 Gitea > 站點管理 > 配置 > 摘要 -> 郵件配置。
|
||||
要發送測試電子郵件以驗證設定，請轉到 Gitea > 站點管理 > 設定 > 摘要 -> 郵件設定。
|
||||
|
||||
有關完整的選項列表，請參閱 [配置備忘單](../administration/config-cheat-sheet.md)
|
||||
有關完整的選項列表，請參閱 [設定備忘單](../administration/config-cheat-sheet.md)
|
||||
|
||||
:::note
|
||||
僅當 SMTP 服務器通信使用 TLS 加密或 `HOST=localhost` 時，才支持身份驗證。TLS 加密可以通過：
|
||||
僅當 SMTP 伺服器通信使用 TLS 加密或 `HOST=localhost` 時，才支援身份驗證。TLS 加密可以透過：
|
||||
:::
|
||||
|
||||
- STARTTLS（也稱為機會性 TLS）通過端口 587。初始連接在明文上完成，但如果服務器支持，則升級為 TLS。
|
||||
- SMTPS 連接（SMTP over TLS）通過默認端口 465。從一開始就使用 TLS 連接到服務器。
|
||||
- STARTTLS（也稱為機會性 TLS）通過端口 587。初始連接在明文上完成，但如果伺服器支援，則升級為 TLS。
|
||||
- SMTPS 連接（SMTP over TLS）通過預設端口 465。從一開始就使用 TLS 連接到伺服器。
|
||||
- 使用 `PROTOCOL=smtps` 強制 SMTPS 連接。（這些都稱為隱式 TLS。）
|
||||
這是由於 Go 內部庫對 STRIPTLS 攻擊的保護。
|
||||
|
||||
@@ -65,7 +65,7 @@ PASSWD = `password`
|
||||
|
||||
### Gmail
|
||||
|
||||
以下配置應適用於 GMail 的 SMTP 服務器：
|
||||
以下設定應適用於 GMail 的 SMTP 伺服器：
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
@@ -79,25 +79,25 @@ PASSWD = `***`
|
||||
PROTOCOL = smtps
|
||||
```
|
||||
|
||||
請注意，您需要通過在 Google 帳戶上啟用 2FA 來創建和使用 [應用程序密碼](https://support.google.com/accounts/answer/185833?hl=en)。您將無法直接使用您的 Google 帳戶密碼。
|
||||
請注意，您需要通過在 Google 帳戶上啟用 2FA 來建立和使用 [應用程式密碼](https://support.google.com/accounts/answer/185833?hl=en)。您將無法直接使用您的 Google 帳戶密碼。
|
||||
|
||||
### ProtonMail
|
||||
|
||||
此功能目前僅適用於選定的 Proton for Business 客戶以及擁有自定義域地址的 Visionary 和 Family 計劃用戶。請參閱 [ProtonMail 的 SMTP 文檔](https://proton.me/support/smtp-submission) 以獲取更多信息。此限制可以通過使用 ProtonMail Bridge 應用程序來繞過。
|
||||
此功能目前僅適用於選定的 Proton for Business 客戶以及擁有自訂域地址的 Visionary 和 Family 計劃使用者。請參閱 [ProtonMail 的 SMTP 文件](https://proton.me/support/smtp-submission) 以獲取更多資訊。此限制可以透過使用 ProtonMail Bridge 應用程式來繞過。
|
||||
|
||||
請注意，使用 SMTP 發送的電子郵件不是 [端到端加密](https://proton.me/support/proton-mail-encryption-explained) 的。然而，它們仍然像 Proton Mail 收件箱中的其他電子郵件一樣存儲為零訪問加密。
|
||||
請注意，使用 SMTP 發送的電子郵件不是 [端到端加密](https://proton.me/support/proton-mail-encryption-explained) 的。然而，它們仍然像 Proton Mail 收件箱中的其他電子郵件一樣儲存為零訪問加密。
|
||||
|
||||
以下配置應適用於 ProtonMail 的 SMTP 服務器：
|
||||
以下設定應適用於 ProtonMail 的 SMTP 伺服器：
|
||||
|
||||
1. 在您的瀏覽器（或桌面應用程序）中，登錄到您的 Proton Mail 帳戶，然後選擇 **設置 → 所有設置 → Proton Mail → IMAP/SMTP → SMTP 令牌**。
|
||||
1. 在您的瀏覽器（或桌面應用程式）中，登入到您的 Proton Mail 帳戶，然後選擇 **設定 → 所有設定 → Proton Mail → IMAP/SMTP → SMTP 令牌**。
|
||||
2. 單擊 **生成令牌**。
|
||||
3. 輸入以下詳細信息以創建新的 SMTP 令牌：
|
||||
3. 輸入以下詳細資訊以建立新的 SMTP 令牌：
|
||||
- **令牌名稱**：選擇一個令牌名稱。這僅供您參考，不會影響令牌的功能。
|
||||
- **電子郵件地址**：選擇一個活動的自定義域地址與您的令牌配對。複製此電子郵件地址並將其用於 `app.ini` 中的 `FROM` 和 `USER` 配置。
|
||||
- **電子電子郵件地址**：選擇一個活動的自訂域地址與您的令牌配對。複製此電子電子郵件地址並將其用於 `app.ini` 中的 `FROM` 和 `USER` 設定。
|
||||
4. 單擊 **生成**。
|
||||
5. 輸入您的 Proton Mail 帳戶密碼。
|
||||
|
||||
您的 SMTP 用戶名和 SMTP 令牌（密碼）將生成。您現在可以將它們作為 `USER` 和 `PASSWD` 輸入到您的 `app.ini` 配置中。
|
||||
您的 SMTP 使用者名稱和 SMTP 令牌（密碼）將生成。您現在可以將它們作為 `USER` 和 `PASSWD` 輸入到您的 `app.ini` 設定中。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
@@ -112,4 +112,4 @@ PASSWD = `TOKEN`
|
||||
|
||||
關閉彈出窗口後，出於安全原因，您將無法再次看到此 SMTP 令牌（密碼）。如果需要旋轉密碼，您可以隨時生成更多令牌。
|
||||
|
||||
注意：您的 Proton Mail 登錄或郵箱密碼將無法與 SMTP 一起使用。
|
||||
注意：您的 Proton Mail 登入或郵箱密碼將無法與 SMTP 一起使用。
|
||||
+4
-4
@@ -11,7 +11,7 @@ aliases:
|
||||
Gitea 支援透過外部二進位檔案進行自訂檔案渲染（例如 Jupyter 筆記本、asciidoc 等），只需：
|
||||
|
||||
- 安裝外部二進位檔案
|
||||
- 在 `app.ini` 檔案中添加一些配置
|
||||
- 在 `app.ini` 檔案中添加一些設定
|
||||
- 重新啟動你的 Gitea 實例
|
||||
|
||||
這支援整個檔案的渲染。如果你想在 markdown 中渲染程式碼區塊，你需要使用 JavaScript。請參閱 [自訂 Gitea](../administration/customizing-gitea.md) 頁面上的一些範例。
|
||||
@@ -35,7 +35,7 @@ RUN pipx install jupyter docutils --include-deps --global
|
||||
# 添加任何其他你可能需要安裝的 Python 套件
|
||||
```
|
||||
|
||||
## `app.ini` 檔案配置
|
||||
## `app.ini` 檔案設定
|
||||
|
||||
在你的自訂 `app.ini` 中為每個外部渲染器添加一個 `[markup.XXXXX]` 部分：
|
||||
|
||||
@@ -84,9 +84,9 @@ RENDER_COMMAND = pandoc -f markdown -t html --katex
|
||||
|
||||
**注意**：如果規則定義在渲染器 ini 部分之上或名稱不匹配渲染器，則應用於每個渲染器。
|
||||
|
||||
一旦你的配置更改完成，重新啟動 Gitea 以使更改生效。
|
||||
一旦你的設定更改完成，重新啟動 Gitea 以使更改生效。
|
||||
|
||||
**注意**：在 Gitea 1.12 之前，有一個單一的 `markup.sanitiser` 部分，具有為多個規則重新定義的鍵，但這種配置方法存在重大問題，因此需要通過多個部分進行配置。
|
||||
**注意**：在 Gitea 1.12 之前，有一個單一的 `markup.sanitiser` 部分，具有為多個規則重新定義的鍵，但這種設定方法存在重大問題，因此需要通過多個部分進行設定。
|
||||
|
||||
### 範例：HTML
|
||||
|
||||
|
||||
+5
-5
@@ -78,7 +78,7 @@ bantime = 900
|
||||
action = iptables-allports
|
||||
```
|
||||
|
||||
如果你使用 Docker，你還需要新增一個 jail 來處理 **iptables** 中的 **FORWARD** 鏈。將其配置在 `/etc/fail2ban/jail.d/gitea-docker.local`：
|
||||
如果你使用 Docker，你還需要新增一個 jail 來處理 **iptables** 中的 **FORWARD** 鏈。將其設定在 `/etc/fail2ban/jail.d/gitea-docker.local`：
|
||||
|
||||
```ini
|
||||
[gitea-docker]
|
||||
@@ -91,17 +91,17 @@ bantime = 900
|
||||
action = iptables-allports[chain="FORWARD"]
|
||||
```
|
||||
|
||||
然後只需運行 `service fail2ban restart` 來應用你的更改。你可以使用 `service fail2ban status` 檢查 fail2ban 是否接受了你的配置。
|
||||
然後只需運行 `service fail2ban restart` 來應用你的更改。你可以使用 `service fail2ban status` 檢查 fail2ban 是否接受了你的設定。
|
||||
|
||||
務必閱讀 fail2ban 並根據你的需求進行配置，這會在一小時內認證失敗 10 次時，將某人從所有端口禁止 **15 分鐘**。
|
||||
務必閱讀 fail2ban 並根據你的需求進行設定，這會在一小時內認證失敗 10 次時，將某人從所有端口禁止 **15 分鐘**。
|
||||
|
||||
如果你在 Nginx 反向代理後運行 Gitea（例如使用 Docker），你需要在 Nginx 配置中添加這一行，這樣 IP 不會顯示為 127.0.0.1：
|
||||
如果你在 Nginx 反向代理後運行 Gitea（例如使用 Docker），你需要在 Nginx 設定中添加這一行，這樣 IP 不會顯示為 127.0.0.1：
|
||||
|
||||
```
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
```
|
||||
|
||||
`app.ini` 中的安全選項需要調整，以允許解釋標頭以及描述受信任代理伺服器的 IP 地址和網絡列表（更多信息請參見 [配置速查表](../administration/config-cheat-sheet.md#security-security)）。
|
||||
`app.ini` 中的安全選項需要調整，以允許解釋標頭以及描述受信任代理伺服器的 IP 地址和網路列表（更多資訊請參見 [設定速查表](../administration/config-cheat-sheet.md)）。
|
||||
|
||||
```
|
||||
REVERSE_PROXY_LIMIT = 1
|
||||
|
||||
+8
-8
@@ -6,9 +6,9 @@ aliases:
|
||||
- /zh-tw/git-lfs-setup
|
||||
---
|
||||
|
||||
# Git LFS 設置
|
||||
# Git LFS 設定
|
||||
|
||||
要使用 Gitea 的內置 LFS 支持，您必須更新 `app.ini` 文件：
|
||||
要使用 Gitea 的內置 LFS 支援，您必須更新 `app.ini` 文件：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
@@ -21,14 +21,14 @@ PATH = /home/gitea/data/lfs
|
||||
```
|
||||
|
||||
:::note
|
||||
LFS 服務器支持需要在服務器上安裝至少 Git v2.1.2
|
||||
LFS 伺服器支援需要在伺服器上安裝至少 Git v2.1.2
|
||||
:::
|
||||
|
||||
# Git LFS 純 SSH 協議
|
||||
|
||||
LFS 純 SSH 協議支持純粹通過 SSH 進行 LFS 連接
|
||||
（無需為 Gitea 服務器公開 HTTP 端點）。
|
||||
可以通過配置選項 `server.LFS_ALLOW_PURE_SSH` 啟用對它的支持：
|
||||
LFS 純 SSH 協議支援純粹通過 SSH 進行 LFS 連接
|
||||
（無需為 Gitea 伺服器公開 HTTP 端點）。
|
||||
可以透過設定選項 `server.LFS_ALLOW_PURE_SSH` 啟用對它的支援：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
@@ -36,7 +36,7 @@ LFS_ALLOW_PURE_SSH = true
|
||||
```
|
||||
|
||||
:::note
|
||||
由於 `git-lfs` 客戶端中存在一個未解決的錯誤，該選項目前默認設置為 false，該錯誤會導致 SSH 傳輸掛起：https://github.com/git-lfs/git-lfs/pull/5816
|
||||
可以通過在所有客戶端機器上設置 git 配置來解決此問題：
|
||||
由於 `git-lfs` 客戶端中存在一個未解決的錯誤，該選專案前預設設定為 false，該錯誤會導致 SSH 傳輸掛起：https://github.com/git-lfs/git-lfs/pull/5816
|
||||
可以透過在所有客戶端機器上設定 git 設定來解決此問題：
|
||||
`git config --global lfs.ssh.automultiplex false`
|
||||
:::
|
||||
+17
-17
@@ -6,16 +6,16 @@ aliases:
|
||||
- /zh-tw/https-setup
|
||||
---
|
||||
|
||||
# HTTPS 設置
|
||||
# HTTPS 設定
|
||||
|
||||
## 使用內置服務器
|
||||
## 使用內置伺服器
|
||||
|
||||
在啟用 HTTPS 之前，請確保您擁有有效的 SSL/TLS 證書。
|
||||
您可以使用自生成的證書進行評估和測試。請運行 `gitea cert --host [HOST]` 生成自簽名證書。
|
||||
|
||||
如果您在服務器上使用 Apache 或 nginx，建議查看 [反向代理指南](./reverse-proxies.md)。
|
||||
如果您在伺服器上使用 Apache 或 nginx，建議查看 [反向代理指南](./reverse-proxies.md)。
|
||||
|
||||
要使用 Gitea 的內置 HTTPS 支持，您必須更改 `app.ini` 文件：
|
||||
要使用 Gitea 的內置 HTTPS 支援，您必須更改 `app.ini` 文件：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
@@ -26,14 +26,14 @@ CERT_FILE = cert.pem
|
||||
KEY_FILE = key.pem
|
||||
```
|
||||
|
||||
請注意，如果您的證書是由第三方證書機構簽署的（即不是自簽名的），則 cert.pem 應包含證書鏈。服務器證書必須是 cert.pem 中的第一個條目，後面依次是中間證書（如果有）。根證書不必包含在內，因為連接的客戶端必須已經擁有它以建立信任關係。
|
||||
要了解更多有關配置值的信息，請查看 [配置備忘單](./config-cheat-sheet.md#server-server)。
|
||||
請注意，如果您的證書是由第三方證書機構簽署的（即不是自簽名的），則 cert.pem 應包含證書鏈。伺服器證書必須是 cert.pem 中的第一個條目，後面依次是中間證書（如果有）。根證書不必包含在內，因為連接的客戶端必須已經擁有它以建立信任關係。
|
||||
要了解更多有關設定值的資訊，請查看 [設定備忘單](./config-cheat-sheet.md)。
|
||||
|
||||
對於 `CERT_FILE` 或 `KEY_FILE` 字段，文件路徑在相對路徑時相對於 `GITEA_CUSTOM` 環境變量。它也可以是絕對路徑。
|
||||
對於 `CERT_FILE` 或 `KEY_FILE` 欄位，文件路徑在相對路徑時相對於 `GITEA_CUSTOM` 環境變量。它也可以是絕對路徑。
|
||||
|
||||
### 設置 HTTP 重定向
|
||||
### 設定 HTTP 重定向
|
||||
|
||||
Gitea 服務器只能監聽一個端口；要將 HTTP 請求重定向到 HTTPS 端口，您需要啟用 HTTP 重定向服務：
|
||||
Gitea 伺服器只能監聽一個端口；要將 HTTP 請求重定向到 HTTPS 端口，您需要啟用 HTTP 重定向服務：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
@@ -42,13 +42,13 @@ REDIRECT_OTHER_PORT = true
|
||||
PORT_TO_REDIRECT = 3080
|
||||
```
|
||||
|
||||
如果您使用 Docker，請確保在 `docker-compose.yml` 文件中配置了此端口。
|
||||
如果您使用 Docker，請確保在 `docker-compose.yml` 文件中設定了此端口。
|
||||
|
||||
## 使用 ACME（默認：Let's Encrypt）
|
||||
## 使用 ACME（預設：Let's Encrypt）
|
||||
|
||||
[ACME](https://tools.ietf.org/html/rfc8555) 是一個證書機構標準協議，允許您自動請求和更新 SSL/TLS 證書。[Let's Encrypt](https://letsencrypt.org/) 是一個使用此標準的免費公開信任的證書機構服務器。僅實現了 `HTTP-01` 和 `TLS-ALPN-01` 挑戰。為了使 ACME 挑戰通過並驗證您的域所有權，必須由 gitea 實例服務外部流量到端口 `80`（`HTTP-01`）或端口 `443`（`TLS-ALPN-01`）。設置 [HTTP 重定向](#setting-up-http-redirection) 和端口轉發可能需要正確路由外部流量。否則，正常流量到端口 `80` 將自動重定向到 HTTPS。**您必須同意** ACME 提供商的服務條款（默認為 Let's Encrypt 的 [服務條款](https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf)）。
|
||||
[ACME](https://tools.ietf.org/html/rfc8555) 是一個證書機構標準協議，允許您自動請求和更新 SSL/TLS 證書。[Let's Encrypt](https://letsencrypt.org/) 是一個使用此標準的免費公開信任的證書機構伺服器。僅實現了 `HTTP-01` 和 `TLS-ALPN-01` 挑戰。為了使 ACME 挑戰通過並驗證您的域所有權，必須由 gitea 實例服務外部流量到端口 `80`（`HTTP-01`）或端口 `443`（`TLS-ALPN-01`）。設定 [HTTP 重定向](#設定-http-重定向) 和端口轉發可能需要正確路由外部流量。否則，正常流量到端口 `80` 將自動重定向到 HTTPS。**您必須同意** ACME 提供商的服務條款（預設為 Let's Encrypt 的 [服務條款](https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf)）。
|
||||
|
||||
使用默認 Let's Encrypt 的最小設置：
|
||||
使用預設 Let's Encrypt 的最小設定：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
@@ -61,7 +61,7 @@ ACME_DIRECTORY=https
|
||||
ACME_EMAIL=[email protected]
|
||||
```
|
||||
|
||||
使用 [smallstep CA](https://github.com/smallstep/certificates) 的最小設置，請參閱 [他們的教程](https://smallstep.com/docs/tutorials/acme-challenge) 以獲取更多信息。
|
||||
使用 [smallstep CA](https://github.com/smallstep/certificates) 的最小設定，請參閱 [他們的教學](https://smallstep.com/docs/tutorials/acme-challenge) 以獲取更多資訊。
|
||||
|
||||
```ini
|
||||
[server]
|
||||
@@ -76,11 +76,11 @@ ACME_DIRECTORY=https
|
||||
ACME_EMAIL=[email protected]
|
||||
```
|
||||
|
||||
要了解更多有關配置值的信息，請查看 [配置備忘單](./config-cheat-sheet.md#server-server)。
|
||||
要了解更多有關設定值的資訊，請查看 [設定備忘單](./config-cheat-sheet.md)。
|
||||
|
||||
## 使用反向代理
|
||||
|
||||
按照 [反向代理指南](../administration/reverse-proxies.md) 設置您的反向代理。
|
||||
按照 [反向代理指南](../administration/reverse-proxies.md) 設定您的反向代理。
|
||||
|
||||
之後，按照以下指南之一啟用 HTTPS：
|
||||
|
||||
@@ -89,5 +89,5 @@ [email protected]
|
||||
- [caddy](https://caddyserver.com/docs/tls)
|
||||
|
||||
:::note
|
||||
僅在代理級別啟用 HTTPS 被稱為 [TLS 終止代理](https://en.wikipedia.org/wiki/TLS_termination_proxy)。代理服務器接受傳入的 TLS 連接，解密內容，並將現在未加密的內容傳遞給 Gitea。只要代理和 Gitea 實例位於同一台機器上，或者位於私有網絡內的不同機器上（代理暴露於外部網絡），這通常是可以的。如果您的 Gitea 實例與代理之間隔著公共網絡，或者您希望完全端到端加密，您也可以 [使用內置服務器直接在 Gitea 中啟用 HTTPS 支持](#using-the-built-in-server) 並通過 HTTPS 轉發連接。
|
||||
僅在代理級別啟用 HTTPS 被稱為 [TLS 終止代理](https://en.wikipedia.org/wiki/TLS_termination_proxy)。代理伺服器接受傳入的 TLS 連接，解密內容，並將現在未加密的內容傳遞給 Gitea。只要代理和 Gitea 實例位於同一臺機器上，或者位於私有網路內的不同機器上（代理暴露於外部網路），這通常是可以的。如果您的 Gitea 實例與代理之間隔著公共網路，或者您希望完全端到端加密，您也可以 [使用內置伺服器直接在 Gitea 中啟用 HTTPS 支援](#使用內置伺服器) 並通過 HTTPS 轉發連接。
|
||||
:::
|
||||
+61
-61
@@ -6,44 +6,44 @@ aliases:
|
||||
- /zh-tw/logging-configuration
|
||||
---
|
||||
|
||||
# 日誌配置
|
||||
# 日誌設定
|
||||
|
||||
Gitea 的日誌配置主要包括 3 種組件：
|
||||
Gitea 的日誌設定主要包括 3 種元件：
|
||||
|
||||
- `[log]` 部分用於一般配置
|
||||
- `[log.<mode-name>]` 部分用於配置不同的日誌寫入器以輸出日誌，即：“寫入模式”，模式名稱也用作“寫入器名稱”。
|
||||
- `[log]` 部分還可以包含子日誌記錄器配置，遵循鍵模式 `logger.<logger-name>.<CONFIG-KEY>`
|
||||
- `[log]` 部分用於一般設定
|
||||
- `[log.<mode-name>]` 部分用於設定不同的日誌寫入器以輸出日誌，即：“寫入模式”，模式名稱也用作“寫入器名稱”。
|
||||
- `[log]` 部分還可以包含子日誌記錄器設定，遵循鍵模式 `logger.<logger-name>.<CONFIG-KEY>`
|
||||
|
||||
默認情況下有一個功能齊全的日誌輸出，因此不需要定義一個。
|
||||
預設情況下有一個功能齊全的日誌輸出，因此不需要定義一個。
|
||||
|
||||
## 收集日誌以獲取幫助
|
||||
|
||||
要收集日誌以獲取幫助和問題報告，請參閱 [支持選項](help/support.md)。
|
||||
要收集日誌以獲取幫助和問題報告，請參閱 [支援選項](help/support.md)。
|
||||
|
||||
## `[log]` 部分
|
||||
|
||||
Gitea 中的日誌設施配置發生在 `[log]` 部分及其子部分中。
|
||||
Gitea 中的日誌設施設定發生在 `[log]` 部分及其子部分中。
|
||||
|
||||
在頂級 `[log]` 部分中可以放置以下配置：
|
||||
在頂級 `[log]` 部分中可以放置以下設定：
|
||||
|
||||
- `ROOT_PATH`：（默認：**%(GITEA_WORK_DIR)/log**）：日誌文件的基本路徑
|
||||
- `MODE`：（默認：**console**）用於默認日誌記錄器的日誌輸出列表。
|
||||
- `LEVEL`：（默認：**Info**）最不嚴重的日誌事件以持久化，大小寫不敏感。可能的值是：`Trace`、`Debug`、`Info`、`Warn`、`Error`、`Fatal`。
|
||||
- `STACKTRACE_LEVEL`：（默認：**None**）對於此級別及更嚴重的事件，將在記錄時打印堆棧跟蹤。
|
||||
- `ROOT_PATH`：（預設：**%(GITEA_WORK_DIR)/log**）：日誌文件的基本路徑
|
||||
- `MODE`：（預設：**console**）用於預設日誌記錄器的日誌輸出列表。
|
||||
- `LEVEL`：（預設：**Info**）最不嚴重的日誌事件以持久化，大小寫不敏感。可能的值是：`Trace`、`Debug`、`Info`、`Warn`、`Error`、`Fatal`。
|
||||
- `STACKTRACE_LEVEL`：（預設：**None**）對於此級別及更嚴重的事件，將在記錄時打印堆棧跟蹤。
|
||||
|
||||
它可以包含以下子日誌記錄器：
|
||||
|
||||
- `logger.router.MODE`：（默認：**,**）：用於路由器日誌記錄器的日誌輸出列表。
|
||||
- `logger.access.MODE`：（默認：**_empty_**）用於訪問日誌記錄器的日誌輸出列表。默認情況下，訪問日誌記錄器被禁用。
|
||||
- `logger.xorm.MODE`：（默認：**,**）用於 XORM 日誌記錄器的日誌輸出列表。
|
||||
- `logger.router.MODE`：（預設：**,**）：用於路由器日誌記錄器的日誌輸出列表。
|
||||
- `logger.access.MODE`：（預設：**_empty_**）用於訪問日誌記錄器的日誌輸出列表。預設情況下，訪問日誌記錄器被禁用。
|
||||
- `logger.xorm.MODE`：（預設：**,**）用於 XORM 日誌記錄器的日誌輸出列表。
|
||||
|
||||
將逗號（`,`）設置為子日誌記錄器的模式意味著使其使用默認的全局 `MODE`。
|
||||
將逗號（`,`）設定為子日誌記錄器的模式意味著使其使用預設的全域 `MODE`。
|
||||
|
||||
## 快速示例
|
||||
## 快速範例
|
||||
|
||||
### 默認（空）配置
|
||||
### 預設（空）設定
|
||||
|
||||
空配置等同於默認：
|
||||
空設定等同於預設：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
@@ -63,9 +63,9 @@ PREFIX =
|
||||
COLORIZE = true
|
||||
```
|
||||
|
||||
這等同於將所有日誌發送到控制台，默認的 Golang 日誌也發送到控制台日誌。
|
||||
這等同於將所有日誌發送到控制檯，預設的 Golang 日誌也發送到控制檯日誌。
|
||||
|
||||
這只是示例，這是默認值，不需要將其寫入配置文件中。
|
||||
這只是範例，這是預設值，不需要將其寫入設定文件中。
|
||||
|
||||
### 禁用路由器日誌並將一些訪問日誌記錄到文件中
|
||||
|
||||
@@ -82,9 +82,9 @@ LEVEL = Warn
|
||||
FILE_NAME = access.log
|
||||
```
|
||||
|
||||
### 為不同模式設置不同的日誌級別
|
||||
### 為不同模式設定不同的日誌級別
|
||||
|
||||
默認日誌（>=Warn）進入 `gitea.log`，而錯誤日誌進入 `file-error.log`：
|
||||
預設日誌（>=Warn）進入 `gitea.log`，而錯誤日誌進入 `file-error.log`：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
@@ -106,18 +106,18 @@ FILE_NAME = file-error.log
|
||||
|
||||
Gitea 提供以下日誌輸出寫入器：
|
||||
|
||||
- `console` - 日誌記錄到 `stdout`（或如果在配置中設置，則記錄到 `stderr`）
|
||||
- `console` - 日誌記錄到 `stdout`（或如果在設定中設定，則記錄到 `stderr`）
|
||||
- `file` - 日誌記錄到文件
|
||||
- `conn` - 日誌記錄到套接字（網絡或 unix）
|
||||
- `conn` - 日誌記錄到套接字（網路或 unix）
|
||||
|
||||
### 通用配置
|
||||
### 通用設定
|
||||
|
||||
某些配置對所有日誌輸出模式都是通用的：
|
||||
某些設定對所有日誌輸出模式都是通用的：
|
||||
|
||||
- `MODE` 是日誌輸出寫入器的模式。它將默認為 ini 部分中的模式名稱。因此 `[log.console]` 將默認為 `MODE = console`。
|
||||
- `MODE` 是日誌輸出寫入器的模式。它將預設為 ini 部分中的模式名稱。因此 `[log.console]` 將預設為 `MODE = console`。
|
||||
- `LEVEL` 是此輸出的最低級別。
|
||||
- `STACKTRACE_LEVEL` 是此輸出將打印堆棧跟蹤的最低級別。
|
||||
- `COLORIZE` 將默認為 `true`，如描述的那樣，否則將默認為 `false`。
|
||||
- `COLORIZE` 將預設為 `true`，如描述的那樣，否則將預設為 `false`。
|
||||
|
||||
#### `EXPRESSION`
|
||||
|
||||
@@ -129,9 +129,9 @@ Gitea 提供以下日誌輸出寫入器：
|
||||
|
||||
#### `FLAGS`
|
||||
|
||||
`FLAGS` 代表在每條消息之前打印的前置日誌上下文信息。它是一個逗號分隔的字符串集。值的順序無關緊要。
|
||||
`FLAGS` 代表在每條消息之前打印的前置日誌上下文資訊。它是一個逗號分隔的字符串集。值的順序無關緊要。
|
||||
|
||||
默認為 `stdflags`（= `date,time,medfile,shortfuncname,levelinitial`）
|
||||
預設為 `stdflags`（= `date,time,medfile,shortfuncname,levelinitial`）
|
||||
|
||||
可能的值是：
|
||||
|
||||
@@ -143,20 +143,20 @@ Gitea 提供以下日誌輸出寫入器：
|
||||
- `shortfile` - 最後的文件名元素和行號：`d.go:23`。
|
||||
- `funcname` - 調用者的函數名稱：`runtime.Caller()`。
|
||||
- `shortfuncname` - 函數名稱的最後部分。覆蓋 `funcname`。
|
||||
- `utc` - 如果設置了日期或時間，則使用 UTC 而不是當地時區。
|
||||
- `levelinitial` - 括號中的提供級別的首字母，例如 `[I]` 表示信息。
|
||||
- `utc` - 如果設定了日期或時間，則使用 UTC 而不是當地時區。
|
||||
- `levelinitial` - 括號中的提供級別的首字母，例如 `[I]` 表示資訊。
|
||||
- `level` - 括號中的級別 `[INFO]`。
|
||||
- `gopid` - 上下文的 Goroutine-PID。
|
||||
- `medfile` - 文件名的最後 20 個字符 - 相當於 `shortfile,longfile`。
|
||||
- `stdflags` - 相當於 `date,time,medfile,shortfuncname,levelinitial`。
|
||||
|
||||
### 控制台模式
|
||||
### 控制檯模式
|
||||
|
||||
在此模式下，日誌記錄器將轉發日誌消息到附加到 Gitea 進程的 stdout 和 stderr 流。
|
||||
|
||||
對於控制台模式的日誌記錄器，如果不是在 Windows 上，或者 Windows 終端可以設置為 ANSI 模式或是 cygwin 或 Msys 管道，則 `COLORIZE` 將默認為 `true`。
|
||||
對於控制檯模式的日誌記錄器，如果不是在 Windows 上，或者 Windows 終端可以設定為 ANSI 模式或是 cygwin 或 Msys 管道，則 `COLORIZE` 將預設為 `true`。
|
||||
|
||||
設置：
|
||||
設定：
|
||||
|
||||
- `STDERR`：**false**：日誌記錄器是否應打印到 `stderr` 而不是 `stdout`。
|
||||
|
||||
@@ -164,15 +164,15 @@ Gitea 提供以下日誌輸出寫入器：
|
||||
|
||||
在此模式下，日誌記錄器將日誌消息保存到文件中。
|
||||
|
||||
設置：
|
||||
設定：
|
||||
|
||||
- `FILE_NAME`：寫入日誌事件的文件，相對於 `ROOT_PATH`，默認為 `%(ROOT_PATH)/gitea.log`。例外：訪問日誌將默認為 `%(ROOT_PATH)/access.log`。
|
||||
- `MAX_SIZE_SHIFT`：**28**：單個文件的最大大小移位。28 代表 256Mb。詳細信息請參見下文。
|
||||
- `FILE_NAME`：寫入日誌事件的文件，相對於 `ROOT_PATH`，預設為 `%(ROOT_PATH)/gitea.log`。例外：訪問日誌將預設為 `%(ROOT_PATH)/access.log`。
|
||||
- `MAX_SIZE_SHIFT`：**28**：單個文件的最大大小移位。28 代表 256Mb。詳細資訊請參見下文。
|
||||
- `LOG_ROTATE` **true**：是否旋轉日誌文件。TODO：如果為 false，是否會在每日旋轉時刪除，還是什麼都不做？。
|
||||
- `DAILY_ROTATE`：**true**：是否每天旋轉日誌。
|
||||
- `MAX_DAYS`：**7**：在此天數後刪除旋轉的日誌文件。
|
||||
- `COMPRESS`：**true**：是否默認使用 gzip 壓縮舊日誌文件。
|
||||
- `COMPRESSION_LEVEL`：**-1**：壓縮級別。詳細信息請參見下文。
|
||||
- `COMPRESS`：**true**：是否預設使用 gzip 壓縮舊日誌文件。
|
||||
- `COMPRESSION_LEVEL`：**-1**：壓縮級別。詳細資訊請參見下文。
|
||||
|
||||
`MAX_SIZE_SHIFT` 定義了文件的最大大小，通過左移 1 給定的次數（`1 << x`）。
|
||||
v1.17.3 時的確切行為可以在 [這裡](https://github.com/go-gitea/gitea/blob/v1.17.3/modules/setting/log.go#L185) 看到。
|
||||
@@ -182,18 +182,18 @@ v1.17.3 時的確切行為可以在 [這裡](https://github.com/go-gitea/gitea/b
|
||||
|
||||
### 連接模式
|
||||
|
||||
在此模式下，日誌記錄器將通過網絡套接字發送日誌消息。
|
||||
在此模式下，日誌記錄器將通過網路套接字發送日誌消息。
|
||||
|
||||
設置：
|
||||
設定：
|
||||
|
||||
- `ADDR`：**:7020**：設置要連接的地址。
|
||||
- `PROTOCOL`：**tcp**：設置協議，可以是“tcp”、“unix”或“udp”。
|
||||
- `ADDR`：**:7020**：設定要連接的地址。
|
||||
- `PROTOCOL`：**tcp**：設定協議，可以是“tcp”、“unix”或“udp”。
|
||||
- `RECONNECT`：**false**：連接丟失時嘗試重新連接。
|
||||
- `RECONNECT_ON_MSG`：**false**：為每條消息重新連接主機。
|
||||
|
||||
### “路由器”日誌記錄器
|
||||
|
||||
當 Gitea 的路由處理程序工作時，路由器日誌記錄器記錄以下消息類型：
|
||||
當 Gitea 的路由處理程式工作時，路由器日誌記錄器記錄以下消息類型：
|
||||
|
||||
- `started` 消息將在 TRACE 級別記錄
|
||||
- `polling`/`completed` 路由將在 INFO 級別記錄。例外：“/assets” 靜態資源請求也在 TRACE 級別記錄。
|
||||
@@ -202,21 +202,21 @@ v1.17.3 時的確切行為可以在 [這裡](https://github.com/go-gitea/gitea/b
|
||||
|
||||
### “XORM”日誌記錄器
|
||||
|
||||
要使 XORM 輸出 SQL 日誌，應在 `[database]` 部分中將 `LOG_SQL` 設置為 `true`。
|
||||
要使 XORM 輸出 SQL 日誌，應在 `[database]` 部分中將 `LOG_SQL` 設定為 `true`。
|
||||
|
||||
### “訪問”日誌記錄器
|
||||
|
||||
訪問日誌記錄器是 Gitea 1.9 以來的新日誌記錄器。它提供了符合 NCSA 通用日誌格式的日誌格式。它高度可配置，但更改其模板時應謹慎。此日誌記錄器的主要好處是 Gitea 現在可以以標準日誌格式記錄訪問，因此可以使用標準工具。
|
||||
訪問日誌記錄器是 Gitea 1.9 以來的新日誌記錄器。它提供了符合 NCSA 通用日誌格式的日誌格式。它高度可設定，但更改其模板時應謹慎。此日誌記錄器的主要好處是 Gitea 現在可以以標準日誌格式記錄訪問，因此可以使用標準工具。
|
||||
|
||||
您可以使用 `logger.access.MODE = ...` 啟用此日誌記錄器。
|
||||
|
||||
如果需要，可以通過更改 `ACCESS_LOG_TEMPLATE` 的值來更改訪問日誌記錄器的格式。
|
||||
如果需要，可以透過更改 `ACCESS_LOG_TEMPLATE` 的值來更改訪問日誌記錄器的格式。
|
||||
|
||||
請注意，訪問日誌記錄器將在 `INFO` 級別記錄，將此日誌記錄器的 `LEVEL` 設置為 `WARN` 或更高將導致沒有訪問日誌。
|
||||
請注意，訪問日誌記錄器將在 `INFO` 級別記錄，將此日誌記錄器的 `LEVEL` 設定為 `WARN` 或更高將導致沒有訪問日誌。
|
||||
|
||||
#### ACCESS_LOG_TEMPLATE
|
||||
|
||||
此值代表一個 go 模板。其默認值為
|
||||
此值代表一個 go 模板。其預設值為
|
||||
|
||||
```tmpl
|
||||
{{.Ctx.RemoteHost}} - {{.Identity}} {{.Start.Format "[02/Jan/2006:15:04:05 -0700]" }} "{{.Ctx.Req.Method}} {{.Ctx.Req.URL.RequestURI}} {{.Ctx.Req.Proto}}" {{.ResponseWriter.Status}} {{.ResponseWriter.Size}} "{{.Ctx.Req.Referer}}" "{{.Ctx.Req.UserAgent}}"`
|
||||
@@ -225,7 +225,7 @@ v1.17.3 時的確切行為可以在 [這裡](https://github.com/go-gitea/gitea/b
|
||||
模板傳遞以下選項：
|
||||
|
||||
- `Ctx` 是 `context.Context`
|
||||
- `Identity` 是 `SignedUserName` 或 `"-"` 如果用戶未登錄
|
||||
- `Identity` 是 `SignedUserName` 或 `"-"` 如果使用者未登入
|
||||
- `Start` 是請求的開始時間
|
||||
- `ResponseWriter` 是 `http.ResponseWriter`
|
||||
|
||||
@@ -234,9 +234,9 @@ v1.17.3 時的確切行為可以在 [這裡](https://github.com/go-gitea/gitea/b
|
||||
## 釋放和重新打開、暫停和恢復日誌記錄
|
||||
|
||||
如果您在 Unix 上運行，您可能希望釋放和重新打開日誌以使用 `logrotate` 或其他工具。
|
||||
可以通過向運行的進程發送 `SIGUSR1`，或運行 `gitea manager logging release-and-reopen` 強制 Gitea 釋放並重新打開其日誌文件和連接。
|
||||
可以透過向運行的進程發送 `SIGUSR1`，或運行 `gitea manager logging release-and-reopen` 強制 Gitea 釋放並重新打開其日誌文件和連接。
|
||||
|
||||
或者，您可能希望暫停和恢復日誌記錄 - 這可以通過使用 `gitea manager logging pause` 和 `gitea manager logging resume` 命令來完成。請注意，暫停日誌記錄時，INFO 級別以下的日誌事件將不會存儲，僅存儲有限數量的事件。日誌記錄可能會暫時阻塞，暫停時會顯著減慢 Gitea 的速度 - 因此建議僅在非常短的時間內暫停。
|
||||
或者，您可能希望暫停和恢復日誌記錄 - 這可以透過使用 `gitea manager logging pause` 和 `gitea manager logging resume` 命令來完成。請注意，暫停日誌記錄時，INFO 級別以下的日誌事件將不會儲存，僅儲存有限數量的事件。日誌記錄可能會暫時阻塞，暫停時會顯著減慢 Gitea 的速度 - 因此建議僅在非常短的時間內暫停。
|
||||
|
||||
## 在 Gitea 運行時添加和刪除日誌記錄
|
||||
|
||||
@@ -247,17 +247,17 @@ v1.17.3 時的確切行為可以在 [這裡](https://github.com/go-gitea/gitea/b
|
||||
|
||||
## 使用 `logrotate` 而不是內置日誌輪換
|
||||
|
||||
Gitea 包含內置日誌輪換，這應該足以滿足大多數部署需求。但是，如果您希望使用 `logrotate` 實用程序：
|
||||
Gitea 包含內置日誌輪換，這應該足以滿足大多數部署需求。但是，如果您希望使用 `logrotate` 實用程式：
|
||||
|
||||
- 通過在 `app.ini` 中將 `LOG_ROTATE` 設置為 `false` 禁用內置日誌輪換。
|
||||
- 通過在 `app.ini` 中將 `LOG_ROTATE` 設定為 `false` 禁用內置日誌輪換。
|
||||
- 安裝 `logrotate`。
|
||||
- 配置 `logrotate` 以匹配您的部署要求，請參閱 `man 8 logrotate` 以了解配置語法詳細信息。
|
||||
- 設定 `logrotate` 以匹配您的部署要求，請參閱 `man 8 logrotate` 以瞭解設定語法詳細資訊。
|
||||
在 `postrotate/endscript` 塊中，通過 `kill -USR1` 或 `kill -10` 向 `gitea` 進程本身發送 `USR1` 信號，或運行 `gitea manager logging release-and-reopen`（使用適當的環境）。
|
||||
確保您的配置適用於 Gitea 日誌記錄器發出的所有文件，如上述部分所述。
|
||||
- 始終使用 `logrotate /etc/logrotate.conf --debug` 測試您的配置。
|
||||
確保您的設定適用於 Gitea 日誌記錄器發出的所有文件，如上述部分所述。
|
||||
- 始終使用 `logrotate /etc/logrotate.conf --debug` 測試您的設定。
|
||||
- 如果您使用 docker 並從容器外部運行，您可以使用
|
||||
`docker exec -u $OS_USER $CONTAINER_NAME sh -c 'gitea manager logging release-and-reopen'`
|
||||
或 `docker exec $CONTAINER_NAME sh -c '/bin/s6-svc -1 /etc/s6/gitea/'` 或直接向 Gitea 進程本身發送 `USR1`。
|
||||
|
||||
下一個 `logrotate` 任務將包括您的配置，因此不需要重新啟動。
|
||||
下一個 `logrotate` 任務將包括您的設定，因此不需要重新啟動。
|
||||
您也可以使用 `logrotate /etc/logrotate.conf --force` 立即重新加載 `logrotate`。
|
||||
+33
-33
@@ -8,26 +8,26 @@ aliases:
|
||||
|
||||
# 郵件模板
|
||||
|
||||
為了製作某些操作的電子郵件主題和內容，Gitea 可以使用模板進行自定義。這些功能的模板位於 [`custom` 目錄](../administration/customizing-gitea.md)下。
|
||||
Gitea 有一個內部模板，作為默認值，如果沒有自定義替代品。
|
||||
為了製作某些操作的電子郵件主題和內容，Gitea 可以使用模板進行自訂。這些功能的模板位於 [`custom` 目錄](../administration/customizing-gitea.md)下。
|
||||
Gitea 有一個內部模板，作為預設值，如果沒有自訂替代品。
|
||||
|
||||
自定義模板在 Gitea 啟動時加載。對它們的更改在 Gitea 再次重啟之前不會被識別。
|
||||
自訂模板在 Gitea 啟動時加載。對它們的更改在 Gitea 再次重啟之前不會被識別。
|
||||
|
||||
## 支持模板的郵件通知
|
||||
## 支援模板的郵件通知
|
||||
|
||||
目前，以下通知事件使用模板：
|
||||
|
||||
| 操作名稱 | 用途 |
|
||||
| ---------- | ---------------------------------------------------------- |
|
||||
| `new` | 創建了一個新問題或拉取請求。 |
|
||||
| `comment` | 在現有問題或拉取請求中創建了一個新評論。 |
|
||||
| `new` | 建立了一個新問題或拉取請求。 |
|
||||
| `comment` | 在現有問題或拉取請求中建立了一個新評論。 |
|
||||
| `close` | 關閉了一個問題或拉取請求。 |
|
||||
| `reopen` | 重新打開了一個問題或拉取請求。 |
|
||||
| `review` | 拉取請求中的審查的主要評論。 |
|
||||
| `approve` | 拉取請求的批准審查的主要評論。 |
|
||||
| `reject` | 拉取請求的變更請求審查的主要評論。 |
|
||||
| `code` | 拉取請求中的代碼單一評論。 |
|
||||
| `assigned` | 用戶被分配到一個問題或拉取請求。 |
|
||||
| `code` | 拉取請求中的程式碼單一評論。 |
|
||||
| `assigned` | 使用者被分配到一個問題或拉取請求。 |
|
||||
| `default` | 任何不包括在上述類別中的操作，或當對應的類別模板不存在時。 |
|
||||
|
||||
特定消息類型的模板路徑為：
|
||||
@@ -44,14 +44,14 @@ custom/templates/mail/{action type}/{action name}.tmpl
|
||||
custom/templates/mail/pull/comment.tmpl
|
||||
```
|
||||
|
||||
但是，不需要為每個操作類型/名稱組合創建模板。
|
||||
但是，不需要為每個操作類型/名稱組合建立模板。
|
||||
使用回退系統來選擇事件的適當模板。使用此列表中的 _第一個存在的_ 模板：
|
||||
|
||||
- 所需 **操作類型** 和 **操作名稱** 的特定模板。
|
||||
- 操作類型 `issue` 和所需 **操作名稱** 的模板。
|
||||
- 操作類型 `issue` 和操作名稱 `default` 的模板。
|
||||
|
||||
唯一必需的模板是操作類型 `issue` 和操作名稱 `default`，它已嵌入 Gitea 中，除非用戶在 `custom` 目錄中覆蓋它。
|
||||
唯一必需的模板是操作類型 `issue` 和操作名稱 `default`，它已嵌入 Gitea 中，除非使用者在 `custom` 目錄中覆蓋它。
|
||||
|
||||
## 模板語法
|
||||
|
||||
@@ -72,32 +72,32 @@ custom/templates/mail/pull/comment.tmpl
|
||||
指定 _主題_ 部分是可選的（因此也是破折號分隔符）。使用時，_主題_ 和 _郵件正文_ 模板之間的分隔符需要至少三個破折號；分隔符行中不允許其他字符。
|
||||
|
||||
_主題_ 和 _郵件正文_ 由 [Golang 的模板引擎](https://go.dev/pkg/text/template/) 解析，
|
||||
並為每個通知提供一個 _元數據上下文_。上下文包含以下元素：
|
||||
並為每個通知提供一個 _元資料上下文_。上下文包含以下元素：
|
||||
|
||||
| 名稱 | 類型 | 可用性 | 用途 |
|
||||
| ------------------ | ---------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `.FallbackSubject` | string | 總是 | 默認主題行。見下文。 |
|
||||
| `.FallbackSubject` | string | 總是 | 預設主題行。見下文。 |
|
||||
| `.Subject` | string | 僅在正文中 | 解析後的 _主題_。 |
|
||||
| `.Body` | string | 總是 | 問題、拉取請求或評論的消息，從 Markdown 解析為 HTML 並進行了清理。不要與 _郵件正文_ 混淆。 |
|
||||
| `.Link` | string | 總是 | 發起問題、拉取請求或評論的地址。 |
|
||||
| `.Issue` | models.Issue | 總是 | 發起通知的問題（或拉取請求）。要獲取特定於拉取請求的數據（例如 `HasMerged`），可以使用 `.Issue.PullRequest`，但應注意，如果問題不是拉取請求，則此字段將為 `nil`。 |
|
||||
| `.Comment` | models.Comment | 如果適用 | 如果通知來自添加到問題或拉取請求的評論，這將包含有關評論的信息。 |
|
||||
| `.Issue` | models.Issue | 總是 | 發起通知的問題（或拉取請求）。要獲取特定於拉取請求的資料（例如 `HasMerged`），可以使用 `.Issue.PullRequest`，但應注意，如果問題不是拉取請求，則此欄位將為 `nil`。 |
|
||||
| `.Comment` | models.Comment | 如果適用 | 如果通知來自添加到問題或拉取請求的評論，這將包含有關評論的資訊。 |
|
||||
| `.IsPull` | bool | 總是 | 如果郵件通知與拉取請求相關聯（即 `.Issue.PullRequest` 不是 `nil`），則為 `true`。 |
|
||||
| `.Repo` | string | 總是 | 包括所有者名稱的存儲庫名稱（例如 `mike/stuff`） |
|
||||
| `.User` | models.User | 總是 | 發起事件的存儲庫所有者。要獲取用戶名（例如 `mike`），可以使用 `.User.Name`。 |
|
||||
| `.Doer` | models.User | 總是 | 觸發通知事件的操作用戶。要獲取用戶名（例如 `rhonda`），可以使用 `.Doer.Name`。 |
|
||||
| `.IsMention` | bool | 總是 | 如果此通知僅因為用戶在評論中被提及而生成，而不是訂閱了源，則為 `true`。如果收件人訂閱了問題或存儲庫，則為 `false`。 |
|
||||
| `.SubjectPrefix` | string | 總是 | 如果通知不是關於創建問題或拉取請求，則為 `Re: `；否則為空字符串。 |
|
||||
| `.Repo` | string | 總是 | 包括所有者名稱的儲存庫名稱（例如 `mike/stuff`） |
|
||||
| `.User` | models.User | 總是 | 發起事件的儲存庫所有者。要獲取使用者名稱（例如 `mike`），可以使用 `.User.Name`。 |
|
||||
| `.Doer` | models.User | 總是 | 觸發通知事件的操作使用者。要獲取使用者名稱（例如 `rhonda`），可以使用 `.Doer.Name`。 |
|
||||
| `.IsMention` | bool | 總是 | 如果此通知僅因為使用者在評論中被提及而生成，而不是訂閱了源，則為 `true`。如果收件人訂閱了問題或儲存庫，則為 `false`。 |
|
||||
| `.SubjectPrefix` | string | 總是 | 如果通知不是關於建立問題或拉取請求，則為 `Re: `；否則為空字符串。 |
|
||||
| `.ActionType` | string | 總是 | `"issue"` 或 `"pull"`。將對應於實際的 _操作類型_，無論選擇了哪個模板。 |
|
||||
| `.ActionName` | string | 總是 | 它將是上述操作類型之一（`new`、`comment` 等），並將對應於實際的 _操作名稱_，無論選擇了哪個模板。 |
|
||||
| `.ReviewComments` | []models.Comment | 總是 | 審查中的代碼評論列表。評論文本將在 `.RenderedContent` 中，引用的代碼將在 `.Patch` 中。 |
|
||||
| `.ReviewComments` | []models.Comment | 總是 | 審查中的程式碼評論列表。評論文本將在 `.RenderedContent` 中，引用的程式碼將在 `.Patch` 中。 |
|
||||
|
||||
所有名稱都是區分大小寫的。
|
||||
|
||||
### 模板的 _主題_ 部分
|
||||
|
||||
郵件 _主題_ 使用的模板引擎是 golang 的 [`text/template`](https://go.dev/pkg/text/template/)。
|
||||
請參閱鏈接的文檔以了解其語法的詳細信息。
|
||||
請參閱鏈接的文件以瞭解其語法的詳細資訊。
|
||||
|
||||
主題的構建步驟如下：
|
||||
|
||||
@@ -107,9 +107,9 @@ _主題_ 和 _郵件正文_ 由 [Golang 的模板引擎](https://go.dev/pkg/text
|
||||
- 刪除所有前導、尾隨和冗餘空格。
|
||||
- 字符串被截斷為其前 256 個符文（字符）。
|
||||
|
||||
如果最終結果是空字符串，**或** 沒有可用的主題模板（即選擇的模板不包括主題部分），將使用 Gitea 的 **內部默認值**。
|
||||
如果最終結果是空字符串，**或** 沒有可用的主題模板（即選擇的模板不包括主題部分），將使用 Gitea 的 **內部預設值**。
|
||||
|
||||
內部默認（回退）主題相當於：
|
||||
內部預設（回退）主題相當於：
|
||||
|
||||
```sh
|
||||
{{.SubjectPrefix}}[{{.Repo}}] {{.Issue.Title}} (#{{.Issue.Index}})
|
||||
@@ -117,31 +117,31 @@ _主題_ 和 _郵件正文_ 由 [Golang 的模板引擎](https://go.dev/pkg/text
|
||||
|
||||
例如：`Re: [mike/stuff] New color palette (#38)`
|
||||
|
||||
Gitea 的默認主題也可以在模板 _元數據_ 中找到，作為 `.FallbackSubject`，即使存在有效的主題模板。
|
||||
Gitea 的預設主題也可以在模板 _元資料_ 中找到，作為 `.FallbackSubject`，即使存在有效的主題模板。
|
||||
|
||||
### 模板的 _郵件正文_ 部分
|
||||
|
||||
郵件 _正文_ 使用的模板引擎是 golang 的 [`html/template`](https://go.dev/pkg/html/template/)。
|
||||
請參閱鏈接的文檔以了解其語法的詳細信息。
|
||||
請參閱鏈接的文件以瞭解其語法的詳細資訊。
|
||||
|
||||
郵件 _正文_ 在郵件主題之後解析，因此有一個額外的 _元數據_ 字段，即實際渲染的主題，考慮所有因素後。
|
||||
郵件 _正文_ 在郵件主題之後解析，因此有一個額外的 _元資料_ 欄位，即實際渲染的主題，考慮所有因素後。
|
||||
|
||||
預期結果是 HTML（包括結構元素如 `<html>`、`<body>` 等）。可以通過 `<style>` 塊、`class` 和 `style` 屬性進行樣式設置。然而，`html/template` 會進行一些 [自動轉義](https://go.dev/pkg/html/template/#hdr-Contexts)，應該考慮到。
|
||||
預期結果是 HTML（包括結構元素如 `<html>`、`<body>` 等）。可以透過 `<style>` 塊、`class` 和 `style` 屬性進行樣式設定。然而，`html/template` 會進行一些 [自動轉義](https://go.dev/pkg/html/template/#hdr-Contexts)，應該考慮到。
|
||||
|
||||
不支持附件（如圖像或外部樣式表）。但是，也可以引用其他模板，例如提供 `<style>` 元素的內容。外部模板必須放置在 `custom/mail` 下，並相對於該目錄引用。例如，`custom/mail/styles/base.tmpl` 可以使用 `{{template styles/base}}` 包含。
|
||||
不支援附件（如圖像或外部樣式表）。但是，也可以引用其他模板，例如提供 `<style>` 元素的內容。外部模板必須放置在 `custom/mail` 下，並相對於該目錄引用。例如，`custom/mail/styles/base.tmpl` 可以使用 `{{template styles/base}}` 包含。
|
||||
|
||||
郵件以 `Content-Type: multipart/alternative` 發送，因此正文以 HTML 和文本格式發送。後者通過剝離 HTML 標記獲得。
|
||||
|
||||
## 故障排除
|
||||
|
||||
郵件的渲染方式直接取決於郵件應用程序的功能。許多郵件客戶端甚至不支持 HTML，因此它們顯示生成的郵件中包含的文本版本。
|
||||
郵件的渲染方式直接取決於郵件應用程式的功能。許多郵件客戶端甚至不支援 HTML，因此它們顯示生成的郵件中包含的文本版本。
|
||||
|
||||
如果模板渲染失敗，只有在郵件發送時才會注意到。
|
||||
如果主題模板失敗，將使用默認主題，並且無論渲染成功的部分如何，都將使用 _郵件正文_。
|
||||
如果主題模板失敗，將使用預設主題，並且無論渲染成功的部分如何，都將使用 _郵件正文_。
|
||||
|
||||
如果有問題，請檢查 [Gitea 的日誌](../administration/logging-config.md) 以獲取錯誤消息。
|
||||
|
||||
## 示例
|
||||
## 範例
|
||||
|
||||
`custom/templates/mail/issue/default.tmpl`：
|
||||
|
||||
@@ -235,13 +235,13 @@ Gitea 的默認主題也可以在模板 _元數據_ 中找到，作為 `.Fallbac
|
||||
| 名稱 | 參數 | 可用性 | 用途 |
|
||||
| ---------------- | ----------- | ------ | ------------------------------------------- |
|
||||
| `AppUrl` | - | 任何 | Gitea 的 URL |
|
||||
| `AppName` | - | 任何 | 從 `app.ini` 設置，通常為 "Gitea" |
|
||||
| `AppName` | - | 任何 | 從 `app.ini` 設定，通常為 "Gitea" |
|
||||
| `AppDomain` | - | 任何 | Gitea 的主機名 |
|
||||
| `EllipsisString` | string, int | 任何 | 將字符串截斷為指定長度；根據需要添加省略號 |
|
||||
| `SanitizeHTML` | string | 僅正文 | 通過刪除任何危險的 HTML 標籤來清理文本 |
|
||||
| `SafeHTML` | string | 僅正文 | 將輸入作為 HTML，可以用於輸出原始 HTML 內容 |
|
||||
|
||||
這些是 _函數_，而不是元數據，因此必須這樣使用：
|
||||
這些是 _函數_，而不是元資料，因此必須這樣使用：
|
||||
|
||||
```html
|
||||
像這樣：{{SanitizeHTML "Escape<my
|
||||
|
||||
+12
-12
@@ -6,17 +6,17 @@ aliases:
|
||||
- /zh-tw/repo-indexer
|
||||
---
|
||||
|
||||
# 存儲庫索引器
|
||||
# 儲存庫索引器
|
||||
|
||||
## 無需索引器的內置存儲庫代碼搜索
|
||||
## 無需索引器的內置儲存庫程式碼搜索
|
||||
|
||||
用戶可以在不設置存儲庫索引器的情況下進行存儲庫級別的代碼搜索。
|
||||
內置代碼搜索基於 `git grep` 命令，對於小型存儲庫來說快速且高效。
|
||||
通過設置存儲庫索引器可以實現更好的代碼搜索支持。
|
||||
使用者可以在不設定儲存庫索引器的情況下進行儲存庫級別的程式碼搜索。
|
||||
內置程式碼搜索基於 `git grep` 命令，對於小型儲存庫來說快速且高效。
|
||||
通過設定儲存庫索引器可以實現更好的程式碼搜索支援。
|
||||
|
||||
## 設置存儲庫索引器
|
||||
## 設定儲存庫索引器
|
||||
|
||||
Gitea 可以通過在您的 [`app.ini`](../administration/config-cheat-sheet.md) 中啟用此功能來搜索存儲庫文件：
|
||||
Gitea 可以透過在您的 [`app.ini`](../administration/config-cheat-sheet.md) 中啟用此功能來搜索儲存庫文件：
|
||||
|
||||
```ini
|
||||
[indexer]
|
||||
@@ -28,7 +28,7 @@ REPO_INDEXER_INCLUDE =
|
||||
REPO_INDEXER_EXCLUDE = resources/bin/**
|
||||
```
|
||||
|
||||
請記住，索引內容可能會消耗大量系統資源，特別是在首次創建索引或全局更新索引時（例如在升級 Gitea 之後）。
|
||||
請記住，索引內容可能會消耗大量系統資源，特別是在首次建立索引或全域更新索引時（例如在升級 Gitea 之後）。
|
||||
|
||||
### 通過大小選擇要索引的文件
|
||||
|
||||
@@ -40,15 +40,15 @@ Gitea 應用來自 [`gobwas/glob` 庫](https://github.com/gobwas/glob) 的 glob
|
||||
|
||||
限制文件列表可以防止索引被派生或不相關的文件（例如 lss、sym、map 等）污染，因此搜索結果更相關。它還可以幫助減少索引大小。
|
||||
|
||||
`REPO_INDEXER_EXCLUDE_VENDORED`（默認：true）從索引中排除供應商文件。
|
||||
`REPO_INDEXER_EXCLUDE_VENDORED`（預設：true）從索引中排除供應商文件。
|
||||
|
||||
`REPO_INDEXER_INCLUDE`（默認：空）是一個逗號分隔的 glob 模式列表，用於**包含**在索引中的文件。空列表表示“_包含所有文件_”。
|
||||
`REPO_INDEXER_EXCLUDE`（默認：空）是一個逗號分隔的 glob 模式列表，用於**排除**索引中的文件。匹配此列表的文件將不會被索引。`REPO_INDEXER_EXCLUDE` 優先於 `REPO_INDEXER_INCLUDE`。
|
||||
`REPO_INDEXER_INCLUDE`（預設：空）是一個逗號分隔的 glob 模式列表，用於**包含**在索引中的文件。空列表表示“_包含所有文件_”。
|
||||
`REPO_INDEXER_EXCLUDE`（預設：空）是一個逗號分隔的 glob 模式列表，用於**排除**索引中的文件。匹配此列表的文件將不會被索引。`REPO_INDEXER_EXCLUDE` 優先於 `REPO_INDEXER_INCLUDE`。
|
||||
|
||||
模式匹配如下：
|
||||
|
||||
- 要匹配所有具有 `.txt` 擴展名的文件，無論在哪個目錄，請使用 `**.txt`。
|
||||
- 要僅匹配存儲庫根級別的所有 `.txt` 擴展名文件，請使用 `*.txt`。
|
||||
- 要僅匹配儲存庫根級別的所有 `.txt` 擴展名文件，請使用 `*.txt`。
|
||||
- 要匹配 `resources/bin` 及以下的所有文件，請使用 `resources/bin/**`。
|
||||
- 要匹配 `resources/bin` 中**立即**的所有文件，請使用 `resources/bin/*`。
|
||||
- 要匹配所有名為 `Makefile` 的文件，請使用 `**Makefile`。
|
||||
|
||||
+42
-42
@@ -8,9 +8,9 @@ aliases:
|
||||
|
||||
# 反向代理
|
||||
|
||||
## 一般配置
|
||||
## 一般設定
|
||||
|
||||
1. 在您的 `app.ini` 文件中設置 `[server] ROOT_URL = https://git.example.com/`。
|
||||
1. 在您的 `app.ini` 文件中設定 `[server] ROOT_URL = https://git.example.com/`。
|
||||
2. 使反向代理將 `https://git.example.com/foo` 傳遞到 `http://gitea:3000/foo`。
|
||||
3. 確保反向代理不解碼 URI。請求 `https://git.example.com/a%2Fb` 應傳遞為 `http://gitea:3000/a%2Fb`。
|
||||
4. 確保 `Host` 和 `X-Forwarded-Proto` 標頭正確傳遞給 Gitea，以使 Gitea 看到實際訪問的 URL。
|
||||
@@ -20,13 +20,13 @@ aliases:
|
||||
通常**不建議**將 Gitea 放在子路徑中，這不常用，並且在某些罕見情況下可能會有一些問題。
|
||||
|
||||
要使 Gitea 與子路徑（例如：`https://common.example.com/gitea/`）一起工作，
|
||||
除了上述的一般配置外，還有一些額外要求：
|
||||
除了上述的一般設定外，還有一些額外要求：
|
||||
|
||||
1. 在您的 `app.ini` 文件中使用 `[server] ROOT_URL = https://common.example.com/gitea/`。
|
||||
2. 使反向代理將 `https://common.example.com/gitea/foo` 傳遞到 `http://gitea:3000/foo`。
|
||||
3. 容器註冊表需要在根級別配置固定子路徑 `/v2`：
|
||||
3. 容器註冊表需要在根級別設定固定子路徑 `/v2`：
|
||||
- 使反向代理將 `https://common.example.com/v2` 傳遞到 `http://gitea:3000/v2`。
|
||||
- 確保 URI 和標頭也正確傳遞（請參閱上述的一般配置）。
|
||||
- 確保 URI 和標頭也正確傳遞（請參閱上述的一般設定）。
|
||||
|
||||
## Nginx
|
||||
|
||||
@@ -53,7 +53,7 @@ server {
|
||||
## Nginx 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，
|
||||
您可以通過將以下 `server` 部分添加到 `nginx.conf` 的 `http` 部分中來設置 Nginx 以在子路徑下服務 Gitea：
|
||||
您可以透過將以下 `server` 部分添加到 `nginx.conf` 的 `http` 部分中來設定 Nginx 以在子路徑下服務 Gitea：
|
||||
|
||||
```nginx
|
||||
server {
|
||||
@@ -77,29 +77,29 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
然後您**必須**在配置中正確設置 `[server] ROOT_URL = http://git.example.com/gitea/`。
|
||||
然後您**必須**在設定中正確設定 `[server] ROOT_URL = http://git.example.com/gitea/`。
|
||||
|
||||
## Nginx 和直接服務靜態資源
|
||||
|
||||
我們可以通過將請求分為靜態和動態來調整性能。
|
||||
我們可以透過將請求分為靜態和動態來調整性能。
|
||||
|
||||
CSS 文件、JavaScript 文件、圖像和網頁字體是靜態內容。
|
||||
首頁、存儲庫視圖或問題列表是動態內容。
|
||||
首頁、儲存庫視圖或問題列表是動態內容。
|
||||
|
||||
Nginx 可以直接服務靜態資源，僅代理動態請求到 Gitea。
|
||||
Nginx 對於服務靜態內容進行了優化，而代理大響應可能正好相反
|
||||
（請參閱 [https://serverfault.com/q/587386](https://serverfault.com/q/587386)）。
|
||||
|
||||
將 Gitea 源存儲庫的快照下載到 `/path/to/gitea/`。
|
||||
之後，在存儲庫目錄中運行 `make frontend` 以生成靜態資源。我們只對此任務的 `public/` 目錄感興趣，因此您可以刪除其餘部分。
|
||||
將 Gitea 源儲存庫的快照下載到 `/path/to/gitea/`。
|
||||
之後，在儲存庫目錄中運行 `make frontend` 以生成靜態資源。我們只對此任務的 `public/` 目錄感興趣，因此您可以刪除其餘部分。
|
||||
（您需要安裝 [Node with npm](https://nodejs.org/en/download/) 和 `make` 來生成靜態資源）
|
||||
|
||||
根據您的用戶基數規模，您可能希望將流量分為兩個不同的服務器，
|
||||
或使用 cdn 來存儲靜態文件。
|
||||
根據您的使用者基數規模，您可能希望將流量分為兩個不同的伺服器，
|
||||
或使用 cdn 來儲存靜態文件。
|
||||
|
||||
### 單節點和單域
|
||||
|
||||
在您的配置中設置 `[server] STATIC_URL_PREFIX = /_/static`。
|
||||
在您的設定中設定 `[server] STATIC_URL_PREFIX = /_/static`。
|
||||
|
||||
```nginx
|
||||
server {
|
||||
@@ -118,7 +118,7 @@ server {
|
||||
|
||||
### 兩個節點和兩個域
|
||||
|
||||
在您的配置中設置 `[server] STATIC_URL_PREFIX = http://cdn.example.com/gitea`。
|
||||
在您的設定中設定 `[server] STATIC_URL_PREFIX = http://cdn.example.com/gitea`。
|
||||
|
||||
```nginx
|
||||
# 運行 Gitea 的應用服務器
|
||||
@@ -150,7 +150,7 @@ server {
|
||||
|
||||
## Apache HTTPD
|
||||
|
||||
如果您希望 Apache HTTPD 服務您的 Gitea 實例，您可以將以下內容添加到您的 Apache HTTPD 配置中（通常位於 Ubuntu 的 `/etc/apache2/httpd.conf`）：
|
||||
如果您希望 Apache HTTPD 服務您的 Gitea 實例，您可以將以下內容添加到您的 Apache HTTPD 設定中（通常位於 Ubuntu 的 `/etc/apache2/httpd.conf`）：
|
||||
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
@@ -164,14 +164,14 @@ server {
|
||||
```
|
||||
|
||||
:::note
|
||||
必須啟用以下 Apache HTTPD 模塊：`proxy`、`proxy_http`。
|
||||
必須啟用以下 Apache HTTPD 模組：`proxy`、`proxy_http`。
|
||||
:::
|
||||
|
||||
如果您希望使用 Let's Encrypt 進行 webroot 驗證，請在 `ProxyPass` 之前添加 `ProxyPass /.well-known !` 行，以禁用將這些請求代理到 Gitea。
|
||||
|
||||
## Apache HTTPD 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 Apache HTTPD 配置中（通常位於 Ubuntu 的 `/etc/apache2/httpd.conf`）來設置 Apache HTTPD 以在子路徑下服務 Gitea：
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以透過將以下內容添加到您的 Apache HTTPD 設定中（通常位於 Ubuntu 的 `/etc/apache2/httpd.conf`）來設定 Apache HTTPD 以在子路徑下服務 Gitea：
|
||||
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
@@ -181,22 +181,22 @@ server {
|
||||
Allow from all
|
||||
</Proxy>
|
||||
AllowEncodedSlashes NoDecode
|
||||
# 注意：在 /git 或端口之後沒有尾隨斜杠
|
||||
# 注意：在 /git 或端口之後沒有尾隨斜槓
|
||||
ProxyPass /git http://localhost:3000 nocanon
|
||||
ProxyPreserveHost On
|
||||
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
然後您**必須**在配置中正確設置 `[server] ROOT_URL = http://git.example.com/git/`。
|
||||
然後您**必須**在設定中正確設定 `[server] ROOT_URL = http://git.example.com/git/`。
|
||||
|
||||
:::note
|
||||
必須啟用以下 Apache HTTPD 模塊：`proxy`、`proxy_http`。
|
||||
必須啟用以下 Apache HTTPD 模組：`proxy`、`proxy_http`。
|
||||
:::
|
||||
|
||||
## Caddy
|
||||
|
||||
如果您希望 Caddy 服務您的 Gitea 實例，您可以將以下服務器塊添加到您的 Caddyfile 中：
|
||||
如果您希望 Caddy 服務您的 Gitea 實例，您可以將以下伺服器塊添加到您的 Caddyfile 中：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
@@ -206,7 +206,7 @@ git.example.com {
|
||||
|
||||
## Caddy 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 Caddyfile 中的服務器塊來設置 Caddy 以在子路徑下服務 Gitea：
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以透過將以下內容添加到您的 Caddyfile 中的伺服器塊來設定 Caddy 以在子路徑下服務 Gitea：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
@@ -217,22 +217,22 @@ git.example.com {
|
||||
}
|
||||
```
|
||||
|
||||
然後在您的配置中設置 `[server] ROOT_URL = http://git.example.com/git/`。
|
||||
然後在您的設定中設定 `[server] ROOT_URL = http://git.example.com/git/`。
|
||||
|
||||
## IIS
|
||||
|
||||
如果您希望使用 IIS 運行 Gitea。您需要設置 IIS 並使用 URL Rewrite 作為反向代理。
|
||||
如果您希望使用 IIS 運行 Gitea。您需要設定 IIS 並使用 URL Rewrite 作為反向代理。
|
||||
|
||||
1. 在 IIS 中設置一個空網站，命名為 `Gitea Proxy`。
|
||||
2. 按照 [Microsoft 的技術社區指南設置 IIS 並使用 URL Rewrite](https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222#M343) 中的前兩步操作。即：
|
||||
1. 在 IIS 中設定一個空網站，命名為 `Gitea Proxy`。
|
||||
2. 按照 [Microsoft 的技術社區指南設定 IIS 並使用 URL Rewrite](https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222#M343) 中的前兩步操作。即：
|
||||
|
||||
- 使用 Microsoft Web Platform Installer 5.1（WebPI）安裝應用程序請求路由（簡稱 ARR），或從 [IIS.net](https://www.iis.net/downloads/microsoft/application-request-routing) 下載擴展。
|
||||
- 安裝模塊後，您將在 IIS 管理控制台中看到一個名為 URL Rewrite 的新圖標。
|
||||
- 打開 IIS 管理控制台，從左側樹視圖中單擊 `Gitea Proxy` 網站。從中間窗格中選擇並雙擊 URL Rewrite 圖標以加載 URL Rewrite 界面。
|
||||
- 從管理控制台的右側窗格中選擇 `Add Rule` 操作，並從 `Inbound and Outbound Rules` 類別中選擇 `Reverse Proxy Rule`。
|
||||
- 在 Inbound Rules 部分中，將服務器名稱設置為運行 Gitea 的主機及其端口。例如，如果您在本地主機上運行 Gitea，端口為 3000，則以下應該可以工作：`127.0.0.1:3000`
|
||||
- 使用 Microsoft Web Platform Installer 5.1（WebPI）安裝應用程式請求路由（簡稱 ARR），或從 [IIS.net](https://www.iis.net/downloads/microsoft/application-request-routing) 下載擴展。
|
||||
- 安裝模組後，您將在 IIS 管理控制檯中看到一個名為 URL Rewrite 的新圖標。
|
||||
- 打開 IIS 管理控制檯，從左側樹視圖中單擊 `Gitea Proxy` 網站。從中間窗格中選擇並雙擊 URL Rewrite 圖標以加載 URL Rewrite 介面。
|
||||
- 從管理控制檯的右側窗格中選擇 `Add Rule` 操作，並從 `Inbound and Outbound Rules` 類別中選擇 `Reverse Proxy Rule`。
|
||||
- 在 Inbound Rules 部分中，將伺服器名稱設定為運行 Gitea 的主機及其端口。例如，如果您在本地主機上運行 Gitea，端口為 3000，則以下應該可以工作：`127.0.0.1:3000`
|
||||
- 啟用 SSL 卸載
|
||||
- 在 Outbound Rules 中，確保設置 `Rewrite the domain names of the links in HTTP response`，並將 `From:` 字段設置為上述內容，將 `To:` 設置為您的外部主機名，例如：`git.example.com`
|
||||
- 在 Outbound Rules 中，確保設定 `Rewrite the domain names of the links in HTTP response`，並將 `From:` 欄位設定為上述內容，將 `To:` 設定為您的外部主機名，例如：`git.example.com`
|
||||
- 現在編輯您的網站的 `web.config` 以匹配以下內容：（根據需要更改 `127.0.0.1:3000` 和 `git.example.com`）
|
||||
|
||||
```xml
|
||||
@@ -303,7 +303,7 @@ git.example.com {
|
||||
|
||||
## HAProxy
|
||||
|
||||
如果您希望 HAProxy 服務您的 Gitea 實例，您可以將以下內容添加到您的 HAProxy 配置中
|
||||
如果您希望 HAProxy 服務您的 Gitea 實例，您可以將以下內容添加到您的 HAProxy 設定中
|
||||
|
||||
在前端部分添加一個 acl 以將調用重定向到 gitea.example.com 到正確的後端
|
||||
|
||||
@@ -322,11 +322,11 @@ backend gitea
|
||||
server localhost:3000 check
|
||||
```
|
||||
|
||||
如果您將 http 內容重定向到 https，配置方式相同，只需記住 HAProxy 和 Gitea 之間的連接將通過 http 完成，因此您不必在 Gitea 的配置中啟用 https。
|
||||
如果您將 http 內容重定向到 https，設定方式相同，只需記住 HAProxy 和 Gitea 之間的連接將通過 http 完成，因此您不必在 Gitea 的設定中啟用 https。
|
||||
|
||||
## HAProxy 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 HAProxy 配置中來設置 HAProxy 以在子路徑下服務 Gitea：
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以透過將以下內容添加到您的 HAProxy 設定中來設定 HAProxy 以在子路徑下服務 Gitea：
|
||||
|
||||
```
|
||||
frontend http-in
|
||||
@@ -336,7 +336,7 @@ frontend http-in
|
||||
...
|
||||
```
|
||||
|
||||
使用該配置 http://example.com/gitea/ 將重定向到您的 Gitea 實例。
|
||||
使用該設定 http://example.com/gitea/ 將重定向到您的 Gitea 實例。
|
||||
|
||||
然後為後端部分
|
||||
|
||||
@@ -346,9 +346,9 @@ backend gitea
|
||||
server localhost:3000 check
|
||||
```
|
||||
|
||||
添加的 http-request 將自動添加尾隨斜杠（如果需要），並在內部刪除 /gitea 從路徑中刪除，以便通過正確設置 http://example.com/gitea 作為根來使其與 Gitea 正確工作。
|
||||
添加的 http-request 將自動添加尾隨斜槓（如果需要），並在內部刪除 /gitea 從路徑中刪除，以便通過正確設定 http://example.com/gitea 作為根來使其與 Gitea 正確工作。
|
||||
|
||||
然後您**必須**在配置中正確設置 `[server] ROOT_URL = http://example.com/gitea/`。
|
||||
然後您**必須**在設定中正確設定 `[server] ROOT_URL = http://example.com/gitea/`。
|
||||
|
||||
## Traefik
|
||||
|
||||
@@ -364,11 +364,11 @@ gitea:
|
||||
- "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000"
|
||||
```
|
||||
|
||||
此配置假設您在 traefik 端處理 HTTPS，並在 Gitea 和 traefik 之間使用 HTTP。
|
||||
此設定假設您在 traefik 端處理 HTTPS，並在 Gitea 和 traefik 之間使用 HTTP。
|
||||
|
||||
## Traefik 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 `docker-compose.yaml`（假設提供者是 docker）來設置 Traefik 以在子路徑下服務 Gitea：
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以透過將以下內容添加到您的 `docker-compose.yaml`（假設提供者是 docker）來設定 Traefik 以在子路徑下服務 Gitea：
|
||||
|
||||
```yaml
|
||||
gitea:
|
||||
@@ -382,4 +382,4 @@ gitea:
|
||||
- "traefik.http.routers.gitea.middlewares=gitea-stripprefix"
|
||||
```
|
||||
|
||||
此配置假設您在 traefik
|
||||
此設定假設您在 traefik
|
||||
+1
-1
@@ -15,7 +15,7 @@ aliases:
|
||||
|
||||
要讓 Gitea 為頂層安裝提供自訂的 `robots.txt`（預設：空的 404），請在 [`custom` 資料夾或 `CustomPath`](../administration/customizing-gitea.md) 中建立一個路徑為 `public/robots.txt` 的檔案。
|
||||
|
||||
如何配置 `robots.txt` 的範例可以在 [https://moz.com/learn/seo/robotstxt](https://moz.com/learn/seo/robotstxt) 找到。
|
||||
如何設定 `robots.txt` 的範例可以在 [https://moz.com/learn/seo/robotstxt](https://moz.com/learn/seo/robotstxt) 找到。
|
||||
|
||||
```txt
|
||||
User-agent: *
|
||||
|
||||
@@ -27,15 +27,15 @@ Gitea 會在以下幾個地方自動生成提交：
|
||||
- 使用編輯器或 API 進行的 CRUD 操作
|
||||
- 從拉取請求合併
|
||||
|
||||
根據配置和伺服器信任，您可能希望 Gitea 簽署這些提交。
|
||||
根據設定和伺服器信任，您可能希望 Gitea 簽署這些提交。
|
||||
|
||||
## 為 Gitea 安裝和生成 GPG 密鑰
|
||||
|
||||
伺服器管理員需要決定如何最好地安裝簽名密鑰。目前，Gitea 使用伺服器的 `git` 命令生成所有提交，因此將使用伺服器的 `gpg` 進行簽名（如果已配置）。管理員應該審查 GPG 的最佳實踐，特別是建議僅安裝簽名的秘密子密鑰，而不安裝主簽名和認證的秘密密鑰。
|
||||
伺服器管理員需要決定如何最好地安裝簽名密鑰。目前，Gitea 使用伺服器的 `git` 命令生成所有提交，因此將使用伺服器的 `gpg` 進行簽名（如果已設定）。管理員應該審查 GPG 的最佳實踐，特別是建議僅安裝簽名的祕密子密鑰，而不安裝主簽名和認證的祕密密鑰。
|
||||
|
||||
## 一般配置
|
||||
## 一般設定
|
||||
|
||||
Gitea 的簽名配置可以在 `app.ini` 的 `[repository.signing]` 部分找到：
|
||||
Gitea 的簽名設定可以在 `app.ini` 的 `[repository.signing]` 部分找到：
|
||||
|
||||
```ini
|
||||
...
|
||||
@@ -56,30 +56,30 @@ MERGES = pubkey, twofa, basesigned, commitssigned
|
||||
首先要討論的是 `SIGNING_KEY`。有三個主要選項：
|
||||
|
||||
- `none` - 這會阻止 Gitea 簽署任何提交
|
||||
- `default` - Gitea 將默認使用 `git config` 中配置的密鑰
|
||||
- `default` - Gitea 將預設使用 `git config` 中設定的密鑰
|
||||
- `KEYID` - Gitea 將使用 ID 為 `KEYID` 的 gpg 密鑰簽署提交。在這種情況下，您應該提供 `SIGNING_NAME` 和 `SIGNING_EMAIL` 以顯示此密鑰。
|
||||
|
||||
`default` 選項將查詢 `git config` 的 `commit.gpgsign` 選項 - 如果設置了此選項，則將根據需要使用 `user.signingkey`、`user.name` 和 `user.email` 的結果。
|
||||
`default` 選項將查詢 `git config` 的 `commit.gpgsign` 選項 - 如果設定了此選項，則將根據需要使用 `user.signingkey`、`user.name` 和 `user.email` 的結果。
|
||||
|
||||
通過調整 Gitea 儲存庫中的 Git `config` 文件，可以使用 `SIGNING_KEY=default` 為每個儲存庫提供不同的簽名密鑰。然而，這顯然不是理想的 UI，因此可能會有所變化。
|
||||
|
||||
:::warning
|
||||
**自 1.17 起**，Gitea 在其自己的主目錄 `[git].HOME_PATH`（默認為 `%(APP_DATA_PATH)/home`）中運行 git，並使用其自己的配置 `{[git].HOME_PATH}/.gitconfig`。
|
||||
**自 1.17 起**，Gitea 在其自己的主目錄 `[git].HOME_PATH`（預設為 `%(APP_DATA_PATH)/home`）中運行 git，並使用其自己的設定 `{[git].HOME_PATH}/.gitconfig`。
|
||||
|
||||
如果您為 Gitea 配置了自定義的 git 配置，應該在系統 git 配置（即 `/etc/gitconfig`）或 Gitea 內部 git 配置 `{[git].HOME_PATH}/.gitconfig` 中設置這些配置。
|
||||
如果您為 Gitea 設定了自訂的 git 設定，應該在系統 git 設定（即 `/etc/gitconfig`）或 Gitea 內部 git 設定 `{[git].HOME_PATH}/.gitconfig` 中設定這些設定。
|
||||
|
||||
git 命令相關的主目錄文件（如 `.gnupg`）也應放在 Gitea 的 git 主目錄 `[git].HOME_PATH` 中。
|
||||
|
||||
如果您希望將 `.gnupg` 目錄保留在 `{[git].HOME_PATH}/` 之外，請考慮將 `$GNUPGHOME` 環境變量設置為您首選的位置，否則 Gitea 只會使用 `{[git].HOME_PATH}/.gnupg` 下的 gpg 密鑰。
|
||||
如果您希望將 `.gnupg` 目錄保留在 `{[git].HOME_PATH}/` 之外，請考慮將 `$GNUPGHOME` 環境變量設定為您首選的位置，否則 Gitea 只會使用 `{[git].HOME_PATH}/.gnupg` 下的 gpg 密鑰。
|
||||
:::
|
||||
|
||||
### `INITIAL_COMMIT`
|
||||
|
||||
此選項決定 Gitea 在創建儲存庫時是否應該簽署初始提交。可能的值是：
|
||||
此選項決定 Gitea 在建立儲存庫時是否應該簽署初始提交。可能的值是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `pubkey`: 僅在使用者擁有公鑰時簽署
|
||||
- `twofa`: 僅在使用者使用雙因素身份驗證登入時簽署
|
||||
- `always`: 始終簽署
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以作為逗號分隔的列表進行組合。提交將在所有選定選項都為真時簽署。
|
||||
@@ -89,8 +89,8 @@ git 命令相關的主目錄文件（如 `.gnupg`）也應放在 Gitea 的 git
|
||||
此選項決定 Gitea 是否應該簽署 Wiki 的提交。可能的值是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `pubkey`: 僅在使用者擁有公鑰時簽署
|
||||
- `twofa`: 僅在使用者使用雙因素身份驗證登入時簽署
|
||||
- `parentsigned`: 僅在父提交已簽署時簽署。
|
||||
- `always`: 始終簽署
|
||||
|
||||
@@ -101,8 +101,8 @@ git 命令相關的主目錄文件（如 `.gnupg`）也應放在 Gitea 的 git
|
||||
此選項決定 Gitea 是否應該簽署來自網頁編輯器或 API CRUD 操作的提交。可能的值是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `pubkey`: 僅在使用者擁有公鑰時簽署
|
||||
- `twofa`: 僅在使用者使用雙因素身份驗證登入時簽署
|
||||
- `parentsigned`: 僅在父提交已簽署時簽署。
|
||||
- `always`: 始終簽署
|
||||
|
||||
@@ -113,8 +113,8 @@ git 命令相關的主目錄文件（如 `.gnupg`）也應放在 Gitea 的 git
|
||||
此選項決定 Gitea 是否應該簽署來自 PR 的合併提交。可能的選項是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `pubkey`: 僅在使用者擁有公鑰時簽署
|
||||
- `twofa`: 僅在使用者使用雙因素身份驗證登入時簽署
|
||||
- `basesigned`: 僅在基礎儲存庫中的父提交已簽署時簽署。
|
||||
- `headsigned`: 僅在頭分支中的頭提交已簽署時簽署。
|
||||
- `commitssigned`: 僅在頭分支中到合併點的所有提交都已簽署時簽署。
|
||||
|
||||
+6
-6
@@ -28,9 +28,9 @@ Gitea 使用 Golang 作為後端程式語言。它使用了許多第三方套件
|
||||
- `models`: 包含由 xorm 用來構建資料庫表格的資料結構。它也包含查詢和更新資料庫的函數。應避免依賴其他 Gitea 程式碼。可以在某些情況下例外，例如記錄。
|
||||
- `models/db`: 基本的資料庫操作。所有其他 `models/xxx` 套件應依賴此套件。`GetEngine` 函數應僅從 `models/` 調用。
|
||||
- `models/fixtures`: 單元測試和整合測試中使用的樣本資料。一個 `yml` 文件代表一個表格，測試開始時會將其載入資料庫。
|
||||
- `models/migrations`: 存儲版本之間的資料庫遷移。更改資料庫結構的 PR **必須** 也有遷移步驟。
|
||||
- `models/migrations`: 儲存版本之間的資料庫遷移。更改資料庫結構的 PR **必須** 也有遷移步驟。
|
||||
- `modules`: 處理 Gitea 中特定功能的不同模組。進行中：其中一些應移動到 `services`，特別是那些依賴於 models 的，因為它們依賴於資料庫。
|
||||
- `modules/setting`: 存儲從 ini 文件讀取的所有系統配置，並已被各處引用。但應盡可能作為函數參數使用。
|
||||
- `modules/setting`: 儲存從 ini 文件讀取的所有系統設定，並已被各處引用。但應盡可能作為函數參數使用。
|
||||
- `modules/git`: 與 `Git` 命令行或 Gogit 套件互動的套件。
|
||||
- `public`: 編譯後的前端文件（javascript、圖片、css 等）。
|
||||
- `routers`: 處理伺服器請求。由於它使用其他 Gitea 套件來處理請求，其他套件（models、modules 或 services）不得依賴 routers。
|
||||
@@ -38,12 +38,12 @@ Gitea 使用 Golang 作為後端程式語言。它使用了許多第三方套件
|
||||
- `routers/install` 僅在系統處於安裝模式（INSTALL_LOCK=false）時響應。
|
||||
- `routers/private` 只會被內部子命令調用，特別是 `serv` 和 `hooks`。
|
||||
- `routers/web` 會處理來自網頁瀏覽器或 Git SMART HTTP 協議的 HTTP 請求。
|
||||
- `services`: 支持常見路由操作或命令執行的函數。使用 `models` 和 `modules` 來處理請求。
|
||||
- `services`: 支援常見路由操作或命令執行的函數。使用 `models` 和 `modules` 來處理請求。
|
||||
- `templates`: 用於生成 html 輸出的 Golang 模板。
|
||||
|
||||
### 套件依賴
|
||||
|
||||
由於 Golang 不支持導入循環，我們必須仔細決定套件依賴關係。這些套件之間有一些層次。以下是理想的套件依賴方向。
|
||||
由於 Golang 不支援導入循環，我們必須仔細決定套件依賴關係。這些套件之間有一些層次。以下是理想的套件依賴方向。
|
||||
|
||||
`cmd` -> `routers` -> `services` -> `models` -> `modules`
|
||||
|
||||
@@ -52,7 +52,7 @@ Gitea 使用 Golang 作為後端程式語言。它使用了許多第三方套件
|
||||
:::warning
|
||||
為什麼我們需要在 `models` 之外的資料庫交易？以及如何實現？
|
||||
某些操作應允許在資料庫記錄插入/更新/刪除失敗時回滾。
|
||||
因此，services 必須允許創建資料庫交易。這裡有一些例子，
|
||||
因此，services 必須允許建立資料庫交易。這裡有一些例子，
|
||||
|
||||
```go
|
||||
// services/repository/repository.go
|
||||
@@ -112,6 +112,6 @@ func UpdateIssue(ctx context.Context, repoID int64) error {
|
||||
|
||||
目前，我們正在進行一些重構，以完成以下事情：
|
||||
|
||||
- 修正不符合規則的代碼。
|
||||
- 修正不符合規則的程式碼。
|
||||
- `models` 中的文件太多了，所以我們正在將其中一些移動到子套件 `models/xxx`。
|
||||
- 一些 `modules` 子套件應移動到 `services`，因為它們依賴於 `models`。
|
||||
+32
-32
@@ -18,7 +18,7 @@ HTML 頁面由 [Go HTML Template](https://pkg.go.dev/html/template) 渲染。
|
||||
|
||||
- **CSS 樣式：** `web_src/css/`
|
||||
- **JavaScript 文件：** `web_src/js/`
|
||||
- **Vue 組件：** `web_src/js/components/`
|
||||
- **Vue 元件：** `web_src/js/components/`
|
||||
- **Go HTML 模板：** `templates/`
|
||||
|
||||
## 一般指南
|
||||
@@ -27,19 +27,19 @@ HTML 頁面由 [Go HTML Template](https://pkg.go.dev/html/template) 渲染。
|
||||
|
||||
### Gitea 特定指南
|
||||
|
||||
1. 每個功能（Fomantic-UI/jQuery 模塊）應該放在單獨的文件/目錄中。
|
||||
1. 每個功能（Fomantic-UI/jQuery 模組）應該放在單獨的文件/目錄中。
|
||||
2. HTML id 和 class 應該使用 kebab-case，最好包含 2-3 個與功能相關的關鍵詞。
|
||||
3. 在 JavaScript 中使用的 HTML id 和 class 應該在整個項目中是唯一的，並且應該包含 2-3 個與功能相關的關鍵詞。我們建議對僅在 JavaScript 中使用的 class 使用 `js-` 前綴。
|
||||
3. 在 JavaScript 中使用的 HTML id 和 class 應該在整個專案中是唯一的，並且應該包含 2-3 個與功能相關的關鍵詞。我們建議對僅在 JavaScript 中使用的 class 使用 `js-` 前綴。
|
||||
4. 不應覆蓋框架提供的 class 的 CSS 樣式。始終使用包含 2-3 個與功能相關的關鍵詞的新 class 名稱來覆蓋框架樣式。Gitea 的 `helpers.less` 中的輔助 CSS class 可能會有所幫助。
|
||||
5. 後端可以使用 `ctx.PageData["myModuleData"] = map[]{}` 將複雜數據傳遞給前端，但不要將整個模型暴露給前端，以避免洩露敏感數據。
|
||||
5. 後端可以使用 `ctx.PageData["myModuleData"] = map[]{}` 將複雜資料傳遞給前端，但不要將整個模型暴露給前端，以避免洩露敏感資料。
|
||||
6. 簡單頁面和與 SEO 相關的頁面使用 Go HTML Template 渲染生成靜態 Fomantic-UI HTML 輸出。複雜頁面可以使用 Vue3。
|
||||
7. 明確變量類型，優先使用 `elem.disabled = true` 而不是 `elem.setAttribute('disabled', 'anything')`，優先使用 `$el.prop('checked', var === 'yes')` 而不是 `$el.prop('checked', var)`。
|
||||
8. 使用語義化元素，優先使用 `<button class="ui button">` 而不是 `<div class="ui button">`。
|
||||
9. 避免在 CSS 中不必要的 `!important`，如果無法避免，請添加註釋解釋為什麼是必要的。
|
||||
10. 避免在一個事件監聽器中混合不同的事件，優先為每個事件使用單獨的事件監聽器。
|
||||
11. 自定義事件名稱建議使用 `ce-` 前綴。
|
||||
11. 自訂事件名稱建議使用 `ce-` 前綴。
|
||||
12. 優先使用 Tailwind CSS，通過 `tw-` 前綴可用，例如 `tw-relative`。Gitea 的輔助 CSS class 使用 `gt-` 前綴（`gt-ellipsis`），而 Gitea 自己的私有框架級 CSS class 使用 `g-` 前綴（`g-modal-confirm`）。
|
||||
13. 盡可能避免內聯腳本和樣式，建議將 JS 代碼放入 JS 文件並使用 CSS class。如果內聯腳本和樣式是不可避免的，請解釋為什麼無法避免。
|
||||
13. 盡可能避免內聯腳本和樣式，建議將 JS 程式碼放入 JS 文件並使用 CSS class。如果內聯腳本和樣式是不可避免的，請解釋為什麼無法避免。
|
||||
|
||||
### 無障礙 / ARIA
|
||||
|
||||
@@ -49,34 +49,34 @@ Gitea 使用一些補丁使 Fomantic UI 更加無障礙（見 `aria.md` 和相
|
||||
|
||||
### 框架使用
|
||||
|
||||
不建議混合使用不同的框架，這會使代碼難以維護。
|
||||
JavaScript 模塊應該遵循一個主要框架並遵循該框架的最佳實踐。
|
||||
不建議混合使用不同的框架，這會使程式碼難以維護。
|
||||
JavaScript 模組應該遵循一個主要框架並遵循該框架的最佳實踐。
|
||||
|
||||
推薦的實現：
|
||||
|
||||
- Vue + 原生 JS
|
||||
- Fomantic-UI (jQuery)
|
||||
- htmx（部分頁面重新加載，適用於靜態組件）
|
||||
- htmx（部分頁面重新加載，適用於靜態元件）
|
||||
- 原生 JS
|
||||
|
||||
不推薦的實現：
|
||||
|
||||
- Vue + Fomantic-UI (jQuery)
|
||||
- jQuery + 原生 JS
|
||||
- htmx + 任何需要大量 JS 代碼的框架，或不必要的功能如 htmx 腳本（`hx-on`）
|
||||
- htmx + 任何需要大量 JS 程式碼的框架，或不必要的功能如 htmx 腳本（`hx-on`）
|
||||
|
||||
為了使 UI 一致，Vue 組件可以使用 Fomantic-UI CSS class。
|
||||
我們使用 htmx 進行簡單的交互。你可以在這個 [PR](https://github.com/go-gitea/gitea/pull/28908) 中看到一個使用 htmx 進行簡單交互的示例。如果你需要更高級的反應性，請使用其他框架（Vue/原生 JS）。
|
||||
為了使 UI 一致，Vue 元件可以使用 Fomantic-UI CSS class。
|
||||
我們使用 htmx 進行簡單的交互。你可以在這個 [PR](https://github.com/go-gitea/gitea/pull/28908) 中看到一個使用 htmx 進行簡單交互的範例。如果你需要更高級的反應性，請使用其他框架（Vue/原生 JS）。
|
||||
雖然不建議混合使用不同的框架，
|
||||
但如果混合是必要的並且代碼設計良好且可維護，應該也是可行的。
|
||||
但如果混合是必要的並且程式碼設計良好且可維護，應該也是可行的。
|
||||
|
||||
### Typescript
|
||||
|
||||
Gitea 正在遷移到類型安全的 Typescript。以下是一些關於 Typescript 在代碼庫中的具體指南：
|
||||
Gitea 正在遷移到類型安全的 Typescript。以下是一些關於 Typescript 在程式碼庫中的具體指南：
|
||||
|
||||
#### 使用類型別名而不是接口
|
||||
#### 使用類型別名而不是介面
|
||||
|
||||
優先使用類型別名，因為它們可以表示任何類型，並且通常比接口更靈活。
|
||||
優先使用類型別名，因為它們可以表示任何類型，並且通常比介面更靈活。
|
||||
|
||||
#### 使用單獨的類型導入
|
||||
|
||||
@@ -91,7 +91,7 @@ Gitea 正在遷移到類型安全的 Typescript。以下是一些關於 Typescri
|
||||
只有在函數內部有 `await` 調用或返回 `Promise` 時，才將函數標記為 `async`。
|
||||
|
||||
不建議使用 `async` 事件監聽器，這可能會導致問題。
|
||||
原因是 `await` 之後的代碼在事件分派之外執行。
|
||||
原因是 `await` 之後的程式碼在事件分派之外執行。
|
||||
參考：https://github.com/github/eslint-plugin-github/blob/main/docs/rules/async-preventdefault.md
|
||||
|
||||
如果事件監聽器必須是 `async`，則 `e.preventDefault()` 應在任何 `await` 之前，
|
||||
@@ -102,29 +102,29 @@ Gitea 正在遷移到類型安全的 Typescript。以下是一些關於 Typescri
|
||||
這是故意這樣做的，我們想調用 `async` 函數並忽略 Promise。
|
||||
一些 lint 規則和 IDE 也會在未處理返回的 Promise 時發出警告。
|
||||
|
||||
### 獲取數據
|
||||
### 獲取資料
|
||||
|
||||
要獲取數據，請使用 `modules/fetch.js` 中的包裝函數 `GET`、`POST` 等。
|
||||
它們接受一個 `data` 選項作為內容，會自動設置 CSRF 令牌並返回一個 [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) 的 Promise。
|
||||
要獲取資料，請使用 `modules/fetch.js` 中的包裝函數 `GET`、`POST` 等。
|
||||
它們接受一個 `data` 選項作為內容，會自動設定 CSRF 令牌並返回一個 [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) 的 Promise。
|
||||
|
||||
### HTML 屬性和 `dataset`
|
||||
|
||||
禁止使用 `dataset`，其駝峰命名行為使得很難 grep 屬性。
|
||||
然而，仍然存在一些特殊情況，所以目前的指南是：
|
||||
|
||||
- 對於遺留代碼：
|
||||
- 對於遺留程式碼：
|
||||
|
||||
- `$.data()` 應重構為 `$.attr()`。
|
||||
- `$.data()` 可以在罕見情況下用於將一些非字符串數據綁定到元素，但這是高度不建議的。
|
||||
- `$.data()` 可以在罕見情況下用於將一些非字符串資料綁定到元素，但這是高度不建議的。
|
||||
|
||||
- 對於新代碼：
|
||||
- 對於新程式碼：
|
||||
- 不應使用 `node.dataset`，應使用 `node.getAttribute`。
|
||||
- 永遠不要將任何用戶數據綁定到 DOM 節點，應使用合適的設計模式來描述節點和數據之間的關係。
|
||||
- 永遠不要將任何使用者資料綁定到 DOM 節點，應使用合適的設計模式來描述節點和資料之間的關係。
|
||||
|
||||
### 顯示/隱藏元素
|
||||
|
||||
- Vue 組件建議使用 `v-if` 和 `v-show` 來顯示/隱藏元素。
|
||||
- Go 模板代碼應使用 `.tw-hidden` 和 `showElem()/hideElem()/toggleElem()`，詳情見 `.tw-hidden` 的註釋。
|
||||
- Vue 元件建議使用 `v-if` 和 `v-show` 來顯示/隱藏元素。
|
||||
- Go 模板程式碼應使用 `.tw-hidden` 和 `showElem()/hideElem()/toggleElem()`，詳情見 `.tw-hidden` 的註釋。
|
||||
|
||||
### Go HTML 模板中的樣式和屬性
|
||||
|
||||
@@ -149,16 +149,16 @@ Gitea 正在遷移到類型安全的 Typescript。以下是一些關於 Typescri
|
||||
></div>
|
||||
```
|
||||
|
||||
以使代碼更具可讀性。
|
||||
以使程式碼更具可讀性。
|
||||
|
||||
### 遺留代碼
|
||||
### 遺留程式碼
|
||||
|
||||
在撰寫本文檔之前，已經存在許多遺留代碼。建議重構遺留代碼以遵循這些指南。
|
||||
在撰寫本文件之前，已經存在許多遺留程式碼。建議重構遺留程式碼以遵循這些指南。
|
||||
|
||||
### Vue3 和 JSX
|
||||
|
||||
Gitea 現在使用 Vue3。我們決定不引入 JSX，以保持 HTML 和 JavaScript 代碼分離。
|
||||
Gitea 現在使用 Vue3。我們決定不引入 JSX，以保持 HTML 和 JavaScript 程式碼分離。
|
||||
|
||||
### UI 示例
|
||||
### UI 範例
|
||||
|
||||
Gitea 使用一些自製的 UI 元素並自定義其他元素，以更好地將它們集成到整體 UI 方法中。當 Gitea 在開發模式下運行時（`RUN_MODE=dev`），可以在 `http(s)://your-gitea-url:port/devtest` 下訪問一些標準化的 UI 示例頁面。
|
||||
Gitea 使用一些自製的 UI 元素並自訂其他元素，以更好地將它們整合到整體 UI 方法中。當 Gitea 在開發模式下運行時（`RUN_MODE=dev`），可以在 `http(s)://your-gitea-url:port/devtest` 下訪問一些標準化的 UI 範例頁面。
|
||||
+5
-5
@@ -10,12 +10,12 @@ aliases:
|
||||
|
||||
## 背景
|
||||
|
||||
自 2014 年 2 月 12 日編寫第一行代碼以來，Gitea 已經成長為一個大型項目。
|
||||
因此，代碼庫變得越來越大。代碼庫越大，維護起來就越困難。
|
||||
存在許多過時的機制，許多框架混合在一起，一些遺留代碼可能會導致錯誤並阻礙新功能。
|
||||
為了使代碼庫更易於維護並使 Gitea 更好，開發人員應牢記使用現代機制來重構舊代碼。
|
||||
自 2014 年 2 月 12 日編寫第一行程式碼以來，Gitea 已經成長為一個大型專案。
|
||||
因此，程式碼庫變得越來越大。程式碼庫越大，維護起來就越困難。
|
||||
存在許多過時的機制，許多框架混合在一起，一些遺留程式碼可能會導致錯誤並阻礙新功能。
|
||||
為了使程式碼庫更易於維護並使 Gitea 更好，開發人員應牢記使用現代機制來重構舊程式碼。
|
||||
|
||||
本文檔是重構代碼庫的指南集合。
|
||||
本文件是重構程式碼庫的指南集合。
|
||||
|
||||
## 重構建議
|
||||
|
||||
|
||||
@@ -8,18 +8,18 @@ aliases:
|
||||
|
||||
# 本地化
|
||||
|
||||
Gitea 的本地化通過我們的 [Crowdin 項目](https://crowdin.com/project/gitea) 進行。
|
||||
Gitea 的本地化通過我們的 [Crowdin 專案](https://crowdin.com/project/gitea) 進行。
|
||||
|
||||
對 **英文** 翻譯的更改，可以通過拉取請求更改
|
||||
對 **英文** 翻譯的更改，可以透過拉取請求更改
|
||||
[英文語言文件](https://github.com/go-gitea/gitea/blob/main/options/locale/locale_en-US.ini) 中的相應鍵。
|
||||
|
||||
對 **非英文** 翻譯的更改，請參考上面的 Crowdin 項目。
|
||||
對 **非英文** 翻譯的更改，請參考上面的 Crowdin 專案。
|
||||
|
||||
## 支持的語言
|
||||
## 支援的語言
|
||||
|
||||
只要翻譯完成度達到 25% 或以上，Crowdin 項目中列出的任何語言都將被支持。
|
||||
只要翻譯完成度達到 25% 或以上，Crowdin 專案中列出的任何語言都將被支援。
|
||||
|
||||
翻譯被接受後，將在下一次 Crowdin 同步後反映在主存儲庫中，通常是在任何 PR 合併後。
|
||||
翻譯被接受後，將在下一次 Crowdin 同步後反映在主儲存庫中，通常是在任何 PR 合併後。
|
||||
|
||||
在撰寫本文時，這意味著更改的翻譯可能不會出現在隨後的 Gitea 發布之前。
|
||||
|
||||
@@ -27,4 +27,4 @@ Gitea 的本地化通過我們的 [Crowdin 項目](https://crowdin.com/project/g
|
||||
|
||||
## 如何貢獻
|
||||
|
||||
不同語言有不同的翻譯指南。請訪問相應的頁面以獲取更多信息。
|
||||
不同語言有不同的翻譯指南。請前往相應的頁面以獲取更多資訊。
|
||||
@@ -8,10 +8,12 @@ aliases:
|
||||
|
||||
# API 使用
|
||||
|
||||
## 啟用/配置 API 訪問
|
||||
## 啟用/設定 API 存取
|
||||
|
||||
預設情況下，`ENABLE_SWAGGER` 是啟用的，`MAX_RESPONSE_ITEMS` 設定為 50。更多資訊請參閱 [配置速查表](../administration/config-cheat-sheet.md)。
|
||||
預設情況下，`ENABLE_SWAGGER` 是啟用的，`MAX_RESPONSE_ITEMS` 設定為 50。更多資訊請參閱 [設定速查表](../administration/config-cheat-sheet.md)。
|
||||
|
||||
<a id="authentication"></a>
|
||||
<a id="通過-api-認證"></a>
|
||||
## 認證
|
||||
|
||||
Gitea 支援以下 API 認證方法：
|
||||
@@ -21,11 +23,11 @@ Gitea 支援以下 API 認證方法：
|
||||
- URL 查詢字串中的 `access_token=...` 參數
|
||||
- HTTP 標頭中的 `Authorization: token ...` 標頭
|
||||
|
||||
所有這些方法都接受相同的 API 金鑰令牌類型。你可以通過查看代碼更好地理解這一點——截至撰寫本文時，Gitea 會解析查詢和標頭以找到令牌，詳見 [modules/auth/auth.go](https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47)。
|
||||
所有這些方法都接受相同的 API 金鑰令牌類型。你可以透過查看程式碼更好地理解這一點——截至撰寫本文時，Gitea 會解析查詢和標頭以找到令牌，詳見 [modules/auth/auth.go](https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47)。
|
||||
|
||||
## 生成和列出 API 令牌
|
||||
|
||||
可以通過向 `/users/:name/tokens` 發送 `POST` 請求來生成新令牌。
|
||||
可以透過向 `/users/:name/tokens` 發送 `POST` 請求來生成新令牌。
|
||||
|
||||
請注意，`/users/:name/tokens` 是一個特殊端點，需要使用 `BasicAuth` 和密碼進行認證，如下所示：
|
||||
|
||||
@@ -34,24 +36,25 @@ $ curl -H "Content-Type: application/json" -d '{"name":"test"}' -u username:pass
|
||||
{"id":1,"name":"test","sha1":"9fcb1158165773dd010fca5f0cf7174316c3e37d","token_last_eight":"16c3e37d"}
|
||||
```
|
||||
|
||||
`sha1`（令牌）只會返回一次，並且不會以明文形式存儲。當使用 `GET` 請求列出令牌時，它不會顯示；例如：
|
||||
`sha1`（令牌）只會返回一次，並且不會以明文形式儲存。當使用 `GET` 請求列出令牌時，它不會顯示；例如：
|
||||
|
||||
```sh
|
||||
$ curl --url https://yourusername:[email protected]/api/v1/users/<username>/tokens
|
||||
[{"name":"test","sha1":"","token_last_eight:"........":},{"name":"dev","sha1":"","token_last_eight":"........"}]
|
||||
```
|
||||
|
||||
要在啟用雙因素認證的情況下使用基本認證 API，你需要發送一個包含一次性密碼（6 位數旋轉令牌）的額外標頭。標頭示例如 `X-Gitea-OTP: 123456`，其中 `123456` 是你從身份驗證器中獲取的代碼。以下是 curl 請求的示例：
|
||||
要在啟用雙因素認證的情況下使用基本認證 API，你需要發送一個包含一次性密碼（6 位數旋轉令牌）的額外標頭。標頭範例如 `X-Gitea-OTP: 123456`，其中 `123456` 是你從身份驗證器中獲取的程式碼。以下是 curl 請求的範例：
|
||||
|
||||
```sh
|
||||
$ curl -H "X-Gitea-OTP: 123456" --url https://yourusername:[email protected]/api/v1/users/yourusername/tokens
|
||||
```
|
||||
|
||||
你也可以通過 Gitea 安裝的網頁界面創建 API 金鑰令牌：`Settings | Applications | Generate New Token`。
|
||||
你也可以透過 Gitea 安裝的網頁介面建立 API 金鑰令牌：`Settings | Applications | Generate New Token`。
|
||||
|
||||
<a id="oauth2-provider"></a>
|
||||
## OAuth2 提供者
|
||||
|
||||
從 Gitea 的 [OAuth2 提供者](development/oauth2-provider.md) 獲取的訪問令牌可以通過以下方法接受：
|
||||
從 Gitea 的 [OAuth2 提供者](development/oauth2-provider.md) 獲取的存取權杖可以透過以下方法接受：
|
||||
|
||||
- HTTP 標頭中的 `Authorization bearer ...` 標頭
|
||||
- URL 查詢字串中的 `token=...` 參數
|
||||
@@ -78,7 +81,7 @@ curl "http://localhost:4000/api/v1/repos/test1/test1/issues" \
|
||||
|
||||
## 分頁
|
||||
|
||||
API 支援分頁。`page` 和 `limit` 參數用於指定頁碼和每頁的項目數量。如果有多頁，則返回 `Link` 標頭，其中包含下一頁、上一頁和最後一頁的鏈接。還返回 `x-total-count` 以指示項目總數。
|
||||
API 支援分頁。`page` 和 `limit` 參數用於指定頁碼和每頁的專案數量。如果有多頁，則返回 `Link` 標頭，其中包含下一頁、上一頁和最後一頁的鏈接。還返回 `x-total-count` 以指示專案總數。
|
||||
|
||||
```sh
|
||||
curl -v "http://localhost/api/v1/repos/search?limit=1"
|
||||
@@ -100,7 +103,7 @@ OpenAPI 文件位於：
|
||||
|
||||
## Sudo
|
||||
|
||||
API 允許管理員用戶以其他用戶的身份 sudo API 請求。只需添加 `sudo=` 參數或 `Sudo:` 請求標頭，並附上要 sudo 的用戶名。
|
||||
API 允許管理員使用者以其他使用者的身份 sudo API 請求。只需添加 `sudo=` 參數或 `Sudo:` 請求標頭，並附上要 sudo 的使用者名稱。
|
||||
|
||||
## SDKs
|
||||
|
||||
|
||||
+48
-48
@@ -16,27 +16,27 @@ aliases:
|
||||
|
||||
## 安裝 Go
|
||||
|
||||
你應該[安裝 Go](https://go.dev/doc/install) 並正確設置你的 Go 環境。
|
||||
你應該[安裝 Go](https://go.dev/doc/install) 並正確設定你的 Go 環境。
|
||||
|
||||
接下來，[安裝 Node.js 和 npm](https://nodejs.org/en/download/)，這是構建 JavaScript 和 CSS 文件所需的。最低支持的 Node.js 版本是 @minNodeVersion@，建議使用最新的 LTS 版本。
|
||||
接下來，[安裝 Node.js 和 npm](https://nodejs.org/en/download/)，這是構建 JavaScript 和 CSS 文件所需的。最低支援的 Node.js 版本是 @minNodeVersion@，建議使用最新的 LTS 版本。
|
||||
|
||||
:::note
|
||||
當執行需要外部工具的 make 任務時，如 `make watch-backend`，Gitea 會自動下載並構建這些工具。要使用這些工具，你必須將 `"$GOPATH"/bin` 目錄添加到可執行路徑中。如果你不將 Go bin 目錄添加到可執行路徑中，你將需要自行管理這一點。
|
||||
:::
|
||||
|
||||
:::note
|
||||
需要 Go 版本 @minGoVersion@ 或更高版本。Gitea 使用 `gofmt` 來格式化源代碼。然而，`gofmt` 的結果可能因 Go 的版本而異。因此，建議安裝我們持續集成運行的 Go 版本。截至最後更新，Go 版本應為 @goVersion@。
|
||||
需要 Go 版本 @minGoVersion@ 或更高版本。Gitea 使用 `gofmt` 來格式化源程式碼。然而，`gofmt` 的結果可能因 Go 的版本而異。因此，建議安裝我們持續整合運行的 Go 版本。截至最後更新，Go 版本應為 @goVersion@。
|
||||
:::
|
||||
|
||||
要 lint 模板文件，請確保安裝 [Python](https://www.python.org/) 和 [Poetry](https://python-poetry.org/)。
|
||||
|
||||
## 安裝 Make
|
||||
|
||||
Gitea 大量使用 Make 來自動化任務並改進開發。這個指南涵蓋了如何安裝 Make。
|
||||
Gitea 大量使用 Make 來自動化任務並改進開發。這個指南涵蓋瞭如何安裝 Make。
|
||||
|
||||
### 在 Linux 上
|
||||
|
||||
使用包管理器安裝。
|
||||
使用套件管理器安裝。
|
||||
|
||||
在 Ubuntu/Debian 上：
|
||||
|
||||
@@ -65,22 +65,22 @@ sudo yum install make
|
||||
- [Chocolatey 包](https://chocolatey.org/packages/make)。運行 `choco install make`
|
||||
|
||||
:::note
|
||||
如果你嘗試使用 Windows 命令提示符構建，你可能會遇到問題。建議使用上述提示（Git bash 或 MinGW），但如果你只有命令提示符（或可能是 PowerShell），你可以使用 [set](https://docs.microsoft.com/zh-tw/windows-server/administration/windows-commands/set_1) 命令設置環境變量，例如 `set TAGS=bindata`。
|
||||
如果你嘗試使用 Windows 命令提示符構建，你可能會遇到問題。建議使用上述提示（Git bash 或 MinGW），但如果你只有命令提示符（或可能是 PowerShell），你可以使用 [set](https://docs.microsoft.com/zh-tw/windows-server/administration/windows-commands/set_1) 命令設定環境變量，例如 `set TAGS=bindata`。
|
||||
:::
|
||||
|
||||
## 下載和克隆 Gitea 源代碼
|
||||
## 下載和克隆 Gitea 源程式碼
|
||||
|
||||
推薦的方法是使用 `git clone` 獲取源代碼。
|
||||
推薦的方法是使用 `git clone` 獲取源程式碼。
|
||||
|
||||
```bash
|
||||
git clone https://github.com/go-gitea/gitea
|
||||
```
|
||||
|
||||
（由於 go 模塊的出現，不再需要從 `$GOPATH` 內構建 go 項目，因此不再推薦使用 `go get` 方法。）
|
||||
（由於 go 模組的出現，不再需要從 `$GOPATH` 內構建 go 專案，因此不再推薦使用 `go get` 方法。）
|
||||
|
||||
## Fork Gitea
|
||||
|
||||
如上所述下載主要的 Gitea 源代碼。然後，在 GitHub 上 fork [Gitea repository](https://github.com/go-gitea/gitea)，並將 git 遠程 origin 切換到你的 fork 或添加你的 fork 作為另一個遠程：
|
||||
如上所述下載主要的 Gitea 源程式碼。然後，在 GitHub 上 fork [Gitea repository](https://github.com/go-gitea/gitea)，並將 git 遠程 origin 切換到你的 fork 或添加你的 fork 作為另一個遠程：
|
||||
|
||||
```bash
|
||||
# 將原始 Gitea origin 重命名為 upstream
|
||||
@@ -97,13 +97,13 @@ git remote add "$FORK_NAME" "[email protected]:$GITHUB_USERNAME/gitea.git"
|
||||
git fetch --all --prune
|
||||
```
|
||||
|
||||
為了能夠創建 pull request，fork 的倉庫應該被添加為 Gitea 源代碼的遠程。否則，無法推送更改。
|
||||
為了能夠建立 pull request，fork 的儲存庫應該被添加為 Gitea 源程式碼的遠程。否則，無法推送更改。
|
||||
|
||||
## 構建 Gitea（基礎）
|
||||
|
||||
查看我們的[從源代碼構建](installation/from-source.md)的[說明](installation/from-source.md)。
|
||||
查看我們的[從源程式碼構建](installation/from-source.md)的[說明](installation/from-source.md)。
|
||||
|
||||
從源代碼構建的最簡單推薦方法是：
|
||||
從源程式碼構建的最簡單推薦方法是：
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
@@ -111,7 +111,7 @@ TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
|
||||
`build` 目標將執行 `frontend` 和 `backend` 子目標。如果存在 `bindata` 標籤，前端文件將被編譯到二進制文件中。建議在進行前端開發時省略該標籤，以便更改能夠反映出來。
|
||||
|
||||
查看 `make help` 以獲取所有可用的 `make` 目標。還可以查看 [`.drone.yml`](https://github.com/go-gitea/gitea/blob/main/.drone.yml) 了解我們的持續集成如何工作。
|
||||
查看 `make help` 以獲取所有可用的 `make` 目標。還可以查看 [`.drone.yml`](https://github.com/go-gitea/gitea/blob/main/.drone.yml) 瞭解我們的持續整合如何工作。
|
||||
|
||||
## 持續構建
|
||||
|
||||
@@ -128,19 +128,19 @@ make watch-frontend
|
||||
make watch-backend
|
||||
```
|
||||
|
||||
在 macOS 上，監視所有後端源文件可能會達到默認的打開文件限制，可以通過 `ulimit -n 12288` 為當前 shell 或在你的 shell 啟動文件中為所有未來的 shell 增加此限制。
|
||||
在 macOS 上，監視所有後端源文件可能會達到預設的打開文件限制，可以透過 `ulimit -n 12288` 為當前 shell 或在你的 shell 啟動文件中為所有未來的 shell 增加此限制。
|
||||
|
||||
### 格式化、代碼分析和拼寫檢查
|
||||
### 格式化、程式碼分析和拼寫檢查
|
||||
|
||||
我們的持續集成將拒絕未通過代碼 linter（包括格式檢查、代碼分析和拼寫檢查）的 PR。
|
||||
我們的持續整合將拒絕未通過程式碼 linter（包括格式檢查、程式碼分析和拼寫檢查）的 PR。
|
||||
|
||||
你應該格式化你的代碼：
|
||||
你應該格式化你的程式碼：
|
||||
|
||||
```bash
|
||||
make fmt
|
||||
```
|
||||
|
||||
並 lint 源代碼：
|
||||
並 lint 源程式碼：
|
||||
|
||||
```bash
|
||||
# lint 前端和後端代碼
|
||||
@@ -149,7 +149,7 @@ make lint
|
||||
make lint-backend
|
||||
```
|
||||
|
||||
**注意**：`gofmt` 的結果取決於當前的 Go 版本。你應該運行與持續集成服務器上相同版本的 Go，如上所述。
|
||||
**注意**：`gofmt` 的結果取決於當前的 Go 版本。你應該運行與持續整合伺服器上相同版本的 Go，如上所述。
|
||||
|
||||
### 處理 JS 和 CSS
|
||||
|
||||
@@ -167,7 +167,7 @@ make build && ./gitea
|
||||
make lint-frontend
|
||||
```
|
||||
|
||||
### 配置本地 ElasticSearch 實例
|
||||
### 設定本地 ElasticSearch 實例
|
||||
|
||||
使用 docker 啟動本地 ElasticSearch 實例：
|
||||
|
||||
@@ -177,7 +177,7 @@ sudo chown -R 1000:1000 $(pwd)/data/elasticsearch
|
||||
docker run --rm --memory="4g" -p 127.0.0.1:9200:9200 -p 127.0.0.1:9300:9300 -e "discovery.type=single-node" -v "$(pwd)/data/elasticsearch:/usr/share/elasticsearch/data" docker.elastic.co/elasticsearch/elasticsearch:7.16.3
|
||||
```
|
||||
|
||||
配置 `app.ini`：
|
||||
設定 `app.ini`：
|
||||
|
||||
```ini
|
||||
[indexer]
|
||||
@@ -190,21 +190,21 @@ REPO_INDEXER_CONN_STR = http://elastic:changeme@localhost:9200
|
||||
|
||||
### 構建和添加 SVG
|
||||
|
||||
SVG 圖標使用 `make svg` 目標構建，將圖標源編譯到輸出目錄 `public/assets/img/svg` 中。自定義圖標可以添加到 `web_src/svg` 目錄中。
|
||||
SVG 圖標使用 `make svg` 目標構建，將圖標源編譯到輸出目錄 `public/assets/img/svg` 中。自訂圖標可以添加到 `web_src/svg` 目錄中。
|
||||
|
||||
### 構建 Logo
|
||||
|
||||
Gitea 標誌的 PNG 和 SVG 版本是從單個 SVG 源文件 `assets/logo.svg` 使用 `TAGS="gitea" make generate-images` 目標構建的。要運行它，必須有 Node.js 和 npm。
|
||||
|
||||
同樣的過程也可以用來從 SVG 源文件生成自定義標誌 PNG，只需更新 `assets/logo.svg` 並運行 `make generate-images`。省略 `gitea` 標籤將僅更新用戶指定的標誌文件。
|
||||
同樣的過程也可以用來從 SVG 源文件生成自訂標誌 PNG，只需更新 `assets/logo.svg` 並運行 `make generate-images`。省略 `gitea` 標籤將僅更新使用者指定的標誌文件。
|
||||
|
||||
### 更新 API
|
||||
|
||||
在創建新 API 路由或修改現有 API 路由時，你**必須**使用 [go-swagger](https://goswagger.io/) 註釋更新和/或創建 [Swagger](https://swagger.io/docs/specification/2-0/what-is-swagger/) 文檔。這些註釋的結構在[規範](https://goswagger.io/use/spec.html#annotation-syntax)中描述。如果你想了解更多關於 Swagger 結構的信息，可以查看 [Swagger 2.0 文檔](https://swagger.io/docs/specification/2-0/basic-structure/) 或與添加新 API 端點的先前 PR 進行比較，例如 [PR #5483](https://github.com/go-gitea/gitea/pull/5843/files#diff-2e0a7b644cf31e1c8ef7d76b444fe3aaR20)
|
||||
在建立新 API 路由或修改現有 API 路由時，你**必須**使用 [go-swagger](https://goswagger.io/) 註釋更新和/或建立 [Swagger](https://swagger.io/docs/specification/2-0/what-is-swagger/) 文件。這些註釋的結構在[規範](https://goswagger.io/use/spec.html#annotation-syntax)中描述。如果你想了解更多關於 Swagger 結構的資訊，可以查看 [Swagger 2.0 文件](https://swagger.io/docs/specification/2-0/basic-structure/) 或與添加新 API 端點的先前 PR 進行比較，例如 [PR #5483](https://github.com/go-gitea/gitea/pull/5843/files#diff-2e0a7b644cf31e1c8ef7d76b444fe3aaR20)
|
||||
|
||||
你應該小心不要破壞依賴於穩定 API 的下游用戶。一般來說，添加是可以接受的，但刪除或對 API 的根本性更改將被拒絕。
|
||||
你應該小心不要破壞依賴於穩定 API 的下游使用者。一般來說，添加是可以接受的，但刪除或對 API 的根本性更改將被拒絕。
|
||||
|
||||
一旦你創建或更改了一個 API 端點，請使用以下命令重新生成 Swagger 文檔：
|
||||
一旦你建立或更改了一個 API 端點，請使用以下命令重新生成 Swagger 文件：
|
||||
|
||||
```bash
|
||||
make generate-swagger
|
||||
@@ -216,19 +216,19 @@ make generate-swagger
|
||||
make swagger-validate
|
||||
```
|
||||
|
||||
你應該提交更改的 swagger JSON 文件。持續集成服務器將使用以下命令檢查是否已完成此操作：
|
||||
你應該提交更改的 swagger JSON 文件。持續整合伺服器將使用以下命令檢查是否已完成此操作：
|
||||
|
||||
```bash
|
||||
make swagger-check
|
||||
```
|
||||
|
||||
:::note
|
||||
請注意，你應該使用 Swagger 2.0 文檔，而不是 OpenAPI 3 文檔。
|
||||
請注意，你應該使用 Swagger 2.0 文件，而不是 OpenAPI 3 文件。
|
||||
:::
|
||||
|
||||
### 創建新配置選項
|
||||
### 建立新設定選項
|
||||
|
||||
在創建新配置選項時，僅將它們添加到 `modules/setting` 文件中是不夠的。你應該將信息添加到 `custom/conf/app.ini` 和 `docs/content/doc/administer/config-cheat-sheet.zh-tw.md` 中的[配置速查表](../administration/config-cheat-sheet.md)。
|
||||
在建立新設定選項時，僅將它們添加到 `modules/setting` 文件中是不夠的。你應該將資訊添加到 `custom/conf/app.ini` 和 `docs/content/doc/administer/config-cheat-sheet.zh-tw.md` 中的[設定速查表](../administration/config-cheat-sheet.md)。
|
||||
|
||||
### 更改標誌
|
||||
|
||||
@@ -238,11 +238,11 @@ make swagger-check
|
||||
make generate-images
|
||||
```
|
||||
|
||||
這將創建必要的 Gitea favicon 和其他圖標。
|
||||
這將建立必要的 Gitea favicon 和其他圖標。
|
||||
|
||||
### 數據庫遷移
|
||||
### 資料庫遷移
|
||||
|
||||
如果你對 `models/` 目錄中的任何數據庫持久化結構進行了重大更改，你將需要進行新的遷移。這些可以在 `models/migrations/` 中找到。你可以使用以下命令確保你的遷移適用於主要數據庫類型：
|
||||
如果你對 `models/` 目錄中的任何資料庫持久化結構進行了重大更改，你將需要進行新的遷移。這些可以在 `models/migrations/` 中找到。你可以使用以下命令確保你的遷移適用於主要資料庫類型：
|
||||
|
||||
```bash
|
||||
make test-sqlite-migration # 使用 SQLite 進行測試，並根據需要切換到適當的數據庫
|
||||
@@ -250,37 +250,37 @@ make test-sqlite-migration # 使用 SQLite 進行測試，並根據需要切換
|
||||
|
||||
## 測試
|
||||
|
||||
Gitea 運行兩種類型的測試：單元測試和集成測試。
|
||||
Gitea 運行兩種類型的測試：單元測試和整合測試。
|
||||
|
||||
### 單元測試
|
||||
|
||||
單元測試由 `*_test.go` 覆蓋在 `go test` 系統中。你可以設置環境變量 `GITEA_UNIT_TESTS_LOG_SQL=1` 以在詳細模式下運行測試時顯示所有 SQL 語句（即設置 `GOTESTFLAGS=-v`）。
|
||||
單元測試由 `*_test.go` 覆蓋在 `go test` 系統中。你可以設定環境變量 `GITEA_UNIT_TESTS_LOG_SQL=1` 以在詳細模式下運行測試時顯示所有 SQL 語句（即設定 `GOTESTFLAGS=-v`）。
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make test # 運行單元測試
|
||||
```
|
||||
|
||||
### 集成測試
|
||||
### 整合測試
|
||||
|
||||
單元測試無法完全測試 Gitea。因此，我們編寫了集成測試；然而，這些測試依賴於數據庫。
|
||||
單元測試無法完全測試 Gitea。因此，我們編寫了整合測試；然而，這些測試依賴於資料庫。
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build test-sqlite
|
||||
```
|
||||
|
||||
將在 SQLite 環境中運行集成測試。集成測試需要安裝 `git lfs`。其他數據庫測試可用，但可能需要調整本地環境。
|
||||
將在 SQLite 環境中運行整合測試。整合測試需要安裝 `git lfs`。其他資料庫測試可用，但可能需要調整本地環境。
|
||||
|
||||
查看 [`tests/integration/README.md`](https://github.com/go-gitea/gitea/blob/main/tests/integration/README.md) 以獲取更多信息以及如何運行單個測試。
|
||||
查看 [`tests/integration/README.md`](https://github.com/go-gitea/gitea/blob/main/tests/integration/README.md) 以獲取更多資訊以及如何運行單個測試。
|
||||
|
||||
### PR 測試
|
||||
|
||||
我們的持續集成將測試代碼是否通過其單元測試，並且所有支持的數據庫將在 Docker 環境中通過集成測試。還將測試從 Gitea 的幾個最近版本的遷移。
|
||||
我們的持續整合將測試程式碼是否通過其單元測試，並且所有支援的資料庫將在 Docker 環境中通過整合測試。還將測試從 Gitea 的幾個最近版本的遷移。
|
||||
|
||||
請提交你的 PR，並根據需要添加額外的測試和集成測試。
|
||||
請提交你的 PR，並根據需要添加額外的測試和整合測試。
|
||||
|
||||
## 網站文檔
|
||||
## 網站文件
|
||||
|
||||
網站文檔位於 `docs/` 中。如果你更改了這些文檔，可以使用以下命令測試你的更改以確保它們通過持續集成：
|
||||
網站文件位於 `docs/` 中。如果你更改了這些文件，可以使用以下命令測試你的更改以確保它們通過持續整合：
|
||||
|
||||
```bash
|
||||
make lint-md
|
||||
@@ -288,21 +288,21 @@ make lint-md
|
||||
|
||||
## Visual Studio Code
|
||||
|
||||
在 `contrib/ide/vscode` 中提供了 `launch.json` 和 `tasks.json` 用於 Visual Studio Code。查看 [`contrib/ide/README.md`](https://github.com/go-gitea/gitea/blob/main/contrib/ide/README.md) 以獲取更多信息。
|
||||
在 `contrib/ide/vscode` 中提供了 `launch.json` 和 `tasks.json` 用於 Visual Studio Code。查看 [`contrib/ide/README.md`](https://github.com/go-gitea/gitea/blob/main/contrib/ide/README.md) 以獲取更多資訊。
|
||||
|
||||
## GoLand
|
||||
|
||||
點擊 `/main.go` 中 `func main()` 函數上的 `Run Application` 箭頭可以快速啟動可調試的 Gitea 實例。
|
||||
|
||||
`Run/Debug Configuration` 中的 `Output Directory` 必須設置為 gitea 項目目錄（包含 `main.go` 和 `go.mod`），否則啟動的實例的工作目錄將是 GoLand 的臨時目錄，並阻止 Gitea 在開發環境中加載動態資源（例如：模板）。
|
||||
`Run/Debug Configuration` 中的 `Output Directory` 必須設定為 gitea 專案目錄（包含 `main.go` 和 `go.mod`），否則啟動的實例的工作目錄將是 GoLand 的臨時目錄，並阻止 Gitea 在開發環境中加載動態資源（例如：模板）。
|
||||
|
||||
要在 GoLand 中使用 SQLite 運行單元測試，請在 `Run/Debug Configuration` 的 `Go tool arguments` 中設置 `-tags sqlite,sqlite_unlock_notify`。
|
||||
要在 GoLand 中使用 SQLite 運行單元測試，請在 `Run/Debug Configuration` 的 `Go tool arguments` 中設定 `-tags sqlite,sqlite_unlock_notify`。
|
||||
|
||||
## 提交 PR
|
||||
|
||||
一旦你對更改感到滿意，請將它們推送並打開一個 pull request。建議允許 Gitea 管理員和所有者修改你的 PR 分支，因為我們需要在合併之前將其更新到 main，並且/或者可能能夠直接幫助修復問題。
|
||||
|
||||
任何 PR 需要兩個 Gitea 維護者的批准，並且需要通過持續集成。查看我們的 [`CONTRIBUTING.md`](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md) 文檔。
|
||||
任何 PR 需要兩個 Gitea 維護者的批准，並且需要通過持續整合。查看我們的 [`CONTRIBUTING.md`](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md) 文件。
|
||||
|
||||
如果你需要更多幫助，請加入 [Discord](https://discord.gg/gitea) #Develop 聊天。
|
||||
|
||||
|
||||
@@ -8,11 +8,11 @@ aliases:
|
||||
|
||||
# 整合
|
||||
|
||||
Gitea 有一個很棒的第三方整合社群，以及在各種其他項目中的一流支援。
|
||||
Gitea 有一個很棒的第三方整合社群，以及在各種其他專案中的一流支援。
|
||||
|
||||
我們在 [awesome-gitea](https://gitea.com/gitea/awesome-gitea) 上整理了一個列表來追蹤這些整合！
|
||||
|
||||
如果你在尋找 [CI/CD](https://gitea.com/gitea/awesome-gitea#user-content-devops)、[SDK](https://gitea.com/gitea/awesome-gitea#user-content-sdk) 或一些額外的 [主題](https://gitea.com/gitea/awesome-gitea#user-content-themes)，你可以在 [awesome-gitea](https://gitea.com/gitea/awesome-gitea) 倉庫中找到它們！
|
||||
如果你在尋找 [CI/CD](https://gitea.com/gitea/awesome-gitea#user-content-devops)、[SDK](https://gitea.com/gitea/awesome-gitea#user-content-sdk) 或一些額外的 [主題](https://gitea.com/gitea/awesome-gitea#user-content-themes)，你可以在 [awesome-gitea](https://gitea.com/gitea/awesome-gitea) 儲存庫中找到它們！
|
||||
|
||||
## 預填新文件名稱和內容
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ aliases:
|
||||
|
||||
# 遷移介面
|
||||
|
||||
完整的遷移在 Gitea 1.9.0 中引入。它定義了兩個介面來支持從其他 Git 主機平台遷移倉庫數據到 Gitea，或者在未來，將 Gitea 數據遷移到其他 Git 主機平台。
|
||||
完整的遷移在 Gitea 1.9.0 中引入。它定義了兩個介面來支援從其他 Git 主機平台遷移儲存庫資料到 Gitea，或者在未來，將 Gitea 資料遷移到其他 Git 主機平台。
|
||||
|
||||
目前，已實現從 GitHub、GitLab 和其他 Gitea 實例的遷移。
|
||||
|
||||
@@ -18,14 +18,14 @@ aliases:
|
||||
|
||||
要從新的 Git 主機平台遷移，有兩個步驟需要更新。
|
||||
|
||||
- 你應該實現一個 `Downloader`，它將用於獲取倉庫信息。
|
||||
- 你應該實現一個 `DownloaderFactory`，它將用於檢測 URL 是否匹配並創建上述 `Downloader`。
|
||||
- 你應該實現一個 `Downloader`，它將用於獲取儲存庫資訊。
|
||||
- 你應該實現一個 `DownloaderFactory`，它將用於檢測 URL 是否匹配並建立上述 `Downloader`。
|
||||
- 你需要在 `init()` 中通過 `RegisterDownloaderFactory` 註冊 `DownloaderFactory`。
|
||||
|
||||
你可以在 [downloader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/downloader.go) 中找到這些介面。
|
||||
|
||||
## 上傳器介面
|
||||
|
||||
目前，只實現了一個 `GiteaLocalUploader`，因此我們僅通過此 `Uploader` 將下載的數據保存到本地 Gitea 實例。其他上傳器目前不支持。
|
||||
目前，只實現了一個 `GiteaLocalUploader`，因此我們僅透過此 `Uploader` 將下載的資料保存到本地 Gitea 實例。其他上傳器目前不支援。
|
||||
|
||||
你可以在 [uploader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/uploader.go) 中找到這些介面。
|
||||
+54
-53
@@ -8,15 +8,15 @@ aliases:
|
||||
|
||||
# OAuth2 提供者
|
||||
|
||||
Gitea 支援作為 OAuth2 提供者，允許第三方應用程式在用戶同意的情況下訪問其資源。
|
||||
Gitea 支援作為 OAuth2 提供者，允許第三方應用程式在使用者同意的情況下訪問其資源。
|
||||
|
||||
當作為 OAuth2 提供者時，Gitea 會針對相關的 OAuth2 應用程式驗證每個授權請求。此應用程式可以由個別用戶、組織管理員或 Gitea 實例管理員設置。
|
||||
當作為 OAuth2 提供者時，Gitea 會針對相關的 OAuth2 應用程式驗證每個授權請求。此應用程式可以由個別使用者、組織管理員或 Gitea 實例管理員設定。
|
||||
|
||||
無論是誰配置的應用程式，第一次授權嘗試都會在用戶的網頁瀏覽器中打開一個新頁面，提示他們授權應用程式。
|
||||
無論是誰設定的應用程式，第一次授權嘗試都會在使用者的網頁瀏覽器中打開一個新頁面，提示他們授權應用程式。
|
||||
|
||||
## 配置
|
||||
## 設定
|
||||
|
||||
Gitea 中的 OAuth2 應用程式需要以下兩步配置：
|
||||
Gitea 中的 OAuth2 應用程式需要以下兩步設定：
|
||||
|
||||
### Gitea 步驟 1
|
||||
|
||||
@@ -40,38 +40,39 @@ Gitea 中的 OAuth2 應用程式需要以下兩步配置：
|
||||
- 憑證（客戶端 ID 和客戶端密鑰）
|
||||
- 所需的範圍和聲明（預期由 Gitea 提供）
|
||||
|
||||
MinIO 的示例：
|
||||
MinIO 的範例：
|
||||
|
||||
|
||||
|
||||
### Gitea 的用戶批准步驟 3
|
||||
### Gitea 的使用者批准步驟 3
|
||||
|
||||
例如，使用 Gitea 帳戶登錄 MinIO...
|
||||
例如，使用 Gitea 帳戶登入 MinIO...
|
||||
|
||||
|
||||
...在成功登錄後將顯示批准彈出窗口：
|
||||
...在成功登入後將顯示批准彈出窗口：
|
||||
|
||||
|
||||
默認情況下，如果第三方設置範圍為 `openid`、`email`、`profile` 和 `groups`，並且用戶批准，應用程式將獲得用戶所有公共和私人資源（倉庫、問題、用戶信息等）的完全訪問權限。
|
||||
預設情況下，如果第三方設定範圍為 `openid`、`email`、`profile` 和 `groups`，並且使用者批准，應用程式將獲得使用者所有公共和私人資源（儲存庫、問題、使用者資訊等）的完全存取權限。
|
||||
|
||||
> **注意：** 目前，如果期望限制訪問，設置 Gitea 中的 OAuth2 應用程式的管理員必須依賴第三方發送的範圍和知情用戶的批准決定。在應用程式設置過程中，管理員無法通過範圍設置限制訪問。
|
||||
> **注意：** 目前，如果期望限制訪問，設定 Gitea 中的 OAuth2 應用程式的管理員必須依賴第三方發送的範圍和知情使用者的批准決定。在應用程式設定過程中，管理員無法通過範圍設定限制訪問。
|
||||
|
||||
<a id="scopes"></a>
|
||||
## 細粒度範圍
|
||||
|
||||
從 v1.23 版本開始，Gitea 支援細粒度範圍，允許第三方請求更有限的訪問權限。這些範圍以前僅適用於[個人訪問令牌](#scopes)，使用戶能夠限制對特定 URL 路徑的訪問。
|
||||
從 v1.23 版本開始，Gitea 支援細粒度範圍，允許第三方請求更有限的存取權限。這些範圍以前僅適用於[個人存取權杖](api-usage)，使使用者能夠限制對特定 URL 路徑的訪問。
|
||||
|
||||
範圍按高級 API 路徑分組，並進一步細化如下：
|
||||
|
||||
- `read`：`GET` 路徑
|
||||
- `write`：`POST`、`PUT`、`PATCH` 和 `DELETE` 路徑（以及 `GET`）
|
||||
|
||||
例如，第三方可以請求最小訪問權限，允許 Gitea 作為簡單的 OpenID Connect (OIDC) 提供者。如果第三方僅添加 `public-only` 到 'openid'，不添加其他或任何組合的範圍 `email`、`userinfo` 或 `groups`，Gitea 將作為基本的單一登錄提供者。此配置僅提供用戶可以使用正確憑證登錄的驗證，僅提供基本信息，如用戶名、電子郵件和公共組織和團隊成員資格列表。
|
||||
例如，第三方可以請求最小存取權限，允許 Gitea 作為簡單的 OpenID Connect (OIDC) 提供者。如果第三方僅添加 `public-only` 到 'openid'，不添加其他或任何組合的範圍 `email`、`userinfo` 或 `groups`，Gitea 將作為基本的單一登入提供者。此設定僅提供使用者可以使用正確憑證登入的驗證，僅提供基本資訊，如使用者名稱、電子郵件和公共組織和團隊成員資格列表。
|
||||
|
||||
當引入任何來自個人訪問令牌的細粒度範圍時，Gitea 將不允許完全訪問（如默認情況下）。相反，它將根據對倉庫、問題、ActivityPub、管理功能、組織、用戶、包或其他功能的讀寫權限構建細粒度訪問。
|
||||
當引入任何來自個人存取權杖的細粒度範圍時，Gitea 將不允許完全訪問（如預設情況下）。相反，它將根據對儲存庫、問題、ActivityPub、管理功能、組織、使用者、包或其他功能的讀寫權限構建細粒度訪問。
|
||||
|
||||
> **注意：** 如果第三方添加任何範圍以外的 OIDC 範圍：`openid`、`email`、`profile` 和 `groups` 或已在個人訪問令牌中找到的範圍，範圍將回退到完全訪問，如 v1.23 之前的情況。
|
||||
> **注意：** 如果第三方添加任何範圍以外的 OIDC 範圍：`openid`、`email`、`profile` 和 `groups` 或已在個人存取權杖中找到的範圍，範圍將回退到完全訪問，如 v1.23 之前的情況。
|
||||
|
||||
顯示給用戶的批准頁面顯示第三方請求的範圍列表。一旦批准，此決定將被記住。如果第三方在未來的請求中更改其請求的範圍，整個流程將失敗，需要重新授權。
|
||||
顯示給使用者的批准頁面顯示第三方請求的範圍列表。一旦批准，此決定將被記住。如果第三方在未來的請求中更改其請求的範圍，整個流程將失敗，需要重新授權。
|
||||
|
||||
## 端點
|
||||
|
||||
@@ -79,22 +80,22 @@ MinIO 的示例：
|
||||
| ----------------------- | ----------------------------------- |
|
||||
| OpenID Connect 發現 | `/.well-known/openid-configuration` |
|
||||
| 授權端點 | `/login/oauth/authorize` |
|
||||
| 訪問令牌端點 | `/login/oauth/access_token` |
|
||||
| OpenID Connect 用戶信息 | `/login/oauth/userinfo` |
|
||||
| 存取權杖端點 | `/login/oauth/access_token` |
|
||||
| OpenID Connect 使用者資訊 | `/login/oauth/userinfo` |
|
||||
| JSON Web 密鑰集 | `/login/oauth/keys` |
|
||||
|
||||
## 支援的 OAuth2 授權
|
||||
|
||||
目前 Gitea 只支援 [**授權碼授權**](https://tools.ietf.org/html/rfc6749#section-1.3.1) 標準，並額外支援以下擴展：
|
||||
|
||||
- [代碼交換的證明密鑰 (PKCE)](https://tools.ietf.org/html/rfc7636)
|
||||
- [程式碼交換的證明密鑰 (PKCE)](https://tools.ietf.org/html/rfc7636)
|
||||
- [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth)
|
||||
|
||||
要作為第三方應用程式使用授權碼授權，需要通過設置中的“應用程式” (`/user/settings/applications`) 部分註冊新應用程式。要測試或調試，你可以使用網頁工具 https://oauthdebugger.com/。
|
||||
要作為第三方應用程式使用授權碼授權，需要通過設定中的“應用程式” (`/user/settings/applications`) 部分註冊新應用程式。要測試或調試，你可以使用網頁工具 https://oauthdebugger.com/。
|
||||
|
||||
## 範圍
|
||||
|
||||
Gitea 支援範圍訪問令牌，允許用戶限制令牌僅在選定的 URL 路徑上操作。範圍按高級 API 路徑分組，並進一步細化如下：
|
||||
Gitea 支援範圍存取權杖，允許使用者限制令牌僅在選定的 URL 路徑上操作。範圍按高級 API 路徑分組，並進一步細化如下：
|
||||
|
||||
- `read`：`GET` 路徑
|
||||
- `write`：`POST`、`PUT`、`PATCH` 和 `DELETE` 路徑（以及 `GET`）
|
||||
@@ -103,38 +104,38 @@ Gitea 令牌範圍如下：
|
||||
|
||||
| 名稱 | 描述 |
|
||||
| ----------------------------------------- | --------------------------------------------------------------------------------- |
|
||||
| **（無範圍）** | 不支援。即使是公共倉庫也需要範圍。 |
|
||||
| **（無範圍）** | 不支援。即使是公共儲存庫也需要範圍。 |
|
||||
| **activitypub** | `activitypub` API 路徑：ActivityPub 相關操作。 |
|
||||
| **read:activitypub** | 授予 ActivityPub 操作的讀取訪問權限。 |
|
||||
| **write:activitypub** | 授予 ActivityPub 操作的讀寫/刪除訪問權限。 |
|
||||
| **read:activitypub** | 授予 ActivityPub 操作的讀取存取權限。 |
|
||||
| **write:activitypub** | 授予 ActivityPub 操作的讀寫/刪除存取權限。 |
|
||||
| **admin** | `/admin/*` API 路徑：全站管理操作（對非管理帳戶隱藏）。 |
|
||||
| **read:admin** | 授予管理操作的讀取訪問權限，例如獲取計劃任務或註冊用戶電子郵件。 |
|
||||
| **write:admin** | 授予管理操作的讀寫/刪除訪問權限，例如運行計劃任務或更新用戶帳戶。 |
|
||||
| **read:admin** | 授予管理操作的讀取存取權限，例如獲取計劃任務或註冊使用者電子郵件。 |
|
||||
| **write:admin** | 授予管理操作的讀寫/刪除存取權限，例如運行計劃任務或更新使用者帳戶。 |
|
||||
| **issue** | `issues/*`、`labels/*`、`milestones/*` API 路徑：問題相關操作。 |
|
||||
| **read:issue** | 授予問題操作的讀取訪問權限，例如獲取問題評論、問題附件和里程碑。 |
|
||||
| **write:issue** | 授予問題操作的讀寫/刪除訪問權限，例如發布或編輯問題評論或附件，並更新里程碑。 |
|
||||
| **read:issue** | 授予問題操作的讀取存取權限，例如獲取問題評論、問題附件和里程碑。 |
|
||||
| **write:issue** | 授予問題操作的讀寫/刪除存取權限，例如發布或編輯問題評論或附件，並更新里程碑。 |
|
||||
| **misc** | 保留供未來使用。 |
|
||||
| **read:misc** | 保留供未來使用。 |
|
||||
| **write:misc** | 保留供未來使用。 |
|
||||
| **notification** | `notification/*` API 路徑：用戶通知操作。 |
|
||||
| **read:notification** | 授予用戶通知的讀取訪問權限，例如用戶訂閱的通知和閱讀新通知。 |
|
||||
| **write:notification** | 授予用戶通知的讀寫/刪除訪問權限，例如將通知標記為已讀。 |
|
||||
| **notification** | `notification/*` API 路徑：使用者通知操作。 |
|
||||
| **read:notification** | 授予使用者通知的讀取存取權限，例如使用者訂閱的通知和閱讀新通知。 |
|
||||
| **write:notification** | 授予使用者通知的讀寫/刪除存取權限，例如將通知標記為已讀。 |
|
||||
| **organization** | `orgs/*` 和 `teams/*` API 路徑：組織和團隊管理操作。 |
|
||||
| **read:organization** | 授予組織和團隊狀態的讀取訪問權限，例如列出用戶可見的所有組織、團隊和團隊成員。 |
|
||||
| **write:organization** | 授予組織和團隊狀態的讀寫/刪除訪問權限，例如創建和更新團隊以及更新組織設置。 |
|
||||
| **read:organization** | 授予組織和團隊狀態的讀取存取權限，例如列出使用者可見的所有組織、團隊和團隊成員。 |
|
||||
| **write:organization** | 授予組織和團隊狀態的讀寫/刪除存取權限，例如建立和更新團隊以及更新組織設定。 |
|
||||
| **package** | `/packages/*` API 路徑：包操作 |
|
||||
| **read:package** | 授予包操作的讀取訪問權限，例如閱讀和下載可用的包。 |
|
||||
| **write:package** | 授予包操作的讀寫/刪除訪問權限。目前與 `read:package` 相同。 |
|
||||
| **repository** | `/repos/*` API 路徑，除了 `/repos/issues/*`：倉庫文件、拉取請求和發佈操作。 |
|
||||
| **read:repository** | 授予倉庫操作的讀取訪問權限，例如獲取倉庫文件、發佈、協作者。 |
|
||||
| **write:repository** | 授予倉庫操作的讀寫/刪除訪問權限，例如獲取更新倉庫文件、創建拉取請求、更新協作者。 |
|
||||
| **user** | `/user/*` 和 `/users/*` API 路徑：用戶相關操作。 |
|
||||
| **read:user** | 授予用戶操作的讀取訪問權限，例如獲取用戶倉庫訂閱和用戶設置。 |
|
||||
| **write:user** | 授予用戶操作的讀寫/刪除訪問權限，例如更新用戶倉庫訂閱、關注的用戶和用戶設置。 |
|
||||
| **read:package** | 授予包操作的讀取存取權限，例如閱讀和下載可用的包。 |
|
||||
| **write:package** | 授予包操作的讀寫/刪除存取權限。目前與 `read:package` 相同。 |
|
||||
| **repository** | `/repos/*` API 路徑，除了 `/repos/issues/*`：儲存庫文件、拉取請求和發佈操作。 |
|
||||
| **read:repository** | 授予儲存庫操作的讀取存取權限，例如獲取儲存庫文件、發佈、協作者。 |
|
||||
| **write:repository** | 授予儲存庫操作的讀寫/刪除存取權限，例如獲取更新儲存庫文件、建立拉取請求、更新協作者。 |
|
||||
| **user** | `/user/*` 和 `/users/*` API 路徑：使用者相關操作。 |
|
||||
| **read:user** | 授予使用者操作的讀取存取權限，例如獲取使用者儲存庫訂閱和使用者設定。 |
|
||||
| **write:user** | 授予使用者操作的讀寫/刪除存取權限，例如更新使用者儲存庫訂閱、關注的使用者和使用者設定。 |
|
||||
|
||||
## 預配置應用程式
|
||||
## 預設定應用程式
|
||||
|
||||
Gitea 在啟動時默認為以下服務創建 OAuth 應用程式，因為我們認為這些應用程式是普遍有用的。
|
||||
Gitea 在啟動時預設為以下服務建立 OAuth 應用程式，因為我們認為這些應用程式是普遍有用的。
|
||||
|
||||
| 應用程式 | 描述 | 客戶端 ID |
|
||||
| --------------------------------------------------------------------------------- | ------------ | -------------------------------------- |
|
||||
@@ -142,7 +143,7 @@ Gitea 在啟動時默認為以下服務創建 OAuth 應用程式，因為我們
|
||||
| [Git Credential Manager](https://github.com/git-ecosystem/git-credential-manager) | Git 憑證助手 | `e90ee53c-94e2-48ac-9358-a874fb9e0662` |
|
||||
| [tea](https://gitea.com/gitea/tea) | tea | `d57cb8c4-630c-4168-8324-ec79935e18d4` |
|
||||
|
||||
為防止意外行為，它們在 UI 中顯示為鎖定，其創建可以通過 `app.ini` 中的 `DEFAULT_APPLICATIONS` 參數進行控制。
|
||||
為防止意外行為，它們在 UI 中顯示為鎖定，其建立可以透過 `app.ini` 中的 `DEFAULT_APPLICATIONS` 參數進行控制。
|
||||
|
||||
## 客戶端類型
|
||||
|
||||
@@ -150,31 +151,31 @@ Gitea 支援機密和公共客戶端類型，[如 RFC 6749 定義](https://datat
|
||||
|
||||
對於公共客戶端，重定向 URI 為回送 IP 地址，例如 `http://127.0.0.1/` 允許任何端口。避免使用 `localhost`，[如 RFC 8252 建議](https://datatracker.ietf.org/doc/html/rfc8252#section-8.3)。
|
||||
|
||||
## 示例
|
||||
## 範例
|
||||
|
||||
### 機密客戶端
|
||||
|
||||
:::note
|
||||
此示例不使用 PKCE。
|
||||
此範例不使用 PKCE。
|
||||
:::
|
||||
|
||||
1. 將用戶重定向到授權端點以獲取他們對訪問資源的同意：
|
||||
1. 將使用者重定向到授權端點以獲取他們對訪問資源的同意：
|
||||
|
||||
```curl
|
||||
https://[YOUR-GITEA-URL]/login/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=code&state=STATE
|
||||
```
|
||||
|
||||
可以通過在設置中註冊應用程式獲取 `CLIENT_ID`。`STATE` 是一個隨機字串，將在用戶授權後發送回你的應用程式。`state` 參數是可選的，但應該用於防止 CSRF 攻擊。
|
||||
可以透過在設定中註冊應用程式獲取 `CLIENT_ID`。`STATE` 是一個隨機字串，將在使用者授權後發送回你的應用程式。`state` 參數是可選的，但應該用於防止 CSRF 攻擊。
|
||||
|
||||
|
||||
|
||||
現在將要求用戶授權你的應用程式。如果他們授權，用戶將被重定向到 `REDIRECT_URL`，例如：
|
||||
現在將要求使用者授權你的應用程式。如果他們授權，使用者將被重定向到 `REDIRECT_URL`，例如：
|
||||
|
||||
```curl
|
||||
https://[REDIRECT_URI]?code=RETURNED_CODE&state=STATE
|
||||
```
|
||||
|
||||
2. 使用重定向提供的 `code`，你可以請求新的應用程式和刷新令牌。訪問令牌端點接受 `application/json` 和 `application/x-www-form-urlencoded` 主體的 POST 請求，例如：
|
||||
2. 使用重定向提供的 `code`，你可以請求新的應用程式和刷新令牌。存取權杖端點接受 `application/json` 和 `application/x-www-form-urlencoded` 主體的 POST 請求，例如：
|
||||
|
||||
```curl
|
||||
POST https://[YOUR-GITEA-URL]/login/oauth/access_token
|
||||
@@ -201,15 +202,15 @@ Gitea 支援機密和公共客戶端類型，[如 RFC 6749 定義](https://datat
|
||||
}
|
||||
```
|
||||
|
||||
`CLIENT_SECRET` 是為此應用程式生成的唯一密鑰。請注意，密鑰僅在你創建/註冊應用程式後可見，無法恢復。如果你丟失了密鑰，必須通過應用程式設置重新生成密鑰。
|
||||
`CLIENT_SECRET` 是為此應用程式生成的唯一密鑰。請注意，密鑰僅在你建立/註冊應用程式後可見，無法恢復。如果你丟失了密鑰，必須通過應用程式設定重新生成密鑰。
|
||||
|
||||
`access_token` 請求中的 `REDIRECT_URI` 必須與 `authorize` 請求中的 `REDIRECT_URI` 匹配。
|
||||
|
||||
3. 使用 `access_token` 進行 [API 請求](development/api-usage.md#oauth2-provider) 以訪問用戶的資源。
|
||||
3. 使用 `access_token` 進行 [API 請求](api-usage) 以訪問使用者的資源。
|
||||
|
||||
### 公共客戶端 (PKCE)
|
||||
|
||||
PKCE（代碼交換的證明密鑰）是 OAuth 流程的擴展，允許在不需要提供客戶端密鑰的情況下進行安全的憑證交換。
|
||||
PKCE（程式碼交換的證明密鑰）是 OAuth 流程的擴展，允許在不需要提供客戶端密鑰的情況下進行安全的憑證交換。
|
||||
|
||||
**注意**：請確保你已將你的 OAuth 應用程式註冊為公共客戶端。
|
||||
|
||||
|
||||
@@ -20,35 +20,36 @@ aliases:
|
||||
|
||||
1.20 目錄是每次合併提交到 [`release/v1.20`](https://github.com/go-gitea/gitea/tree/release/v1.20) 分支時構建的夜間構建。
|
||||
|
||||
1.20.0 目錄是當 [`v1.20.0`](https://github.com/go-gitea/gitea/releases/tag/v1.20.0) 標籤創建時創建的發布構建。
|
||||
1.20.0 目錄是當 [`v1.20.0`](https://github.com/go-gitea/gitea/releases/tag/v1.20.0) 標籤建立時建立的發布構建。
|
||||
|
||||
夜間構建（1.x）下載將隨著提交合併到各自的分支而變化，它們包含在標籤發布之前的最新更改/修復。
|
||||
|
||||
如果錯誤修復針對 1.20.1，但 1.20.1 尚未發布，您可以獲取 "1.20-nightly" 構建以獲取錯誤修復。
|
||||
|
||||
## 如何找到配置文件 "app.ini"
|
||||
## 如何找到設定文件 "app.ini"
|
||||
|
||||
這取決於您如何安裝 Gitea。如果您沒有手動設置自定義路徑或配置文件的路徑，那麼配置文件 (app.ini) 應該存在於 Gitea 工作路徑的 "custom/conf" 目錄中。一些軟件包供應商可能會使用 "/etc/gitea" 來存儲配置文件，而其他供應商則不會。
|
||||
這取決於您如何安裝 Gitea。如果您沒有手動設定自訂路徑或設定文件的路徑，那麼設定文件 (app.ini) 應該存在於 Gitea 工作路徑的 "custom/conf" 目錄中。一些套件供應商可能會使用 "/etc/gitea" 來儲存設定文件，而其他供應商則不會。
|
||||
|
||||
您可以通過檢查 Gitea 的啟動日誌或閱讀 Gitea 網站管理員 -> 配置摘要來手動查找配置文件 (app.ini)。
|
||||
您可以透過檢查 Gitea 的啟動日誌或閱讀 Gitea 網站管理員 -> 設定摘要來手動查找設定文件 (app.ini)。
|
||||
|
||||
如果您使用的是一些隔離環境（如容器 docker），您看到的路徑通常不是主機文件系統中的實際路徑。在這種情況下，您需要檢查容器的文件系統卷映射並找出主機上配置文件的實際路徑。
|
||||
如果您使用的是一些隔離環境（如容器 docker），您看到的路徑通常不是主機文件系統中的實際路徑。在這種情況下，您需要檢查容器的文件系統卷映射並找出主機上設定文件的實際路徑。
|
||||
|
||||
## Gitea 存儲文件的位置
|
||||
<a id="where-does-gitea-store-what-file"></a>
|
||||
## Gitea 儲存文件的位置
|
||||
|
||||
- _`AppWorkPath`_
|
||||
- `app.ini` 中的 `WORK_PATH` 選項
|
||||
- 否則 `--work-path` 標誌
|
||||
- 否則環境變量 `GITEA_WORK_DIR`
|
||||
- 否則在構建時設置的內置值
|
||||
- 否則在構建時設定的內置值
|
||||
- 否則包含 Gitea 二進制文件的目錄
|
||||
- `AppDataPath`（默認為數據庫、索引器等）
|
||||
- `AppDataPath`（預設為資料庫、索引器等）
|
||||
- `app.ini` 中的 `APP_DATA_PATH`
|
||||
- 否則 _`AppWorkPath`_`/data`
|
||||
- _`CustomPath`_（自定義模板）
|
||||
- _`CustomPath`_（自訂模板）
|
||||
- `--custom-path` 標誌
|
||||
- 否則環境變量 `GITEA_CUSTOM`
|
||||
- 否則在構建時設置的內置值
|
||||
- 否則在構建時設定的內置值
|
||||
- 否則 _`AppWorkPath`_`/custom`
|
||||
- HomeDir
|
||||
- Unix：環境變量 `HOME`
|
||||
@@ -56,12 +57,12 @@ aliases:
|
||||
- RepoRootPath
|
||||
- `app.ini` 中 \[repository] 部分的 `ROOT`（如果是絕對路徑）
|
||||
- 否則 _`AppWorkPath`_`/ROOT`（如果 `app.ini` 中 \[repository] 部分的 `ROOT` 是相對路徑）
|
||||
- 默認 `%(APP_DATA_PATH)/gitea-repositories`
|
||||
- INI（配置文件）
|
||||
- 預設 `%(APP_DATA_PATH)/gitea-repositories`
|
||||
- INI（設定文件）
|
||||
- `--config` 標誌
|
||||
- 構建時設置的可能內置值
|
||||
- 構建時設定的可能內置值
|
||||
- 否則 _`CustomPath`_`/conf/app.ini`
|
||||
- SQLite 數據庫
|
||||
- SQLite 資料庫
|
||||
- `app.ini` 中 `database` 部分的 `PATH`
|
||||
- 否則 `%(APP_DATA_PATH)/gitea.db`
|
||||
|
||||
@@ -70,13 +71,13 @@ aliases:
|
||||
有幾個地方可能會導致顯示不正確。
|
||||
|
||||
1. 如果使用反向代理，請確保您已按照[反向代理指南](../administration/reverse-proxies.md)中的正確指示進行操作
|
||||
2. 確保您已正確設置 `app.ini` 中 `server` 部分的 `ROOT_URL`
|
||||
2. 確保您已正確設定 `app.ini` 中 `server` 部分的 `ROOT_URL`
|
||||
|
||||
如果某些克隆選項未顯示（HTTP/S 或 SSH），可以在 `app.ini` 中檢查以下選項
|
||||
|
||||
- `DISABLE_HTTP_GIT`：如果設置為 true，則不會有 HTTP/HTTPS 連接
|
||||
- `DISABLE_SSH`：如果設置為 true，則不會有 SSH 連接
|
||||
- `SSH_EXPOSE_ANONYMOUS`：如果設置為 false，則匿名用戶將隱藏 SSH 連接
|
||||
- `DISABLE_HTTP_GIT`：如果設定為 true，則不會有 HTTP/HTTPS 連接
|
||||
- `DISABLE_SSH`：如果設定為 true，則不會有 SSH 連接
|
||||
- `SSH_EXPOSE_ANONYMOUS`：如果設定為 false，則匿名使用者將隱藏 SSH 連接
|
||||
|
||||
## 文件上傳失敗：413 Request Entity Too Large
|
||||
|
||||
@@ -84,43 +85,43 @@ aliases:
|
||||
|
||||
請參閱[反向代理指南](../administration/reverse-proxies.md)以獲取 nginx 的解決方案。
|
||||
|
||||
## 自定義模板未加載或工作不正確
|
||||
## 自訂模板未加載或工作不正確
|
||||
|
||||
Gitea 的自定義模板必須添加到正確的位置，否則 Gitea 將無法找到並使用它們。
|
||||
Gitea 的自訂模板必須添加到正確的位置，否則 Gitea 將無法找到並使用它們。
|
||||
|
||||
模板的正確路徑將相對於 `CustomPath`
|
||||
|
||||
1. 要查找 `CustomPath`，請在網站管理 -> 配置中查找自定義文件根路徑
|
||||
2. 如果您仍然無法找到路徑，可以[在上面計算](#where-does-gitea-store-what-file)默認值
|
||||
3. 一旦您找到了正確的自定義路徑，您可以參考[自定義 Gitea](../administration/customizing-gitea.md)頁面將模板添加到正確的位置。
|
||||
1. 要查找 `CustomPath`，請在網站管理 -> 設定中查找自訂文件根路徑
|
||||
2. 如果您仍然無法找到路徑，可以在上面計算預設值
|
||||
3. 一旦您找到了正確的自訂路徑，您可以參考[自訂 Gitea](../administration/customizing-gitea.md)頁面將模板添加到正確的位置。
|
||||
|
||||
## Gitea 是否有 "GitHub/GitLab pages" 功能？
|
||||
|
||||
Gitea 沒有內置的 Pages 服務器。您需要一個專用域來提供靜態頁面以避免 CSRF 安全風險。
|
||||
Gitea 沒有內置的 Pages 伺服器。您需要一個專用域來提供靜態頁面以避免 CSRF 安全風險。
|
||||
|
||||
對於簡單的使用，您可以使用反向代理來重寫並從 Gitea 的原始文件 URL 提供靜態內容。
|
||||
|
||||
已經有可用的第三方服務，如獨立的[pages 服務器](https://codeberg.org/Codeberg/pages-server)或[caddy 插件](https://github.com/42wim/caddy-gitea)，可以提供所需的功能。
|
||||
已經有可用的第三方服務，如獨立的[pages 伺服器](https://codeberg.org/Codeberg/pages-server)或[caddy 外掛](https://github.com/42wim/caddy-gitea)，可以提供所需的功能。
|
||||
|
||||
## 活躍用戶與禁止登錄用戶
|
||||
## 活躍使用者與禁止登入使用者
|
||||
|
||||
在 Gitea 中，“活躍”用戶是指通過電子郵件激活其帳戶的用戶。
|
||||
在 Gitea 中，“活躍”使用者是指通過電子郵件激活其帳戶的使用者。
|
||||
|
||||
“禁止登錄”用戶是指不再允許登錄 Gitea 的用戶
|
||||
“禁止登入”使用者是指不再允許登入 Gitea 的使用者
|
||||
|
||||
## 什麼是 Swagger？
|
||||
|
||||
[Swagger](https://swagger.io/) 是 Gitea 用於其 API 文檔的工具。
|
||||
[Swagger](https://swagger.io/) 是 Gitea 用於其 API 文件的工具。
|
||||
|
||||
所有 Gitea 實例都有內置的 API，無法完全禁用它。
|
||||
但是，您可以通過在 `app.ini` 的 `api` 部分中設置 `ENABLE_SWAGGER` 為 `false` 來禁用顯示其文檔。
|
||||
有關更多信息，請參閱 Gitea 的 [API 文檔](development/api-usage.md)。
|
||||
但是，您可以透過在 `app.ini` 的 `api` 部分中設定 `ENABLE_SWAGGER` 為 `false` 來禁用顯示其文件。
|
||||
有關更多資訊，請參閱 Gitea 的 [API 文件](development/api-usage.md)。
|
||||
|
||||
您可以在 https://gitea.com/api/swagger 上查看最新的 API（例如）
|
||||
|
||||
您還可以在 https://gitea.com/swagger.v1.json 上查看 `swagger.json` 文件的示例
|
||||
您還可以在 https://gitea.com/swagger.v1.json 上查看 `swagger.json` 文件的範例
|
||||
|
||||
## 調整您的服務器以供公用/私用
|
||||
## 調整您的伺服器以供公用/私用
|
||||
|
||||
### 防止垃圾郵件
|
||||
|
||||
@@ -128,48 +129,48 @@ Gitea 沒有內置的 Pages 服務器。您需要一個專用域來提供靜態
|
||||
|
||||
1. 通過白名單或黑名單某些電子郵件域
|
||||
2. 通過僅白名單某些域與 OpenID（見下文）
|
||||
3. 在 `app.ini` 中設置 `ENABLE_CAPTCHA` 為 `true` 並正確配置 `RECAPTCHA_SECRET` 和 `RECAPTCHA_SITEKEY`
|
||||
4. 設置 `DISABLE_REGISTRATION` 為 `true` 並通過 [CLI](../administration/command-line.md)、[API](development/api-usage.md) 或 Gitea 的管理 UI 創建新用戶
|
||||
3. 在 `app.ini` 中設定 `ENABLE_CAPTCHA` 為 `true` 並正確設定 `RECAPTCHA_SECRET` 和 `RECAPTCHA_SITEKEY`
|
||||
4. 設定 `DISABLE_REGISTRATION` 為 `true` 並通過 [CLI](../administration/command-line.md)、[API](development/api-usage.md) 或 Gitea 的管理 UI 建立新使用者
|
||||
|
||||
### 只允許/阻止某些電子郵件域
|
||||
|
||||
您可以在 `app.ini` 的 `[service]` 部分中配置 `EMAIL_DOMAIN_WHITELIST` 或 `EMAIL_DOMAIN_BLOCKLIST`
|
||||
您可以在 `app.ini` 的 `[service]` 部分中設定 `EMAIL_DOMAIN_WHITELIST` 或 `EMAIL_DOMAIN_BLOCKLIST`
|
||||
|
||||
### 只允許/阻止某些 OpenID 提供商
|
||||
|
||||
您可以在 `app.ini` 的 `[openid]` 部分中配置 `WHITELISTED_URIS` 或 `BLACKLISTED_URIS`
|
||||
您可以在 `app.ini` 的 `[openid]` 部分中設定 `WHITELISTED_URIS` 或 `BLACKLISTED_URIS`
|
||||
|
||||
:::note
|
||||
白名單優先，如果它不是空白的，則忽略黑名單。
|
||||
:::
|
||||
|
||||
### 僅限問題用戶
|
||||
### 僅限問題使用者
|
||||
|
||||
目前的實現方式是創建/修改用戶，將其最大倉庫創建限制設置為 0。
|
||||
目前的實現方式是建立/修改使用者，將其最大儲存庫建立限制設定為 0。
|
||||
|
||||
### 受限用戶
|
||||
### 受限使用者
|
||||
|
||||
受限用戶僅限於根據其組織/團隊成員資格和協作關係訪問部分內容，忽略組織/倉庫等的公共標誌。
|
||||
受限使用者僅限於根據其組織/團隊成員資格和協作關係訪問部分內容，忽略組織/儲存庫等的公共標誌。
|
||||
|
||||
示例用例：一家公司運行一個需要登錄的 Gitea 實例。大多數倉庫是公共的（所有同事都可以訪問/瀏覽）。
|
||||
範例用例：一家公司運行一個需要登入的 Gitea 實例。大多數儲存庫是公共的（所有同事都可以訪問/瀏覽）。
|
||||
|
||||
某個時候，客戶或第三方需要訪問特定倉庫並且僅限於該倉庫。將此類客戶帳戶設置為受限並使用團隊成員資格和/或協作關係授予所需的訪問權限是一種簡單的方法，無需將所有內容設置為私有。
|
||||
某個時候，客戶或第三方需要訪問特定儲存庫並且僅限於該儲存庫。將此類客戶帳戶設定為受限並使用團隊成員資格和/或協作關係授予所需的存取權限是一種簡單的方法，無需將所有內容設定為私有。
|
||||
|
||||
### 啟用 Fail2ban
|
||||
|
||||
使用 [Fail2Ban](../administration/fail2ban-setup.md) 監控並阻止基於日誌模式的自動登錄嘗試或其他惡意行為
|
||||
使用 [Fail2Ban](../administration/fail2ban-setup.md) 監控並阻止基於日誌模式的自動登入嘗試或其他惡意行為
|
||||
|
||||
## SSHD 與內置 SSH
|
||||
|
||||
SSHD 是大多數 Unix 系統上的內置 SSH 服務器。
|
||||
SSHD 是大多數 Unix 系統上的內置 SSH 伺服器。
|
||||
|
||||
Gitea 也提供了自己的 SSH 服務器，用於 SSHD 不可用時使用。
|
||||
Gitea 也提供了自己的 SSH 伺服器，用於 SSHD 不可用時使用。
|
||||
|
||||
## 翻譯不正確/如何添加更多翻譯
|
||||
|
||||
我們的翻譯目前在我們的 [Crowdin 項目](https://crowdin.com/project/gitea) 上進行群眾外包
|
||||
我們的翻譯目前在我們的 [Crowdin 專案](https://crowdin.com/project/gitea) 上進行群眾外包
|
||||
|
||||
無論您是想更改翻譯還是添加新翻譯，都需要在那裡進行，因為所有翻譯都會在我們的 CI 中通過 Crowdin 集成進行覆蓋。
|
||||
無論您是想更改翻譯還是添加新翻譯，都需要在那裡進行，因為所有翻譯都會在我們的 CI 中通過 Crowdin 整合進行覆蓋。
|
||||
|
||||
## 推送 Hook / Webhook / Actions 未運行
|
||||
|
||||
@@ -177,15 +178,15 @@ Gitea 也提供了自己的 SSH 服務器，用於 SSHD 不可用時使用。
|
||||
|
||||
有幾種可能性：
|
||||
|
||||
1. git hooks 不同步：在網站管理面板上運行“重新同步所有倉庫的 pre-receive、update 和 post-receive hooks”
|
||||
2. git 倉庫（和 hooks）存儲在某些文件系統上（例如由 NAS 掛載）不支持腳本執行，確保文件系統支持 `chmod a+x any-script`
|
||||
3. 如果您使用 docker，確保 Docker 服務器（不是客戶端）>= 20.10.6
|
||||
1. git hooks 不同步：在網站管理面板上運行“重新同步所有儲存庫的 pre-receive、update 和 post-receive hooks”
|
||||
2. git 儲存庫（和 hooks）儲存在某些文件系統上（例如由 NAS 掛載）不支援腳本執行，確保文件系統支援 `chmod a+x any-script`
|
||||
3. 如果您使用 docker，確保 Docker 伺服器（不是客戶端）>= 20.10.6
|
||||
|
||||
## SSH 問題
|
||||
|
||||
如果您無法通過 `ssh` 訪問倉庫，但 `https` 正常工作，請考慮查看以下內容。
|
||||
如果您無法通過 `ssh` 訪問儲存庫，但 `https` 正常工作，請考慮查看以下內容。
|
||||
|
||||
首先，確保您可以通過 SSH 訪問 Gitea。
|
||||
首先，確保您可以透過 SSH 訪問 Gitea。
|
||||
|
||||
`ssh [email protected]`
|
||||
|
||||
@@ -198,7 +199,7 @@ If this is unexpected, please log in with password and setup Gitea under another
|
||||
|
||||
如果您沒有收到上述消息但仍然連接，這意味著您的 SSH 密鑰**未**由 Gitea 管理。這意味著 hooks 不會運行，還有其他潛在問題。
|
||||
|
||||
如果您無法連接，您的 SSH 密鑰可能在本地配置不正確。
|
||||
如果您無法連接，您的 SSH 密鑰可能在本地設定不正確。
|
||||
這是特定於 SSH 而不是 Gitea 的問題，因此不在此處涵蓋。
|
||||
|
||||
### SSH 常見錯誤
|
||||
@@ -208,25 +209,25 @@ Permission denied (publickey).
|
||||
fatal: Could not read from remote repository.
|
||||
```
|
||||
|
||||
此錯誤表示服務器拒絕了登錄嘗試，請檢查以下內容：
|
||||
此錯誤表示伺服器拒絕了登入嘗試，請檢查以下內容：
|
||||
|
||||
- 在客戶端：
|
||||
- 確保公鑰和私鑰已添加到正確的 Gitea 用戶。
|
||||
- 確保遠程 URL 中沒有問題。特別是，確保 Git 用戶名（在 `@` 之前）拼寫正確。
|
||||
- 確保公鑰和私鑰已添加到正確的 Gitea 使用者。
|
||||
- 確保遠程 URL 中沒有問題。特別是，確保 Git 使用者名稱（在 `@` 之前）拼寫正確。
|
||||
- 確保客戶端機器上的公鑰和私鑰正確。
|
||||
- 在服務器上：
|
||||
- 在伺服器上：
|
||||
|
||||
- 確保倉庫存在並且名稱正確。
|
||||
- 檢查系統用戶主目錄中 `.ssh` 目錄的權限。
|
||||
- 確保儲存庫存在並且名稱正確。
|
||||
- 檢查系統使用者主目錄中 `.ssh` 目錄的權限。
|
||||
- 驗證正確的公鑰已添加到 `.ssh/authorized_keys`。
|
||||
|
||||
嘗試在 Gitea 管理面板上運行“重寫 '.ssh/authorized_keys' 文件（用於 Gitea SSH 密鑰）”。
|
||||
|
||||
- 閱讀 Gitea 日誌。
|
||||
- 閱讀 /var/log/auth（或類似）。
|
||||
- 檢查倉庫的權限。
|
||||
- 檢查儲存庫的權限。
|
||||
|
||||
以下是缺少公鑰的示例，其中身份驗證成功，但某些其他設置阻止 SSH 訪問正確的倉庫。
|
||||
以下是缺少公鑰的範例，其中身份驗證成功，但某些其他設定阻止 SSH 訪問正確的儲存庫。
|
||||
|
||||
```
|
||||
fatal: Could not read from remote repository.
|
||||
@@ -235,77 +236,77 @@ Please make sure you have the correct access rights
|
||||
and the repository exists.
|
||||
```
|
||||
|
||||
在這種情況下，請查看以下設置：
|
||||
在這種情況下，請查看以下設定：
|
||||
|
||||
- 在服務器上：
|
||||
- 確保 `git` 系統用戶設置了可用的 shell
|
||||
- 在伺服器上：
|
||||
- 確保 `git` 系統使用者設定了可用的 shell
|
||||
- 使用 `getent passwd git | cut -d: -f7` 驗證
|
||||
- 可以使用 `usermod` 或 `chsh` 進行修改。
|
||||
- 確保 `.ssh/authorized_keys` 中的 `gitea serv` 命令使用正確的配置文件。
|
||||
- 確保 `.ssh/authorized_keys` 中的 `gitea serv` 命令使用正確的設定文件。
|
||||
|
||||
## 遷移帶有標籤的倉庫後缺少發布
|
||||
## 遷移帶有標籤的儲存庫後缺少發布
|
||||
|
||||
要遷移帶有所有標籤的倉庫，您需要做兩件事：
|
||||
要遷移帶有所有標籤的儲存庫，您需要做兩件事：
|
||||
|
||||
- 將標籤推送到倉庫：
|
||||
- 將標籤推送到儲存庫：
|
||||
|
||||
```
|
||||
git push --tags
|
||||
```
|
||||
|
||||
- 在 Gitea 中（重新）同步所有倉庫的標籤：
|
||||
- 在 Gitea 中（重新）同步所有儲存庫的標籤：
|
||||
|
||||
```
|
||||
gitea admin repo-sync-releases
|
||||
```
|
||||
|
||||
## 如何在啟動 Gitea 之前創建用戶
|
||||
## 如何在啟動 Gitea 之前建立使用者
|
||||
|
||||
Gitea 提供了一個子命令 `gitea migrate` 來初始化數據庫，之後您可以使用 [admin CLI 命令](../administration/command-line.md#admin) 像正常一樣添加用戶。
|
||||
Gitea 提供了一個子命令 `gitea migrate` 來初始化資料庫，之後您可以使用 [admin CLI 命令](../administration/command-line.md#admin) 像正常一樣添加使用者。
|
||||
|
||||
## 如何啟用密碼重置
|
||||
|
||||
沒有密碼重置的設置。當配置了[郵件服務](../administration/email-setup.md)時，它會啟用，否則禁用。
|
||||
沒有密碼重置的設定。當設定了[郵件服務](../administration/email-setup.md)時，它會啟用，否則禁用。
|
||||
|
||||
## 如何更改用戶的密碼
|
||||
## 如何更改使用者的密碼
|
||||
|
||||
- 作為**管理員**，您可以更改任何用戶的密碼（並可選擇強制他們在下次登錄時更改）...
|
||||
- 作為**管理員**，您可以更改任何使用者的密碼（並可選擇強制他們在下次登入時更改）...
|
||||
|
||||
- 通過導航到您的 `網站管理 -> 用戶帳戶` 頁面並編輯用戶。
|
||||
- 通過導航到您的 `網站管理 -> 用戶帳戶` 頁面並編輯使用者。
|
||||
- 通過使用 [admin CLI 命令](../administration/command-line.md#admin)。
|
||||
|
||||
請記住，大多數命令還需要一個[全局標誌](../administration/command-line.md#global-options)來指向正確的配置。
|
||||
請記住，大多數命令還需要一個[全域標誌](../administration/command-line.md#global-options)來指向正確的設定。
|
||||
|
||||
- 作為**用戶**，您可以更改它...
|
||||
- 作為**使用者**，您可以更改它...
|
||||
|
||||
- 在您的帳戶 `設置 -> 帳戶` 頁面（此方法**需要**您知道當前密碼）。
|
||||
- 通過使用 `忘記密碼` 連結。
|
||||
|
||||
如果 `忘記密碼/帳戶恢復` 頁面被禁用，請聯繫您的管理員配置[郵件服務](../administration/email-setup.md)。
|
||||
如果 `忘記密碼/帳戶恢復` 頁面被禁用，請聯繫您的管理員設定[郵件服務](../administration/email-setup.md)。
|
||||
|
||||
## 數據庫啟動期間有關結構默認值的警告
|
||||
## 資料庫啟動期間有關結構預設值的警告
|
||||
|
||||
有時在進行遷移時，舊列和默認值可能會保留在數據庫模式中。這可能會導致如下警告：
|
||||
有時在進行遷移時，舊列和預設值可能會保留在資料庫模式中。這可能會導致如下警告：
|
||||
|
||||
```
|
||||
2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync() [W] Table user Column keep_activity_private db default is , struct default is 0
|
||||
```
|
||||
|
||||
這些警告可以安全地忽略，但您可以通過讓 Gitea 重新創建這些表來停止這些警告：
|
||||
這些警告可以安全地忽略，但您可以透過讓 Gitea 重新建立這些表來停止這些警告：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table user
|
||||
```
|
||||
|
||||
這將使 Gitea 重新創建用戶表並將舊數據複製到新表中，並適當設置默認值。
|
||||
這將使 Gitea 重新建立使用者表並將舊資料複製到新表中，並適當設定預設值。
|
||||
|
||||
您可以讓 Gitea 重新創建多個表：
|
||||
您可以讓 Gitea 重新建立多個表：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table table1 table2 ...
|
||||
```
|
||||
|
||||
如果您希望 Gitea 重新創建所有表，只需調用：
|
||||
如果您希望 Gitea 重新建立所有表，只需調用：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table
|
||||
|
||||
@@ -19,13 +19,13 @@ aliases:
|
||||
|
||||
# 錯誤報告
|
||||
|
||||
如果您發現錯誤，請[在 GitHub 上創建問題](https://github.com/go-gitea/gitea/issues)。
|
||||
如果您發現錯誤，請[在 GitHub 上建立問題](https://github.com/go-gitea/gitea/issues)。
|
||||
|
||||
:::note
|
||||
尋求支援時，最好準備以下信息，以便幫助您的人擁有所有需要的信息：
|
||||
尋求支援時，最好準備以下資訊，以便幫助您的人擁有所有需要的資訊：
|
||||
:::
|
||||
|
||||
1. 您的 `app.ini`（必要時刪除任何敏感數據）。
|
||||
1. 您的 `app.ini`（必要時刪除任何敏感資料）。
|
||||
2. 您看到的任何錯誤消息。
|
||||
3. Gitea 日誌以及與情況相關的所有其他日誌。
|
||||
- 收集 `trace` / `debug` 級別的日誌更有用（請參閱下一節）。
|
||||
@@ -33,17 +33,17 @@ aliases:
|
||||
- 使用 docker 時，使用 `docker logs --tail 1000 <gitea-container>` 收集日誌。
|
||||
4. 可重現的步驟，以便其他人可以更快、更輕鬆地重現和理解問題。
|
||||
- 可以使用 [demo.gitea.com](https://demo.gitea.com) 重現問題。
|
||||
5. 如果您遇到緩慢/掛起/死鎖問題，請在問題發生時報告堆棧跟踪。
|
||||
轉到“網站管理” -> “監控” -> “堆棧跟踪” -> “下載診斷報告”。
|
||||
5. 如果您遇到緩慢/掛起/死鎖問題，請在問題發生時報告堆棧跟蹤。
|
||||
轉到“網站管理” -> “監控” -> “堆棧跟蹤” -> “下載診斷報告”。
|
||||
|
||||
# 高級錯誤報告提示
|
||||
|
||||
## 更多日誌配置選項
|
||||
## 更多日誌設定選項
|
||||
|
||||
默認情況下，日誌輸出到控制台，級別為 `info`。
|
||||
如果您需要設置日誌級別和/或從文件中收集日誌，
|
||||
您可以將以下配置複製到您的 `app.ini`（刪除所有其他 `[log]` 部分），
|
||||
然後您將在 Gitea 的日誌目錄（默認：`%(GITEA_WORK_DIR)/log`）中找到 `*.log` 文件。
|
||||
預設情況下，日誌輸出到控制檯，級別為 `info`。
|
||||
如果您需要設定日誌級別和/或從文件中收集日誌，
|
||||
您可以將以下設定複製到您的 `app.ini`（刪除所有其他 `[log]` 部分），
|
||||
然後您將在 Gitea 的日誌目錄（預設：`%(GITEA_WORK_DIR)/log`）中找到 `*.log` 文件。
|
||||
|
||||
```ini
|
||||
; 要顯示所有 SQL 日誌，您還可以在 [database] 部分中設置 LOG_SQL=true
|
||||
@@ -52,13 +52,13 @@ LEVEL=debug
|
||||
MODE=console,file
|
||||
```
|
||||
|
||||
## 通過命令行收集堆棧跟踪
|
||||
## 通過命令行收集堆棧跟蹤
|
||||
|
||||
Gitea 可以使用 Golang 的 pprof 處理程序和工具鏈來收集堆棧跟踪和其他運行時信息。
|
||||
Gitea 可以使用 Golang 的 pprof 處理程式和工具鏈來收集堆棧跟蹤和其他運行時資訊。
|
||||
|
||||
如果 Web UI 停止工作，您可以嘗試通過命令行收集堆棧跟踪：
|
||||
如果 Web UI 停止工作，您可以嘗試通過命令行收集堆棧跟蹤：
|
||||
|
||||
1. 設置 `app.ini`：
|
||||
1. 設定 `app.ini`：
|
||||
|
||||
```
|
||||
[server]
|
||||
@@ -68,4 +68,4 @@ Gitea 可以使用 Golang 的 pprof 處理程序和工具鏈來收集堆棧跟
|
||||
2. 重啟 Gitea
|
||||
|
||||
3. 嘗試觸發錯誤，當請求卡住一段時間時，
|
||||
使用 `curl` 或瀏覽器訪問：`http://127.0.0.1:6060/debug/pprof/goroutine?debug=1` 獲取堆棧跟踪。
|
||||
使用 `curl` 或瀏覽器訪問：`http://127.0.0.1:6060/debug/pprof/goroutine?debug=1` 獲取堆棧跟蹤。
|
||||
@@ -6,101 +6,101 @@ sidebar_position: 10
|
||||
|
||||
# 什麼是 Gitea？
|
||||
|
||||
Gitea 是一個無痛、自我託管的全方位軟體開發服務。它包括 Git 託管、代碼審查、團隊協作、包註冊表和 CI/CD。它類似於 GitHub、Bitbucket 和 GitLab。
|
||||
Gitea 是一個無痛、自我託管的全方位軟體開發服務。它包括 Git 託管、程式碼審查、團隊協作、包註冊表和 CI/CD。它類似於 GitHub、Bitbucket 和 GitLab。
|
||||
|
||||
Gitea 最初是從 [Gogs](https://gogs.io) 分叉出來的，幾乎所有的代碼都已經改變。請參閱 [Gitea 公告](https://blog.gitea.com/welcome-to-gitea/) 博客文章以了解分叉的理由。
|
||||
Gitea 最初是從 [Gogs](https://gogs.io) 分叉出來的，幾乎所有的程式碼都已經改變。請參閱 [Gitea 公告](https://blog.gitea.com/welcome-to-gitea/) 部落格文章以瞭解分叉的理由。
|
||||
|
||||
:::warning
|
||||
|
||||
Gitea 不會從上游發送或挑選提交，因此如果您從 Gogs 升級到 Gitea，無法保證它能正常工作。建議的方法是將存儲庫從 Gogs 遷移到 Gitea。
|
||||
Gitea 不會從上游發送或挑選提交，因此如果您從 Gogs 升級到 Gitea，無法保證它能正常工作。建議的方法是將儲存庫從 Gogs 遷移到 Gitea。
|
||||
|
||||
:::
|
||||
|
||||
## 目的
|
||||
|
||||
這個項目的目標是提供最簡單、最快速、最無痛的方式來設置自我託管的 Git 服務。
|
||||
這個專案的目標是提供最簡單、最快速、最無痛的方式來設定自我託管的 Git 服務。
|
||||
|
||||
使用 Go，可以在 Go 支持的 **所有平台** 上跨平台獨立完成，包括 Linux、macOS 和 Windows，支持 x86、amd64、ARM 和 PowerPC 架構。
|
||||
使用 Go，可以在 Go 支援的 **所有平台** 上跨平台獨立完成，包括 Linux、macOS 和 Windows，支援 x86、amd64、ARM 和 PowerPC 架構。
|
||||
您可以使用 [在線演示](https://demo.gitea.com) 試用。
|
||||
|
||||
## 功能
|
||||
|
||||
- **代碼託管**
|
||||
- **程式碼託管**
|
||||
|
||||
Gitea 支持創建和管理存儲庫、瀏覽提交歷史和代碼文件、審查和合併代碼提交、管理協作者、處理分支等。它還支持許多常見的 Git 功能，如標籤、挑選、鉤子、集成協作工具等。
|
||||
Gitea 支援建立和管理儲存庫、瀏覽提交歷史和程式碼檔案、審查和合併程式碼提交、管理協作者、處理分支等。它還支援許多常見的 Git 功能，如標籤、挑選、鉤子、整合協作工具等。
|
||||
|
||||
- **輕量且快速**
|
||||
|
||||
Gitea 的設計目標之一是輕量且快速響應。與一些大型代碼託管平台不同，它保持精簡，在速度方面表現良好，適合資源有限的服務器環境。由於其輕量設計，Gitea 的資源消耗相對較低，在資源受限的環境中表現良好。
|
||||
Gitea 的設計目標之一是輕量且快速響應。與一些大型程式碼託管平台不同，它保持精簡，在速度方面表現良好，適合資源有限的伺服器環境。由於其輕量設計，Gitea 的資源消耗相對較低，在資源受限的環境中表現良好。
|
||||
|
||||
- **簡單部署和維護**
|
||||
|
||||
它可以輕鬆部署在各種服務器上，無需複雜的配置或依賴項。這使得個人開發者或小型團隊可以方便地設置和管理自己的 Git 服務。
|
||||
它可以輕鬆部署在各種伺服器上，無需複雜的設定或依賴項。這使得個人開發者或小型團隊可以方便地設定和管理自己的 Git 服務。
|
||||
|
||||
- **安全性**
|
||||
|
||||
Gitea 非常重視安全性，提供用戶權限管理、訪問控制列表等功能，以確保代碼和數據的安全。
|
||||
Gitea 非常重視安全性，提供使用者權限管理、存取控制清單等功能，以確保程式碼和資料的安全。
|
||||
|
||||
- **代碼審查**
|
||||
- **程式碼審查**
|
||||
|
||||
代碼審查支持 Pull Request 工作流程和 AGit 工作流程。審查者可以在線瀏覽代碼並提供審查意見或反饋。提交者可以接收審查意見並在線回應或修改代碼。代碼審查可以幫助個人和組織提高代碼質量。
|
||||
程式碼審查支援 Pull Request 工作流程和 AGit 工作流程。審查者可以在線瀏覽程式碼並提供審查意見或反饋。提交者可以接收審查意見並在線回應或修改程式碼。程式碼審查可以幫助個人和組織提高程式碼質量。
|
||||
|
||||
- **CI/CD**
|
||||
|
||||
Gitea Actions 支持 CI/CD 功能，與 GitHub Actions 兼容。用戶可以使用熟悉的 YAML 格式編寫工作流程，並重用各種現有的 Actions 插件。Actions 插件支持從任何 Git 網站下載。
|
||||
Gitea Actions 支援 CI/CD 功能，與 GitHub Actions 相容。使用者可以使用熟悉的 YAML 格式編寫工作流程，並重用各種現有的 Actions 外掛。Actions 外掛支援從任何 Git 網站下載。
|
||||
|
||||
- **項目管理**
|
||||
- **專案管理**
|
||||
|
||||
Gitea 通過列和問題跟踪項目需求、功能和錯誤。問題支持分支、標籤、里程碑、分配、時間跟踪、截止日期、依賴項等功能。
|
||||
Gitea 通過列和問題跟蹤專案需求、功能和錯誤。問題支援分支、標籤、里程碑、分配、時間跟蹤、截止日期、依賴項等功能。
|
||||
|
||||
- **工件存儲庫**
|
||||
- **工件儲存庫**
|
||||
|
||||
Gitea 支持超過 20 種不同類型的公共或私有軟件包管理，包括 Cargo、Chef、Composer、Conan、Conda、Container、Helm、Maven、npm、NuGet、Pub、PyPI、RubyGems、Vagrant 等。
|
||||
Gitea 支援超過 20 種不同類型的公共或私有套件管理，包括 Cargo、Chef、Composer、Conan、Conda、Container、Helm、Maven、npm、NuGet、Pub、PyPI、RubyGems、Vagrant 等。
|
||||
|
||||
- **開源社區支持**
|
||||
- **開源社區支援**
|
||||
|
||||
Gitea 是基於 MIT 許可證的開源項目。它擁有活躍的開源社區，不斷開發和改進平台。該項目還積極歡迎社區貢獻，確保更新和創新。
|
||||
Gitea 是基於 MIT 許可證的開源專案。它擁有活躍的開源社區，不斷開發和改進平台。該專案還積極歡迎社區貢獻，確保更新和創新。
|
||||
|
||||
- **多語言支持**
|
||||
- **多語言支援**
|
||||
|
||||
Gitea 提供多語言界面，滿足全球用戶需求，促進國際化和本地化。
|
||||
Gitea 提供多語言介面，滿足全球使用者需求，促進國際化和本地化。
|
||||
|
||||
有關更詳細的信息，請參閱：https://docs.gitea.com/installation/comparison#general-features
|
||||
有關更詳細的資訊，請參閱：https://docs.gitea.com/installation/comparison#general-features
|
||||
|
||||
## 系統要求
|
||||
|
||||
- Raspberry Pi 3 足夠運行 Gitea 以應對小型工作負載。
|
||||
- 2 個 CPU 核心和 1GB RAM 通常足夠小型團隊/項目使用。
|
||||
- 2 個 CPU 核心和 1GB RAM 通常足夠小型團隊/專案使用。
|
||||
- Gitea 應該在 UNIX 類系統上的專用非 root 系統帳戶下運行。
|
||||
- 注意：Gitea 管理 `~/.ssh/authorized_keys` 文件。以普通用戶運行 Gitea 可能會破壞該用戶的登錄能力。
|
||||
- 注意：Gitea 管理 `~/.ssh/authorized_keys` 文件。以普通使用者運行 Gitea 可能會破壞該使用者的登入能力。
|
||||
- 需要 [Git](https://git-scm.com/) 2.0.0 或更高版本。
|
||||
- 如果啟用並且您的 Git 版本 >= 2.1.2，將提供 [Git Large File Storage](https://git-lfs.github.com/)。
|
||||
- 如果您的 Git 版本 >= 2.18，將自動啟用 Git 提交圖渲染。
|
||||
|
||||
## 瀏覽器支持
|
||||
## 瀏覽器支援
|
||||
|
||||
- 最新 2 個版本的 Chrome、Firefox、Safari 和 Edge
|
||||
- Firefox ESR
|
||||
|
||||
## 組件
|
||||
## 元件
|
||||
|
||||
- Web 服務器框架：[Chi](http://github.com/go-chi/chi)
|
||||
- Web 伺服器框架：[Chi](http://github.com/go-chi/chi)
|
||||
- ORM：[XORM](https://xorm.io)
|
||||
- UI 框架：
|
||||
- [jQuery](https://jquery.com)
|
||||
- [Fomantic UI](https://fomantic-ui.com)
|
||||
- [Vue3](https://vuejs.org)
|
||||
- 以及各種組件（請參閱 package.json）
|
||||
- 以及各種元件（請參閱 package.json）
|
||||
- 編輯器：
|
||||
- [CodeMirror](https://codemirror.net)
|
||||
- [EasyMDE](https://github.com/Ionaru/easy-markdown-editor)
|
||||
- [Monaco Editor](https://microsoft.github.io/monaco-editor)
|
||||
- 數據庫驅動：
|
||||
- 資料庫驅動：
|
||||
- [github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)
|
||||
- [github.com/lib/pq](https://github.com/lib/pq)
|
||||
- [github.com/mattn/go-sqlite3](https://github.com/mattn/go-sqlite3)
|
||||
- [github.com/denisenkom/go-mssqldb](https://github.com/denisenkom/go-mssqldb)
|
||||
|
||||
## 集成支持
|
||||
## 整合支援
|
||||
|
||||
請訪問 [Awesome Gitea](https://gitea.com/gitea/awesome-gitea/) 獲取更多第三方集成支持
|
||||
請前往 [Awesome Gitea](https://gitea.com/gitea/awesome-gitea/) 獲取更多第三方整合支援
|
||||
@@ -14,13 +14,13 @@ aliases:
|
||||
|
||||
_表格中使用的符號：_
|
||||
|
||||
- _✓ - 支持_
|
||||
- _✓ - 支援_
|
||||
|
||||
- _⁄ - 支持但功能有限_
|
||||
- _⁄ - 支援但功能有限_
|
||||
|
||||
- _✘ - 不支持_
|
||||
- _✘ - 不支援_
|
||||
|
||||
- _⚙️ - 通過第三方軟件支持_
|
||||
- _⚙️ - 通過第三方軟件支援_
|
||||
|
||||
## 一般功能
|
||||
|
||||
@@ -28,25 +28,25 @@ _表格中使用的符號：_
|
||||
| ------------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
|
||||
| 開源且免費 | ✓ | ✘ | ✓ | ✘ | ✘ | ✓ | ✓ |
|
||||
| 低 RAM/ CPU 使用量 | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ |
|
||||
| 多數據庫支持 | ✓ | ✘ | ⁄ | ⁄ | ✓ | ✓ | ✓ |
|
||||
| 多操作系統支持 | ✓ | ✘ | ✘ | ✘ | ✘ | ✓ | ✓ |
|
||||
| 多資料庫支援 | ✓ | ✘ | ⁄ | ⁄ | ✓ | ✓ | ✓ |
|
||||
| 多操作系統支援 | ✓ | ✘ | ✘ | ✘ | ✘ | ✓ | ✓ |
|
||||
| 易於升級 | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
| 遠程遙測 | **✘** | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 第三方渲染工具支持 | ✓ | ✘ | ✘ | ✘ | ✓ | ✘ | ✘ |
|
||||
| 第三方渲染工具支援 | ✓ | ✘ | ✘ | ✘ | ✓ | ✘ | ✘ |
|
||||
| WebAuthn (2FA) | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ |
|
||||
| 廣泛的 API | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 內置包/容器註冊表 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 同步提交到外部倉庫（推送鏡像） | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
| 從外部倉庫同步提交（拉取鏡像） | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
| 同步提交到外部儲存庫（推送鏡像） | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
| 從外部儲存庫同步提交（拉取鏡像） | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
| 淺色和深色主題 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 自定義主題支持 | ✓ | ✘ | ✘ | ✘ | ✓ | ✓ | ✓ |
|
||||
| Markdown 支持 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| CSV 支持 | ✓ | ✓ | ✘ | ✘ | ✓ | ✘ | ✘ |
|
||||
| 自訂主題支援 | ✓ | ✘ | ✘ | ✘ | ✓ | ✓ | ✓ |
|
||||
| Markdown 支援 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| CSV 支援 | ✓ | ✓ | ✘ | ✘ | ✓ | ✘ | ✘ |
|
||||
| 'GitHub / GitLab 頁面' | [⚙️][gitea-pages-server], [⚙️][gitea-caddy-plugin] | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Gists / Snippets | [⚙️][opengist] | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 特定倉庫的 wiki（作為倉庫本身） | ✓ | ✓ | ✓ | ✓ | / | ✘ | ✘ |
|
||||
| 特定儲存庫的 wiki（作為儲存庫本身） | ✓ | ✓ | ✓ | ✓ | / | ✘ | ✘ |
|
||||
| 部署令牌 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 具有寫權限的倉庫令牌 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 具有寫權限的儲存庫令牌 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| RSS 提要 | ✓ | ✓ | ✘ | ✘ | ✘ | ✓ | ✓ |
|
||||
| 內置 CI/CD | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 子組：組內組 | [✘](https://github.com/go-gitea/gitea/issues/1872) | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
@@ -54,34 +54,34 @@ _表格中使用的符號：_
|
||||
| Markdown 中的 Mermaid 圖表 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Markdown 中的數學語法 | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
|
||||
## 代碼管理
|
||||
## 程式碼管理
|
||||
|
||||
| 功能 | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
|
||||
| ------------------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
|
||||
| 倉庫主題 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 倉庫代碼搜索 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 全局代碼搜索 | ✓ | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 儲存庫主題 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 儲存庫程式碼搜索 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 全域程式碼搜索 | ✓ | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Git LFS 2.0 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 組里程碑 | [✘](https://github.com/go-gitea/gitea/issues/14622) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 細粒度用戶角色（代碼、問題、Wiki 等） | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 細粒度使用者角色（程式碼、問題、Wiki 等） | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 驗證提交者 | ⁄ | ? | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| GPG 簽名提交 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| SSH 簽名提交 | ✓ | ✓ | ✓ | ✓ | ? | ✘ | ✘ |
|
||||
| 拒絕未簽名的提交 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 從其他服務遷移倉庫 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 倉庫活動頁面 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 從其他服務遷移儲存庫 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 儲存庫活動頁面 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 分支管理器 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 創建新分支 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 網頁代碼編輯器 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 建立新分支 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 網頁程式碼編輯器 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 提交圖 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 模板倉庫 | ✓ | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 模板儲存庫 | ✓ | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ |
|
||||
| Git Blame | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 圖像更改的可視比較 | ✓ | ✓ | ? | ? | ? | ✘ | ✘ |
|
||||
|
||||
- Gitea 具有內置的倉庫級代碼搜索
|
||||
- 更好的代碼搜索支持可以通過[使用倉庫索引器](../administration/repo-indexer.md)來實現
|
||||
- Gitea 具有內置的儲存庫級程式碼搜索
|
||||
- 更好的程式碼搜索支援可以透過[使用儲存庫索引器](../administration/repo-indexer.md)來實現
|
||||
|
||||
## 問題跟踪器
|
||||
## 問題跟蹤器
|
||||
|
||||
| Feature | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
|
||||
| ----------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
|
||||
|
||||
+11
-11
@@ -6,31 +6,31 @@ aliases:
|
||||
- /zh-tw/database-prep
|
||||
---
|
||||
|
||||
# 數據庫準備
|
||||
# 資料庫準備
|
||||
|
||||
您需要一個數據庫來使用 Gitea。Gitea 支持 PostgreSQL (>= 12)、MySQL (>= 8.0)、MariaDB (>= 10.4)、SQLite（內置）和 MSSQL (>= 2012 SP4)。本頁將指導您準備數據庫。由於這些數據庫引擎在生產中廣泛使用，這裡將只涵蓋 PostgreSQL 和 MySQL。如果您計劃使用 SQLite，您可以忽略本章。
|
||||
您需要一個資料庫來使用 Gitea。Gitea 支援 PostgreSQL (>= 12)、MySQL (>= 8.0)、MariaDB (>= 10.4)、SQLite（內置）和 MSSQL (>= 2012 SP4)。本頁將指導您準備資料庫。由於這些資料庫引擎在生產中廣泛使用，這裡將只涵蓋 PostgreSQL 和 MySQL。如果您計劃使用 SQLite，您可以忽略本章。
|
||||
|
||||
:::warning
|
||||
將一種數據庫類型轉換為另一種數據庫類型不是一個經過充分測試的過程，您可能會遇到問題。最好在第一次安裝時選擇最終的數據庫類型。請注意，SQLite 無法擴展；如果您預計您的實例將來會增長，您應該選擇另一種數據庫類型。
|
||||
將一種資料庫類型轉換為另一種資料庫類型不是一個經過充分測試的過程，您可能會遇到問題。最好在第一次安裝時選擇最終的資料庫類型。請注意，SQLite 無法擴展；如果您預計您的實例將來會增長，您應該選擇另一種資料庫類型。
|
||||
:::
|
||||
|
||||
如果您使用不受支持的數據庫版本，請[與我們聯繫](/help/support)以獲取有關我們擴展支持合同的信息。我們可以為舊數據庫提供測試和支持，並將這些修復集成到 Gitea 代碼庫中。
|
||||
如果您使用不受支援的資料庫版本，請[與我們聯繫](/help/support)以獲取有關我們擴展支援合同的資訊。我們可以為舊資料庫提供測試和支援，並將這些修復整合到 Gitea 程式碼庫中。
|
||||
|
||||
數據庫實例可以與 Gitea 在同一台機器上（本地數據庫設置），也可以在不同的機器上（遠程數據庫）。
|
||||
資料庫實例可以與 Gitea 在同一臺機器上（本地資料庫設定），也可以在不同的機器上（遠程資料庫）。
|
||||
|
||||
:::note
|
||||
以下所有步驟都要求您選擇的數據庫引擎已安裝在您的系統上。對於遠程數據庫設置，請在數據庫實例上安裝服務器應用程序，並在您的 Gitea 服務器上安裝客戶端程序。客戶端程序用於測試從 Gitea 服務器到數據庫的連接，而 Gitea 本身使用 Go 提供的數據庫驅動程序來完成相同的事情。此外，請確保服務器和客戶端使用相同的引擎版本，以便某些引擎功能正常工作。出於安全原因，請使用安全密碼保護 `root`（MySQL）或 `postgres`（PostgreSQL）數據庫超級用戶。這些步驟假設您在 Linux 上運行數據庫和 Gitea 服務器。
|
||||
以下所有步驟都要求您選擇的資料庫引擎已安裝在您的系統上。對於遠程資料庫設定，請在資料庫實例上安裝伺服器應用程式，並在您的 Gitea 伺服器上安裝客戶端程式。客戶端程式用於測試從 Gitea 伺服器到資料庫的連接，而 Gitea 本身使用 Go 提供的資料庫驅動程式來完成相同的事情。此外，請確保伺服器和客戶端使用相同的引擎版本，以便某些引擎功能正常工作。出於安全原因，請使用安全密碼保護 `root`（MySQL）或 `postgres`（PostgreSQL）資料庫超級使用者。這些步驟假設您在 Linux 上運行資料庫和 Gitea 伺服器。
|
||||
:::
|
||||
|
||||
## MySQL/MariaDB
|
||||
|
||||
1. 對於遠程數據庫設置，您需要使 MySQL 監聽您的 IP 地址。在數據庫實例上的 `/etc/mysql/my.cnf` 中編輯 `bind-address` 選項：
|
||||
1. 對於遠程資料庫設定，您需要使 MySQL 監聽您的 IP 地址。在資料庫實例上的 `/etc/mysql/my.cnf` 中編輯 `bind-address` 選項：
|
||||
|
||||
```ini
|
||||
bind-address = 203.0.113.3
|
||||
```
|
||||
|
||||
2. 在數據庫實例上，以 root 身份登錄到數據庫控制台：
|
||||
2. 在資料庫實例上，以 root 身份登入到資料庫控制檯：
|
||||
|
||||
```sh
|
||||
mysql -u root -p
|
||||
@@ -38,16 +38,16 @@ aliases:
|
||||
|
||||
按提示輸入密碼。
|
||||
|
||||
3. 創建將由 Gitea 使用的數據庫用戶，通過密碼進行身份驗證。本示例使用 `'gitea'` 作為密碼。請為您的實例使用安全密碼。
|
||||
3. 建立將由 Gitea 使用的資料庫使用者，通過密碼進行身份驗證。本範例使用 `'gitea'` 作為密碼。請為您的實例使用安全密碼。
|
||||
|
||||
對於本地數據庫：
|
||||
對於本地資料庫：
|
||||
|
||||
```sql
|
||||
SET old_passwords=0;
|
||||
CREATE USER 'gitea'@'%' IDENTIFIED BY 'gitea';
|
||||
```
|
||||
|
||||
對於遠程數據庫：
|
||||
對於遠程資料庫：
|
||||
|
||||
```sql
|
||||
SET old_passwords=0;
|
||||
|
||||
+18
-18
@@ -8,7 +8,7 @@ aliases:
|
||||
|
||||
# 從二進制安裝
|
||||
|
||||
所有下載都支持 SQLite、MySQL 和 PostgreSQL，並內置資產。這可能與 Gogs 不同。
|
||||
所有下載都支援 SQLite、MySQL 和 PostgreSQL，並內置資產。這可能與 Gogs 不同。
|
||||
|
||||
## 下載
|
||||
|
||||
@@ -21,7 +21,7 @@ aliases:
|
||||
**對於 Windows**，您可能需要 `windows-4.0-amd64`。它適用於所有現代版本的 Windows，但還有一個 `386` 平台可用，專為舊的 32 位版本的 Windows 設計。
|
||||
|
||||
:::info
|
||||
還有一個 `gogit-windows` 文件可用，它是為了解決一些[性能問題](https://github.com/go-gitea/gitea/pull/15482)而創建的，這些問題是一些 Windows 用戶在舊系統/版本上報告的。如果您遇到性能問題，應該考慮使用此文件，並讓我們知道它是否改善了性能。
|
||||
還有一個 `gogit-windows` 文件可用，它是為瞭解決一些[性能問題](https://github.com/go-gitea/gitea/pull/15482)而建立的，這些問題是一些 Windows 使用者在舊系統/版本上報告的。如果您遇到性能問題，應該考慮使用此文件，並讓我們知道它是否改善了性能。
|
||||
:::
|
||||
|
||||
**對於 macOS**，如果您的硬件使用 Apple Silicon，您應該選擇 `darwin-arm64`，或者對於 Intel 選擇 `darwin-amd64`。
|
||||
@@ -52,22 +52,22 @@ gpg --verify gitea-@[email protected] gitea-@version@-linux-amd64
|
||||
查找文本 `Good signature from "Teabot <[email protected]>"` 以確認二進制文件良好，
|
||||
儘管有 `This key is not certified with a trusted signature!` 之類的警告。
|
||||
|
||||
## 推薦的服務器配置
|
||||
## 推薦的伺服器設定
|
||||
|
||||
:::note
|
||||
以下許多目錄也可以使用[環境變量](../administration/environment-variables.md)進行配置！
|
||||
值得注意的是，配置 `GITEA_WORK_DIR` 將告訴 Gitea 將其工作目錄設置在哪裡，並簡化安裝過程。
|
||||
以下許多目錄也可以使用[環境變量](../administration/environment-variables.md)進行設定！
|
||||
值得注意的是，設定 `GITEA_WORK_DIR` 將告訴 Gitea 將其工作目錄設定在哪裡，並簡化安裝過程。
|
||||
:::
|
||||
|
||||
### 準備環境
|
||||
|
||||
檢查服務器上是否安裝了 Git。如果沒有，請先安裝它。Gitea 需要 Git 版本 >= 2.0。
|
||||
檢查伺服器上是否安裝了 Git。如果沒有，請先安裝它。Gitea 需要 Git 版本 >= 2.0。
|
||||
|
||||
```sh
|
||||
git --version
|
||||
```
|
||||
|
||||
創建一個用戶來運行 Gitea（例如 `git`）
|
||||
建立一個使用者來運行 Gitea（例如 `git`）
|
||||
|
||||
```sh
|
||||
# 在 Ubuntu/Debian 上：
|
||||
@@ -92,7 +92,7 @@ adduser \
|
||||
git
|
||||
```
|
||||
|
||||
### 創建所需的目錄結構
|
||||
### 建立所需的目錄結構
|
||||
|
||||
```sh
|
||||
mkdir -p /var/lib/gitea/{custom,data,log}
|
||||
@@ -105,7 +105,7 @@ chmod 770 /etc/gitea
|
||||
|
||||
:::note
|
||||
|
||||
> `/etc/gitea` 暫時設置為用戶 `git` 的寫入權限，以便 Web 安裝程序可以寫入配置文件。安裝完成後，建議將權限設置為只讀：
|
||||
> `/etc/gitea` 暫時設定為使用者 `git` 的寫入權限，以便 Web 安裝程式可以寫入設定文件。安裝完成後，建議將權限設定為只讀：
|
||||
> :::
|
||||
|
||||
> ```sh
|
||||
@@ -113,26 +113,26 @@ chmod 770 /etc/gitea
|
||||
> chmod 640 /etc/gitea/app.ini
|
||||
> ```
|
||||
|
||||
如果您不希望 Web 安裝程序能夠寫入配置文件，可以使配置文件對 Gitea 用戶（所有者/組 `root:git`，模式 `0640`）只讀，但您需要手動編輯配置文件以：
|
||||
如果您不希望 Web 安裝程式能夠寫入設定文件，可以使設定文件對 Gitea 使用者（所有者/組 `root:git`，模式 `0640`）只讀，但您需要手動編輯設定文件以：
|
||||
|
||||
- 設置 `INSTALL_LOCK= true`，
|
||||
- 確保所有數據庫配置詳細信息正確設置
|
||||
- 確保設置了 `SECRET_KEY` 和 `INTERNAL_TOKEN` 值。（您可能需要使用 `gitea generate secret` 來生成這些密鑰。）
|
||||
- 確保設置了您需要的任何其他密鑰。
|
||||
- 設定 `INSTALL_LOCK= true`，
|
||||
- 確保所有資料庫設定詳細資訊正確設定
|
||||
- 確保設定了 `SECRET_KEY` 和 `INTERNAL_TOKEN` 值。（您可能需要使用 `gitea generate secret` 來生成這些密鑰。）
|
||||
- 確保設定了您需要的任何其他密鑰。
|
||||
|
||||
有關使用 `gitea generate secret` 的信息，請參閱[命令行文檔](../administration/command-line.md)。
|
||||
有關使用 `gitea generate secret` 的資訊，請參閱[命令行文件](../administration/command-line.md)。
|
||||
|
||||
### 配置 Gitea 的工作目錄
|
||||
### 設定 Gitea 的工作目錄
|
||||
|
||||
:::note
|
||||
如果您計劃將 Gitea 作為 Linux 服務運行，則可以跳過此步驟，因為服務文件允許您設置 `WorkingDirectory`。否則，請考慮（半）永久性地設置此環境變量，以便 Gitea 始終使用正確的工作目錄。
|
||||
如果您計劃將 Gitea 作為 Linux 服務運行，則可以跳過此步驟，因為服務文件允許您設定 `WorkingDirectory`。否則，請考慮（半）永久性地設定此環境變量，以便 Gitea 始終使用正確的工作目錄。
|
||||
:::
|
||||
|
||||
```sh
|
||||
export GITEA_WORK_DIR=/var/lib/gitea/
|
||||
```
|
||||
|
||||
### 將 Gitea 二進制文件複製到全局位置
|
||||
### 將 Gitea 二進制文件複製到全域位置
|
||||
|
||||
```sh
|
||||
cp gitea /usr/local/bin/gitea
|
||||
|
||||
@@ -12,9 +12,9 @@ aliases:
|
||||
|
||||
### macOS
|
||||
|
||||
目前，在 MacOS 上安裝的唯一支持方法是 [Homebrew](http://brew.sh/)。
|
||||
目前，在 MacOS 上安裝的唯一支援方法是 [Homebrew](http://brew.sh/)。
|
||||
按照[從二進制部署](installation/from-binary.md)指南可能有效，
|
||||
但不受支持。要通過 `brew` 安裝 Gitea：
|
||||
但不受支援。要通過 `brew` 安裝 Gitea：
|
||||
|
||||
```
|
||||
brew install gitea
|
||||
@@ -24,7 +24,7 @@ brew install gitea
|
||||
|
||||
### Alpine Linux
|
||||
|
||||
Alpine Linux 在其社區存儲庫中有 [Gitea](https://pkgs.alpinelinux.org/packages?name=gitea&branch=edge)，該存儲庫遵循最新的穩定版本。
|
||||
Alpine Linux 在其社區儲存庫中有 [Gitea](https://pkgs.alpinelinux.org/packages?name=gitea&branch=edge)，該儲存庫遵循最新的穩定版本。
|
||||
|
||||
```sh
|
||||
apk add gitea
|
||||
@@ -32,7 +32,7 @@ apk add gitea
|
||||
|
||||
### Arch Linux
|
||||
|
||||
滾動發行版在其官方額外存儲庫中有 [Gitea](https://www.archlinux.org/packages/extra/x86_64/gitea/)，並且隨著新的 Gitea 發行版提供包更新。
|
||||
滾動發行版在其官方額外儲存庫中有 [Gitea](https://www.archlinux.org/packages/extra/x86_64/gitea/)，並且隨著新的 Gitea 發行版提供包更新。
|
||||
|
||||
```sh
|
||||
pacman -S gitea
|
||||
@@ -48,7 +48,7 @@ pacman -S gitea
|
||||
|
||||
### Gentoo Linux
|
||||
|
||||
滾動發行版在其官方社區存儲庫中有 [Gitea](https://packages.gentoo.org/packages/www-apps/gitea)，並且隨著新的 Gitea 發行版提供包更新。
|
||||
滾動發行版在其官方社區儲存庫中有 [Gitea](https://packages.gentoo.org/packages/www-apps/gitea)，並且隨著新的 Gitea 發行版提供包更新。
|
||||
|
||||
```sh
|
||||
emerge gitea -va
|
||||
@@ -66,7 +66,7 @@ snap install gitea
|
||||
### SUSE 和 openSUSE
|
||||
|
||||
OpenSUSE 構建服務提供 [openSUSE 和 SLE](https://software.opensuse.org/download/package?package=gitea&project=devel%3Atools%3Ascm) 的包
|
||||
在開發軟件配置管理存儲庫中
|
||||
在開發軟件設定管理儲存庫中
|
||||
|
||||
### Windows
|
||||
|
||||
@@ -86,7 +86,7 @@ choco install gitea
|
||||
pkg install gitea
|
||||
```
|
||||
|
||||
要獲取最新版本，或使用自定義選項構建端口，
|
||||
要獲取最新版本，或使用自訂選項構建端口，
|
||||
[從端口安裝](https://www.freebsd.org/doc/handbook/ports-using.html)：
|
||||
|
||||
```
|
||||
@@ -95,8 +95,8 @@ cd /usr/ports/www/gitea
|
||||
make install clean
|
||||
```
|
||||
|
||||
該端口使用標準的 FreeBSD 文件系統佈局：配置文件位於 `/usr/local/etc/gitea`，
|
||||
捆綁的模板、選項、插件和主題位於 `/usr/local/share/gitea`，啟動腳本
|
||||
該端口使用標準的 FreeBSD 文件系統佈局：設定文件位於 `/usr/local/etc/gitea`，
|
||||
捆綁的模板、選項、外掛和主題位於 `/usr/local/share/gitea`，啟動腳本
|
||||
位於 `/usr/local/etc/rc.d/gitea`。
|
||||
|
||||
要使 Gitea 作為服務運行，請運行 `sysrc gitea_enable=YES` 並使用 `service gitea start` 啟動它。
|
||||
|
||||
+17
-17
@@ -6,25 +6,25 @@ aliases:
|
||||
- /zh-tw/install-from-source
|
||||
---
|
||||
|
||||
# 從源代碼安裝
|
||||
# 從源程式碼安裝
|
||||
|
||||
您應該[安裝 go](https://go.dev/doc/install) 並正確設置您的 go 環境。特別是，建議設置 `$GOPATH` 環境變量並添加 go bin 目錄或目錄 `${GOPATH//://bin:}/bin` 到 `$PATH`。請參閱 Go wiki 條目 [GOPATH](https://github.com/golang/go/wiki/GOPATH)。
|
||||
您應該[安裝 go](https://go.dev/doc/install) 並正確設定您的 go 環境。特別是，建議設定 `$GOPATH` 環境變量並添加 go bin 目錄或目錄 `${GOPATH//://bin:}/bin` 到 `$PATH`。請參閱 Go wiki 條目 [GOPATH](https://github.com/golang/go/wiki/GOPATH)。
|
||||
|
||||
接下來，[安裝帶有 npm 的 Node.js](https://nodejs.org/en/download/)，這是構建 JavaScript 和 CSS 文件所必需的。支持的最低 Node.js 版本是 @minNodeVersion@，建議使用最新的 LTS 版本。
|
||||
接下來，[安裝帶有 npm 的 Node.js](https://nodejs.org/en/download/)，這是構建 JavaScript 和 CSS 文件所必需的。支援的最低 Node.js 版本是 @minNodeVersion@，建議使用最新的 LTS 版本。
|
||||
|
||||
:::note
|
||||
需要 Go 版本 @minGoVersion@ 或更高版本。但是，建議獲取與我們的持續集成相同的版本，請參閱[在 Gitea 上進行黑客攻擊](development/hacking-on-gitea.md) 中的建議
|
||||
需要 Go 版本 @minGoVersion@ 或更高版本。但是，建議獲取與我們的持續整合相同的版本，請參閱[在 Gitea 上進行黑客攻擊](development/hacking-on-gitea.md) 中的建議
|
||||
:::
|
||||
|
||||
## 下載
|
||||
|
||||
首先，我們必須檢索源代碼。由於 go 模塊的出現，最簡單的方法是直接使用 Git，因為我們不再需要在 GOPATH 中構建 Gitea。
|
||||
首先，我們必須檢索源程式碼。由於 go 模組的出現，最簡單的方法是直接使用 Git，因為我們不再需要在 GOPATH 中構建 Gitea。
|
||||
|
||||
```bash
|
||||
git clone https://github.com/go-gitea/gitea
|
||||
```
|
||||
|
||||
（本文檔的早期版本建議使用 `go get`。這不再是必需的。）
|
||||
（本文件的早期版本建議使用 `go get`。這不再是必需的。）
|
||||
|
||||
決定要構建和安裝的 Gitea 版本。目前，有多種選擇可供選擇。`main` 分支代表當前的開發版本。要使用 main 構建，請跳到[構建部分](#build)。
|
||||
|
||||
@@ -41,7 +41,7 @@ git checkout @sourceBranch@
|
||||
git fetch origin pull/xyz/head:pr-xyz
|
||||
```
|
||||
|
||||
要從特定標記版本（如 @sourceVersion@）的源代碼構建 Gitea，請列出可用標記並檢出特定標記。
|
||||
要從特定標記版本（如 @sourceVersion@）的源程式碼構建 Gitea，請列出可用標記並檢出特定標記。
|
||||
|
||||
使用以下命令列出可用標籤。
|
||||
|
||||
@@ -52,7 +52,7 @@ git checkout @sourceVersion@ # 或 git checkout pr-xyz
|
||||
|
||||
## 構建
|
||||
|
||||
要從源代碼構建，系統上必須存在以下程序：
|
||||
要從源程式碼構建，系統上必須存在以下程式：
|
||||
|
||||
- `go` @minGoVersion@ 或更高版本，請參閱[此處](https://go.dev/dl/)
|
||||
- `node` @minNodeVersion@ 或更高版本，帶有 `npm`，請參閱[此處](https://nodejs.org/en/download/)
|
||||
@@ -63,8 +63,8 @@ git checkout @sourceVersion@ # 或 git checkout pr-xyz
|
||||
根據要求，可以包括以下構建標籤。
|
||||
|
||||
- `bindata`：構建單個整體二進制文件，包含所有資產。生產構建所需。
|
||||
- `sqlite sqlite_unlock_notify`：啟用對 [SQLite3](https://sqlite.org/) 數據庫的支持。僅建議用於小型安裝。
|
||||
- `pam`：啟用對 PAM（Linux 可插拔身份驗證模塊）的支持。可用於驗證本地用戶或擴展身份驗證到 PAM 可用的方法。
|
||||
- `sqlite sqlite_unlock_notify`：啟用對 [SQLite3](https://sqlite.org/) 資料庫的支援。僅建議用於小型安裝。
|
||||
- `pam`：啟用對 PAM（Linux 可插拔身份驗證模組）的支援。可用於驗證本地使用者或擴展身份驗證到 PAM 可用的方法。
|
||||
- `gogit`：（實驗性）使用 go-git 變體的 Git 命令。
|
||||
|
||||
將所有資產（JS/CSS/模板等）捆綁到二進制文件中。使用 `bindata` 構建標籤是生產部署所必需的。當您開發/測試 Gitea 或能夠正確分離資產時，可以排除 `bindata`。
|
||||
@@ -75,7 +75,7 @@ git checkout @sourceVersion@ # 或 git checkout pr-xyz
|
||||
TAGS="bindata" make build
|
||||
```
|
||||
|
||||
在我們的持續集成系統的默認發布構建中，構建標籤是：`TAGS="bindata sqlite sqlite_unlock_notify"`。因此，從源代碼構建的最簡單推薦方法是：
|
||||
在我們的持續整合系統的預設發布構建中，構建標籤是：`TAGS="bindata sqlite sqlite_unlock_notify"`。因此，從源程式碼構建的最簡單推薦方法是：
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
@@ -95,21 +95,21 @@ TAGS="bindata" make backend
|
||||
## 測試
|
||||
|
||||
按照上述步驟操作後，工作目錄中將有一個 `gitea` 二進制文件。
|
||||
可以從此目錄進行測試或移動到具有測試數據的目錄。當 Gitea 從命令行手動啟動時，可以通過按 `Ctrl + C` 將其終止。
|
||||
可以從此目錄進行測試或移動到具有測試資料的目錄。當 Gitea 從命令行手動啟動時，可以透過按 `Ctrl + C` 將其終止。
|
||||
|
||||
```bash
|
||||
./gitea web
|
||||
```
|
||||
|
||||
## 更改默認路徑
|
||||
## 更改預設路徑
|
||||
|
||||
Gitea 將從 _`CustomPath`_ 中搜索許多內容。默認情況下，這是運行 Gitea 時當前工作目錄中的 `custom/` 目錄。它還將在 `$(CustomPath)/conf/app.ini` 中查找其配置文件，並將當前工作目錄用作許多可配置值的相對基本路徑 _`AppWorkPath`_。最後，靜態文件將從 _`StaticRootPath`_ 提供，默認為 _`AppWorkPath`_。
|
||||
Gitea 將從 _`CustomPath`_ 中搜索許多內容。預設情況下，這是運行 Gitea 時當前工作目錄中的 `custom/` 目錄。它還將在 `$(CustomPath)/conf/app.ini` 中查找其設定文件，並將當前工作目錄用作許多可設定值的相對基本路徑 _`AppWorkPath`_。最後，靜態文件將從 _`StaticRootPath`_ 提供，預設為 _`AppWorkPath`_。
|
||||
|
||||
這些值雖然在開發時很有用，但可能會與下游用戶的偏好發生衝突。
|
||||
這些值雖然在開發時很有用，但可能會與下游使用者的偏好發生衝突。
|
||||
|
||||
一種選擇是使用腳本文件來影子 `gitea` 二進制文件並在運行 Gitea 之前創建適當的環境。但是，在構建時，您可以使用 `make` 的 `LDFLAGS` 環境變量更改這些默認值。適當的設置如下
|
||||
一種選擇是使用腳本文件來影子 `gitea` 二進制文件並在運行 Gitea 之前建立適當的環境。但是，在構建時，您可以使用 `make` 的 `LDFLAGS` 環境變量更改這些預設值。適當的設定如下
|
||||
|
||||
- 要設置 _`CustomPath`_，請使用 `LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=custom-path\""`
|
||||
- 要設定 _`CustomPath`_，請使用 `LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=custom-path\""`
|
||||
- 對
|
||||
|
||||
---
|
||||
|
||||
+4
-4
@@ -11,23 +11,23 @@ aliases:
|
||||
## Cloudron
|
||||
|
||||
Gitea 可在 [Cloudron](https://cloudron.io) 上一鍵安裝。
|
||||
Cloudron 使您可以輕鬆地在服務器上運行 Gitea 等應用程序，並保持它們的最新和安全。
|
||||
Cloudron 使您可以輕鬆地在伺服器上運行 Gitea 等應用程式，並保持它們的最新和安全。
|
||||
|
||||
[](https://cloudron.io/button.html?app=io.gitea.cloudronapp)
|
||||
|
||||
Gitea 包由[此處](https://git.cloudron.io/cloudron/gitea-app)維護。
|
||||
|
||||
有一個[演示實例](https://my.demo.cloudron.io)（用戶名：cloudron 密碼：cloudron），您可以在其中試驗運行 Gitea。
|
||||
有一個[演示實例](https://my.demo.cloudron.io)（使用者名稱：cloudron 密碼：cloudron），您可以在其中試驗運行 Gitea。
|
||||
|
||||
## Linode
|
||||
|
||||
[Linode](https://www.linode.com/) 在其市場中有 Gitea 作為應用程序。
|
||||
[Linode](https://www.linode.com/) 在其市場中有 Gitea 作為應用程式。
|
||||
|
||||
要將 Gitea 部署到 Linode，請查看 [Linode Marketplace](https://www.linode.com/marketplace/apps/linode/gitea/)。
|
||||
|
||||
## alwaysdata
|
||||
|
||||
[alwaysdata](https://www.alwaysdata.com/) 在其市場中有 Gitea 作為應用程序。
|
||||
[alwaysdata](https://www.alwaysdata.com/) 在其市場中有 Gitea 作為應用程式。
|
||||
|
||||
要將 Gitea 部署到 alwaysdata，請查看 [alwaysdata Marketplace](https://www.alwaysdata.com/en/marketplace/gitea/)。
|
||||
|
||||
|
||||
+5
-5
@@ -10,18 +10,18 @@ aliases:
|
||||
|
||||
Gitea 提供了一個 Helm Chart 以允許在 kubernetes 上安裝。
|
||||
|
||||
可以使用以下命令進行非自定義安裝：
|
||||
可以使用以下命令進行非自訂安裝：
|
||||
|
||||
```
|
||||
helm repo add gitea-charts https://dl.gitea.com/charts/
|
||||
helm install gitea gitea-charts/gitea
|
||||
```
|
||||
|
||||
如果您想自定義安裝，包括 kubernetes ingress，請參閱完整的 [Gitea helm chart 配置詳細信息](https://gitea.com/gitea/helm-chart/)
|
||||
如果您想自訂安裝，包括 kubernetes ingress，請參閱完整的 [Gitea helm chart 設定詳細資訊](https://gitea.com/gitea/helm-chart/)
|
||||
|
||||
## 健康檢查端點
|
||||
|
||||
Gitea 帶有一個健康檢查端點 `/api/healthz`，您可以在 kubernetes 中這樣配置它：
|
||||
Gitea 帶有一個健康檢查端點 `/api/healthz`，您可以在 kubernetes 中這樣設定它：
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
@@ -35,7 +35,7 @@ livenessProbe:
|
||||
failureThreshold: 10
|
||||
```
|
||||
|
||||
成功的健康檢查響應將返回 http 代碼 `200`，示例如下：
|
||||
成功的健康檢查響應將返回 http 程式碼 `200`，範例如下：
|
||||
|
||||
```json
|
||||
HTTP/1.1 200 OK
|
||||
@@ -60,4 +60,4 @@ HTTP/1.1 200 OK
|
||||
}
|
||||
```
|
||||
|
||||
有關更多信息，請參考 kubernetes 文檔 [定義 liveness HTTP 請求](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request)
|
||||
有關更多資訊，請參考 kubernetes 文件 [定義 liveness HTTP 請求](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request)
|
||||
+6
-6
@@ -12,11 +12,11 @@ aliases:
|
||||
|
||||
## 使用 systemd
|
||||
|
||||
將示例 [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) 複製到 `/etc/systemd/system/gitea.service`，然後使用您喜歡的編輯器編輯該文件。
|
||||
將範例 [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) 複製到 `/etc/systemd/system/gitea.service`，然後使用您喜歡的編輯器編輯該文件。
|
||||
|
||||
取消註釋需要在此主機上啟用的任何服務，例如 MySQL。
|
||||
|
||||
更改用戶、主目錄和其他所需的啟動值。如果使用默認端口，請更改 PORT 或刪除 -p 標誌。
|
||||
更改使用者、主目錄和其他所需的啟動值。如果使用預設端口，請更改 PORT 或刪除 -p 標誌。
|
||||
|
||||
在啟動時啟用並啟動 Gitea：
|
||||
|
||||
@@ -39,17 +39,17 @@ sudo systemctl enable gitea --now
|
||||
sudo apt install supervisor
|
||||
```
|
||||
|
||||
為 supervisor 日誌創建一個日誌目錄：
|
||||
為 supervisor 日誌建立一個日誌目錄：
|
||||
|
||||
```
|
||||
# 假設 Gitea 安裝在 /home/git/gitea/
|
||||
mkdir /home/git/gitea/log/supervisor
|
||||
```
|
||||
|
||||
將示例中的配置附加到 `/etc/supervisor/supervisord.conf`
|
||||
[supervisord 配置](https://github.com/go-gitea/gitea/blob/main/contrib/supervisor/gitea)。
|
||||
將範例中的設定附加到 `/etc/supervisor/supervisord.conf`
|
||||
[supervisord 設定](https://github.com/go-gitea/gitea/blob/main/contrib/supervisor/gitea)。
|
||||
|
||||
使用您喜歡的編輯器，更改用戶 (`git`) 和主目錄 (`/home/git`) 設置以匹配部署環境。如果使用默認端口，請更改 PORT 或刪除 -p 標誌。
|
||||
使用您喜歡的編輯器，更改使用者 (`git`) 和主目錄 (`/home/git`) 設定以匹配部署環境。如果使用預設端口，請更改 PORT 或刪除 -p 標誌。
|
||||
|
||||
最後在啟動時啟用並啟動 supervisor：
|
||||
|
||||
|
||||
+31
-31
@@ -13,18 +13,18 @@ aliases:
|
||||
## 檢查變更日誌中的重大變更
|
||||
|
||||
為了使 Gitea 更好，一些重大變更是不可避免的，特別是對於大里程碑版本。
|
||||
在升級之前，請閱讀 [Gitea 博客上的變更日誌](https://blog.gitea.com/)
|
||||
在升級之前，請閱讀 [Gitea 部落格上的變更日誌](https://blog.gitea.com/)
|
||||
並檢查這些重大變更是否會影響您的 Gitea 實例。
|
||||
|
||||
## 驗證沒有已棄用的配置選項
|
||||
## 驗證沒有已棄用的設定選項
|
||||
|
||||
Gitea 的新版本通常會帶有更改的配置語法或選項，這些選項通常會在站點管理面板頂部顯示至少一個發布週期。如果這些警告未解決，Gitea 可能會拒絕在下一版本中啟動。
|
||||
Gitea 的新版本通常會帶有更改的設定語法或選項，這些選項通常會在站點管理面板頂部顯示至少一個發布週期。如果這些警告未解決，Gitea 可能會拒絕在下一版本中啟動。
|
||||
|
||||
## 降級備份
|
||||
|
||||
Gitea 保持對補丁版本的兼容性，其前兩個字段相同（`a.b.x` -> `a.b.y`），
|
||||
這些補丁版本可以使用相同的數據庫結構進行升級和降級。
|
||||
否則（`a.b.?` -> `a.c.?`），較新的 Gitea 版本將升級舊數據庫
|
||||
Gitea 保持對補丁版本的相容性，其前兩個欄位相同（`a.b.x` -> `a.b.y`），
|
||||
這些補丁版本可以使用相同的資料庫結構進行升級和降級。
|
||||
否則（`a.b.?` -> `a.c.?`），較新的 Gitea 版本將升級舊資料庫
|
||||
到可能與舊版本不同的新結構。
|
||||
|
||||
例如：
|
||||
@@ -32,12 +32,12 @@ Gitea 保持對補丁版本的兼容性，其前兩個字段相同（`a.b.x` ->
|
||||
| 從 | 到 | 結果 |
|
||||
| ----- | ----- | ------------------------------------------------------------------------------------------------- |
|
||||
| 1.4.0 | 1.4.1 | ✅ |
|
||||
| 1.4.1 | 1.4.0 | ⚠️ 不建議，請自行承擔風險！雖然如果數據庫結構沒有更改，它可能會工作，但強烈建議使用備份進行降級。 |
|
||||
| 1.4.x | 1.5.y | ✅ 數據庫已升級。您可以直接從 1.4.x 升級到最新的 1.5.y。 |
|
||||
| 1.5.y | 1.4.x | ❌ 數據庫已經升級，無法用於舊版 Gitea，請使用備份進行降級。 |
|
||||
| 1.4.1 | 1.4.0 | ⚠️ 不建議，請自行承擔風險！雖然如果資料庫結構沒有更改，它可能會工作，但強烈建議使用備份進行降級。 |
|
||||
| 1.4.x | 1.5.y | ✅ 資料庫已升級。您可以直接從 1.4.x 升級到最新的 1.5.y。 |
|
||||
| 1.5.y | 1.4.x | ❌ 資料庫已經升級，無法用於舊版 Gitea，請使用備份進行降級。 |
|
||||
|
||||
**由於您無法運行升級後的數據庫的舊版 Gitea，
|
||||
在數據庫升級之前應始終進行備份。**
|
||||
**由於您無法運行升級後的資料庫的舊版 Gitea，
|
||||
在資料庫升級之前應始終進行備份。**
|
||||
|
||||
如果您在生產環境中使用 Gitea，強烈建議在升級之前進行備份，
|
||||
即使升級是在補丁版本之間進行的。
|
||||
@@ -45,45 +45,45 @@ Gitea 保持對補丁版本的兼容性，其前兩個字段相同（`a.b.x` ->
|
||||
備份步驟：
|
||||
|
||||
- 停止 Gitea 實例
|
||||
- 備份數據庫
|
||||
- 備份 Gitea 配置
|
||||
- 備份 `APP_DATA_PATH` 中的 Gitea 數據文件
|
||||
- 備份 Gitea 外部存儲（例如：S3/MinIO 或其他使用的存儲）
|
||||
- 備份資料庫
|
||||
- 備份 Gitea 設定
|
||||
- 備份 `APP_DATA_PATH` 中的 Gitea 資料文件
|
||||
- 備份 Gitea 外部儲存（例如：S3/MinIO 或其他使用的儲存）
|
||||
|
||||
如果您使用雲服務或具有快照功能的文件系統，
|
||||
為 Gitea 數據卷和相關對象存儲創建快照更方便。
|
||||
為 Gitea 資料卷和相關對象儲存建立快照更方便。
|
||||
|
||||
在所有步驟準備就緒後，下載新版本，停止應用程序，執行備份，
|
||||
然後啟動新應用程序。在每次啟動時，Gitea 會驗證數據庫是否是最新的，並自動
|
||||
執行任何必要的遷移。根據數據庫的大小，這可能會在
|
||||
首次啟動期間需要一些額外時間，期間應用程序將不可用。
|
||||
在所有步驟準備就緒後，下載新版本，停止應用程式，執行備份，
|
||||
然後啟動新應用程式。在每次啟動時，Gitea 會驗證資料庫是否是最新的，並自動
|
||||
執行任何必要的遷移。根據資料庫的大小，這可能會在
|
||||
首次啟動期間需要一些額外時間，期間應用程式將不可用。
|
||||
|
||||
## 使用 Docker 升級
|
||||
|
||||
- `docker pull` 最新的 Gitea 版本。
|
||||
- 停止運行的實例，備份數據。
|
||||
- 停止運行的實例，備份資料。
|
||||
- 使用 `docker` 或 `docker-compose` 啟動較新的 Gitea Docker 容器。
|
||||
|
||||
## 從包升級
|
||||
|
||||
- 停止運行的實例，備份數據。
|
||||
- 使用您的包管理器將 Gitea 升級到最新版本。
|
||||
- 停止運行的實例，備份資料。
|
||||
- 使用您的套件管理器將 Gitea 升級到最新版本。
|
||||
- 啟動 Gitea 實例。
|
||||
|
||||
## 從二進制文件升級
|
||||
|
||||
- 將最新的 Gitea 二進制文件下載到臨時目錄。
|
||||
- 停止運行的實例，備份數據。
|
||||
- 停止運行的實例，備份資料。
|
||||
- 用下載的二進制文件替換已安裝的 Gitea 二進制文件。
|
||||
- 啟動 Gitea 實例。
|
||||
|
||||
可以在 Gitea 的源代碼樹中找到一個自動執行這些步驟的腳本，用於在 Linux 上部署 [`contrib/upgrade.sh`](https://github.com/go-gitea/gitea/blob/main/contrib/upgrade.sh)。
|
||||
可以在 Gitea 的源程式碼樹中找到一個自動執行這些步驟的腳本，用於在 Linux 上部署 [`contrib/upgrade.sh`](https://github.com/go-gitea/gitea/blob/main/contrib/upgrade.sh)。
|
||||
|
||||
## 注意自定義模板
|
||||
## 注意自訂模板
|
||||
|
||||
Gitea 的模板結構和變量可能會在版本之間發生變化，如果您使用自定義模板，
|
||||
請注意您的模板是否與您使用的 Gitea 版本兼容。
|
||||
Gitea 的模板結構和變量可能會在版本之間發生變化，如果您使用自訂模板，
|
||||
請注意您的模板是否與您使用的 Gitea 版本相容。
|
||||
|
||||
如果自定義模板與 Gitea 版本不匹配，您可能會遇到：
|
||||
`50x` 服務器錯誤，頁面組件丟失或故障，頁面佈局異常，...
|
||||
刪除或更新不兼容的模板，Gitea 網頁將再次正常工作。
|
||||
如果自訂模板與 Gitea 版本不匹配，您可能會遇到：
|
||||
`50x` 伺服器錯誤，頁面元件丟失或故障，頁面佈局異常，...
|
||||
刪除或更新不相容的模板，Gitea 網頁將再次正常工作。
|
||||
+4
-4
@@ -16,7 +16,7 @@ aliases:
|
||||
RUN_USER = COMPUTERNAME$
|
||||
```
|
||||
|
||||
將 Gitea 設置為以本地系統用戶身份運行。
|
||||
將 Gitea 設定為以本地系統使用者身份運行。
|
||||
|
||||
COMPUTERNAME 是命令行中 `echo %COMPUTERNAME%` 的響應。如果響應是 `USER-PC`，則 `RUN_USER = USER-PC$`
|
||||
|
||||
@@ -41,12 +41,12 @@ sc.exe create gitea start= auto binPath= "\"C:\gitea\gitea.exe\" web --config \"
|
||||
不要忘記將 `C:\gitea` 替換為正確的 Gitea 目錄。
|
||||
|
||||
打開“Windows 服務”，搜索名為“gitea”的服務，右鍵單擊它並單擊
|
||||
“運行”。如果一切正常，Gitea 將在 `http://localhost:3000`（或配置的端口）上可訪問。
|
||||
“運行”。如果一切正常，Gitea 將在 `http://localhost:3000`（或設定的端口）上可訪問。
|
||||
|
||||
### 服務啟動類型
|
||||
|
||||
觀察到在加載系統期間啟動時，Gitea 服務可能會在 Windows 事件日誌中記錄超時並且無法啟動。
|
||||
在這種情況下，將啟動類型更改為“自動延遲”。這可以在服務創建期間完成，也可以通過運行配置命令完成
|
||||
在這種情況下，將啟動類型更改為“自動延遲”。這可以在服務建立期間完成，也可以透過運行設定命令完成
|
||||
|
||||
```sh
|
||||
sc.exe config gitea start= delayed-auto
|
||||
@@ -60,7 +60,7 @@ sc.exe config gitea start= delayed-auto
|
||||
sc.exe config gitea depend= mariadb
|
||||
```
|
||||
|
||||
這將確保當 Windows 機器重新啟動時，Gitea 的自動啟動將推遲到數據庫準備就緒，從而減少啟動失敗。
|
||||
這將確保當 Windows 機器重新啟動時，Gitea 的自動啟動將推遲到資料庫準備就緒，從而減少啟動失敗。
|
||||
|
||||
## 註銷 Gitea
|
||||
|
||||
|
||||
+53
-53
@@ -12,18 +12,18 @@ Gitea 在其 Docker Hub 組織中提供自動更新的 Docker 映像。可以
|
||||
始終使用最新的穩定標籤或使用另一個處理更新的服務
|
||||
Docker 映像。
|
||||
|
||||
無根映像使用 Gitea 內部 SSH 提供 Git 協議，不支持 OpenSSH。
|
||||
無根映像使用 Gitea 內部 SSH 提供 Git 協議，不支援 OpenSSH。
|
||||
|
||||
此參考設置指導用戶通過基於 `docker-compose` 的設置，但 `docker-compose` 的安裝
|
||||
不在本文檔的範圍內。要安裝 `docker-compose` 本身，請遵循
|
||||
此參考設定指導使用者通過基於 `docker-compose` 的設定，但 `docker-compose` 的安裝
|
||||
不在本文件的範圍內。要安裝 `docker-compose` 本身，請遵循
|
||||
官方[安裝說明](https://docs.docker.com/compose/install/)。
|
||||
|
||||
## 基礎
|
||||
|
||||
最簡單的設置只是創建一個卷和一個網絡，並啟動 `docker.gitea.com/gitea:latest-rootless`
|
||||
作為服務的映像。由於沒有可用的數據庫，可以使用 SQLite3 進行初始化。
|
||||
最簡單的設定只是建立一個卷和一個網路，並啟動 `docker.gitea.com/gitea:latest-rootless`
|
||||
作為服務的映像。由於沒有可用的資料庫，可以使用 SQLite3 進行初始化。
|
||||
|
||||
為 `data` 和 `config` 創建一個目錄：
|
||||
為 `data` 和 `config` 建立一個目錄：
|
||||
|
||||
```sh
|
||||
mkdir -p gitea/{data,config}
|
||||
@@ -50,7 +50,7 @@ services:
|
||||
- "2222:2222"
|
||||
```
|
||||
|
||||
請注意，卷應由配置文件中指定的 UID/GID 的用戶/組擁有。默認情況下，docker 中的 Gitea 將使用 uid:1000 gid:1000。如果需要，您可以使用以下命令設置這些文件夾的所有權：
|
||||
請注意，卷應由設定文件中指定的 UID/GID 的使用者/組擁有。預設情況下，docker 中的 Gitea 將使用 uid:1000 gid:1000。如果需要，您可以使用以下命令設定這些文件夾的所有權：
|
||||
|
||||
```sh
|
||||
sudo chown 1000:1000 config/ data/
|
||||
@@ -60,9 +60,9 @@ sudo chown 1000:1000 config/ data/
|
||||
|
||||
對於穩定版本，您可以使用 `:latest-rootless`、`:1-rootless` 或指定某個版本，例如 `:@dockerVersion@-rootless`，但如果您想使用最新的開發版本，則 `:nightly-rootless` 將是一個合適的標籤。如果您想運行來自發布分支的最新提交，您可以使用 `:1.x-nightly-rootless` 標籤，其中 x 是 Gitea 的次要版本。（例如 `:1.16-nightly-rootless`）
|
||||
|
||||
## 自定義端口
|
||||
## 自訂端口
|
||||
|
||||
要在不同的端口上綁定集成的 ssh 和 web 服務器，請調整
|
||||
要在不同的端口上綁定整合的 ssh 和 web 伺服器，請調整
|
||||
端口部分。通常只需更改主機端口並保持容器內的端口不變。
|
||||
|
||||
```diff
|
||||
@@ -84,10 +84,10 @@ services:
|
||||
+ - "22:2222"
|
||||
```
|
||||
|
||||
## MySQL 數據庫
|
||||
## MySQL 資料庫
|
||||
|
||||
要將 Gitea 與 MySQL 數據庫結合使用，請將這些更改應用到
|
||||
上面創建的 `docker-compose.yml` 文件。
|
||||
要將 Gitea 與 MySQL 資料庫結合使用，請將這些更改應用到
|
||||
上面建立的 `docker-compose.yml` 文件。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
@@ -125,10 +125,10 @@ services:
|
||||
+ - ./mysql:/var/lib/mysql
|
||||
```
|
||||
|
||||
## PostgreSQL 數據庫
|
||||
## PostgreSQL 資料庫
|
||||
|
||||
要將 Gitea 與 PostgreSQL 數據庫結合使用，請將這些更改應用到
|
||||
上面創建的 `docker-compose.yml` 文件。
|
||||
要將 Gitea 與 PostgreSQL 資料庫結合使用，請將這些更改應用到
|
||||
上面建立的 `docker-compose.yml` 文件。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
@@ -167,8 +167,8 @@ services:
|
||||
|
||||
## 命名卷
|
||||
|
||||
要使用命名卷而不是主機卷，請在 `docker-compose.yml` 配置中定義並使用命名卷。此更改將自動
|
||||
創建所需的卷。您不需要擔心命名卷的權限；Docker 會自動處理。
|
||||
要使用命名卷而不是主機卷，請在 `docker-compose.yml` 設定中定義並使用命名卷。此更改將自動
|
||||
建立所需的卷。您不需要擔心命名卷的權限；Docker 會自動處理。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
@@ -195,13 +195,13 @@ services:
|
||||
- "2222:2222"
|
||||
```
|
||||
|
||||
MySQL 或 PostgreSQL 容器需要單獨創建。
|
||||
MySQL 或 PostgreSQL 容器需要單獨建立。
|
||||
|
||||
## 自定義用戶
|
||||
## 自訂使用者
|
||||
|
||||
您可以選擇使用自定義用戶（遵循 --user 標誌定義 https://docs.docker.com/engine/reference/run/#user）。
|
||||
例如，要克隆主機用戶 `git` 定義，請使用命令 `id -u git` 並將其添加到 `docker-compose.yml` 文件中：
|
||||
請確保掛載的文件夾可由用戶寫入。
|
||||
您可以選擇使用自訂使用者（遵循 --user 標誌定義 https://docs.docker.com/engine/reference/run/#user）。
|
||||
例如，要克隆主機使用者 `git` 定義，請使用命令 `id -u git` 並將其添加到 `docker-compose.yml` 文件中：
|
||||
請確保掛載的文件夾可由使用者寫入。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
@@ -226,14 +226,14 @@ services:
|
||||
:::note
|
||||
從 2023 年 7 月起，Compose V1 停止接收更新。它也不再可用於 Docker Desktop 的新版本中。
|
||||
|
||||
Compose V2 包含在所有當前支持的 Docker Desktop 版本中。請使用 V2 進行以下操作。
|
||||
Compose V2 包含在所有當前支援的 Docker Desktop 版本中。請使用 V2 進行以下操作。
|
||||
:::
|
||||
|
||||
要基於 `docker-compose` 啟動此設置，請執行 `docker-compose up -d`，
|
||||
在後台啟動 Gitea。使用 `docker-compose ps` 將顯示 Gitea 是否
|
||||
要基於 `docker-compose` 啟動此設定，請執行 `docker-compose up -d`，
|
||||
在後臺啟動 Gitea。使用 `docker-compose ps` 將顯示 Gitea 是否
|
||||
正確啟動。可以使用 `docker-compose logs` 查看日誌。
|
||||
|
||||
要關閉設置，請執行 `docker-compose down`。這將停止
|
||||
要關閉設定，請執行 `docker-compose down`。這將停止
|
||||
並殺死容器。卷將仍然存在。
|
||||
|
||||
:::note
|
||||
@@ -243,23 +243,23 @@ Compose V2 包含在所有當前支持的 Docker Desktop 版本中。請使用 V
|
||||
|
||||
## 安裝
|
||||
|
||||
通過 `docker-compose` 啟動 Docker 設置後，應該可以使用
|
||||
通過 `docker-compose` 啟動 Docker 設定後，應該可以使用
|
||||
喜愛的瀏覽器完成安裝。訪問 http://server-ip:3000 並按照
|
||||
安裝向導進行操作。如果數據庫是使用 `docker-compose` 設置啟動的，
|
||||
如上所述，請注意 `db` 必須用作數據庫主機名。
|
||||
安裝向導進行操作。如果資料庫是使用 `docker-compose` 設定啟動的，
|
||||
如上所述，請注意 `db` 必須用作資料庫主機名。
|
||||
|
||||
## 自定義
|
||||
## 自訂
|
||||
|
||||
[此處](../administration/customizing-gitea.md) 描述的自定義文件應
|
||||
[此處](../administration/customizing-gitea.md) 描述的自訂文件應
|
||||
放置在 `/var/lib/gitea/custom` 目錄中。如果使用主機卷，則可以很容易地訪問這些
|
||||
文件；對於命名卷，這是通過另一個容器或直接訪問
|
||||
`/var/lib/docker/volumes/gitea_gitea/_/var_lib_gitea` 來完成的。配置文件將保存在
|
||||
`/var/lib/docker/volumes/gitea_gitea/_/var_lib_gitea` 來完成的。設定文件將保存在
|
||||
安裝後的 `/etc/gitea/app.ini` 中。
|
||||
|
||||
## 升級
|
||||
|
||||
:::warning
|
||||
:exclamation::exclamation: **確保您已將數據卷掛載到 Docker 容器外的某個位置** :exclamation::exclamation:
|
||||
:exclamation::exclamation: **確保您已將資料卷掛載到 Docker 容器外的某個位置** :exclamation::exclamation:
|
||||
:::
|
||||
|
||||
要將您的安裝升級到最新版本：
|
||||
@@ -274,27 +274,27 @@ docker-compose up -d
|
||||
|
||||
## 從標準映像升級
|
||||
|
||||
- 備份您的設置
|
||||
- 備份您的設定
|
||||
- 將卷掛載點從 /data 更改為 /var/lib/gitea
|
||||
- 如果您使用了自定義 app.ini，請將其移動到掛載到 /etc/gitea 的新卷中
|
||||
- 如果您使用了自訂 app.ini，請將其移動到掛載到 /etc/gitea 的新卷中
|
||||
- 將文件夾（在卷內）重命名為 gitea 為 custom
|
||||
- 如有需要，編輯 app.ini
|
||||
- 設置 START_SSH_SERVER = true
|
||||
- 設定 START_SSH_SERVER = true
|
||||
- 使用映像 docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
|
||||
## 使用環境變量管理部署
|
||||
|
||||
除了上述環境變量外，`app.ini` 中的任何設置都可以設置
|
||||
除了上述環境變量外，`app.ini` 中的任何設定都可以設定
|
||||
或使用形式為 `GITEA__SECTION_NAME__KEY_NAME` 的環境變量覆蓋。
|
||||
這些設置在每次 docker 容器啟動時應用，不會傳遞到 Gitea 的子進程中。
|
||||
完整信息[此處](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini)。
|
||||
這些設定在每次 docker 容器啟動時應用，不會傳遞到 Gitea 的子進程中。
|
||||
完整資訊[此處](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini)。
|
||||
|
||||
這些環境變量可以在 `docker-compose.yml` 中傳遞給 docker 容器。
|
||||
以下示例將啟用 smtp 郵件服務器，如果所需的環境變量
|
||||
`GITEA__mailer__FROM`、`GITEA__mailer__HOST`、`GITEA__mailer__PASSWD` 在主機上設置
|
||||
或在與 `docker-compose.yml` 相同的目錄中的 `.env` 文件中設置。
|
||||
以下範例將啟用 smtp 郵件伺服器，如果所需的環境變量
|
||||
`GITEA__mailer__FROM`、`GITEA__mailer__HOST`、`GITEA__mailer__PASSWD` 在主機上設定
|
||||
或在與 `docker-compose.yml` 相同的目錄中的 `.env` 文件中設定。
|
||||
|
||||
這些設置也可以通過定義形式為的環境變量來設置或覆蓋：
|
||||
這些設定也可以透過定義形式為的環境變量來設定或覆蓋：
|
||||
`GITEA__section_name__KEY_NAME__FILE` 指向文件。
|
||||
|
||||
```bash
|
||||
@@ -311,15 +311,15 @@ services:
|
||||
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
|
||||
```
|
||||
|
||||
要設置所需的 TOKEN 和 SECRET 值，請考慮使用 Gitea 的內置[生成實用程序函數](../administration/command-line.md#generate)。
|
||||
要設定所需的 TOKEN 和 SECRET 值，請考慮使用 Gitea 的內置[生成實用程式函數](../administration/command-line.md#generate)。
|
||||
|
||||
# SSH 容器透傳
|
||||
|
||||
由於 SSH 在容器內運行，因此如果需要 SSH 支持，則需要將 SSH 從主機透傳到容器。一種選擇是將容器 SSH 運行在非標準端口上（或將主機端口移動到非標準端口）。另一種可能更直接的方法是將 SSH 命令從主機轉發到容器。以下說明了這種設置。
|
||||
由於 SSH 在容器內運行，因此如果需要 SSH 支援，則需要將 SSH 從主機透傳到容器。一種選擇是將容器 SSH 運行在非標準端口上（或將主機端口移動到非標準端口）。另一種可能更直接的方法是將 SSH 命令從主機轉發到容器。以下說明瞭這種設定。
|
||||
|
||||
本指南假設您已在主機上創建了一個名為 `git` 的用戶，該用戶有權運行 `docker exec`，並且 Gitea 容器名為 `gitea`。您需要修改該用戶的 shell 以使用 `docker exec` 將命令轉發到容器內的 `sh` 可執行文件。
|
||||
本指南假設您已在主機上建立了一個名為 `git` 的使用者，該使用者有權運行 `docker exec`，並且 Gitea 容器名為 `gitea`。您需要修改該使用者的 shell 以使用 `docker exec` 將命令轉發到容器內的 `sh` 可執行文件。
|
||||
|
||||
首先，在主機上創建文件 `/usr/local/bin/gitea-shell`，內容如下：
|
||||
首先，在主機上建立文件 `/usr/local/bin/gitea-shell`，內容如下：
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
@@ -328,19 +328,19 @@ services:
|
||||
|
||||
請注意，docker 命令中的 `gitea` 是容器的名稱。如果您命名不同，請不要忘記更改它。
|
||||
|
||||
您還應確保已正確設置 shell 包裝器的權限：
|
||||
您還應確保已正確設定 shell 包裝器的權限：
|
||||
|
||||
```bash
|
||||
sudo chmod +x /usr/local/bin/gitea-shell
|
||||
```
|
||||
|
||||
包裝器就位後，您可以將其設置為 `git` 用戶的 shell：
|
||||
包裝器就位後，您可以將其設定為 `git` 使用者的 shell：
|
||||
|
||||
```bash
|
||||
sudo usermod -s /usr/local/bin/gitea-shell git
|
||||
```
|
||||
|
||||
現在所有的 SSH 命令都轉發到容器，您需要在主機上設置 SSH 認證。這是通過利用 [SSH AuthorizedKeysCommand](../administration/command-line.md#keys) 將密鑰與 Gitea 接受的密鑰匹配來完成的。在主機上的 `/etc/ssh/sshd_config` 中添加以下塊：
|
||||
現在所有的 SSH 命令都轉發到容器，您需要在主機上設定 SSH 認證。這是通過利用 [SSH AuthorizedKeysCommand](../administration/command-line.md#keys) 將密鑰與 Gitea 接受的密鑰匹配來完成的。在主機上的 `/etc/ssh/sshd_config` 中添加以下塊：
|
||||
|
||||
```bash
|
||||
Match User git
|
||||
@@ -348,9 +348,9 @@ Match User git
|
||||
AuthorizedKeysCommand /usr/bin/docker exec -i gitea /usr/local/bin/gitea keys -c /etc/gitea/app.ini -e git -u %u -t %t -k %k
|
||||
```
|
||||
|
||||
（從 1.16.0 開始，您不需要設置 `-c /etc/gitea/app.ini` 選項。）
|
||||
（從 1.16.0 開始，您不需要設定 `-c /etc/gitea/app.ini` 選項。）
|
||||
|
||||
剩下的就是重啟 SSH 服務器：
|
||||
剩下的就是重啟 SSH 伺服器：
|
||||
|
||||
```bash
|
||||
sudo systemctl restart sshd
|
||||
@@ -359,4 +359,4 @@ sudo systemctl restart sshd
|
||||
**注意**
|
||||
|
||||
這實際上並未使用 docker SSH - 它只是使用周圍的命令。
|
||||
理論上，您可以不運行內部 SSH 服務器。
|
||||
理論上，您可以不運行內部 SSH 伺服器。
|
||||
+36
-36
@@ -10,11 +10,11 @@ aliases:
|
||||
|
||||
Gitea 在其 Docker Hub 組織中提供自動更新的 Docker 映像。可以始終使用最新的穩定標籤或使用其他服務來處理 Docker 映像的更新。
|
||||
|
||||
此參考設置指導用戶基於 `docker-compose` 進行設置，但 `docker-compose` 的安裝不在本文檔的範圍內。要安裝 `docker-compose` 本身，請按照官方的[安裝說明](https://docs.docker.com/compose/install/)進行操作。
|
||||
此參考設定指導使用者基於 `docker-compose` 進行設定，但 `docker-compose` 的安裝不在本文件的範圍內。要安裝 `docker-compose` 本身，請按照官方的[安裝說明](https://docs.docker.com/compose/install/)進行操作。
|
||||
|
||||
## 基本
|
||||
|
||||
最簡單的設置只需創建一個卷和一個網絡，並將 `docker.gitea.com/gitea:latest` 映像作為服務啟動。由於沒有可用的數據庫，可以使用 SQLite3 進行初始化。創建一個名為 `gitea` 的目錄，並將以下內容粘貼到名為 `docker-compose.yml` 的文件中。請注意，卷應由配置文件中指定的 UID/GID 的用戶/組擁有。如果您未給卷正確的權限，容器可能無法啟動。對於穩定版本，您可以使用 `:latest`、`:1` 或指定某個版本，如 `:@dockerVersion@`，但如果您想使用 Gitea 的最新開發版本，則可以使用 `:nightly` 標籤。如果您想運行來自發布分支的最新提交，可以使用 `:1.x-nightly` 標籤，其中 x 是 Gitea 的次要版本。（例如 `:1.16-nightly`）
|
||||
最簡單的設定只需建立一個卷和一個網路，並將 `docker.gitea.com/gitea:latest` 映像作為服務啟動。由於沒有可用的資料庫，可以使用 SQLite3 進行初始化。建立一個名為 `gitea` 的目錄，並將以下內容粘貼到名為 `docker-compose.yml` 的文件中。請注意，卷應由設定文件中指定的 UID/GID 的使用者/組擁有。如果您未給卷正確的權限，容器可能無法啟動。對於穩定版本，您可以使用 `:latest`、`:1` 或指定某個版本，如 `:@dockerVersion@`，但如果您想使用 Gitea 的最新開發版本，則可以使用 `:nightly` 標籤。如果您想運行來自發布分支的最新提交，可以使用 `:1.x-nightly` 標籤，其中 x 是 Gitea 的次要版本。（例如 `:1.16-nightly`）
|
||||
|
||||
```yaml
|
||||
version: "3"
|
||||
@@ -44,7 +44,7 @@ services:
|
||||
|
||||
## 端口
|
||||
|
||||
要在不同的端口上綁定集成的 OpenSSH 守護進程和 Web 服務器，請調整端口部分。通常只需更改主機端口並保持容器內的端口不變。
|
||||
要在不同的端口上綁定整合的 OpenSSH 守護進程和 Web 伺服器，請調整端口部分。通常只需更改主機端口並保持容器內的端口不變。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
@@ -74,11 +74,11 @@ services:
|
||||
+ - "2221:22"
|
||||
```
|
||||
|
||||
## 數據庫
|
||||
## 資料庫
|
||||
|
||||
### MySQL 數據庫
|
||||
### MySQL 資料庫
|
||||
|
||||
要將 Gitea 與 MySQL 數據庫結合使用，請對上面創建的 `docker-compose.yml` 文件進行以下更改。
|
||||
要將 Gitea 與 MySQL 資料庫結合使用，請對上面建立的 `docker-compose.yml` 文件進行以下更改。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
@@ -126,9 +126,9 @@ services:
|
||||
+ - ./mysql:/var/lib/mysql
|
||||
```
|
||||
|
||||
### PostgreSQL 數據庫
|
||||
### PostgreSQL 資料庫
|
||||
|
||||
要將 Gitea 與 PostgreSQL 數據庫結合使用，請對上面創建的 `docker-compose.yml` 文件進行以下更改。
|
||||
要將 Gitea 與 PostgreSQL 資料庫結合使用，請對上面建立的 `docker-compose.yml` 文件進行以下更改。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
@@ -177,7 +177,7 @@ services:
|
||||
|
||||
## 命名卷
|
||||
|
||||
要使用命名卷而不是主機卷，請在 `docker-compose.yml` 配置中定義並使用命名卷。此更改將自動創建所需的卷。使用命名卷時，您不需要擔心權限問題；Docker 會自動處理。
|
||||
要使用命名卷而不是主機卷，請在 `docker-compose.yml` 設定中定義並使用命名卷。此更改將自動建立所需的卷。使用命名卷時，您不需要擔心權限問題；Docker 會自動處理。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
@@ -207,19 +207,19 @@ services:
|
||||
- "222:22"
|
||||
```
|
||||
|
||||
MySQL 或 PostgreSQL 容器需要單獨創建。
|
||||
MySQL 或 PostgreSQL 容器需要單獨建立。
|
||||
|
||||
## 啟動
|
||||
|
||||
:::note
|
||||
從 2023 年 7 月起，Compose V1 停止接收更新。它也不再包含在 Docker Desktop 的新版本中。
|
||||
|
||||
Compose V2 包含在所有當前支持的 Docker Desktop 版本中。請使用 V2 進行以下操作。
|
||||
Compose V2 包含在所有當前支援的 Docker Desktop 版本中。請使用 V2 進行以下操作。
|
||||
:::
|
||||
|
||||
要基於 `docker-compose` 啟動此設置，請執行 `docker-compose up -d`，以在後台啟動 Gitea。使用 `docker-compose ps` 將顯示 Gitea 是否正確啟動。可以使用 `docker-compose logs` 查看日誌。
|
||||
要基於 `docker-compose` 啟動此設定，請執行 `docker-compose up -d`，以在後臺啟動 Gitea。使用 `docker-compose ps` 將顯示 Gitea 是否正確啟動。可以使用 `docker-compose logs` 查看日誌。
|
||||
|
||||
要關閉設置，請執行 `docker-compose down`。這將停止並殺死容器。卷仍然存在。
|
||||
要關閉設定，請執行 `docker-compose down`。這將停止並殺死容器。卷仍然存在。
|
||||
|
||||
:::note
|
||||
如果在 http 上使用非 3000 端口，請更改 app.ini 以匹配 `LOCAL_ROOT_URL = http://localhost:3000/`。
|
||||
@@ -227,22 +227,22 @@ Compose V2 包含在所有當前支持的 Docker Desktop 版本中。請使用 V
|
||||
|
||||
## 安裝
|
||||
|
||||
通過 `docker-compose` 啟動 Docker 設置後，應該可以使用喜愛的瀏覽器來完成安裝。訪問 http://server-ip:3000 並按照安裝向導進行操作。如果數據庫是使用上述 `docker-compose` 設置啟動的，請注意，數據庫主機名必須使用 `db`。
|
||||
通過 `docker-compose` 啟動 Docker 設定後，應該可以使用喜愛的瀏覽器來完成安裝。訪問 http://server-ip:3000 並按照安裝向導進行操作。如果資料庫是使用上述 `docker-compose` 設定啟動的，請注意，資料庫主機名必須使用 `db`。
|
||||
|
||||
## 使用環境變量配置 Gitea 內的用戶
|
||||
## 使用環境變量設定 Gitea 內的使用者
|
||||
|
||||
- `USER`: **git**: 在容器內運行 Gitea 的用戶名。
|
||||
- `USER_UID`: **1000**: 在容器內運行 Gitea 的用戶的 UID（Unix 用戶 ID）。如果使用主機卷，請將其與 `/data` 卷的所有者的 UID 匹配（使用命名卷時不需要）。
|
||||
- `USER_GID`: **1000**: 在容器內運行 Gitea 的用戶的 GID（Unix 組 ID）。如果使用主機卷，請將其與 `/data` 卷的所有者的 GID 匹配（使用命名卷時不需要）。
|
||||
- `USER`: **git**: 在容器內運行 Gitea 的使用者名稱。
|
||||
- `USER_UID`: **1000**: 在容器內運行 Gitea 的使用者的 UID（Unix 使用者 ID）。如果使用主機卷，請將其與 `/data` 卷的所有者的 UID 匹配（使用命名卷時不需要）。
|
||||
- `USER_GID`: **1000**: 在容器內運行 Gitea 的使用者的 GID（Unix 組 ID）。如果使用主機卷，請將其與 `/data` 卷的所有者的 GID 匹配（使用命名卷時不需要）。
|
||||
|
||||
## 自定義
|
||||
## 自訂
|
||||
|
||||
[此處](../administration/customizing-gitea.md)描述的自定義文件應放置在 `/data/gitea` 目錄中。如果使用主機卷，訪問這些文件非常容易；對於命名卷，可以通過另一個容器或直接訪問 `/var/lib/docker/volumes/gitea_gitea/_data` 來完成。安裝後，配置文件將保存在 `/data/gitea/conf/app.ini`。
|
||||
[此處](../administration/customizing-gitea.md)描述的自訂文件應放置在 `/data/gitea` 目錄中。如果使用主機卷，訪問這些文件非常容易；對於命名卷，可以透過另一個容器或直接訪問 `/var/lib/docker/volumes/gitea_gitea/_data` 來完成。安裝後，設定文件將保存在 `/data/gitea/conf/app.ini`。
|
||||
|
||||
## 升級
|
||||
|
||||
:::warning
|
||||
確保您已將卷數據保存到 Docker 容器外的某個位置
|
||||
確保您已將卷資料保存到 Docker 容器外的某個位置
|
||||
:::
|
||||
|
||||
要將您的安裝升級到最新版本：
|
||||
@@ -257,11 +257,11 @@ docker-compose up -d
|
||||
|
||||
## 使用環境變量管理部署
|
||||
|
||||
除了上述的環境變量外，`app.ini` 中的任何設置都可以使用形式為 `GITEA__SECTION_NAME__KEY_NAME` 的環境變量進行設置或覆蓋。這些設置在每次 Docker 容器啟動時應用，不會傳遞到 Gitea 的子進程中。完整信息[在此](https://github.com/go-gitea/gitea/tree/master/contrib/environment-to-ini)。
|
||||
除了上述的環境變量外，`app.ini` 中的任何設定都可以使用形式為 `GITEA__SECTION_NAME__KEY_NAME` 的環境變量進行設定或覆蓋。這些設定在每次 Docker 容器啟動時應用，不會傳遞到 Gitea 的子進程中。完整資訊[在此](https://github.com/go-gitea/gitea/tree/master/contrib/environment-to-ini)。
|
||||
|
||||
這些環境變量可以在 `docker-compose.yml` 中傳遞給 Docker 容器。以下示例將在設置所需的環境變量 `GITEA__mailer__FROM`、`GITEA__mailer__HOST`、`GITEA__mailer__PASSWD` 時啟用 SMTP 郵件服務器。
|
||||
這些環境變量可以在 `docker-compose.yml` 中傳遞給 Docker 容器。以下範例將在設定所需的環境變量 `GITEA__mailer__FROM`、`GITEA__mailer__HOST`、`GITEA__mailer__PASSWD` 時啟用 SMTP 郵件伺服器。
|
||||
|
||||
這些設置也可以通過定義形式為 `GITEA__section_name__KEY_NAME__FILE` 的環境變量並指向文件的內容來設置或覆蓋。
|
||||
這些設定也可以透過定義形式為 `GITEA__section_name__KEY_NAME__FILE` 的環境變量並指向文件的內容來設定或覆蓋。
|
||||
|
||||
```yaml
|
||||
---
|
||||
@@ -277,7 +277,7 @@ services:
|
||||
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
|
||||
```
|
||||
|
||||
Gitea 將自動為每個新安裝生成新的密鑰/令牌並將其寫入 app.ini。如果您想手動設置密鑰/令牌，可以使用以下 Docker 命令來使用 Gitea 的內置[生成實用程序函數](../administration/command-line.md#generate)。安裝後請勿丟失/更改您的 SECRET_KEY，否則加密數據將無法解密。
|
||||
Gitea 將自動為每個新安裝生成新的密鑰/令牌並將其寫入 app.ini。如果您想手動設定密鑰/令牌，可以使用以下 Docker 命令來使用 Gitea 的內置[生成實用程式函數](../administration/command-line.md#generate)。安裝後請勿丟失/更改您的 SECRET_KEY，否則加密資料將無法解密。
|
||||
|
||||
以下命令將輸出新的 `SECRET_KEY` 和 `INTERNAL_TOKEN` 到 `stdout`，然後您可以將其放置在您的環境變量中。
|
||||
|
||||
@@ -297,27 +297,27 @@ services:
|
||||
|
||||
## SSH 容器透傳
|
||||
|
||||
由於 SSH 在容器內運行，如果需要 SSH 支持，則需要將 SSH 從主機透傳到容器。一個選項是將容器 SSH 運行在非標準端口（或將主機端口移動到非標準端口）。另一個可能更直接的選項是讓 Gitea 用戶 SSH 到主機上的 Gitea 用戶，然後將這些連接中繼到 Docker。或者，如果主機有多個 IP 地址，主機可以在一個上監聽，Gitea 在另一個上監聽。
|
||||
由於 SSH 在容器內運行，如果需要 SSH 支援，則需要將 SSH 從主機透傳到容器。一個選項是將容器 SSH 運行在非標準端口（或將主機端口移動到非標準端口）。另一個可能更直接的選項是讓 Gitea 使用者 SSH 到主機上的 Gitea 使用者，然後將這些連接中繼到 Docker。或者，如果主機有多個 IP 地址，主機可以在一個上監聽，Gitea 在另一個上監聽。
|
||||
|
||||
### 理解對 Gitea 的 SSH 訪問（無需透傳）
|
||||
|
||||
要理解需要發生什麼，首先需要理解在沒有透傳的情況下會發生什麼。因此，我們將嘗試解釋這一點：
|
||||
|
||||
1. 客戶端使用網頁將其 SSH 公鑰添加到 Gitea。
|
||||
2. Gitea 將為此密鑰在其運行用戶 `git` 的 `.ssh/authorized_keys` 文件中添加一個條目。
|
||||
3. 此條目具有公鑰，但也具有 `command=` 選項。Gitea 使用此命令將此密鑰與客戶端用戶匹配並管理身份驗證。
|
||||
4. 然後，客戶端使用 `git` 用戶向 SSH 服務器發出 SSH 請求，例如 `git clone git@domain:user/repo.git`。
|
||||
5. 客戶端將嘗試與服務器進行身份驗證，一次向服務器傳遞一個或多個公鑰。
|
||||
6. 對於客戶端提供的每個密鑰，SSH 服務器將首先檢查其配置中的 `AuthorizedKeysCommand` 以查看公鑰是否匹配，然後檢查 `git` 用戶的 `authorized_keys` 文件。
|
||||
2. Gitea 將為此密鑰在其運行使用者 `git` 的 `.ssh/authorized_keys` 文件中添加一個條目。
|
||||
3. 此條目具有公鑰，但也具有 `command=` 選項。Gitea 使用此命令將此密鑰與客戶端使用者匹配並管理身份驗證。
|
||||
4. 然後，客戶端使用 `git` 使用者向 SSH 伺服器發出 SSH 請求，例如 `git clone git@domain:user/repo.git`。
|
||||
5. 客戶端將嘗試與伺服器進行身份驗證，一次向伺服器傳遞一個或多個公鑰。
|
||||
6. 對於客戶端提供的每個密鑰，SSH 伺服器將首先檢查其設定中的 `AuthorizedKeysCommand` 以查看公鑰是否匹配，然後檢查 `git` 使用者的 `authorized_keys` 文件。
|
||||
7. 將選擇第一個匹配的條目，假設這是 Gitea 條目，則現在將執行 `command=`。
|
||||
8. SSH 服務器為 `git` 用戶創建一個用戶會話，並使用 `git` 用戶的 shell 運行 `command=`
|
||||
8. SSH 伺服器為 `git` 使用者建立一個使用者會話，並使用 `git` 使用者的 shell 運行 `command=`
|
||||
9. 這將運行 `gitea serv`，接管 SSH 會話的其餘部分並管理 gitea 的身份驗證和授權。
|
||||
|
||||
現在，要使 SSH 透傳工作，我們需要主機 SSH 匹配公鑰，然後在 Docker 上運行 `gitea serv`。有多種方法可以做到這一點。然而，所有這些都需要將有關 Docker 的一些信息傳遞給主機。
|
||||
現在，要使 SSH 透傳工作，我們需要主機 SSH 匹配公鑰，然後在 Docker 上運行 `gitea serv`。有多種方法可以做到這一點。然而，所有這些都需要將有關 Docker 的一些資訊傳遞給主機。
|
||||
|
||||
### SSHing Shim（使用 authorized_keys）
|
||||
|
||||
在此選項中，主機只需使用 gitea 創建的 `authorized_keys`，但在第 9 步中，主機運行的 `gitea` 命令是一個 shim，實際上運行 ssh 進入 docker，然後運行真正的 docker `gitea` 本身。
|
||||
在此選項中，主機只需使用 gitea 建立的 `authorized_keys`，但在第 9 步中，主機運行的 `gitea` 命令是一個 shim，實際上運行 ssh 進入 docker，然後運行真正的 docker `gitea` 本身。
|
||||
|
||||
- 要使轉發工作，容器的 SSH 端口（22）需要在 `docker-compose.yml` 中映射到主機端口 2222。由於此端口不需要暴露給外界，因此可以映射到主機的 `localhost`：
|
||||
|
||||
@@ -327,7 +327,7 @@ services:
|
||||
- "127.0.0.1:2222:22"
|
||||
```
|
||||
|
||||
- 接下來在主機上創建與容器值 `USER_UID`/`USER_GID` 共享相同 `UID`/`GID` 的 `git` 用戶。這些值可以在 `docker-compose.yml` 中設置為環境變量：
|
||||
- 接下來在主機上建立與容器值 `USER_UID`/`USER_GID` 共享相同 `UID`/`GID` 的 `git` 使用者。這些值可以在 `docker-compose.yml` 中設定為環境變量：
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
@@ -335,7 +335,7 @@ services:
|
||||
- USER_GID=1000
|
||||
```
|
||||
|
||||
- 將主機的 `/home/git/.ssh` 安裝到容器中。這確保了 `authorized_keys` 文件在主機 `git` 用戶和容器 `git` 用戶之間共享，否則 SSH 身份驗證無法在容器內工作。
|
||||
- 將主機的 `/home/git/.ssh` 安裝到容器中。這確保了 `authorized_keys` 文件在主機 `git` 使用者和容器 `git` 使用者之間共享，否則 SSH 身份驗證無法在容器內工作。
|
||||
|
||||
```yaml
|
||||
volumes:
|
||||
|
||||
+44
-44
@@ -10,9 +10,9 @@ sidebar_position: 20
|
||||
|
||||
## 要求
|
||||
|
||||
目前 runner 支持兩種運行模式。一種是在 docker 容器中運行，另一種是在主機上運行。如果選擇在 [docker](https://docker.com) 容器中運行作業，建議先 [安裝 docker](https://docs.docker.com/engine/install/) 並確保 docker 守護進程正在運行。
|
||||
目前 runner 支援兩種運行模式。一種是在 docker 容器中運行，另一種是在主機上運行。如果選擇在 [docker](https://docker.com) 容器中運行作業，建議先 [安裝 docker](https://docs.docker.com/engine/install/) 並確保 docker 守護進程正在運行。
|
||||
|
||||
其他與 Docker API 兼容的 OCI 容器引擎也應該可以工作，但未經測試。
|
||||
其他與 Docker API 相容的 OCI 容器引擎也應該可以工作，但未經測試。
|
||||
|
||||
但是，如果您確定只想在主機上直接運行作業，則不需要 docker。
|
||||
|
||||
@@ -26,52 +26,52 @@ sidebar_position: 20
|
||||
但是，如果您想使用最新的夜間構建，可以從 [下載頁面](https://dl.gitea.com/act_runner/) 下載。
|
||||
|
||||
下載二進制文件時，請確保下載了適合您平台的正確文件。
|
||||
如果您使用的是類 Unix 操作系統，可以通過運行以下命令進行檢查。
|
||||
如果您使用的是類 Unix 操作系統，可以透過運行以下命令進行檢查。
|
||||
|
||||
```bash
|
||||
chmod +x act_runner
|
||||
./act_runner --version
|
||||
```
|
||||
|
||||
如果看到版本信息，則表示您已下載了正確的二進制文件。
|
||||
如果看到版本資訊，則表示您已下載了正確的二進制文件。
|
||||
|
||||
### 獲取註冊令牌
|
||||
|
||||
您可以在不同級別註冊 runner，它可以是：
|
||||
|
||||
- 實例級別：runner 將為實例中的所有倉庫運行作業。
|
||||
- 組織級別：runner 將為組織中的所有倉庫運行作業。
|
||||
- 倉庫級別：runner 將為其所屬的倉庫運行作業。
|
||||
- 實例級別：runner 將為實例中的所有儲存庫運行作業。
|
||||
- 組織級別：runner 將為組織中的所有儲存庫運行作業。
|
||||
- 儲存庫級別：runner 將為其所屬的儲存庫運行作業。
|
||||
|
||||
請注意，即使倉庫有自己的倉庫級別 runner，它仍然可以使用實例級別或組織級別的 runner。未來的版本可能會提供更多控制選項。
|
||||
請注意，即使儲存庫有自己的儲存庫級別 runner，它仍然可以使用實例級別或組織級別的 runner。未來的版本可能會提供更多控制選項。
|
||||
|
||||
在註冊 runner 並運行它之前，您需要一個註冊令牌。runner 的級別決定了從哪裡獲取註冊令牌。
|
||||
|
||||
- 實例級別：管理員設置頁面，例如 `<your_gitea.com>/admin/actions/runners`。
|
||||
- 組織級別：組織設置頁面，例如 `<your_gitea.com>/<org>/settings/actions/runners`。
|
||||
- 倉庫級別：倉庫設置頁面，例如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。
|
||||
- 實例級別：管理員設定頁面，例如 `<your_gitea.com>/admin/actions/runners`。
|
||||
- 組織級別：組織設定頁面，例如 `<your_gitea.com>/<org>/settings/actions/runners`。
|
||||
- 儲存庫級別：儲存庫設定頁面，例如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。
|
||||
|
||||
如果看不到設置頁面，請確保您具有正確的權限並且已啟用 Actions。
|
||||
如果看不到設定頁面，請確保您具有正確的權限並且已啟用 Actions。
|
||||
|
||||
註冊令牌的格式是一個隨機字符串 `D0gvfu2iHfUjNqCYVljVyRV14fISpJxxxxxxxxxx`。
|
||||
|
||||
註冊令牌也可以從 gitea [命令行界面](../../administration/command-line.md#actions-generate-runner-token) 獲取：
|
||||
註冊令牌也可以從 gitea [命令行介面](/administration/command-line#actions-generate-runner-token) 獲取：
|
||||
|
||||
```
|
||||
gitea --config /etc/gitea/app.ini actions generate-runner-token
|
||||
```
|
||||
|
||||
令牌在註銷並使用 web 界面中的令牌重置鏈接替換為新令牌之前，對註冊多個 runner 有效。
|
||||
令牌在註銷並使用 Web 介面中的令牌重置鏈接替換為新令牌之前，對註冊多個 runner 有效。
|
||||
|
||||
### 配置
|
||||
### 設定
|
||||
|
||||
配置是通過配置文件完成的。它是可選的，當未指定配置文件時，將使用默認配置。您可以通過運行以下命令生成配置文件：
|
||||
設定是通過設定文件完成的。它是可選的，當未指定設定文件時，將使用預設設定。您可以透過運行以下命令生成設定文件：
|
||||
|
||||
```bash
|
||||
./act_runner generate-config
|
||||
```
|
||||
|
||||
默認配置是安全的，可以直接使用。
|
||||
預設設定是安全的，可以直接使用。
|
||||
|
||||
```bash
|
||||
./act_runner generate-config > config.yaml
|
||||
@@ -82,24 +82,24 @@ gitea --config /etc/gitea/app.ini actions generate-runner-token
|
||||
|
||||
在運行 act runner 之前需要註冊，因為 runner 需要知道從哪裡獲取作業。這對於 Gitea 實例識別 runner 也很重要。
|
||||
|
||||
如果使用二進制包安裝，可以通過運行以下命令註冊 act runner。
|
||||
如果使用二進制包安裝，可以透過運行以下命令註冊 act runner。
|
||||
|
||||
```bash
|
||||
./act_runner register
|
||||
```
|
||||
|
||||
或者，您可以使用 `--config` 選項指定前面提到的配置文件。
|
||||
或者，您可以使用 `--config` 選項指定前面提到的設定文件。
|
||||
|
||||
```bash
|
||||
./act_runner --config config.yaml register
|
||||
```
|
||||
|
||||
您將被要求逐步輸入註冊信息，包括：
|
||||
您將被要求逐步輸入註冊資訊，包括：
|
||||
|
||||
- Gitea 實例 URL，例如 `https://gitea.com/` 或 `http://192.168.8.8:3000/`。
|
||||
- 註冊令牌。
|
||||
- runner 名稱，可選。如果留空，將使用主機名。
|
||||
- runner 標籤，可選。如果留空，將使用默認標籤。
|
||||
- runner 標籤，可選。如果留空，將使用預設標籤。
|
||||
|
||||
您可能會對 runner 標籤感到困惑，稍後將解釋。
|
||||
|
||||
@@ -110,16 +110,16 @@ gitea --config /etc/gitea/app.ini actions generate-runner-token
|
||||
```
|
||||
|
||||
註冊 runner 後，您可以在當前目錄中找到一個名為 `.runner` 的新文件。
|
||||
該文件存儲註冊信息。
|
||||
該文件儲存註冊資訊。
|
||||
請不要手動編輯它。
|
||||
如果該文件丟失或損壞，您可以簡單地刪除它並重新註冊。
|
||||
|
||||
如果您想將註冊信息存儲在其他位置，可以在配置文件中指定，
|
||||
如果您想將註冊資訊儲存在其他位置，可以在設定文件中指定，
|
||||
並且不要忘記指定 `--config` 選項。
|
||||
|
||||
### 在命令行中啟動 runner
|
||||
|
||||
註冊 runner 後，可以通過運行以下命令運行它：
|
||||
註冊 runner 後，可以透過運行以下命令運行它：
|
||||
|
||||
```shell
|
||||
./act_runner daemon
|
||||
@@ -135,7 +135,7 @@ runner 將從 Gitea 實例中獲取作業並自動運行它們。
|
||||
|
||||
### 使用 Systemd 啟動 runner
|
||||
|
||||
也可以將 act-runner 作為 [systemd](https://en.wikipedia.org/wiki/Systemd) 服務運行。在系統上創建一個非特權的 `act_runner` 用戶，並在 `/etc/systemd/system/act_runner.service` 中創建以下文件。`ExecStart` 和 `WorkingDirectory` 中的路徑可能需要根據您安裝 `act_runner` 二進制文件、其配置文件和 `act_runner` 用戶的主目錄進行調整。
|
||||
也可以將 act-runner 作為 [systemd](https://en.wikipedia.org/wiki/Systemd) 服務運行。在系統上建立一個非特權的 `act_runner` 使用者，並在 `/etc/systemd/system/act_runner.service` 中建立以下文件。`ExecStart` 和 `WorkingDirectory` 中的路徑可能需要根據您安裝 `act_runner` 二進制文件、其設定文件和 `act_runner` 使用者的主目錄進行調整。
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
@@ -165,11 +165,11 @@ sudo systemctl daemon-reload
|
||||
sudo systemctl enable act_runner --now
|
||||
```
|
||||
|
||||
如果使用 Docker，應在啟動服務之前將 `act_runner` 用戶添加到 `docker` 組。請記住，這實際上給了 `act_runner` 對系統的 root 訪問權限 [[1]](https://docs.docker.com/engine/security/#docker-daemon-attack-surface)。
|
||||
如果使用 Docker，應在啟動服務之前將 `act_runner` 使用者添加到 `docker` 組。請記住，這實際上給了 `act_runner` 對系統的 root 存取權限 [[1]](https://docs.docker.com/engine/security/#docker-daemon-attack-surface)。
|
||||
|
||||
### 使用 LaunchDaemon(macOS) 啟動 runner
|
||||
|
||||
Mac 使用 `launchd` 代替 systemd 註冊守護進程。默認情況下，守護進程以 root 用戶身份運行，因此如果需要，可以通過 `dscl` 工具創建一個非特權的 `_act_runner` 用戶。然後應在 `/Library/LaunchDaemon/com.gitea.act_runner.plist` 目錄中創建以下文件。`WorkingDirectory`、`ProgramArguments`、`StandardOutPath`、`StandardErrPath` 和 `HOME` 環境變量的路徑可能需要更新以反映您的安裝。此外，任何不在示例 `PATH` 中的可執行文件都需要顯式包含，並且不會從現有配置中繼承。
|
||||
Mac 使用 `launchd` 代替 systemd 註冊守護進程。預設情況下，守護進程以 root 使用者身份運行，因此如果需要，可以透過 `dscl` 工具建立一個非特權的 `_act_runner` 使用者。然後應在 `/Library/LaunchDaemon/com.gitea.act_runner.plist` 目錄中建立以下文件。`WorkingDirectory`、`ProgramArguments`、`StandardOutPath`、`StandardErrPath` 和 `HOME` 環境變量的路徑可能需要更新以反映您的安裝。此外，任何不在範例 `PATH` 中的可執行文件都需要顯式包含，並且不會從現有設定中繼承。
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
@@ -214,7 +214,7 @@ Mac 使用 `launchd` 代替 systemd 註冊守護進程。默認情況下，守
|
||||
sudo launchctl load /Library/LaunchDaemon/com.gitea.act_runner.plist
|
||||
```
|
||||
|
||||
您還可以設置 Linux 服務或 Windows 服務，以便 runner 自動運行。
|
||||
您還可以設定 Linux 服務或 Windows 服務，以便 runner 自動運行。
|
||||
|
||||
## 使用 docker 映像安裝
|
||||
|
||||
@@ -233,15 +233,15 @@ docker pull docker.io/gitea/act_runner:latest # 用於最新的穩定版本
|
||||
docker pull docker.io/gitea/act_runner:nightly # 用於最新的夜間構建
|
||||
```
|
||||
|
||||
### 配置
|
||||
### 設定
|
||||
|
||||
配置是可選的，但您也可以使用 docker 生成配置文件：
|
||||
設定是可選的，但您也可以使用 docker 生成設定文件：
|
||||
|
||||
```bash
|
||||
docker run --entrypoint="" --rm -it docker.io/gitea/act_runner:latest act_runner generate-config > config.yaml
|
||||
```
|
||||
|
||||
使用 docker 映像時，可以使用 `CONFIG_FILE` 環境變量指定配置文件。確保該文件已作為卷掛載到容器中：
|
||||
使用 docker 映像時，可以使用 `CONFIG_FILE` 環境變量指定設定文件。確保該文件已作為卷掛載到容器中：
|
||||
|
||||
```bash
|
||||
docker run -v $PWD/config.yaml:/config.yaml -e CONFIG_FILE=/config.yaml ...
|
||||
@@ -252,7 +252,7 @@ docker run -v $PWD/config.yaml:/config.yaml -e CONFIG_FILE=/config.yaml ...
|
||||
|
||||
### 使用 docker 啟動 runner
|
||||
|
||||
如果您使用的是 docker 映像，行為會略有不同。在這種情況下，註冊和運行結合為一步，因此您需要在運行 act runner 時指定註冊信息。
|
||||
如果您使用的是 docker 映像，行為會略有不同。在這種情況下，註冊和運行結合為一步，因此您需要在運行 act runner 時指定註冊資訊。
|
||||
|
||||
使用 docker run 快速啟動如下。您需要從上述步驟中獲取 `<registration_token>`，並為 `<runner_name>` 提供一個特殊的唯一名稱
|
||||
|
||||
@@ -265,7 +265,7 @@ docker run \
|
||||
-d docker.io/gitea/act_runner:nightly
|
||||
```
|
||||
|
||||
有更多參數可以配置它。
|
||||
有更多參數可以設定它。
|
||||
|
||||
```bash
|
||||
docker run \
|
||||
@@ -288,7 +288,7 @@ docker run \
|
||||
|
||||
### 使用 docker compose 啟動 runner
|
||||
|
||||
您還可以使用以下 `docker-compose.yml` 設置 runner：
|
||||
您還可以使用以下 `docker-compose.yml` 設定 runner：
|
||||
|
||||
```yml
|
||||
version: "3.8"
|
||||
@@ -309,23 +309,23 @@ services:
|
||||
|
||||
使用 docker 時，不需要進入容器並手動運行 `./act_runner daemon` 命令。容器成功啟動後，它將顯示為您的 Gitea 實例中的活動 runner。
|
||||
|
||||
## 高級配置
|
||||
## 高級設定
|
||||
|
||||
### 使用 docker 映像啟動 runner 時配置緩存
|
||||
### 使用 docker 映像啟動 runner 時設定緩存
|
||||
|
||||
如果您不打算在工作流中使用 `actions/cache`，可以忽略此部分。
|
||||
|
||||
如果在沒有任何額外配置的情況下使用 `actions/cache`，它將返回以下錯誤：
|
||||
如果在沒有任何額外設定的情況下使用 `actions/cache`，它將返回以下錯誤：
|
||||
|
||||
> Failed to restore: getCacheEntry failed: connect ETIMEDOUT IP:PORT
|
||||
|
||||
發生此錯誤是因為 runner 容器和作業容器位於不同的網絡上，因此作業容器無法訪問 runner 容器。
|
||||
發生此錯誤是因為 runner 容器和作業容器位於不同的網路上，因此作業容器無法訪問 runner 容器。
|
||||
|
||||
因此，必須配置緩存操作以確保其正常運行。請按照以下步驟操作：
|
||||
因此，必須設定緩存操作以確保其正常運行。請按照以下步驟操作：
|
||||
|
||||
- 1.獲取運行 runner 容器的主機的 LAN IP 地址。
|
||||
- 2.查找運行 runner 容器的主機上的可用端口號。
|
||||
- 3.在配置文件中配置以下設置：
|
||||
- 3.在設定文件中設定以下設定：
|
||||
|
||||
```yaml
|
||||
cache:
|
||||
@@ -350,17 +350,17 @@ docker run \
|
||||
|
||||
runner 的標籤用於確定 runner 可以運行哪些作業以及如何運行它們。
|
||||
|
||||
默認標籤是 `ubuntu-latest:docker://node:16-bullseye,ubuntu-22.04:docker://node:16-bullseye,ubuntu-20.04:docker://node:16-bullseye,ubuntu-18.04:docker://node:16-buster`。
|
||||
它是一個逗號分隔的列表，每個項目都是一個標籤。
|
||||
預設標籤是 `ubuntu-latest:docker://node:16-bullseye,ubuntu-22.04:docker://node:16-bullseye,ubuntu-20.04:docker://node:16-bullseye,ubuntu-18.04:docker://node:16-buster`。
|
||||
它是一個逗號分隔的列表，每個專案都是一個標籤。
|
||||
|
||||
以 `ubuntu-22.04:docker://node:16-bullseye` 為例。
|
||||
這意味著 runner 可以運行 `runs-on: ubuntu-22.04` 的作業，並且作業將在 docker 容器中運行，映像為 `node:16-bullseye`。
|
||||
|
||||
如果默認映像不足以滿足您的需求，並且您有足夠的磁盤空間使用更好更大的映像，可以將其更改為 `ubuntu-22.04:docker://<the image you like>`。
|
||||
如果預設映像不足以滿足您的需求，並且您有足夠的磁盤空間使用更好更大的映像，可以將其更改為 `ubuntu-22.04:docker://<the image you like>`。
|
||||
您可以在 [act images](https://github.com/nektos/act/blob/master/IMAGES.md) 上找到更多有用的映像。
|
||||
|
||||
如果您想在主機上直接運行作業，可以將其更改為 `ubuntu-22.04:host` 或僅 `ubuntu-22.04`，`:host` 是可選的。
|
||||
但是，我們建議您使用一個特殊的名稱，如 `linux_amd64:host` 或 `windows:host` 以避免誤用。
|
||||
|
||||
從 Gitea 1.21 開始，您可以通過修改 runner 配置文件中的 `runners.labels` 來更改標籤（如果您沒有配置文件，請參考 [配置教程](#configuration)）。
|
||||
從 Gitea 1.21 開始，您可以透過修改 runner 設定文件中的 `runners.labels` 來更改標籤（如果您沒有設定文件，請參考 設定教學）。
|
||||
重新啟動 runner 後，它將使用這些新標籤，即通過調用 `./act_runner daemon --config config.yaml`。
|
||||
@@ -6,12 +6,12 @@ sidebar_position: 110
|
||||
|
||||
# 徽章
|
||||
|
||||
Gitea 內置了徽章系統，允許您在其他地方顯示倉庫的狀態。您可以使用以下徽章：
|
||||
Gitea 內置了徽章系統，允許您在其他地方顯示儲存庫的狀態。您可以使用以下徽章：
|
||||
|
||||
## 工作流程徽章
|
||||
|
||||
Gitea Actions 工作流程徽章是一個顯示最新工作流程運行狀態的徽章。
|
||||
它設計為與 [GitHub Actions 工作流程徽章](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge) 兼容。
|
||||
它設計為與 [GitHub Actions 工作流程徽章](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge) 相容。
|
||||
|
||||
您可以使用以下 URL 獲取徽章：
|
||||
|
||||
@@ -19,8 +19,8 @@ Gitea Actions 工作流程徽章是一個顯示最新工作流程運行狀態的
|
||||
https://your-gitea-instance.com/{owner}/{repo}/actions/workflows/{workflow_file}/badge.svg?branch={branch}&event={event}
|
||||
```
|
||||
|
||||
- `{owner}`: 倉庫的所有者。
|
||||
- `{repo}`: 倉庫的名稱。
|
||||
- `{owner}`: 儲存庫的所有者。
|
||||
- `{repo}`: 儲存庫的名稱。
|
||||
- `{workflow_file}`: 工作流程文件的名稱。
|
||||
- `{branch}`: 可選。工作流程的分支。默認為倉庫的默認分支。
|
||||
- `{event}`: 可選。工作流程的事件。默認為無。
|
||||
- `{branch}`: 可選。工作流程的分支。預設為儲存庫的預設分支。
|
||||
- `{event}`: 可選。工作流程的事件。預設為無。
|
||||
+23
-23
@@ -6,25 +6,25 @@ sidebar_position: 120
|
||||
|
||||
# 與 GitHub Actions 的比較
|
||||
|
||||
儘管 Gitea Actions 設計為與 GitHub Actions 兼容，但它們之間仍存在一些差異。
|
||||
儘管 Gitea Actions 設計為與 GitHub Actions 相容，但它們之間仍存在一些差異。
|
||||
|
||||
## 附加功能
|
||||
|
||||
### 絕對操作 URL
|
||||
|
||||
Gitea Actions 支持通過絕對 URL 定義操作，這意味著您可以使用來自任何 git 倉庫的操作。
|
||||
Gitea Actions 支援通過絕對 URL 定義操作，這意味著您可以使用來自任何 git 儲存庫的操作。
|
||||
例如 `uses: https://github.com/actions/checkout@v4` 或 `uses: http://your_gitea.com/owner/repo@branch`。
|
||||
|
||||
### 用 Go 編寫的操作
|
||||
|
||||
Gitea Actions 支持用 Go 編寫操作。
|
||||
請參閱 [創建 Go 操作](https://blog.gitea.com/creating-go-actions/)。
|
||||
Gitea Actions 支援用 Go 編寫操作。
|
||||
請參閱 [建立 Go 操作](https://blog.gitea.com/creating-go-actions/)。
|
||||
|
||||
### 支持非標準語法 @yearly, @monthly, @weekly, @daily, @hourly 在計劃中
|
||||
### 支援非標準語法 @yearly, @monthly, @weekly, @daily, @hourly 在計劃中
|
||||
|
||||
GitHub Actions 不支持這一點。https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
|
||||
GitHub Actions 不支援這一點。https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
|
||||
|
||||
## 不支持的工作流程語法
|
||||
## 不支援的工作流程語法
|
||||
|
||||
### `concurrency`
|
||||
|
||||
@@ -68,58 +68,58 @@ GitHub Actions 不支持這一點。https://docs.github.com/en/actions/using-wor
|
||||
|
||||
請參閱 [GitHub Actions 的工作流程語法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on)。
|
||||
|
||||
目前 Gitea Actions 只支持 `runs-on: xyz` 或 `runs-on: [xyz]`。
|
||||
目前 Gitea Actions 只支援 `runs-on: xyz` 或 `runs-on: [xyz]`。
|
||||
|
||||
## 缺少的功能
|
||||
|
||||
### 包倉庫授權
|
||||
### 包儲存庫授權
|
||||
|
||||
在倉庫內運行的作業的 `GITEA_TOKEN` 應該能夠發布到相關的包倉庫（即上傳 OCI 映像）。請參閱 [自動令牌身份驗證](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) 中的“包”範圍的“默認訪問”。
|
||||
在儲存庫內運行的作業的 `GITEA_TOKEN` 應該能夠發布到相關的包儲存庫（即上傳 OCI 映像）。請參閱 [自動令牌身份驗證](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) 中的“包”範圍的“預設訪問”。
|
||||
|
||||
目前 Gitea Actions 尚未實現此功能。Gitea Actions 的一個解決方法是使用個人訪問令牌（PAT）。請參閱此 [github 問題和評論](https://github.com/go-gitea/gitea/issues/23642#issuecomment-2119876692) 以跟踪此功能。
|
||||
目前 Gitea Actions 尚未實現此功能。Gitea Actions 的一個解決方法是使用個人存取權杖（PAT）。請參閱此 [github 問題和評論](https://github.com/go-gitea/gitea/issues/23642#issuecomment-2119876692) 以跟蹤此功能。
|
||||
|
||||
### 問題匹配器
|
||||
|
||||
問題匹配器是一種掃描操作輸出以查找指定正則表達式模式並在 UI 中突出顯示該信息的方法。
|
||||
問題匹配器是一種掃描操作輸出以查找指定正則表達式模式並在 UI 中突出顯示該資訊的方法。
|
||||
請參閱 [問題匹配器](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md)。
|
||||
|
||||
目前 Gitea Actions 忽略它。
|
||||
|
||||
### 創建錯誤註釋
|
||||
### 建立錯誤註釋
|
||||
|
||||
請參閱 [為錯誤創建註釋](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/using-workflows/workflow-commands-for-github-actions#example-creating-an-annotation-for-an-error)
|
||||
|
||||
目前 Gitea Actions 忽略它。
|
||||
|
||||
### 表達式
|
||||
|
||||
對於 [表達式](https://docs.github.com/en/actions/learn-github-actions/expressions)，僅支持 [`always()`](https://docs.github.com/en/actions/learn-github-actions/expressions#always)。
|
||||
對於 [表達式](https://docs.github.com/en/actions/learn-github-actions/expressions)，僅支援 [`always()`](https://docs.github.com/en/actions/learn-github-actions/expressions#always)。
|
||||
|
||||
## 缺少的 UI 功能
|
||||
|
||||
### 預處理和後處理步驟
|
||||
|
||||
預處理和後處理步驟在作業日誌用戶界面中沒有自己的部分。
|
||||
預處理和後處理步驟在作業日誌使用者介面中沒有自己的部分。
|
||||
|
||||
### 服務步驟
|
||||
|
||||
服務步驟在作業日誌用戶界面中沒有自己的部分。
|
||||
服務步驟在作業日誌使用者介面中沒有自己的部分。
|
||||
|
||||
## 不同的行為
|
||||
|
||||
### 下載操作
|
||||
|
||||
以前（1.21.0 之前），`[actions].DEFAULT_ACTIONS_URL` 默認為 `https://gitea.com`。
|
||||
以前（1.21.0 之前），`[actions].DEFAULT_ACTIONS_URL` 預設為 `https://gitea.com`。
|
||||
我們已經限制了此選項僅允許兩個值（`github` 和 `self`）。
|
||||
當設置為 `github` 時，新的默認值，Gitea 將從 `https://github.com` 下載非完全限定的操作。
|
||||
例如，如果您使用 `uses: actions/checkout@v4`，它將從 `https://github.com/actions/checkout.git` 下載 checkout 倉庫。
|
||||
當設定為 `github` 時，新的預設值，Gitea 將從 `https://github.com` 下載非完全限定的操作。
|
||||
例如，如果您使用 `uses: actions/checkout@v4`，它將從 `https://github.com/actions/checkout.git` 下載 checkout 儲存庫。
|
||||
|
||||
如果您想從其他 git 託管服務器下載操作，可以使用絕對 URL，例如 `uses: https://gitea.com/actions/checkout@v4`。
|
||||
如果您想從其他 git 託管伺服器下載操作，可以使用絕對 URL，例如 `uses: https://gitea.com/actions/checkout@v4`。
|
||||
|
||||
如果您的 Gitea 實例位於內部網或受限區域，您可以將 URL 設置為 `self`，以便默認僅從您自己的實例下載操作。
|
||||
如果您的 Gitea 實例位於內部網或受限區域，您可以將 URL 設定為 `self`，以便預設僅從您自己的實例下載操作。
|
||||
當然，您仍然可以在工作流程中使用絕對 URL。
|
||||
|
||||
有關 `[actions].DEFAULT_ACTIONS_URL` 配置的更多詳細信息，請參閱 [配置備忘單](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
有關 `[actions].DEFAULT_ACTIONS_URL` 設定的更多詳細資訊，請參閱 [設定備忘單](../../administration/config-cheat-sheet.md)。
|
||||
|
||||
### 上下文可用性
|
||||
|
||||
|
||||
@@ -6,78 +6,78 @@ sidebar_position: 140
|
||||
|
||||
# Gitea Actions 的設計
|
||||
|
||||
Gitea Actions 有多個組件。本文件將分別描述它們。
|
||||
Gitea Actions 有多個元件。本文件將分別描述它們。
|
||||
|
||||
## Act
|
||||
|
||||
[nektos/act](https://github.com/nektos/act) 項目是一個出色的工具，允許您在本地運行 GitHub Actions。
|
||||
[nektos/act](https://github.com/nektos/act) 專案是一個出色的工具，允許您在本地運行 GitHub Actions。
|
||||
我們受此啟發，想知道是否可以為 Gitea 運行操作。
|
||||
|
||||
然而，雖然 [nektos/act](https://github.com/nektos/act) 被設計為命令行工具，但我們實際上需要的是一個專門為 Gitea 進行修改的 Go 庫。
|
||||
所以我們將其分叉為 [gitea/act](https://gitea.com/gitea/act)。
|
||||
|
||||
這是一個軟分叉，將定期跟隨上游。
|
||||
儘管添加了一些自定義提交，但我們將盡量避免更改太多原始代碼。
|
||||
儘管添加了一些自訂提交，但我們將盡量避免更改太多原始程式碼。
|
||||
|
||||
分叉的 act 只是 Gitea 特定用法的 shim 或適配器。
|
||||
已經進行了一些額外的提交，例如：
|
||||
|
||||
- 將執行日誌輸出到 logger 鉤子，以便可以報告給 Gitea
|
||||
- 禁用 GraphQL URL，因為 Gitea 不支持它
|
||||
- 禁用 GraphQL URL，因為 Gitea 不支援它
|
||||
- 為每個作業啟動一個新容器，而不是重用，以確保隔離。
|
||||
|
||||
這些修改沒有理由合併到上游。
|
||||
如果用戶只想在本地運行受信任的操作，這些修改沒有意義。
|
||||
如果使用者只想在本地運行受信任的操作，這些修改沒有意義。
|
||||
|
||||
然而，未來可能會有重疊，例如兩個項目都需要的錯誤修復或新功能。
|
||||
在這些情況下，我們將把更改貢獻回上游倉庫。
|
||||
然而，未來可能會有重疊，例如兩個專案都需要的錯誤修復或新功能。
|
||||
在這些情況下，我們將把更改貢獻回上游儲存庫。
|
||||
|
||||
## Act runner
|
||||
|
||||
Gitea 的 runner 被稱為 act runner，因為它基於 act。
|
||||
|
||||
像其他 CI runner 一樣，我們將其設計為 Gitea 的外部部分，這意味著它應該在與 Gitea 不同的服務器上運行。
|
||||
像其他 CI runner 一樣，我們將其設計為 Gitea 的外部部分，這意味著它應該在與 Gitea 不同的伺服器上運行。
|
||||
|
||||
為了確保 runner 連接到正確的 Gitea 實例，我們需要使用令牌註冊它。
|
||||
此外，runner 將向 Gitea 介紹自己並通過報告其標籤來聲明它可以運行的作業類型。
|
||||
|
||||
前面提到過，工作流程文件中的 `runs-on: ubuntu-latest` 意味著作業將在具有 `ubuntu-latest` 標籤的 runner 上運行。
|
||||
但是 runner 如何知道運行 `ubuntu-latest`？答案在於將標籤映射到環境。
|
||||
這就是為什麼在註冊期間添加自定義標籤時，您需要輸入一些複雜的內容，如 `my_custom_label:docker://centos:7`。
|
||||
這就是為什麼在註冊期間添加自訂標籤時，您需要輸入一些複雜的內容，如 `my_custom_label:docker://centos:7`。
|
||||
這意味著 runner 可以接受需要在 `my_custom_label` 上運行的作業，並將其通過 docker 容器運行，映像為 `centos:7`。
|
||||
|
||||
然而，docker 並不是唯一的選擇。
|
||||
act 還支持直接在主機上運行作業。
|
||||
act 還支援直接在主機上運行作業。
|
||||
這是通過標籤如 `linux_arm:host` 實現的。
|
||||
這個標籤表示 runner 可以接受需要在 `linux_arm` 上運行的作業，並直接在主機上運行它。
|
||||
|
||||
標籤的設計遵循格式 `label[:schema[:args]]`。
|
||||
如果省略 schema，則默認為 `host`。
|
||||
如果省略 schema，則預設為 `host`。
|
||||
所以，
|
||||
|
||||
- `my_custom_label:docker://node:18`: 使用 `node:18` Docker 映像運行標籤為 `my_custom_label` 的作業。
|
||||
- `my_custom_label:host`: 直接在主機上運行標籤為 `my_custom_label` 的作業。
|
||||
- `my_custom_label`: 與 `my_custom_label:host` 相同。
|
||||
- `my_custom_label:vm:ubuntu-latest`: （僅示例，未實現）使用 `ubuntu-latest` ISO 的虛擬機運行標籤為 `my_custom_label` 的作業。
|
||||
- `my_custom_label:vm:ubuntu-latest`: （僅範例，未實現）使用 `ubuntu-latest` ISO 的虛擬機運行標籤為 `my_custom_label` 的作業。
|
||||
|
||||
## 通信協議
|
||||
|
||||
由於 act runner 是 Gitea 的獨立部分，我們需要一個協議來讓 runner 與 Gitea 實例通信。
|
||||
然而，我們認為讓 Gitea 監聽一個新端口不是一個好主意。
|
||||
相反，我們希望重用 HTTP 端口，這意味著我們需要一個與 HTTP 兼容的協議。
|
||||
相反，我們希望重用 HTTP 端口，這意味著我們需要一個與 HTTP 相容的協議。
|
||||
我們選擇使用 gRPC over HTTP。
|
||||
|
||||
我們使用 [actions-proto-def](https://gitea.com/gitea/actions-proto-def) 和 [actions-proto-go](https://gitea.com/gitea/actions-proto-go) 來將它們連接起來。
|
||||
有關 gRPC 的更多信息可以在 [其網站](https://grpc.io/) 上找到。
|
||||
有關 gRPC 的更多資訊可以在 [其網站](https://grpc.io/) 上找到。
|
||||
|
||||
## 網絡架構
|
||||
## 網路架構
|
||||
|
||||
讓我們來看看整體網絡架構。
|
||||
讓我們來看看整體網路架構。
|
||||
這將幫助您排除一些問題，並解釋為什麼用 Gitea 實例的回環地址註冊 runner 是個壞主意。
|
||||
|
||||
|
||||
|
||||
圖片中標記了四個網絡連接，箭頭的方向表示建立連接的方向。
|
||||
圖片中標記了四個網路連接，箭頭的方向表示建立連接的方向。
|
||||
|
||||
### 連接 1，act runner 到 Gitea 實例
|
||||
|
||||
@@ -85,33 +85,33 @@ act runner 必須能夠連接到 Gitea 以接收任務並發送回執行結果
|
||||
|
||||
### 連接 2，作業容器到 Gitea 實例
|
||||
|
||||
作業容器與 runner 有不同的網絡命名空間，即使它們在同一台機器上。
|
||||
如果工作流程中有 `actions/checkout@v4`，它們需要連接到 Gitea 以獲取代碼。
|
||||
運行某些作業並不總是需要獲取代碼，但在大多數情況下是必需的。
|
||||
作業容器與 runner 有不同的網路命名空間，即使它們在同一臺機器上。
|
||||
如果工作流程中有 `actions/checkout@v4`，它們需要連接到 Gitea 以獲取程式碼。
|
||||
運行某些作業並不總是需要獲取程式碼，但在大多數情況下是必需的。
|
||||
|
||||
如果您使用回環地址註冊 runner，當它在同一台機器上時，runner 可以連接到 Gitea。
|
||||
但是，如果作業容器嘗試從 localhost 獲取代碼，則會失敗，因為 Gitea 不在同一容器中。
|
||||
如果您使用回環地址註冊 runner，當它在同一臺機器上時，runner 可以連接到 Gitea。
|
||||
但是，如果作業容器嘗試從 localhost 獲取程式碼，則會失敗，因為 Gitea 不在同一容器中。
|
||||
|
||||
### 連接 3，act runner 到互聯網
|
||||
|
||||
當您使用一些操作如 `actions/checkout@v4` 時，act runner 會下載腳本，而不是作業容器。
|
||||
默認情況下，它從 [github.com](http://github.com/) 下載，因此需要訪問互聯網。如果您將 `DEFAULT_ACTIONS_URL` 配置為 `self`，則它將默認從您的 Gitea 實例下載。然後在下載操作本身時不會連接到互聯網。
|
||||
它還默認從 Docker Hub 下載一些 docker 映像，這也需要訪問互聯網。
|
||||
預設情況下，它從 [github.com](http://github.com/) 下載，因此需要訪問互聯網。如果您將 `DEFAULT_ACTIONS_URL` 設定為 `self`，則它將預設從您的 Gitea 實例下載。然後在下載操作本身時不會連接到互聯網。
|
||||
它還預設從 Docker Hub 下載一些 docker 映像，這也需要訪問互聯網。
|
||||
|
||||
然而，訪問互聯網並不是絕對必要的。
|
||||
您可以配置您的 Gitea 實例從您的內聯設施中獲取操作或映像。
|
||||
您可以設定您的 Gitea 實例從您的內聯設施中獲取操作或映像。
|
||||
|
||||
事實上，您的 Gitea 實例可以同時作為操作市場和映像註冊表。
|
||||
您可以將操作倉庫從 GitHub 鏡像到您的 Gitea 實例，並正常使用它們。
|
||||
您可以將操作儲存庫從 GitHub 鏡像到您的 Gitea 實例，並正常使用它們。
|
||||
而 [Gitea 容器註冊表](usage/packages/container.md) 可以用作 Docker 映像註冊表。
|
||||
|
||||
### 連接 4，作業容器到互聯網
|
||||
|
||||
當使用如 `actions/setup-go@v5` 的操作時，可能需要從互聯網下載資源以在作業容器中設置 Go 語言環境。
|
||||
當使用如 `actions/setup-go@v5` 的操作時，可能需要從互聯網下載資源以在作業容器中設定 Go 語言環境。
|
||||
因此，訪問互聯網是這些操作成功完成所必需的。
|
||||
|
||||
然而，這也是可選的。
|
||||
您可以使用自己的自定義操作來避免依賴互聯網訪問，或者您可以使用打包的 Docker 映像來運行已安裝所有依賴項的作業。
|
||||
您可以使用自己的自訂操作來避免依賴互聯網訪問，或者您可以使用打包的 Docker 映像來運行已安裝所有依賴項的作業。
|
||||
|
||||
## 總結
|
||||
|
||||
@@ -119,4 +119,4 @@ act runner 必須能夠連接到 Gitea 以接收任務並發送回執行結果
|
||||
訪問互聯網是可選的，但沒有它將需要一些額外的工作。
|
||||
換句話說：runner 最好能夠自己查詢互聯網，但您不需要將其暴露在互聯網上（無論是入站還是出站）。
|
||||
|
||||
如果您在使用 Gitea Actions 時遇到任何網絡問題，希望上圖可以幫助您排除它們。
|
||||
如果您在使用 Gitea Actions 時遇到任何網路問題，希望上圖可以幫助您排除它們。
|
||||
@@ -8,9 +8,9 @@ sidebar_position: 200
|
||||
|
||||
這頁包含了一些關於 Gitea Actions 的常見問題和解答。
|
||||
|
||||
## 是否可以預設禁用新倉庫的 Actions？
|
||||
## 是否可以預設禁用新儲存庫的 Actions？
|
||||
|
||||
可以，當你為實例啟用 Actions 時，你可以選擇預設為所有新倉庫啟用 `actions` 單元。
|
||||
可以，當你為實例啟用 Actions 時，你可以選擇預設為所有新儲存庫啟用 `actions` 單元。
|
||||
|
||||
```ini
|
||||
[repository]
|
||||
@@ -21,13 +21,13 @@ DEFAULT_REPO_UNITS = ...,repo.actions
|
||||
## 我們應該在工作流程文件中使用 `${{ github.xyz }}` 還是 `${{ gitea.xyz }}`？
|
||||
|
||||
你可以使用 `github.xyz`，Gitea 也能正常運作。
|
||||
如前所述，Gitea Actions 設計上與 GitHub Actions 兼容。
|
||||
如前所述，Gitea Actions 設計上與 GitHub Actions 相容。
|
||||
然而，我們建議使用 `gitea.xyz`，以防 Gitea 添加了 GitHub 沒有的功能，避免在工作流程文件中出現不同種類的 secrets（而且你是在 Gitea 上使用這個工作流程，而不是 GitHub）。
|
||||
不過，這完全是可選的，因為目前兩者的效果相同。
|
||||
|
||||
## 使用 `actions/checkout@v4` 等 actions 時，runner 會下載腳本到哪裡？
|
||||
|
||||
在 GitHub 上有成千上萬的 [actions 腳本](https://github.com/marketplace?type=actions)，當你寫 `uses: actions/checkout@v4` 時，它會默認從 [github.com/actions/checkout](http://github.com/actions/checkout) 下載腳本。
|
||||
在 GitHub 上有成千上萬的 [actions 腳本](https://github.com/marketplace?type=actions)，當你寫 `uses: actions/checkout@v4` 時，它會預設從 [github.com/actions/checkout](http://github.com/actions/checkout) 下載腳本。
|
||||
但如果你想從其他地方（如 gitea.com）而不是 GitHub 使用 actions 怎麼辦？
|
||||
|
||||
好消息是你可以指定 URL 前綴來從任何地方使用 actions。
|
||||
@@ -40,26 +40,26 @@ DEFAULT_REPO_UNITS = ...,repo.actions
|
||||
|
||||
注意，`https://` 或 `http://` 前綴是必要的！
|
||||
|
||||
這是與 GitHub Actions 的一個區別，後者僅支持來自 GitHub 的 actions 腳本。
|
||||
但這應該允許用戶在運行 Actions 時有更多的靈活性。
|
||||
這是與 GitHub Actions 的一個區別，後者僅支援來自 GitHub 的 actions 腳本。
|
||||
但這應該允許使用者在運行 Actions 時有更多的靈活性。
|
||||
|
||||
另外，如果你希望你的 runners 默認從你自己的 Gitea 實例下載 actions，你可以通過設置 `[actions].DEFAULT_ACTIONS_URL` 來配置。
|
||||
參見 [配置備忘單](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
另外，如果你希望你的 runners 預設從你自己的 Gitea 實例下載 actions，你可以透過設定 `[actions].DEFAULT_ACTIONS_URL` 來設定。
|
||||
參見 [設定備忘單](../../administration/config-cheat-sheet.md)。
|
||||
|
||||
## 如何限制 runners 的權限？
|
||||
|
||||
Runners 只具有連接到你的 Gitea 實例的權限。
|
||||
當任何 runner 接收到一個要運行的任務時，它將臨時獲得與該任務相關的倉庫的有限權限。
|
||||
如果你想給 runner 更多的權限，允許它訪問更多的私有倉庫或外部系統，你可以傳遞 [secrets](usage/actions/secrets.md) 給它。
|
||||
當任何 runner 接收到一個要運行的任務時，它將臨時獲得與該任務相關的儲存庫的有限權限。
|
||||
如果你想給 runner 更多的權限，允許它訪問更多的私有儲存庫或外部系統，你可以傳遞 [secrets](usage/actions/secrets.md) 給它。
|
||||
|
||||
對 Actions 進行精細的權限控制是一項複雜的工作。
|
||||
未來，我們將為 Gitea 添加更多選項，使其更具可配置性，例如允許更多的寫入訪問倉庫或讀取同一組織中所有倉庫的訪問權限。
|
||||
未來，我們將為 Gitea 添加更多選項，使其更具可設定性，例如允許更多的寫入訪問儲存庫或讀取同一組織中所有儲存庫的存取權限。
|
||||
|
||||
## 如何避免被黑客攻擊？
|
||||
|
||||
有兩種類型的可能攻擊：未知的 runner 竊取你的倉庫中的代碼或 secrets，或惡意腳本控制你的 runner。
|
||||
有兩種類型的可能攻擊：未知的 runner 竊取你的儲存庫中的程式碼或 secrets，或惡意腳本控制你的 runner。
|
||||
|
||||
避免前者意味著不允許你不認識的人為你的倉庫、組織或實例註冊 runners。
|
||||
避免前者意味著不允許你不認識的人為你的儲存庫、組織或實例註冊 runners。
|
||||
|
||||
後者則有點複雜。
|
||||
如果你為你的公司使用私人 Gitea 實例，你可能不需要擔心安全問題，因為你信任你的同事並且可以追究他們的責任。
|
||||
@@ -67,20 +67,20 @@ Runners 只具有連接到你的 Gitea 實例的權限。
|
||||
對於公共實例，情況有點不同。
|
||||
以下是我們在 [gitea.com](http://gitea.com/) 上的做法：
|
||||
|
||||
- 我們只為 "gitea" 組織註冊 runners，因此我們的 runners 不會執行來自其他倉庫的任務。
|
||||
- 我們只為 "gitea" 組織註冊 runners，因此我們的 runners 不會執行來自其他儲存庫的任務。
|
||||
- 我們的 runners 總是使用隔離的容器運行任務。雖然可以直接在主機上這樣做，但我們選擇不這樣做以提高安全性。
|
||||
- 要運行 fork pull requests 的 actions，需要批准。參見 [#22803](https://github.com/go-gitea/gitea/pull/22803)。
|
||||
- 如果有人在 [gitea.com](http://gitea.com/) 上為他們的倉庫或組織註冊了他們自己的 runner，我們不反對，只是不會在我們的組織中使用它。然而，他們應該注意確保該 runner 不被他們不認識的其他用戶使用。
|
||||
- 如果有人在 [gitea.com](http://gitea.com/) 上為他們的儲存庫或組織註冊了他們自己的 runner，我們不反對，只是不會在我們的組織中使用它。然而，他們應該注意確保該 runner 不被他們不認識的其他使用者使用。
|
||||
|
||||
## act runner 支持哪些操作系統？
|
||||
## act runner 支援哪些操作系統？
|
||||
|
||||
它在 Linux、macOS 和 Windows 上運行良好。
|
||||
雖然理論上支持其他操作系統，但它們需要進一步測試。
|
||||
雖然理論上支援其他操作系統，但它們需要進一步測試。
|
||||
|
||||
需要注意的一點是，如果你選擇直接在主機上運行任務而不是在任務容器中，操作系統之間的環境差異可能會導致意外的失敗。
|
||||
|
||||
例如，bash 在大多數情況下在 Windows 上不可用，而 act 嘗試默認使用 bash 運行腳本。
|
||||
因此，你需要在工作流程文件中指定 `powershell` 為默認 shell，參見 [defaults.run](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun)。
|
||||
例如，bash 在大多數情況下在 Windows 上不可用，而 act 嘗試預設使用 bash 運行腳本。
|
||||
因此，你需要在工作流程文件中指定 `powershell` 為預設 shell，參見 [defaults.run](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun)。
|
||||
|
||||
```yaml
|
||||
defaults:
|
||||
@@ -88,7 +88,7 @@ defaults:
|
||||
shell: powershell
|
||||
```
|
||||
|
||||
## 為什麼選擇 GitHub Actions？為什麼不選擇與 GitLab CI/CD 兼容的東西？
|
||||
## 為什麼選擇 GitHub Actions？為什麼不選擇與 GitLab CI/CD 相容的東西？
|
||||
|
||||
[@lunny](https://gitea.com/lunny) 在 [實現 actions 的問題](https://github.com/go-gitea/gitea/issues/13539) 中解釋了這一點。
|
||||
此外，Actions 不僅僅是一個 CI/CD 系統，還是一個自動化工具。
|
||||
@@ -120,32 +120,32 @@ defaults:
|
||||
|
||||
目前，act runner 嘗試匹配標籤中的每個人並使用它找到的第一個匹配。
|
||||
|
||||
## runner 的代理標籤和自定義標籤有什麼區別？
|
||||
## runner 的代理標籤和自訂標籤有什麼區別？
|
||||
|
||||
|
||||
|
||||
代理標籤是在註冊期間由 runner 向 Gitea 實例報告的。
|
||||
另一方面，自定義標籤是由 Gitea 管理員或組織或倉庫的所有者手動添加的（取決於 runner 的級別）。
|
||||
另一方面，自訂標籤是由 Gitea 管理員或組織或儲存庫的所有者手動添加的（取決於 runner 的級別）。
|
||||
|
||||
然而，這裡的設計需要改進，因為它目前有一些粗糙的邊緣。
|
||||
你可以向已註冊的 runner 添加自定義標籤，例如 `centos`，這意味著 runner 將接收具有 `runs-on: centos` 的任務。
|
||||
然而，runner 可能不知道為這個標籤使用哪個環境，導致它使用默認映像或導致邏輯死胡同。
|
||||
這個默認值可能不符合用戶的期望。
|
||||
你可以向已註冊的 runner 添加自訂標籤，例如 `centos`，這意味著 runner 將接收具有 `runs-on: centos` 的任務。
|
||||
然而，runner 可能不知道為這個標籤使用哪個環境，導致它使用預設映像或導致邏輯死衚衕。
|
||||
這個預設值可能不符合使用者的期望。
|
||||
參見 [runtime.go#L71](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L71)。
|
||||
|
||||
同時，我們建議你重新註冊你的 runner，如果你想更改它的標籤。
|
||||
|
||||
## Gitea Actions runner 會有更多的實現嗎？
|
||||
|
||||
雖然我們希望提供更多選擇，但我們有限的人力意味著 act runner 將是唯一官方支持的 runner。
|
||||
然而，Gitea 和 act runner 都是完全開源的，所以任何人都可以創建一個新的/更好的實現。
|
||||
無論你如何決定，我們都支持你的選擇。
|
||||
如果你 fork 了 act runner 來創建你自己的版本：如果你能並且認為你的更改也會幫助其他人，請將更改貢獻回來。
|
||||
雖然我們希望提供更多選擇，但我們有限的人力意味著 act runner 將是唯一官方支援的 runner。
|
||||
然而，Gitea 和 act runner 都是完全開源的，所以任何人都可以建立一個新的/更好的實現。
|
||||
無論你如何決定，我們都支援你的選擇。
|
||||
如果你 fork 了 act runner 來建立你自己的版本：如果你能並且認為你的更改也會幫助其他人，請將更改貢獻回來。
|
||||
|
||||
## Gitea 支持哪些工作流程觸發事件？
|
||||
## Gitea 支援哪些工作流程觸發事件？
|
||||
|
||||
所有列在此表中的事件都是支持的事件，並且與 GitHub 兼容。
|
||||
對於僅由 GitHub 支持的事件，請參見 GitHub 的 [文檔](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows)。
|
||||
所有列在此表中的事件都是支援的事件，並且與 GitHub 相容。
|
||||
對於僅由 GitHub 支援的事件，請參見 GitHub 的 [文件](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows)。
|
||||
|
||||
| 觸發事件 | 活動類型 |
|
||||
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
|
||||
|
||||
@@ -10,25 +10,25 @@ sidebar_position: 1
|
||||
|
||||
## 名稱
|
||||
|
||||
它類似並兼容於 [GitHub Actions](https://github.com/features/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"。
|
||||
- "Actions" 可能指上述任何一個，取決於上下文。在本文件中，它指的是 "Gitea Actions"。
|
||||
- "action" 或 "actions" 指的是一些腳本/外掛，如 "actions/checkout@v4" 或 "actions/cache@v3"。
|
||||
|
||||
## Runners
|
||||
|
||||
就像其他 CI/CD 解決方案一樣，Gitea 不會自己運行作業，而是將作業委派給 runners。
|
||||
Gitea Actions 的 runner 稱為 [act runner](https://gitea.com/gitea/act_runner)，它是一個獨立的程序，也是用 Go 編寫的。
|
||||
Gitea Actions 的 runner 稱為 [act runner](https://gitea.com/gitea/act_runner)，它是一個獨立的程式，也是用 Go 編寫的。
|
||||
它基於 [nektos/act](http://github.com/nektos/act) 的 [fork](https://gitea.com/gitea/act)。
|
||||
|
||||
由於 runner 是獨立部署的，可能會有潛在的安全問題。
|
||||
為了避免這些問題，請遵循兩個簡單的規則：
|
||||
|
||||
- 不要為你不信任的倉庫、組織或實例使用你不信任的 runner。
|
||||
- 不要為你不信任的倉庫、組織或實例提供 runner。
|
||||
- 不要為你不信任的儲存庫、組織或實例使用你不信任的 runner。
|
||||
- 不要為你不信任的儲存庫、組織或實例提供 runner。
|
||||
|
||||
對於內部使用的 Gitea 實例，如企業或個人使用的實例，這兩個規則都不是問題，它們自然如此。
|
||||
然而，對於公共 Gitea 實例，如 [gitea.com](https://gitea.com)，在添加或使用 runners 時應記住這兩個規則。
|
||||
|
||||
+26
-26
@@ -8,33 +8,33 @@ sidebar_position: 10
|
||||
|
||||
本頁將引導你使用 Gitea Actions 的過程。
|
||||
|
||||
## 設置 Gitea
|
||||
## 設定 Gitea
|
||||
|
||||
首先，你需要一個 Gitea 實例。
|
||||
你可以按照 [文檔](installation/from-package.md) 設置一個新實例或升級現有實例。
|
||||
你可以按照 [文件](installation/from-package.md) 設定一個新實例或升級現有實例。
|
||||
無論你如何安裝或運行 Gitea，只要其版本是 1.19.0 或更高版本即可。
|
||||
|
||||
從 1.21.0 開始，Actions 默認啟用。如果你使用的是 1.21.0 之前的版本，你需要在配置文件中添加以下內容以啟用它：
|
||||
從 1.21.0 開始，Actions 預設啟用。如果你使用的是 1.21.0 之前的版本，你需要在設定文件中添加以下內容以啟用它：
|
||||
|
||||
```ini
|
||||
[actions]
|
||||
ENABLED=true
|
||||
```
|
||||
|
||||
如果你想了解更多或在配置過程中遇到任何問題，請參考 [配置備忘單](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
如果你想了解更多或在設定過程中遇到任何問題，請參考 [設定備忘單](../../administration/config-cheat-sheet.md)。
|
||||
|
||||
### 設置 runner
|
||||
### 設定 runner
|
||||
|
||||
Gitea Actions 需要 [act runner](https://gitea.com/gitea/act_runner) 來運行作業。
|
||||
為了避免消耗過多資源並影響 Gitea 實例，建議在與 Gitea 實例不同的機器上啟動 runners。
|
||||
|
||||
你可以使用 [預構建的二進位文件](http://dl.gitea.com/act_runner) 或 [docker 映像](https://hub.docker.com/r/gitea/act_runner/tags) 設置 runner。
|
||||
你可以使用 [預構建的二進位文件](http://dl.gitea.com/act_runner) 或 [docker 映像](https://hub.docker.com/r/gitea/act_runner/tags) 設定 runner。
|
||||
|
||||
在進一步操作之前，我們建議使用預構建的二進位文件作為命令行運行它，以確保它適用於你的環境，特別是如果你在本地主機上運行 runner。
|
||||
如果出現問題，這樣也更容易調試。
|
||||
|
||||
runner 可以在隔離的 Docker 容器中運行作業，因此你需要確保已安裝 Docker 並且 Docker 守護進程正在運行。
|
||||
雖然這不是絕對必要的，因為 runner 也可以直接在主機上運行作業，這取決於你如何配置它。
|
||||
雖然這不是絕對必要的，因為 runner 也可以直接在主機上運行作業，這取決於你如何設定它。
|
||||
然而，建議使用 Docker 來運行作業，因為這樣更安全且更易於管理。
|
||||
|
||||
在運行 runner 之前，你應該首先使用以下命令將其註冊到你的 Gitea 實例：
|
||||
@@ -47,22 +47,22 @@ runner 可以在隔離的 Docker 容器中運行作業，因此你需要確保
|
||||
|
||||
`instance` 指的是你的 Gitea 實例的地址，如 `http://192.168.8.8:3000` 或 `https://gitea.com`。
|
||||
runner 和作業容器（由 runner 啟動以執行作業）將連接到此地址。
|
||||
這意味著它可能與你的 Gitea 實例的 `ROOT_URL` 不同，後者是為網頁訪問配置的。
|
||||
這意味著它可能與你的 Gitea 實例的 `ROOT_URL` 不同，後者是為網頁訪問設定的。
|
||||
使用回環地址如 `127.0.0.1` 或 `localhost` 總是個壞主意。
|
||||
如果你不確定使用哪個地址，通常 LAN 地址是正確的選擇。
|
||||
|
||||
`token` 用於身份驗證和識別，如 `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`。
|
||||
每個令牌可以用來創建多個 runners，直到使用重置鏈接替換為新令牌。
|
||||
你可以從以下位置獲取不同級別的令牌來創建相應級別的 runners：
|
||||
每個令牌可以用來建立多個 runners，直到使用重置鏈接替換為新令牌。
|
||||
你可以從以下位置獲取不同級別的令牌來建立相應級別的 runners：
|
||||
|
||||
- 實例級別：管理員設置頁面，如 `<your_gitea.com>/admin/actions/runners`。
|
||||
- 組織級別：組織設置頁面，如 `<your_gitea.com>/<org>/settings/actions/runners`。
|
||||
- 倉庫級別：倉庫設置頁面，如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。
|
||||
- 實例級別：管理員設定頁面，如 `<your_gitea.com>/admin/actions/runners`。
|
||||
- 組織級別：組織設定頁面，如 `<your_gitea.com>/<org>/settings/actions/runners`。
|
||||
- 儲存庫級別：儲存庫設定頁面，如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。
|
||||
|
||||
|
||||
|
||||
註冊後，一個名為 `.runner` 的新文件將出現在當前目錄中。
|
||||
該文件存儲註冊信息。
|
||||
該文件儲存註冊資訊。
|
||||
請不要手動編輯它。
|
||||
如果該文件丟失或損壞，你可以簡單地刪除它並重新註冊。
|
||||
|
||||
@@ -76,20 +76,20 @@ runner 和作業容器（由 runner 啟動以執行作業）將連接到此地
|
||||
|
||||
|
||||
|
||||
你可以訪問 [Act runner](usage/actions/act-runner.md) 獲取更多信息。
|
||||
你可以訪問 [Act runner](usage/actions/act-runner.md) 獲取更多資訊。
|
||||
|
||||
### 使用 Actions
|
||||
|
||||
即使 Gitea 實例啟用了 Actions，倉庫仍然默認禁用 Actions。
|
||||
即使 Gitea 實例啟用了 Actions，儲存庫仍然預設禁用 Actions。
|
||||
|
||||
要啟用它，請轉到倉庫的設置頁面，如 `your_gitea.com/<owner>/repo/settings` 並啟用 `Enable Repository Actions`。
|
||||
要啟用它，請轉到儲存庫的設定頁面，如 `your_gitea.com/<owner>/repo/settings` 並啟用 `Enable Repository Actions`。
|
||||
|
||||
|
||||
|
||||
接下來的步驟可能相當複雜。
|
||||
你需要學習 [工作流程語法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) 並編寫你想要的工作流程文件。
|
||||
|
||||
然而，我們可以從一個簡單的示例開始：
|
||||
然而，我們可以從一個簡單的範例開始：
|
||||
|
||||
```yaml
|
||||
name: Gitea Actions Demo
|
||||
@@ -115,22 +115,22 @@ jobs:
|
||||
|
||||
:::warning
|
||||
|
||||
某些 actions 可能無法在 SHA256 倉庫中正常運行，或者當 Gitea 在子路徑上運行時。這包括 [actions/checkout](https://github.com/actions/checkout/issues/1843)。
|
||||
某些 actions 可能無法在 SHA256 儲存庫中正常運行，或者當 Gitea 在子路徑上運行時。這包括 [actions/checkout](https://github.com/actions/checkout/issues/1843)。
|
||||
|
||||
:::
|
||||
|
||||
你可以將其作為擴展名為 `.yaml` 的文件上傳到倉庫的 `.gitea/workflows/` 目錄中，例如 `.gitea/workflows/demo.yaml`。
|
||||
你可以將其作為擴展名為 `.yaml` 的文件上傳到儲存庫的 `.gitea/workflows/` 目錄中，例如 `.gitea/workflows/demo.yaml`。
|
||||
你可能會注意到這與 [GitHub Actions 快速入門](https://docs.github.com/en/actions/quickstart) 非常相似。
|
||||
那是因為 Gitea Actions 設計上盡可能與 GitHub Actions 兼容。
|
||||
那是因為 Gitea Actions 設計上盡可能與 GitHub Actions 相容。
|
||||
|
||||
請注意，示例文件中包含一些表情符號。
|
||||
請確保你的數據庫支持它們，特別是當使用 MySQL 時。
|
||||
請注意，範例文件中包含一些表情符號。
|
||||
請確保你的資料庫支援它們，特別是當使用 MySQL 時。
|
||||
如果字符集不是 `utf8mb4`，將會出現錯誤，如 `Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`。
|
||||
有關更多信息，請參見 [數據庫準備](../../installation/database-preparation.md#mysqlmariadb)。
|
||||
有關更多資訊，請參見 [資料庫準備](../../installation/database-preparation.md#mysqlmariadb)。
|
||||
|
||||
或者，你可以刪除示例文件中的所有表情符號並重試。
|
||||
或者，你可以刪除範例文件中的所有表情符號並重試。
|
||||
|
||||
行 `on: [push]` 表示當你向此倉庫推送提交時，工作流程將被觸發。
|
||||
行 `on: [push]` 表示當你向此儲存庫推送提交時，工作流程將被觸發。
|
||||
然而，當你上傳 YAML 文件時，它也會推送一個提交，因此你應該在 Actions 標籤中看到一個新任務。
|
||||
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ sidebar_position: 50
|
||||
|
||||
# Secrets
|
||||
|
||||
Secrets 允許你在用戶、組織或倉庫中存儲敏感信息。
|
||||
Secrets 允許你在使用者、組織或儲存庫中儲存敏感資訊。
|
||||
Secrets 在 Gitea 1.19+ 可用，並且在 1.20+ 啟用 ACTIONS 時可見。
|
||||
|
||||
## 命名你的 secrets
|
||||
@@ -17,15 +17,15 @@ Secrets 在 Gitea 1.19+ 可用，並且在 1.20+ 啟用 ACTIONS 時可見。
|
||||
- Secret 名稱不得以 `GITHUB_` 和 `GITEA_` 前綴開頭。
|
||||
- Secret 名稱不得以數字開頭。
|
||||
- Secret 名稱不區分大小寫。
|
||||
- Secret 名稱在創建它們的級別上必須是唯一的。
|
||||
- Secret 名稱在建立它們的級別上必須是唯一的。
|
||||
|
||||
例如，在倉庫級別創建的 secret 必須在該倉庫中具有唯一名稱，而在組織級別創建的 secret 必須在該級別上具有唯一名稱。
|
||||
例如，在儲存庫級別建立的 secret 必須在該儲存庫中具有唯一名稱，而在組織級別建立的 secret 必須在該級別上具有唯一名稱。
|
||||
|
||||
### 使用 secrets
|
||||
|
||||
創建配置變數後，它們將自動填充到 `secrets` 上下文中。
|
||||
可以通過表達式 `${{ secrets.SECRET_NAME }}` 在工作流程中訪問它們。
|
||||
建立設定變數後，它們將自動填充到 `secrets` 上下文中。
|
||||
可以透過表達式 `${{ secrets.SECRET_NAME }}` 在工作流程中訪問它們。
|
||||
|
||||
### 優先級
|
||||
|
||||
如果在多個級別存在同名 secret，則最低級別的 secret 優先。例如，如果組織級別的 secret 與倉庫級別的 secret 同名，則倉庫級別的 secret 優先。
|
||||
如果在多個級別存在同名 secret，則最低級別的 secret 優先。例如，如果組織級別的 secret 與儲存庫級別的 secret 同名，則儲存庫級別的 secret 優先。
|
||||
Loaded 50 of 652 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user