docs: add zh-tw folder (#195)
Signed-off-by: appleboy <appleboy.tw@gmail.com> Reviewed-on: https://gitea.com/gitea/docs/pulls/195 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: appleboy <appleboy.tw@gmail.com> Co-committed-by: appleboy <appleboy.tw@gmail.com>
This commit is contained in:
appleboy
@@ -0,0 +1,13 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
title: "Administration"
|
||||
slug: "administration"
|
||||
sidebar_position: 30
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "Administration"
|
||||
sidebar_position: 20
|
||||
collapse: true
|
||||
identifier: "administration"
|
||||
---
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
date: "2019-12-28"
|
||||
slug: adding-legal-pages
|
||||
sidebar_position: 110
|
||||
aliases:
|
||||
- /zh-tw/adding-legal-pages
|
||||
---
|
||||
|
||||
# 添加法律頁面
|
||||
|
||||
某些司法管轄區（例如歐盟）要求在網站上添加某些法律頁面（例如隱私政策）。請按照以下步驟將它們添加到您的 Gitea 實例中。
|
||||
|
||||
## 獲取頁面
|
||||
|
||||
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 項目對您的服務器負責。
|
||||
|
||||
## 使其可見
|
||||
|
||||
創建或附加到 `/path/to/custom/templates/custom/extra_links_footer.tmpl`：
|
||||
|
||||
```go
|
||||
<a class="item" href="{{AppSubUrl}}/assets/privacy.html">隱私政策</a>
|
||||
```
|
||||
|
||||
重新啟動 Gitea 以查看更改。
|
||||
+277
@@ -0,0 +1,277 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "authentication"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
- /zh-tw/authentication
|
||||
---
|
||||
|
||||
# 認證
|
||||
|
||||
## LDAP（輕量級目錄訪問協議）
|
||||
|
||||
LDAP via BindDN 和簡單身份驗證 LDAP 共享以下字段：
|
||||
|
||||
- 授權名稱 **（必填）**
|
||||
|
||||
- 分配給新授權方法的名稱。
|
||||
|
||||
- 主機 **（必填）**
|
||||
|
||||
- 可以訪問 LDAP 服務器的地址。
|
||||
- 例如：`mydomain.com`
|
||||
|
||||
- 端口 **（必填）**
|
||||
|
||||
- 連接到服務器時使用的端口。
|
||||
- 例如：`389` 用於 LDAP 或 `636` 用於 LDAP SSL
|
||||
|
||||
- 啟用 TLS 加密（可選）
|
||||
|
||||
- 是否在連接到 LDAP 服務器時使用 TLS。
|
||||
|
||||
- 管理員過濾器（可選）
|
||||
|
||||
- 指定用戶是否應被授予管理員權限的 LDAP 過濾器。如果用戶帳戶通過過濾器，用戶將被授予管理員權限。
|
||||
- 例如：`(objectClass=adminAccount)`
|
||||
- Microsoft Active Directory（AD）的示例：`(memberOf=CN=admin-group,OU=example,DC=example,DC=org)`
|
||||
|
||||
- 用戶名屬性（可選）
|
||||
|
||||
- 包含用戶名的用戶 LDAP 記錄的屬性。給定屬性值將在首次成功登錄後用於新 Gitea 帳戶用戶名。留空以使用登錄表單中給定的登錄名。
|
||||
- 當提供的登錄名與多個屬性匹配時，這很有用，但應僅使用單個特定屬性作為 Gitea 帳戶名，請參閱“用戶過濾器”。
|
||||
- 例如：`uid`
|
||||
- Microsoft Active Directory（AD）的示例：`sAMAccountName`
|
||||
|
||||
- 名字屬性（可選）
|
||||
|
||||
- 包含用戶名字的用戶 LDAP 記錄的屬性。這將用於填充其帳戶信息。
|
||||
- 例如：`givenName`
|
||||
|
||||
- 姓氏屬性（可選）
|
||||
|
||||
- 包含用戶姓氏的用戶 LDAP 記錄的屬性。這將用於填充其帳戶信息。
|
||||
- 例如：`sn`
|
||||
|
||||
- 電子郵件屬性 **（必填）**
|
||||
- 包含用戶電子郵件地址的用戶 LDAP 記錄的屬性。這將用於填充其帳戶信息。
|
||||
- 例如：`mail`
|
||||
|
||||
### LDAP via BindDN
|
||||
|
||||
添加以下字段：
|
||||
|
||||
- 綁定 DN（可選）
|
||||
|
||||
- 綁定到 LDAP 服務器時使用的 DN。這可以留空以執行匿名搜索。
|
||||
- 例如：`cn=Search,dc=mydomain,dc=com`
|
||||
|
||||
- 綁定密碼（可選）
|
||||
|
||||
- 上面指定的綁定 DN 的密碼（如果有）。_注意：密碼使用服務器上的 SECRET_KEY 加密存儲。仍然建議確保綁定 DN 具有盡可能少的權限。_
|
||||
|
||||
- 用戶搜索基礎 **（必填）**
|
||||
|
||||
- 將搜索用戶帳戶的 LDAP 基礎。
|
||||
- 例如：`ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 用戶過濾器 **（必填）**
|
||||
- 聲明如何查找嘗試進行身份驗證的用戶記錄的 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`，例如當匹配提供的登錄名與多個屬性（例如用戶標識符、電子郵件甚至電話號碼）時。
|
||||
- 例如：`(&(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 目錄時請小心。
|
||||
|
||||
### 使用簡單身份驗證的 LDAP
|
||||
|
||||
添加以下字段：
|
||||
|
||||
- 用戶 DN **（必填）**
|
||||
|
||||
- 用作用戶 DN 的模板。`%s` 匹配參數將替換為登錄表單中給定的登錄名。
|
||||
- 例如：`cn=%s,ou=Users,dc=mydomain,dc=com`
|
||||
- 例如：`uid=%s,ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 用戶搜索基礎（可選）
|
||||
|
||||
- 將搜索用戶帳戶的 LDAP 基礎。
|
||||
- 例如：`ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 用戶過濾器 **（必填）**
|
||||
- 聲明何時允許用戶登錄的 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: uid=bender,ou=users,dc=planetexpress,dc=com`，則為 `dn`。
|
||||
|
||||
- 驗證 LDAP 中的組成員資格（可選）
|
||||
|
||||
- 聲明如何在上述 DN 中查找有效組的 LDAP 過濾器。
|
||||
- 例如：`(|(cn=gitea_users)(cn=admins))`
|
||||
|
||||
## PAM（可插拔身份驗證模塊）
|
||||
|
||||
此過程啟用 PAM 身份驗證。用戶仍然可以使用用戶管理手動添加到系統中。PAM 提供了一種機制，可以通過測試它們來自動將用戶添加到當前數據庫中。要使用普通的 Linux 密碼，運行 Gitea 的用戶還必須具有對 `/etc/shadow` 的讀取訪問權限，以便在使用公鑰登錄時檢查帳戶的有效性。
|
||||
|
||||
**注意**：如果用戶已將 SSH 公鑰添加到 Gitea 中，則使用這些密鑰 _可能_ 會繞過登錄檢查系統。因此，如果您希望禁用使用 PAM 身份驗證的用戶，您 _應該_ 也使用內置用戶管理器手動禁用 Gitea 中的帳戶。
|
||||
|
||||
1. 配置和準備安裝。
|
||||
- 建議您創建一個管理用戶。
|
||||
- 可能還需要取消選擇自動註冊。
|
||||
1. 數據庫初始化後，以新創建的管理用戶身份登錄。
|
||||
1. 導航到用戶設置（右上角的圖標），然後選擇 `站點管理` -> `身份驗證源`，然後選擇 `添加身份驗證源`。
|
||||
1. 填寫以下字段：
|
||||
- `身份驗證類型`：`PAM`
|
||||
- `名稱`：此處的任何值都應有效，如果您願意，可以使用“系統身份驗證”。
|
||||
- `PAM 服務名稱`：選擇 `/etc/pam.d/` 下列出的執行所需身份驗證的文件。[^1]
|
||||
- `PAM 電子郵件域`：附加到用戶身份驗證的電子郵件後綴。例如，如果登錄系統期望用戶名為 `gituser`，並且此字段設置為 `mail.com`，則 Gitea 將期望經過身份驗證的 GIT 實例的 `用戶電子郵件` 字段為 `gituser@mail.com`。[^2]
|
||||
|
||||
**注意**：PAM 支持是通過 [構建時標誌](installation/from-source.md#build) 添加的，官方提供的二進制文件未啟用此功能。PAM 需要必要的 libpam 動態庫可用，並且需要編譯器可以訪問必要的 PAM 開發標頭。
|
||||
|
||||
[^1]: 例如，使用 Debian "Bullseye" 上的標準 Linux 登錄，使用 `common-session-noninteractive` - 此值可能對其他版本的 Debian（包括 Ubuntu 和 Mint）有效，請參閱您的發行版文檔。
|
||||
[^2]: **這是 PAM 的必填字段**。請注意：在上述示例中，用戶將以 `gituser` 而不是 `gituser@mail.com` 登錄 Gitea Web 界面。
|
||||
|
||||
## SMTP（簡單郵件傳輸協議）
|
||||
|
||||
此選項允許 Gitea 以 Gitea 用戶身份登錄到 SMTP 主機。要配置此項，請設置以下字段：
|
||||
|
||||
- 授權名稱 **（必填）**
|
||||
|
||||
- 分配給新授權方法的名稱。
|
||||
|
||||
- SMTP 身份驗證類型 **（必填）**
|
||||
|
||||
- 用於連接到 SMTP 主機的身份驗證類型，PLAIN 或 LOGIN。
|
||||
|
||||
- 主機 **（必填）**
|
||||
|
||||
- 可以訪問 SMTP 主機的地址。
|
||||
- 例如：`smtp.mydomain.com`
|
||||
|
||||
- 端口 **（必填）**
|
||||
|
||||
- 連接到服務器時使用的端口。
|
||||
- 例如：`587`
|
||||
|
||||
- 允許的域
|
||||
|
||||
- 如果使用公共 SMTP 主機或具有多個域的 SMTP 主機，則限制哪些域可以登錄。
|
||||
- 例如：`gitea.com,mydomain.com,mydomain2.com`
|
||||
|
||||
- 強制 SMTPS
|
||||
|
||||
- 默認情況下，將使用 SMTPS 連接到端口 465，如果您希望對其他端口使用 SMTPS，請設置此值。
|
||||
- 否則，如果服務器提供 `STARTTLS` 擴展，將使用此擴展。
|
||||
|
||||
- 跳過 TLS 驗證
|
||||
|
||||
- 禁用身份驗證上的 TLS 驗證。
|
||||
|
||||
- 此身份驗證源已激活
|
||||
- 啟用或禁用此身份驗證源。
|
||||
|
||||
## FreeIPA
|
||||
|
||||
- 為了使用 FreeIPA 憑據登錄 Gitea，需要為 Gitea 創建一個綁定帳戶：
|
||||
|
||||
- 在 FreeIPA 服務器上，創建一個 `gitea.ldif` 文件，將 `dc=example,dc=com` 替換為您的 DN，並提供適當的安全密碼：
|
||||
|
||||
```sh
|
||||
dn: uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com
|
||||
changetype: add
|
||||
objectclass: account
|
||||
objectclass: simplesecurityobject
|
||||
uid: gitea
|
||||
userPassword: secure password
|
||||
passwordExpirationTime: 20380119031407Z
|
||||
nsIdleTimeout: 0
|
||||
```
|
||||
|
||||
- 導入 LDIF（如果需要，將 localhost 更改為 IPA 服務器）。將提示輸入目錄管理員密碼：
|
||||
|
||||
```sh
|
||||
ldapmodify -h localhost -p 389 -x -D \
|
||||
"cn=Directory Manager" -W -f gitea.ldif
|
||||
```
|
||||
|
||||
- 為 gitea_users 添加一個 IPA 組：
|
||||
|
||||
```sh
|
||||
ipa group-add --desc="Gitea Users" gitea_users
|
||||
```
|
||||
|
||||
- 注意：有關 IPA 憑據的錯誤，請運行 `kinit admin` 並提供域管理員帳戶密碼。
|
||||
|
||||
- 以管理員身份登錄 Gitea，然後單擊管理面板下的“身份驗證”。然後單擊 `添加新源` 並填寫詳細信息，根據需要更改所有內容。
|
||||
|
||||
## SPNEGO 與 SSPI（Kerberos/NTLM，僅適用於 Windows）
|
||||
|
||||
Gitea 支持通過 Windows 中內置的安全支持提供程序接口（SSPI）為服務器的 Web 部分進行 SPNEGO 單點登錄身份驗證（RFC4559 定義的方案）。SSPI 僅在 Windows 環境中工作 - 當服務器和客戶端都運行 Windows 時。
|
||||
|
||||
在激活 SSPI 單點登錄身份驗證（SSO）之前，您必須準備好環境：
|
||||
|
||||
- 在活動目錄中創建一個單獨的用戶帳戶，該帳戶下將運行 `gitea.exe` 進程（例如，域 `domain.local` 下的 `user`）：
|
||||
|
||||
- 為運行 `gitea.exe` 的主機創建一個類別為 `HTTP` 的服務主體名稱：
|
||||
|
||||
- 以特權域用戶（例如域管理員）身份啟動 `命令提示符` 或 `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`）
|
||||
|
||||
- 啟動 Web 服務器（`gitea.exe web`）
|
||||
|
||||
- 通過在 `站點管理 -> 身份驗證源` 中添加 `SPNEGO 與 SSPI` 身份驗證源來啟用 SSPI 身份驗證
|
||||
|
||||
- 使用任何域用戶登錄到同一域中的客戶端計算機（客戶端計算機，不同於運行 `gitea.exe` 的服務器）
|
||||
|
||||
- 如果您使用的是 Chrome 或 Edge，請將 Web 應用程序的 URL 添加到本地內部網站（`Internet 選項 -> 安全 -> 本地內部網站 -> 網站`）
|
||||
|
||||
- 啟動 Chrome 或 Edge 並導航到 Gitea 的 FQDN URL（例如 `http://host.domain.local:3000`）
|
||||
|
||||
- 單擊儀表板上的 `登錄` 按鈕，選擇 SSPI 以使用當前登錄到計算機的相同用戶自動登錄
|
||||
|
||||
- 如果不起作用，請確保：
|
||||
- 您未在運行 Gitea 的同一服務器上運行 Web 瀏覽器。您應該在域加入的計算機（客戶端）上運行 Web 瀏覽器，該計算機與服務器不同。如果客戶端和服務器都在同一計算機上運行，NTLM 將優先於 Kerberos。
|
||||
- 主機只有一個 `HTTP/...` SPN
|
||||
- SPN 僅包含主機名，不包含端口
|
||||
- 您已將 Web 應用程序的 URL 添加到 `本地內部網站區域`
|
||||
- 服務器和客戶端的時鐘不應相差超過 5 分鐘（取決於組策略）
|
||||
- Internet Explorer 中應啟用 `集成 Windows 身份驗證`（在 `高級設置` 下）
|
||||
|
||||
## 反向代理
|
||||
|
||||
Gitea 支持反向代理標頭身份驗證，它將讀取標頭作為受信任的登錄用戶名或用戶電子郵件地址。默認情況下未啟用此功能，您可以通過以下方式啟用它
|
||||
|
||||
```ini
|
||||
[service]
|
||||
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
|
||||
```
|
||||
|
||||
默認登錄用戶名在 `X-WEBAUTH-USER` 標頭中，您可以通過更
|
||||
+172
@@ -0,0 +1,172 @@
|
||||
---
|
||||
date: "2017-01-01T16:00:00+02:00"
|
||||
slug: "backup-and-restore"
|
||||
sidebar_position: 11
|
||||
aliases:
|
||||
- /zh-tw/backup-and-restore
|
||||
---
|
||||
|
||||
# 備份和恢復
|
||||
|
||||
Gitea 目前有一個 `dump` 命令，可以將安裝保存到 ZIP 文件中。此文件可以解壓縮並用於恢復實例。
|
||||
|
||||
## 備份一致性
|
||||
|
||||
為了確保 Gitea 實例的一致性，必須在備份期間關閉它。
|
||||
|
||||
Gitea 由數據庫、文件和 git 存儲庫組成，這些都會在使用時發生變化。例如，當遷移正在進行時，數據庫中會創建一個事務，同時 git 存儲庫正在被複製。如果備份發生在遷移過程中，git 存儲庫可能不完整，儘管數據庫聲稱它是完整的，因為它是在之後轉儲的。避免此類競爭條件的唯一方法是在備份期間停止 Gitea 實例。
|
||||
|
||||
## 備份命令 (`dump`)
|
||||
|
||||
切換到運行 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
|
||||
2016/12/27 22:32:09 Dumping local repositories.../home/git/gitea-repositories
|
||||
2016/12/27 22:32:22 Dumping database...
|
||||
2016/12/27 22:32:22 Packing dump files...
|
||||
2016/12/27 22:32:34 Removing tmp work dir: /tmp/gitea-dump-417443001
|
||||
2016/12/27 22:32:34 Finish dumping in file gitea-dump-1482906742.zip
|
||||
```
|
||||
|
||||
在 `gitea-dump-1482906742.zip` 文件中，將包含以下內容：
|
||||
|
||||
- `app.ini` - 如果最初存儲在默認的 `custom/` 目錄之外，則為配置文件的可選副本
|
||||
- `custom/` - `custom/` 中的所有配置或自定義文件。
|
||||
- `data/` - 數據目錄（APP_DATA_PATH），如果您使用文件會話，則不包括會話。此目錄包括 `attachments`、`avatars`、`lfs`、`indexers`，如果您使用 SQLite，則包括 SQLite 文件。
|
||||
- `repos/` - 存儲庫目錄的完整副本。
|
||||
- `gitea-db.sql` - 數據庫的 SQL 轉儲
|
||||
- `log/` - 各種日誌。它們在恢復或遷移時不需要。
|
||||
|
||||
中間備份文件創建在臨時目錄中，可以通過 `--tempdir` 命令行參數或 `TMPDIR` 環境變量指定。
|
||||
|
||||
## 備份數據庫
|
||||
|
||||
由 `gitea dump` 創建的 SQL 轉儲使用 XORM，Gitea 管理員可能更喜歡使用原生的 MySQL 和 PostgreSQL 轉儲工具。使用 XORM 轉儲數據庫時仍然存在一些未解決的問題，這些問題可能會在嘗試恢復時引起問題。
|
||||
|
||||
```sh
|
||||
# mysql
|
||||
mysqldump -u$USER -p$PASS --database $DATABASE > gitea-db.sql
|
||||
# postgres
|
||||
pg_dump -U $USER $DATABASE > gitea-db.sql
|
||||
```
|
||||
|
||||
### 使用 Docker (`dump`)
|
||||
|
||||
使用 Docker 執行 `dump` 命令有一些注意事項。
|
||||
|
||||
該命令必須以 `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-dump-1482906742.zip`
|
||||
|
||||
## 恢復命令 (`restore`)
|
||||
|
||||
目前不支持恢復命令。這是一個手動過程，主要涉及將文件移動到正確的位置並恢復數據庫轉儲。
|
||||
|
||||
示例：
|
||||
|
||||
```sh
|
||||
unzip gitea-dump-1610949662.zip
|
||||
cd gitea-dump-1610949662
|
||||
mv app.ini /etc/gitea/conf/app.ini
|
||||
mv data/* /var/lib/gitea/data/
|
||||
mv log/* /var/lib/gitea/log/
|
||||
mv repos/* /var/lib/gitea/data/gitea-repositories/
|
||||
chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea
|
||||
|
||||
# mysql
|
||||
mysql --default-character-set=utf8mb4 -u$USER -p$PASS $DATABASE <gitea-db.sql
|
||||
# sqlite3
|
||||
sqlite3 $DATABASE_PATH <gitea-db.sql
|
||||
# postgres
|
||||
psql -U $USER -d $DATABASE < gitea-db.sql
|
||||
|
||||
service gitea restart
|
||||
```
|
||||
|
||||
如果安裝方法更改（例如，二進制 -> Docker），或者 Gitea 安裝到與以前不同的目錄，則應重新生成存儲庫 Git Hooks。
|
||||
|
||||
在 Gitea 運行並從 Gitea 二進制文件所在的目錄中，執行：`./gitea admin regenerate hooks`
|
||||
|
||||
這確保存儲庫 Git Hooks 中的應用程序和配置文件路徑與當前安裝一致且適用。如果這些路徑未更新，存儲庫 `push` 操作將失敗。
|
||||
|
||||
如果您仍然有問題，請考慮運行 `./gitea doctor check` 以檢查可能的錯誤（或使用 `--fix` 選項運行）。
|
||||
|
||||
### 使用 Docker (`restore`)
|
||||
|
||||
在基於 Docker 的 gitea 實例中也不支持恢復命令。恢復過程包含與前一部分中描述的相同步驟，但使用不同的路徑。
|
||||
|
||||
示例：
|
||||
|
||||
```sh
|
||||
# 在容器中打開 bash 會話
|
||||
docker exec --user git -it 2a83b293548e bash
|
||||
# 在容器內解壓備份文件
|
||||
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
|
||||
# 重新生成 Git Hooks
|
||||
/usr/local/bin/gitea -c '/data/gitea/conf/app.ini' admin regenerate hooks
|
||||
```
|
||||
|
||||
gitea 容器中的默認用戶是 `git`（1000:1000）。請將 `2a83b293548e` 替換為您的 gitea 容器 ID 或名稱。
|
||||
|
||||
### 使用 Docker-rootless (`restore`)
|
||||
|
||||
Docker-rootless 容器中的恢復工作流程僅在使用的目錄上有所不同：
|
||||
|
||||
```sh
|
||||
# 在容器中打開 bash 會話
|
||||
docker exec --user git -it 2a83b293548e bash
|
||||
# 在容器內解壓備份文件
|
||||
unzip gitea-dump-1610949662.zip
|
||||
cd gitea-dump-1610949662
|
||||
# 恢復 app.ini
|
||||
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
|
||||
# 重新生成 Git Hooks
|
||||
/usr/local/bin/gitea -c '/etc/gitea/app.ini' admin regenerate hooks
|
||||
```
|
||||
|
||||
### 使用 `gitea dump` 轉換數據庫類型
|
||||
|
||||
`gitea dump` 命令可以生成一個 SQL 文件，可以由另一種數據庫類型讀取，這在您在第一次安裝期間未選擇正確的數據庫時很有用。
|
||||
|
||||
請注意，此轉換過程尚未經過充分測試，因此建議在第一次安裝期間選擇最終的數據庫類型，而不要嘗試之後更改。
|
||||
|
||||
停止 Gitea 服務器，然後確保您擁有原始數據庫的完整備份。
|
||||
|
||||
在嘗試轉換之前，確保原始數據庫是乾淨的。運行 `gitea doctor check --all --fix` 和 `gitea doctor recreate-table` 以解決常見問題。
|
||||
|
||||
使用 `--database` 標誌獲取目標格式的 Gitea 轉儲，在此示例中為 PostgreSQL：`gitea dump --database postgres`，然後從生成的 ZIP 文件中提取 `gitea-db.sql` 文件。
|
||||
|
||||
創建 PostgreSQL Gitea 用戶和 Gitea 數據庫。然後，使用以下命令將 SQL 文件作為 Gitea 用戶導入到 Gitea 數據庫中：
|
||||
|
||||
```sh
|
||||
sudo -u postgres psql -d gitea
|
||||
gitea=# SET synchronous_commit TO off
|
||||
gitea=# SET on_error_stop TO on
|
||||
gitea=# \i gitea-db.sql
|
||||
```
|
||||
|
||||
禁用 `synchronous_commit` 使 PostgreSQL 對崩潰的抵抗力降低，但使導入速度更快。由於我們已經有原始數據庫的備份，並且我們可以檢查導入是否成功完成，因此這應該是一個不錯的權衡。
|
||||
|
||||
導入完成後，設置 Gitea 以使用 PostgreSQL 並重新啟動 Gitea 服務器。祝你好運！
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
date: "2020-01-25T21:00:00-03:00"
|
||||
slug: "cmd-embedded"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-tw/cmd-embedded
|
||||
---
|
||||
|
||||
# 嵌入式數據提取工具
|
||||
|
||||
Gitea 的可執行文件包含運行所需的所有資源：模板、圖像、樣式表和翻譯。可以通過將替換文件放置在 `custom` 目錄中的匹配路徑中來覆蓋其中的任何資源（請參閱 [自定義 Gitea](../administration/customizing-gitea.md)）。
|
||||
|
||||
要獲取嵌入資源的副本以供編輯，可以從操作系統的 shell 界面使用 CLI 的 `embedded` 命令。
|
||||
|
||||
:::note
|
||||
嵌入式數據提取工具包含在 Gitea 1.12 及更高版本中。
|
||||
:::
|
||||
|
||||
## 列出資源
|
||||
|
||||
要列出嵌入在 Gitea 可執行文件中的資源，請使用以下語法：
|
||||
|
||||
```sh
|
||||
gitea embedded list [--include-vendored] [patterns...]
|
||||
```
|
||||
|
||||
`--include-vendored` 標誌使命令包括供應商文件，這些文件通常被排除在外；即，Gitea 所需的外部庫中的文件（例如 [octicons](https://octicons.github.com/) 等）。
|
||||
|
||||
可以提供文件搜索模式列表。Gitea 使用 [gobwas/glob](https://github.com/gobwas/glob) 進行其 glob 語法。以下是一些示例：
|
||||
|
||||
- 列出所有模板文件，在任何虛擬目錄中：`**.tmpl`
|
||||
- 列出所有郵件模板文件：`templates/mail/**.tmpl`
|
||||
- 列出 `public/assets/img` 內的所有文件：`public/assets/img/**`
|
||||
|
||||
不要忘記對模式使用引號，因為空格、`*` 和其他字符可能對您的命令 shell 有特殊含義。
|
||||
|
||||
如果未提供任何模式，則列出所有文件。
|
||||
|
||||
### 示例：列出所有嵌入文件
|
||||
|
||||
列出所有路徑中包含 `openid` 的嵌入文件：
|
||||
|
||||
```sh
|
||||
$ gitea embedded list '**openid**'
|
||||
public/assets/img/auth/openid_connect.svg
|
||||
public/assets/img/openid-16x16.png
|
||||
templates/user/auth/finalize_openid.tmpl
|
||||
templates/user/auth/signin_openid.tmpl
|
||||
templates/user/auth/signup_openid_connect.tmpl
|
||||
templates/user/auth/signup_openid_navbar.tmpl
|
||||
templates/user/auth/signup_openid_register.tmpl
|
||||
templates/user/settings/security_openid.tmpl
|
||||
```
|
||||
|
||||
## 提取資源
|
||||
|
||||
要提取嵌入在 Gitea 可執行文件中的資源，請使用以下語法：
|
||||
|
||||
```sh
|
||||
gitea [--config {file}] embedded extract [--destination {dir}|--custom] [--overwrite|--rename] [--include-vendored] {patterns...}
|
||||
```
|
||||
|
||||
`--config` 選項告訴 Gitea `app.ini` 配置文件的位置（如果它不在默認位置）。此選項僅與 `--custom` 標誌一起使用。
|
||||
|
||||
`--destination` 選項告訴 Gitea 文件必須提取到的目錄。默認是當前目錄。
|
||||
|
||||
`--custom` 標誌告訴 Gitea 將文件直接提取到 `custom` 目錄中。為了使其工作，命令需要知道 `app.ini` 配置文件的位置（`--config`），並且根據配置，從 Gitea 通常啟動的目錄運行。詳情請參閱 [自定義 Gitea](../administration/customizing-gitea.md)。
|
||||
|
||||
`--overwrite` 標誌允許覆蓋目標目錄中的任何現有文件。
|
||||
|
||||
`--rename` 標誌告訴 Gitea 將目標目錄中的任何現有文件重命名為 `filename.bak`。以前的 `.bak` 文件將被覆蓋。
|
||||
|
||||
必須提供至少一個文件搜索模式；請參閱上面的 `list` 子命令以了解模式語法和示例。
|
||||
|
||||
### 重要通知
|
||||
|
||||
確保**僅提取那些需要自定義的文件**。`custom` 目錄中存在的文件不會被 Gitea 的升級過程升級。當 Gitea 升級到新版本（通過替換可執行文件）時，許多嵌入文件將發生變化。Gitea 將尊重並使用 `custom` 目錄中找到的任何文件，即使它們是舊的且不兼容。
|
||||
|
||||
### 示例：提取郵件模板
|
||||
|
||||
將郵件模板提取到臨時目錄：
|
||||
|
||||
```sh
|
||||
$ mkdir tempdir
|
||||
$ gitea embedded extract --destination tempdir 'templates/mail/**.tmpl'
|
||||
Extracting to tempdir:
|
||||
tempdir/templates/mail/auth/activate.tmpl
|
||||
tempdir/templates/mail/auth/activate_email.tmpl
|
||||
tempdir/templates/mail/auth/register_notify.tmpl
|
||||
tempdir/templates/mail/auth/reset_passwd.tmpl
|
||||
tempdir/templates/mail/issue/assigned.tmpl
|
||||
tempdir/templates/mail/issue/default.tmpl
|
||||
tempdir/templates/mail/notify/collaborator.tmpl
|
||||
```
|
||||
+230
@@ -0,0 +1,230 @@
|
||||
---
|
||||
date: "2017-01-01T16:00:00+02:00"
|
||||
slug: "command-line"
|
||||
sidebar_position: 1
|
||||
aliases:
|
||||
- /zh-tw/command-line
|
||||
---
|
||||
|
||||
# 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）。
|
||||
|
||||
注意：默認的 custom-path、config 和 work-path 也可以在構建時更改（如果需要）。
|
||||
|
||||
## 命令
|
||||
|
||||
### web
|
||||
|
||||
啟動服務器：
|
||||
|
||||
- 選項：
|
||||
- `--port number`, `-p number`: 端口號。可選。（默認：3000）。覆蓋配置文件。
|
||||
- `--install-port number`: 運行安裝頁面的端口號。可選。（默認：3000）。覆蓋配置文件。
|
||||
- `--pid path`, `-P path`: Pidfile 路徑。可選。
|
||||
- `--quiet`, `-q`: 只在控制台上發出致命日誌，適用於日誌設置之前的日誌。
|
||||
- `--verbose`: 在控制台上發出跟踪日誌，適用於日誌設置之前的日誌。
|
||||
- 示例：
|
||||
- `gitea web`
|
||||
- `gitea web --port 80`
|
||||
- `gitea web --config /etc/gitea.ini --pid /some/custom/gitea.pid`
|
||||
- 注意：
|
||||
- Gitea 不應以 root 身份運行。要綁定到 1024 以下的端口，可以在 Linux 上使用 setcap：`sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`。每次更新 Gitea 時都需要重新執行此操作。
|
||||
|
||||
### admin
|
||||
|
||||
管理操作：
|
||||
|
||||
- 命令：
|
||||
- `user`:
|
||||
- `list`:
|
||||
- 選項：
|
||||
- `--admin`: 僅列出管理員用戶。可選。
|
||||
- 描述：列出所有存在的用戶
|
||||
- 示例：
|
||||
- `gitea admin user list`
|
||||
- `delete`:
|
||||
- 選項：
|
||||
- `--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 中的新功能。
|
||||
- `--password value`: 密碼。必需。
|
||||
- `--email value`: 電子郵件。必需。
|
||||
- `--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 me@example.com`
|
||||
- `change-password`:
|
||||
- 選項：
|
||||
- `--username value`, `-u value`: 用戶名。必需。
|
||||
- `--password value`, `-p value`: 新密碼。必需。
|
||||
- `--must-change-password`: 用戶在登錄後需要設置新密碼，默認：true。可以通過 `--must-change-password=false` 禁用。
|
||||
- 示例：
|
||||
- `gitea admin user change-password --username myname --password asecurepassword`
|
||||
- `must-change-password`:
|
||||
- 參數：
|
||||
- `[username...]`: 必須更改密碼的用戶
|
||||
- 選項：
|
||||
- `--all`, `-A`: 強制所有用戶更改密碼
|
||||
- `--exclude username`, `-e username`: 排除給定的用戶。可以多次設置。
|
||||
- `--unset`: 撤銷給定用戶的強制密碼更改
|
||||
- `generate-access-token`:
|
||||
- 選項：
|
||||
- `--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 鉤子
|
||||
- `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`: 應用程序名稱。
|
||||
- `--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 登錄源。
|
||||
- `--skip-local-2fa`: 允許源覆蓋本地 2FA。（可選）
|
||||
- `--scopes`: 為此 OAuth2 源請求的其他範圍。（可選）
|
||||
- `--required-claim-name`: 必須設置的聲明名稱，以允許用戶使用此源登錄。（可選）
|
||||
- `--required-claim-value`: 必須設置的聲明值，以允許用戶使用此源登錄。（可選）
|
||||
- `--group-claim-name`: 為此源提供組名稱的聲明名稱。（可選）
|
||||
- `--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`: 應用程序名稱。
|
||||
- `--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 登錄源。
|
||||
- `--skip-local-2fa`: 允許源覆蓋本地 2FA。（可選）
|
||||
- `--scopes`: 為此 OAuth2 源請求的其他範圍。
|
||||
- `--required-claim-name`: 必須設置的聲明名稱，以允許用戶使用此源登錄。（可選）
|
||||
- `--required-claim-value`: 必須設置的聲明值，以允許用戶使用此源登錄。（可選）
|
||||
- `--group-claim-name`: 為此源提供組名稱的聲明名稱。（可選）
|
||||
- `--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。
|
||||
- `--host`: SMTP 主機。必需。
|
||||
- `--port`: SMTP 端口。必需。
|
||||
- `--force-smtps`: SMTPS 始終用於端口 465。設置此選項以在其他端口上強制使用 SMTPS。
|
||||
- `--skip-verify`: 跳過 TLS 驗證。
|
||||
- `--helo-hostname`: 與 HELO 一起發送的主機名。留空以發送當前主機名。
|
||||
- `--disable-helo`: 禁用 SMTP helo。
|
||||
- `--allowed-domains`: 留空以允許所有域。用逗號（','）分隔多個域。
|
||||
- `--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` 值
|
||||
- 示例：
|
||||
- `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）身份驗證源
|
||||
- 選項：
|
||||
- `--name value`: 身份驗證名稱。必需。
|
||||
- `--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 具有盡可能少的權限。
|
||||
- `--attributes-in-bind`: 在綁定 DN 上下文中獲取屬性。
|
||||
- `--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）身份驗證源
|
||||
- 選項：
|
||||
- `--id value`: 身份驗證源的 ID。必需。
|
||||
- `--name value`: 身份驗證名稱。
|
||||
- `--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
|
||||
+138
@@ -0,0 +1,138 @@
|
||||
---
|
||||
date: "2016-12-26T16:00:00+02:00"
|
||||
slug: "config-cheat-sheet"
|
||||
sidebar_position: 30
|
||||
aliases:
|
||||
- /zh-tw/config-cheat-sheet
|
||||
---
|
||||
|
||||
# 配置備忘單
|
||||
|
||||
這是一份 Gitea 配置文件的備忘單。它包含了大多數可以配置的設置以及它們的默認值。
|
||||
|
||||
對 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) 提供的功能，用於遞歸讀取值。
|
||||
|
||||
在下面的默認值中，形式為 `$XYZ` 的值指的是環境變量。（但是，請參閱 `environment-to-ini`。）形式為 _`XxYyZz`_ 的值指的是作為默認配置一部分列出的值。這些符號形式不會在您自己的 `app.ini` 文件中工作，僅在此處作為文檔列出。
|
||||
|
||||
包含 `#` 或 `;` 的值必須使用 `` ` `` 或 `"""` 引號。
|
||||
|
||||
:::info
|
||||
Gitea 配置更改需要完全重啟才能生效。
|
||||
:::
|
||||
|
||||
## 默認配置（非 `app.ini` 配置）
|
||||
|
||||
這些值是環境依賴的，但構成了許多值的基礎。它們將在運行 `gitea help` 或啟動時作為默認配置的一部分報告。它們在那裡發出的順序略有不同，但我們將在這裡按設置順序列出它們。
|
||||
|
||||
- _`AppPath`_：這是運行 gitea 二進制文件的絕對路徑。
|
||||
- _`AppWorkPath`_：這指的是 `gitea` 二進制文件的“工作路徑”。它是通過使用以下層次結構中的第一個設置來確定的：
|
||||
- `app.ini` 中的 `WORK_PATH` 選項
|
||||
- 傳遞給二進制文件的 `--work-path` 標誌
|
||||
- 環境變量 `$GITEA_WORK_DIR`
|
||||
- 構建時設置的內置值（請參閱從源代碼構建）
|
||||
- 否則，它默認為 _`AppPath`_ 的目錄
|
||||
- 如果上述任何一個是相對路徑，則它們將相對於 _`AppPath`_ 的目錄變為絕對路徑
|
||||
- _`CustomPath`_：這是自定義模板和其他選項的基本目錄。
|
||||
它是通過使用以下層次結構中的第一個設置來確定的：
|
||||
- 傳遞給二進制文件的 `--custom-path` 標誌
|
||||
- 環境變量 `$GITEA_CUSTOM`
|
||||
- 構建時設置的內置值（請參閱從源代碼構建）
|
||||
- 否則，它默認為 _`AppWorkPath`_`/custom`
|
||||
- 如果上述任何一個是相對路徑，則它們將相對於 _`AppWorkPath`_ 的目錄變為絕對路徑
|
||||
- _`CustomConf`_：這是 `app.ini` 文件的路徑。
|
||||
- 傳遞給二進制文件的 `--config` 標誌
|
||||
- 構建時設置的內置值（請參閱從源代碼構建）
|
||||
- 否則，它默認為 _`CustomPath`_`/conf/app.ini`
|
||||
- 如果上述任何一個是相對路徑，則它們將相對於 _`CustomPath`_ 的目錄變為絕對路徑
|
||||
|
||||
此外，還有 _`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`，適用於生產使用。
|
||||
- `WORK_PATH`：**_the-work-path_**：工作目錄，請參閱上面的 AppWorkPath 註釋。
|
||||
|
||||
## 存儲庫（`repository`）
|
||||
|
||||
- `ROOT`：**%(APP_DATA_PATH)s/gitea-repositories**：存儲所有存儲庫數據的根路徑。
|
||||
相對路徑解釋為 **_`AppWorkPath`_/%(ROOT)s**。
|
||||
- `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**：創建新存儲庫時的默認私有設置。
|
||||
\[last, private, public\]
|
||||
- `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。
|
||||
- `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**：通過將它們放在以存儲庫命名的目錄中來為存檔文件添加前綴。
|
||||
- `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**：允許無最大數量限制的分叉存儲庫
|
||||
|
||||
### 存儲庫 - 編輯器（`repository.editor`）
|
||||
|
||||
- `LINE_WRAP_EXTENSIONS`：**.txt,.md,.markdown,.mdown,.mkd,.livemd,**：在 Monaco 編輯器中應換行的文件擴展名列表。用逗號分隔擴展名。要換行沒有擴展名的文件，只需放置一個逗號
|
||||
- `PREVIEWABLE_FILE_MODES`：**markdown**：具有預覽 API 的有效文件模式，例如 `api/v1/markdown`。用逗號分隔值。如果文件擴展名不匹配，則不會顯示編輯模式中的預覽選項卡。
|
||||
|
||||
### 存儲庫 - 拉取請求（`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**：在默認的壓縮合併消息中，包含組成拉取請求的所有提交的提交消息。
|
||||
- `ADD_CO_COMMITTER_TRAILERS`：**true**：如果提交者與作者不匹配，則在合併提交消息中添加共同作者和共同提交者的尾部。
|
||||
- `TEST_CONFLICTING_PATCHES_WITH_GIT_APPLY`：**false**：PR 補丁使用三方合併方法進行測試，以發現是否存在衝突。如果此設置設置為 **true**，則將使用 `git apply` 重新測試衝突的補丁 - 這是 1.18（及更早版本）中的先前行為，但效率較低。如果您發現需要此設置，請報告。
|
||||
- `RETARGET_CHILDREN_ON_MERGE`：**true**：在合併父拉取請求時，將子拉取請求重新定位到父拉取請求分支目標。僅適用於目標相同存儲庫的合併 PR。
|
||||
|
||||
### 存儲庫 - 問題（`repository.issue`）
|
||||
|
||||
- `LOCK_REASONS`：**Too heated,Off-topic,Resolved,Spam**：可以鎖定拉取請求或問題的原因列表
|
||||
- `MAX_PINNED`：**3**：每個存儲庫的最大固定問題數量。設置為 0 以禁用固定問題。
|
||||
|
||||
### 存儲庫 - 上傳（`repository.upload`）
|
||||
|
||||
- `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`）
|
||||
|
||||
- `ALLOWED_TYPES`：**_empty_**：允許的文件擴展名（`.zip`）、MIME 類型（`text/plain`）
|
||||
+287
@@ -0,0 +1,287 @@
|
||||
---
|
||||
date: "2017-04-15T14:56:00+02:00"
|
||||
slug: "customizing-gitea"
|
||||
sidebar_position: 100
|
||||
aliases:
|
||||
- /zh-tw/customizing-gitea
|
||||
---
|
||||
|
||||
# 自定義 Gitea
|
||||
|
||||
自定義 Gitea 通常使用 `CustomPath` 文件夾進行 - 默認情況下，這是工作目錄（WorkPath）中的 `custom` 文件夾，但如果您的構建設置不同，則可能會有所不同。這是覆蓋配置設置、模板等的中心位置。您可以使用 `gitea help` 檢查 `CustomPath`。您還可以在 _站點管理_ 頁面的 _配置_ 標籤中找到路徑。您可以通過設置 `GITEA_CUSTOM` 環境變量或使用 `gitea` 二進制文件上的 `--custom-path` 選項來覆蓋 `CustomPath`。（該選項將覆蓋環境變量。）
|
||||
|
||||
如果 Gitea 是從二進制文件部署的，則所有默認路徑都將相對於 Gitea 二進制文件。如果從發行版安裝，這些路徑可能會修改為 Linux 文件系統標準。Gitea 將嘗試創建所需的文件夾，包括 `custom/`。發行版可能會使用 `/etc/gitea/` 提供 `custom` 的符號鏈接。
|
||||
|
||||
應用程序設置可以在 `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` 可能由啟動腳本設置。您可以在站點管理頁面的“配置”標籤下檢查是否設置了該值。
|
||||
|
||||
- [環境變量列表](../administration/environment-variables.md)
|
||||
|
||||
:::note
|
||||
Gitea 必須完全重啟才能看到配置更改。
|
||||
:::
|
||||
|
||||
## 提供自定義公共文件
|
||||
|
||||
要使 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 源代碼庫，替換 `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.png` - 用於 Open Graph
|
||||
- `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 圖標的瀏覽器
|
||||
|
||||
如果源圖像不是矢量格式，您可以嘗試使用工具（如[這個](https://www.aconvert.com/image/png-to-svg/)）將光柵圖像轉換為矢量圖像。
|
||||
|
||||
## 自定義 Gitea 頁面和資源
|
||||
|
||||
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 embedded` 工具](../administration/cmd-embedded.md)。或者，它們可以在 Gitea 源代碼的 [`templates`](https://github.com/go-gitea/gitea/tree/main/templates) 目錄中找到（注意：示例鏈接來自 `main` 分支。確保使用與您使用的版本兼容的模板）。
|
||||
|
||||
請注意，任何包含在 `{{` 和 `}}` 之間的語句都是 Gitea 的模板語法，應在完全理解這些組件之前不要觸摸。
|
||||
|
||||
### 自定義起始頁/首頁
|
||||
|
||||
從 `templates` 為您的 Gitea 版本複製 [`home.tmpl`](https://github.com/go-gitea/gitea/blob/main/templates/home.tmpl) 到 `$GITEA_CUSTOM/templates`。
|
||||
根據需要進行編輯。
|
||||
不要忘記重啟您的 Gitea 以應用更改。
|
||||
|
||||
### 添加鏈接和標籤
|
||||
|
||||
如果您只想在頂部導航欄或頁腳中添加額外的鏈接，或在存儲庫視圖中添加額外的標籤，可以將它們放在 `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` 中。
|
||||
|
||||
為了匹配當前樣式，鏈接應具有類名“item”，您可以使用 `{{AppSubUrl}}` 獲取基本 URL：
|
||||
`<a class="item" href="{{AppSubUrl}}/assets/impressum.html">Impressum</a>`
|
||||
|
||||
有關更多信息，請參閱 [添加法律頁面](../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)）
|
||||
|
||||
### 頁面的其他添加
|
||||
|
||||
除了 `extra_links.tmpl` 和 `extra_tabs.tmpl`，還有其他有用的模板，您可以將它們放在 `$GITEA_CUSTOM/templates/custom/` 目錄中：
|
||||
|
||||
- `header.tmpl`，在 `<head>` 標籤結束之前，您可以添加自定義 CSS 文件。
|
||||
- `body_outer_pre.tmpl`，在 `<body>` 開始之後。
|
||||
- `body_inner_pre.tmpl`，在頂部導航欄之前，但已經在主容器 `<div class="full height">` 內。
|
||||
- `body_inner_post.tmpl`，在主容器結束之前。
|
||||
- `body_outer_post.tmpl`，在底部 `<footer>` 元素之前。
|
||||
- `footer.tmpl`，在 `<body>` 標籤結束之前，是添加 JavaScript 的好地方。
|
||||
|
||||
### 使用 Gitea 變量
|
||||
|
||||
可以在自定義模板中使用各種 Gitea 變量。
|
||||
|
||||
首先，_臨時_ 啟用開發模式：在您的 `app.ini` 中將 `RUN_MODE = prod` 更改為 `RUN_MODE = dev`。然後將 `{{ $ | DumpVar }}` 添加到任何模板中，重啟 Gitea 並刷新該頁面；這將轉儲所有可用變量。
|
||||
|
||||
找到您需要的數據，並使用相應的變量；例如，如果您需要存儲庫的名稱，則可以使用 `{{.Repository.Name}}`。
|
||||
|
||||
如果您需要以某種方式轉換這些數據，並且不熟悉 Go，一個簡單的解決方法是將數據添加到 DOM 並添加一個小的 JavaScript 腳本塊來操作數據。
|
||||
|
||||
### 示例：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`：
|
||||
|
||||
```html
|
||||
<script>
|
||||
$(async () => {
|
||||
if (!$(".language-plantuml").length) return;
|
||||
await Promise.all([
|
||||
$.getScript("https://your-gitea-server.com/assets/deflate.js"),
|
||||
$.getScript("https://your-gitea-server.com/assets/encode.js"),
|
||||
$.getScript(
|
||||
"https://your-gitea-server.com/assets/plantuml_codeblock_parse.js"
|
||||
),
|
||||
]);
|
||||
// 用您的 plantuml 服務器地址替換調用
|
||||
parsePlantumlCodeBlocks("https://www.plantuml.com/plantuml");
|
||||
});
|
||||
</script>
|
||||
```
|
||||
|
||||
然後您可以將以下塊添加到您的 markdown 中：
|
||||
|
||||
```plantuml
|
||||
Alice -> Bob: Authentication Request
|
||||
Bob --> Alice: Authentication Response
|
||||
|
||||
Alice -> Bob: Another authentication Request
|
||||
Alice <-- Bob: Another authentication Response
|
||||
```
|
||||
|
||||
該腳本將檢測帶有 `class="language-plantuml"` 的標籤，但您可以通過提供第二個參數給 `parsePlantumlCodeBlocks` 來更改此設置。
|
||||
|
||||
### 示例：STL 預覽
|
||||
|
||||
您可以通過添加以下內容直接在 Gitea 中顯示 STL 文件：
|
||||
|
||||
```html
|
||||
<script>
|
||||
function lS(src) {
|
||||
return new Promise(function (resolve, reject) {
|
||||
let s = document.createElement("script");
|
||||
s.src = src;
|
||||
s.addEventListener("load", () => {
|
||||
resolve();
|
||||
});
|
||||
document.body.appendChild(s);
|
||||
});
|
||||
}
|
||||
|
||||
if ($('.view-raw>a[href$=".stl" i]').length) {
|
||||
$("body").append(
|
||||
'<link href="/assets/Madeleine.js/src/css/Madeleine.css" rel="stylesheet">'
|
||||
);
|
||||
Promise.all([
|
||||
lS("/assets/Madeleine.js/src/lib/stats.js"),
|
||||
lS("/assets/Madeleine.js/src/lib/detector.js"),
|
||||
lS("/assets/Madeleine.js/src/lib/three.min.js"),
|
||||
lS("/assets/Madeleine.js/src/Madeleine.js"),
|
||||
]).then(function () {
|
||||
$(".view-raw")
|
||||
.attr("id", "view-raw")
|
||||
.attr("style", "padding: 0;margin-bottom: -10px;");
|
||||
new Madeleine({
|
||||
target: "view-raw",
|
||||
data: $('.view-raw>a[href$=".stl" i]').attr("href"),
|
||||
path: "/assets/Madeleine.js/src",
|
||||
});
|
||||
$('.view-raw>a[href$=".stl"]').remove();
|
||||
});
|
||||
}
|
||||
</script>
|
||||
```
|
||||
|
||||
到文件 `templates/custom/footer.tmpl`
|
||||
|
||||
您還需要下載庫 [Madeleine.js](https://github.com/beige90/Madeleine.js) 的內容並將其放置在 `$GITEA_CUSTOM/public/assets/` 文件夾下。
|
||||
|
||||
您應該最終得到類似於以下結構的文件夾：
|
||||
|
||||
```
|
||||
$GITEA_CUSTOM/templates
|
||||
-- custom
|
||||
`-- footer.tmpl
|
||||
|
||||
$GITEA_CUSTOM/public/assets/
|
||||
-- Madeleine.js
|
||||
|-- LICENSE
|
||||
|-- README.md
|
||||
|-- css
|
||||
| |-- pygment_trac.css
|
||||
| `-- stylesheet.css
|
||||
|-- examples
|
||||
| |-- ajax.html
|
||||
| |-- index.html
|
||||
| `-- upload.html
|
||||
|-- images
|
||||
| |-- bg_hr.png
|
||||
| |-- blacktocat.png
|
||||
| |-- icon_download.png
|
||||
| `-- sprite_download.png
|
||||
|-- models
|
||||
| |-- dino2.stl
|
||||
| |-- ducati.stl
|
||||
| |-- gallardo.stl
|
||||
| |-- lamp.stl
|
||||
| |-- octocat.stl
|
||||
| |-- skull.stl
|
||||
| `-- treefrog.stl
|
||||
`-- src
|
||||
|-- Madeleine.js
|
||||
|-- css
|
||||
| `-- Madeleine.css
|
||||
|-- icons
|
||||
| |-- logo.png
|
||||
| |-- madeleine.eot
|
||||
| |-- madeleine.svg
|
||||
| |-- madeleine.ttf
|
||||
| `-- madeleine.woff
|
||||
`-- lib
|
||||
|-- MadeleineConverter.js
|
||||
|-- MadeleineLoader.js
|
||||
|-- detector.js
|
||||
|-- stats.js
|
||||
`-- three.min.js
|
||||
```
|
||||
|
||||
然後重啟 Gitea 並在您的 Gitea 實例上打開 STL 文件。
|
||||
|
||||
## 自定義 Gitea 郵件
|
||||
|
||||
`$GITEA_CUSTOM/templates/mail` 文件夾允許更改 Gitea 的每封郵件的正文。
|
||||
可以在 Gitea 源代碼的 [`templates/mail`](https://github.com/go-gitea/gitea/tree/main/templates/mail) 目錄中找到要覆蓋的模板。
|
||||
通過在 `$GITEA_CUSTOM/templates/mail` 下製作文件副本來覆蓋，使用與源相匹配的完整路徑結構。
|
||||
|
||||
任何包含在 `{{` 和 `}}` 之間的語句都是 Gitea 的模板語法，應在完全理解這些組件之前不要觸摸。
|
||||
|
||||
## 向 Gitea 添加分析
|
||||
|
||||
可以向 Gitea 添加 Google Analytics、Matomo（以前稱為 Piwik）和其他分析服務。要添加跟踪代碼，請參閱本文檔的“頁面的其他添加”部分，並將 JavaScript 添加到 `$GITEA_CUSTOM/templates/custom/header.tmpl` 文件中。
|
||||
|
||||
## 自定義 gitignores、標籤、許可證、本地化和 readmes
|
||||
|
||||
將自定義文件放置在 `custom/options` 下的相應子文件夾中。
|
||||
|
||||
:::note
|
||||
文件不應具有文件擴展名，例如 `Labels` 而不是 `Labels.txt`
|
||||
:::
|
||||
|
||||
### gitignores
|
||||
|
||||
要添加自定義 .gitignore，請將包含現有 [.gitignore 規則](https://git-scm.com/docs/gitignore) 的文件添加到 `$GITEA_CUSTOM/options/gitignore`
|
||||
|
||||
## 自定義 git 配置
|
||||
|
||||
從 Gitea 1.20 開始，您可以通過 `git.config` 部分自定義 git 配置。
|
||||
|
||||
### 啟用簽名 git 推送
|
||||
|
||||
要啟用簽名 git 推送，請設置以下兩個選項：
|
||||
|
||||
```ini
|
||||
[git.config]
|
||||
receive.advertisePushOptions = true
|
||||
receive.certNonceSeed = <randomstring>
|
||||
```
|
||||
|
||||
`certNonceSeed` 應設置為隨機字符串並保持秘密。
|
||||
|
||||
### 標籤
|
||||
|
||||
從 Gitea 1.19 開始，您可以將遵循 [YAML 標籤格式](https://github.com/go-gitea/gitea/blob/main/options/label/Advanced.yaml) 的文件添加到 `$GITEA_CUSTOM/options/label`：
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
- name: "foo/bar" # 在下拉列表中顯示的標籤名稱
|
||||
exclusive: true # 是否使用專用命名空間進行範圍標籤。範圍分隔符為 /
|
||||
color: aabbcc # 十六進制顏色編碼
|
||||
description: Some label # 標籤意圖的長描述
|
||||
```
|
||||
|
||||
仍然可以使用 [舊文件格式](https://github.com/go-gitea/gitea/blob/main/options
|
||||
@@ -0,0 +1,115 @@
|
||||
---
|
||||
date: "2019-10-15T10:10:00+05:00"
|
||||
slug: "email-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-tw/email-setup
|
||||
---
|
||||
|
||||
# 電子郵件設置
|
||||
|
||||
Gitea 具有發送交易電子郵件（如註冊確認）的郵件功能。它可以配置為使用 Sendmail（或兼容的 MTA，如 Postfix 和 msmtp）或直接使用 SMTP 服務器。
|
||||
|
||||
## 使用 Sendmail
|
||||
|
||||
使用 `sendmail` 命令作為郵件程序。
|
||||
|
||||
:::note
|
||||
要在官方 Gitea Docker 映像中使用，請配置為 SMTP 版本（請參閱以下部分）。
|
||||
:::
|
||||
|
||||
:::note
|
||||
對於面向互聯網的網站，請參閱您的 MTA 文檔以獲取有關通過 TLS 發送電子郵件的說明。還設置 SPF、DMARC 和 DKIM DNS 記錄，以使發送的電子郵件被各種電子郵件提供商接受為合法。
|
||||
:::
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = gitea@mydomain.com
|
||||
PROTOCOL = sendmail
|
||||
SENDMAIL_PATH = /usr/sbin/sendmail
|
||||
SENDMAIL_ARGS = "--" ; 大多數 "sendmail" 程序接受選項，"--" 將防止電子郵件地址被解釋為選項。
|
||||
```
|
||||
|
||||
## 使用 SMTP
|
||||
|
||||
直接使用 SMTP 服務器作為中繼。此選項適用於您不想在實例上設置 MTA，但您在電子郵件提供商處有帳戶的情況。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = gitea@mydomain.com
|
||||
PROTOCOL = smtps
|
||||
SMTP_ADDR = mail.mydomain.com
|
||||
SMTP_PORT = 587
|
||||
USER = gitea@mydomain.com
|
||||
PASSWD = `password`
|
||||
```
|
||||
|
||||
重新啟動 Gitea 以使配置更改生效。
|
||||
|
||||
要發送測試電子郵件以驗證設置，請轉到 Gitea > 站點管理 > 配置 > 摘要 -> 郵件配置。
|
||||
|
||||
有關完整的選項列表，請參閱 [配置備忘單](../administration/config-cheat-sheet.md)
|
||||
|
||||
:::note
|
||||
僅當 SMTP 服務器通信使用 TLS 加密或 `HOST=localhost` 時，才支持身份驗證。TLS 加密可以通過：
|
||||
:::
|
||||
|
||||
- STARTTLS（也稱為機會性 TLS）通過端口 587。初始連接在明文上完成，但如果服務器支持，則升級為 TLS。
|
||||
- SMTPS 連接（SMTP over TLS）通過默認端口 465。從一開始就使用 TLS 連接到服務器。
|
||||
- 使用 `PROTOCOL=smtps` 強制 SMTPS 連接。（這些都稱為隱式 TLS。）
|
||||
這是由於 Go 內部庫對 STRIPTLS 攻擊的保護。
|
||||
|
||||
請注意，自 2018 年以來，[RFC8314](https://tools.ietf.org/html/rfc8314#section-3) 建議使用隱式 TLS。
|
||||
|
||||
### Gmail
|
||||
|
||||
以下配置應適用於 GMail 的 SMTP 服務器：
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
HOST = smtp.gmail.com:465 ; 對於 Gitea >= 1.18.0，刪除此行
|
||||
SMTP_ADDR = smtp.gmail.com
|
||||
SMTP_PORT = 465
|
||||
FROM = example.user@gmail.com
|
||||
USER = example.user
|
||||
PASSWD = `***`
|
||||
PROTOCOL = smtps
|
||||
```
|
||||
|
||||
請注意，您需要通過在 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 應用程序來繞過。
|
||||
|
||||
請注意，使用 SMTP 發送的電子郵件不是 [端到端加密](https://proton.me/support/proton-mail-encryption-explained) 的。然而，它們仍然像 Proton Mail 收件箱中的其他電子郵件一樣存儲為零訪問加密。
|
||||
|
||||
以下配置應適用於 ProtonMail 的 SMTP 服務器：
|
||||
|
||||
1. 在您的瀏覽器（或桌面應用程序）中，登錄到您的 Proton Mail 帳戶，然後選擇 **設置 → 所有設置 → Proton Mail → IMAP/SMTP → SMTP 令牌**。
|
||||
2. 單擊 **生成令牌**。
|
||||
3. 輸入以下詳細信息以創建新的 SMTP 令牌：
|
||||
- **令牌名稱**：選擇一個令牌名稱。這僅供您參考，不會影響令牌的功能。
|
||||
- **電子郵件地址**：選擇一個活動的自定義域地址與您的令牌配對。複製此電子郵件地址並將其用於 `app.ini` 中的 `FROM` 和 `USER` 配置。
|
||||
4. 單擊 **生成**。
|
||||
5. 輸入您的 Proton Mail 帳戶密碼。
|
||||
|
||||
您的 SMTP 用戶名和 SMTP 令牌（密碼）將生成。您現在可以將它們作為 `USER` 和 `PASSWD` 輸入到您的 `app.ini` 配置中。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = example.user@customdomain.tld
|
||||
PROTOCOL = smtp+starttls
|
||||
SMTP_ADDR = smtp.protonmail.ch
|
||||
SMTP_PORT = 587
|
||||
USER = example.user@customdomain.tld
|
||||
PASSWD = `TOKEN`
|
||||
```
|
||||
|
||||
關閉彈出窗口後，出於安全原因，您將無法再次看到此 SMTP 令牌（密碼）。如果需要旋轉密碼，您可以隨時生成更多令牌。
|
||||
|
||||
注意：您的 Proton Mail 登錄或郵箱密碼將無法與 SMTP 一起使用。
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
date: "2017-04-08T11:34:00+02:00"
|
||||
slug: "environment-variables"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
- /zh-tw/environment-variables
|
||||
---
|
||||
|
||||
# Environment variables
|
||||
|
||||
This is an inventory of Gitea environment variables. They change Gitea behaviour.
|
||||
|
||||
Initialize them before Gitea command to be effective, for example:
|
||||
|
||||
```sh
|
||||
GITEA_CUSTOM=/home/gitea/custom ./gitea web
|
||||
```
|
||||
|
||||
## From Go language
|
||||
|
||||
As Gitea is written in Go, it uses some variables that influence the behaviour of Go's runtime, such as:
|
||||
|
||||
- `GOMEMLIMIT`
|
||||
- `GOGC`
|
||||
- `GOMAXPROCS`
|
||||
- `GODEBUG`
|
||||
|
||||
For documentation about each of the variables available, refer to the
|
||||
[official Go documentation on runtime environment variables](https://pkg.go.dev/runtime#hdr-Environment_Variables).
|
||||
|
||||
## Gitea files
|
||||
|
||||
- `GITEA_WORK_DIR`: Absolute path of working directory.
|
||||
- `GITEA_CUSTOM`: Gitea uses `WorkPath`/custom folder by default. Use this variable to change _custom_ directory.
|
||||
|
||||
## Operating system specifics
|
||||
|
||||
- `USER`: System user that Gitea will run as. Used for some repository access strings.
|
||||
- `USERNAME`: if no `USER` found, Gitea will use `USERNAME`
|
||||
- `HOME`: User home directory path. The `USERPROFILE` environment variable is used in Windows.
|
||||
|
||||
### Only on Windows
|
||||
|
||||
- `USERPROFILE`: User home directory path. If empty, uses `HOMEDRIVE` + `HOMEPATH`
|
||||
- `HOMEDRIVE`: Main drive path used to access the home directory (C:)
|
||||
- `HOMEPATH`: Home relative path in the given home drive path
|
||||
|
||||
## Miscellaneous
|
||||
|
||||
- `SKIP_MINWINSVC`: If set to 1, do not run as a service on Windows.
|
||||
+184
@@ -0,0 +1,184 @@
|
||||
---
|
||||
date: "2018-11-23:00:00+02:00"
|
||||
slug: "external-renderers"
|
||||
sidebar_position: 60
|
||||
aliases:
|
||||
- /zh-tw/external-renderers
|
||||
---
|
||||
|
||||
# External renderers
|
||||
|
||||
Gitea supports custom file renderings (i.e., Jupyter notebooks, asciidoc, etc.) through external binaries,
|
||||
it is just a matter of:
|
||||
|
||||
- installing external binaries
|
||||
- add some configuration to your `app.ini` file
|
||||
- restart your Gitea instance
|
||||
|
||||
This supports rendering of whole files. If you want to render code blocks in markdown you would need to do something with javascript. See some examples on the [Customizing Gitea](../administration/customizing-gitea.md) page.
|
||||
|
||||
## Installing external binaries
|
||||
|
||||
In order to get file rendering through external binaries, their associated packages must be installed.
|
||||
If you're using a Docker image, your `Dockerfile` should contain something along this lines:
|
||||
|
||||
```docker
|
||||
FROM docker.gitea.com/gitea:@dockerVersion@
|
||||
[...]
|
||||
|
||||
COPY custom/app.ini /data/gitea/conf/app.ini
|
||||
[...]
|
||||
|
||||
RUN apk --no-cache add asciidoctor freetype freetype-dev gcc g++ libpng libffi-dev pandoc python3-dev py3-pyzmq pipx
|
||||
# install any other package you need for your external renderers
|
||||
|
||||
RUN pipx install jupyter docutils --include-deps --global
|
||||
# add above any other python package you may need to install
|
||||
```
|
||||
|
||||
## `app.ini` file configuration
|
||||
|
||||
add one `[markup.XXXXX]` section per external renderer on your custom `app.ini`:
|
||||
|
||||
```ini
|
||||
[markup.asciidoc]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .adoc,.asciidoc
|
||||
RENDER_COMMAND = "asciidoctor -s -a showtitle --out-file=- -"
|
||||
; Input is not a standard input but a file
|
||||
IS_INPUT_FILE = false
|
||||
|
||||
[markup.jupyter]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .ipynb
|
||||
RENDER_COMMAND = "jupyter nbconvert --stdin --stdout --to html --template basic"
|
||||
IS_INPUT_FILE = false
|
||||
|
||||
[markup.restructuredtext]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .rst
|
||||
RENDER_COMMAND = "timeout 30s pandoc +RTS -M512M -RTS -f rst"
|
||||
IS_INPUT_FILE = false
|
||||
```
|
||||
|
||||
If your external markup relies on additional classes and attributes on the generated HTML elements, you might need to enable custom sanitizer policies. Gitea uses the [`bluemonday`](https://godoc.org/github.com/microcosm-cc/bluemonday) package as our HTML sanitizer. The example below could be used to support server-side [KaTeX](https://katex.org/) rendering output from [`pandoc`](https://pandoc.org/).
|
||||
|
||||
```ini
|
||||
[markup.sanitizer.TeX]
|
||||
; Pandoc renders TeX segments as <span>s with the "math" class, optionally
|
||||
; with "inline" or "display" classes depending on context.
|
||||
; - note this is different from the built-in math support in our markdown parser which uses <code>
|
||||
ELEMENT = span
|
||||
ALLOW_ATTR = class
|
||||
REGEXP = ^\s*((math(\s+|$)|inline(\s+|$)|display(\s+|$)))+
|
||||
|
||||
[markup.markdown]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .md,.markdown
|
||||
RENDER_COMMAND = pandoc -f markdown -t html --katex
|
||||
```
|
||||
|
||||
You must define `ELEMENT` and `ALLOW_ATTR` in each section.
|
||||
|
||||
To define multiple entries, add a unique alphanumeric suffix (e.g., `[markup.sanitizer.1]` and `[markup.sanitizer.something]`).
|
||||
|
||||
To apply a sanitisation rules only for a specify external renderer they must use the renderer name, e.g. `[markup.sanitizer.asciidoc.rule-1]`, `[markup.sanitizer.<renderer>.rule-1]`.
|
||||
|
||||
**Note**: If the rule is defined above the renderer ini section or the name does not match a renderer it is applied to every renderer.
|
||||
|
||||
Once your configuration changes have been made, restart Gitea to have changes take effect.
|
||||
|
||||
**Note**: Prior to Gitea 1.12 there was a single `markup.sanitiser` section with keys that were redefined for multiple rules, however,
|
||||
there were significant problems with this method of configuration necessitating configuration through multiple sections.
|
||||
|
||||
### Example: HTML
|
||||
|
||||
Render HTML files directly:
|
||||
|
||||
```ini
|
||||
[markup.html]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .html,.htm
|
||||
RENDER_COMMAND = cat
|
||||
; Input is not a standard input but a file
|
||||
IS_INPUT_FILE = true
|
||||
|
||||
[markup.sanitizer.html.1]
|
||||
ELEMENT = div
|
||||
ALLOW_ATTR = class
|
||||
|
||||
[markup.sanitizer.html.2]
|
||||
ELEMENT = a
|
||||
ALLOW_ATTR = class
|
||||
```
|
||||
|
||||
### Example: Office DOCX
|
||||
|
||||
Display Office DOCX files with [`pandoc`](https://pandoc.org/):
|
||||
|
||||
```ini
|
||||
[markup.docx]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .docx
|
||||
RENDER_COMMAND = "pandoc --from docx --to html --self-contained --template /path/to/basic.html"
|
||||
|
||||
[markup.sanitizer.docx.img]
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
The template file has the following content:
|
||||
|
||||
```
|
||||
$body$
|
||||
```
|
||||
|
||||
### Example: Jupyter Notebook
|
||||
|
||||
Display Jupyter Notebook files with [`nbconvert`](https://github.com/jupyter/nbconvert):
|
||||
|
||||
```ini
|
||||
[markup.jupyter]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .ipynb
|
||||
RENDER_COMMAND = "jupyter-nbconvert --stdin --stdout --to html --template basic"
|
||||
|
||||
[markup.sanitizer.jupyter.img]
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
## Customizing CSS
|
||||
|
||||
The external renderer is specified in the .ini in the format `[markup.XXXXX]` and the HTML supplied by your external renderer will be wrapped in a `<div>` with classes `markup` and `XXXXX`. The `markup` class provides out of the box styling (as does `markdown` if `XXXXX` is `markdown`). Otherwise you can use these classes to specifically target the contents of your rendered HTML.
|
||||
|
||||
And so you could write some CSS:
|
||||
|
||||
```css
|
||||
.markup.XXXXX html {
|
||||
font-size: 100%;
|
||||
overflow-y: scroll;
|
||||
-webkit-text-size-adjust: 100%;
|
||||
-ms-text-size-adjust: 100%;
|
||||
}
|
||||
|
||||
.markup.XXXXX body {
|
||||
color: #444;
|
||||
font-family: Georgia, Palatino, "Palatino Linotype", Times, "Times New Roman",
|
||||
serif;
|
||||
font-size: 12px;
|
||||
line-height: 1.7;
|
||||
padding: 1em;
|
||||
margin: auto;
|
||||
max-width: 42em;
|
||||
background: #fefefe;
|
||||
}
|
||||
|
||||
.markup.XXXXX p {
|
||||
color: orangered;
|
||||
}
|
||||
```
|
||||
|
||||
Add your stylesheet to your custom directory e.g `custom/public/assets/css/my-style-XXXXX.css` and import it using a custom header file `custom/templates/custom/header.tmpl`:
|
||||
|
||||
```html
|
||||
<link rel="stylesheet" href="{{AppSubUrl}}/assets/css/my-style-XXXXX.css" />
|
||||
```
|
||||
+118
@@ -0,0 +1,118 @@
|
||||
---
|
||||
date: "2018-05-11T11:00:00+02:00"
|
||||
slug: "fail2ban-setup"
|
||||
sidebar_position: 16
|
||||
aliases:
|
||||
- /zh-tw/fail2ban-setup
|
||||
---
|
||||
|
||||
# Fail2ban Setup
|
||||
|
||||
**Remember that fail2ban is powerful and can cause lots of issues if you do it incorrectly, so make
|
||||
sure to test this before relying on it so you don't lock yourself out.**
|
||||
|
||||
Gitea returns an HTTP 200 for bad logins in the web logs, but if you have logging options on in
|
||||
`app.ini`, then you should be able to go off of `log/gitea.log`, which gives you something like this
|
||||
on a bad authentication from the web or CLI using SSH or HTTP respectively:
|
||||
|
||||
```log
|
||||
2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:143:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:155:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:198:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:213:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:227:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:249:sshConnectionFailed() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(From 1.15 this new message will available and doesn't have any of the false positive results that above messages from publicKeyHandler do. This will only be logged if the user has completely failed authentication.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:08:44 ...s/context/context.go:204:HandleText() [E] invalid credentials from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
Add our filter in `/etc/fail2ban/filter.d/gitea.local`:
|
||||
|
||||
```ini
|
||||
# gitea.local
|
||||
[Definition]
|
||||
failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST>
|
||||
ignoreregex =
|
||||
```
|
||||
|
||||
Add our jail in `/etc/fail2ban/jail.d/gitea.local`:
|
||||
|
||||
```ini
|
||||
[gitea]
|
||||
enabled = true
|
||||
filter = gitea
|
||||
logpath = /var/lib/gitea/log/gitea.log
|
||||
maxretry = 10
|
||||
findtime = 3600
|
||||
bantime = 900
|
||||
action = iptables-allports
|
||||
```
|
||||
|
||||
If you're using Docker, you'll also need to add an additional jail to handle the **FORWARD**
|
||||
chain in **iptables**. Configure it in `/etc/fail2ban/jail.d/gitea-docker.local`:
|
||||
|
||||
```ini
|
||||
[gitea-docker]
|
||||
enabled = true
|
||||
filter = gitea
|
||||
logpath = /var/lib/gitea/log/gitea.log
|
||||
maxretry = 10
|
||||
findtime = 3600
|
||||
bantime = 900
|
||||
action = iptables-allports[chain="FORWARD"]
|
||||
```
|
||||
|
||||
Then simply run `service fail2ban restart` to apply your changes. You can check to see if
|
||||
fail2ban has accepted your configuration using `service fail2ban status`.
|
||||
|
||||
Make sure and read up on fail2ban and configure it to your needs, this bans someone
|
||||
for **15 minutes** (from all ports) when they fail authentication 10 times in an hour.
|
||||
|
||||
If you run Gitea behind a reverse proxy with Nginx (for example with Docker), you need to add
|
||||
this to your Nginx configuration so that IPs don't show up as 127.0.0.1:
|
||||
|
||||
```
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
```
|
||||
|
||||
The security options in `app.ini` need to be adjusted to allow the interpretation of the headers
|
||||
as well as the list of IP addresses and networks that describe trusted proxy servers
|
||||
(See the [configuration cheat sheet](../administration/config-cheat-sheet.md#security-security) for more information).
|
||||
|
||||
```
|
||||
REVERSE_PROXY_LIMIT = 1
|
||||
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.1/8 ; 172.17.0.0/16 for the docker default network
|
||||
```
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
---
|
||||
date: "2019-10-06T08:00:00+05:00"
|
||||
slug: "git-lfs-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-tw/git-lfs-setup
|
||||
---
|
||||
|
||||
# Git LFS 設置
|
||||
|
||||
要使用 Gitea 的內置 LFS 支持，您必須更新 `app.ini` 文件：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
; 啟用 git-lfs 支持。true 或 false，默認為 false。
|
||||
LFS_START_SERVER = true
|
||||
|
||||
[lfs]
|
||||
; 您的 lfs 文件所在的位置，默認為 data/lfs。
|
||||
PATH = /home/gitea/data/lfs
|
||||
```
|
||||
|
||||
:::note
|
||||
LFS 服務器支持需要在服務器上安裝至少 Git v2.1.2
|
||||
:::
|
||||
|
||||
# Git LFS 純 SSH 協議
|
||||
|
||||
LFS 純 SSH 協議支持純粹通過 SSH 進行 LFS 連接
|
||||
（無需為 Gitea 服務器公開 HTTP 端點）。
|
||||
可以通過配置選項 `server.LFS_ALLOW_PURE_SSH` 啟用對它的支持：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
LFS_ALLOW_PURE_SSH = true
|
||||
```
|
||||
|
||||
:::note
|
||||
由於 `git-lfs` 客戶端中存在一個未解決的錯誤，該選項目前默認設置為 false，該錯誤會導致 SSH 傳輸掛起：https://github.com/git-lfs/git-lfs/pull/5816
|
||||
可以通過在所有客戶端機器上設置 git 配置來解決此問題：
|
||||
`git config --global lfs.ssh.automultiplex false`
|
||||
:::
|
||||
+93
@@ -0,0 +1,93 @@
|
||||
---
|
||||
date: "2018-06-02T11:00:00+02:00"
|
||||
slug: "https-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-tw/https-setup
|
||||
---
|
||||
|
||||
# HTTPS 設置
|
||||
|
||||
## 使用內置服務器
|
||||
|
||||
在啟用 HTTPS 之前，請確保您擁有有效的 SSL/TLS 證書。
|
||||
您可以使用自生成的證書進行評估和測試。請運行 `gitea cert --host [HOST]` 生成自簽名證書。
|
||||
|
||||
如果您在服務器上使用 Apache 或 nginx，建議查看 [反向代理指南](./reverse-proxies.md)。
|
||||
|
||||
要使用 Gitea 的內置 HTTPS 支持，您必須更改 `app.ini` 文件：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL = https
|
||||
ROOT_URL = https://git.example.com:3000/
|
||||
HTTP_PORT = 3000
|
||||
CERT_FILE = cert.pem
|
||||
KEY_FILE = key.pem
|
||||
```
|
||||
|
||||
請注意，如果您的證書是由第三方證書機構簽署的（即不是自簽名的），則 cert.pem 應包含證書鏈。服務器證書必須是 cert.pem 中的第一個條目，後面依次是中間證書（如果有）。根證書不必包含在內，因為連接的客戶端必須已經擁有它以建立信任關係。
|
||||
要了解更多有關配置值的信息，請查看 [配置備忘單](./config-cheat-sheet.md#server-server)。
|
||||
|
||||
對於 `CERT_FILE` 或 `KEY_FILE` 字段，文件路徑在相對路徑時相對於 `GITEA_CUSTOM` 環境變量。它也可以是絕對路徑。
|
||||
|
||||
### 設置 HTTP 重定向
|
||||
|
||||
Gitea 服務器只能監聽一個端口；要將 HTTP 請求重定向到 HTTPS 端口，您需要啟用 HTTP 重定向服務：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
REDIRECT_OTHER_PORT = true
|
||||
; 重定向服務應監聽的端口
|
||||
PORT_TO_REDIRECT = 3080
|
||||
```
|
||||
|
||||
如果您使用 Docker，請確保在 `docker-compose.yml` 文件中配置了此端口。
|
||||
|
||||
## 使用 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)）。
|
||||
|
||||
使用默認 Let's Encrypt 的最小設置：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL=https
|
||||
DOMAIN=git.example.com
|
||||
ENABLE_ACME=true
|
||||
ACME_ACCEPTTOS=true
|
||||
ACME_DIRECTORY=https
|
||||
;; 電子郵件可以在此處省略，並在首次運行時手動提供，之後將被緩存
|
||||
ACME_EMAIL=email@example.com
|
||||
```
|
||||
|
||||
使用 [smallstep CA](https://github.com/smallstep/certificates) 的最小設置，請參閱 [他們的教程](https://smallstep.com/docs/tutorials/acme-challenge) 以獲取更多信息。
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL=https
|
||||
DOMAIN=git.example.com
|
||||
ENABLE_ACME=true
|
||||
ACME_ACCEPTTOS=true
|
||||
ACME_URL=https://ca.example.com/acme/acme/directory
|
||||
;; 如果使用系統的信任，則可以省略
|
||||
;ACME_CA_ROOT=/path/to/root_ca.crt
|
||||
ACME_DIRECTORY=https
|
||||
ACME_EMAIL=email@example.com
|
||||
```
|
||||
|
||||
要了解更多有關配置值的信息，請查看 [配置備忘單](./config-cheat-sheet.md#server-server)。
|
||||
|
||||
## 使用反向代理
|
||||
|
||||
按照 [反向代理指南](../administration/reverse-proxies.md) 設置您的反向代理。
|
||||
|
||||
之後，按照以下指南之一啟用 HTTPS：
|
||||
|
||||
- [nginx](https://nginx.org/en/docs/http/configuring_https_servers.html)
|
||||
- [apache2/httpd](https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html)
|
||||
- [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 轉發連接。
|
||||
:::
|
||||
+263
@@ -0,0 +1,263 @@
|
||||
---
|
||||
date: "2019-04-02T17:06:00+01:00"
|
||||
slug: "logging-config"
|
||||
sidebar_position: 40
|
||||
aliases:
|
||||
- /zh-tw/logging-configuration
|
||||
---
|
||||
|
||||
# 日誌配置
|
||||
|
||||
Gitea 的日誌配置主要包括 3 種組件：
|
||||
|
||||
- `[log]` 部分用於一般配置
|
||||
- `[log.<mode-name>]` 部分用於配置不同的日誌寫入器以輸出日誌，即：“寫入模式”，模式名稱也用作“寫入器名稱”。
|
||||
- `[log]` 部分還可以包含子日誌記錄器配置，遵循鍵模式 `logger.<logger-name>.<CONFIG-KEY>`
|
||||
|
||||
默認情況下有一個功能齊全的日誌輸出，因此不需要定義一個。
|
||||
|
||||
## 收集日誌以獲取幫助
|
||||
|
||||
要收集日誌以獲取幫助和問題報告，請參閱 [支持選項](help/support.md)。
|
||||
|
||||
## `[log]` 部分
|
||||
|
||||
Gitea 中的日誌設施配置發生在 `[log]` 部分及其子部分中。
|
||||
|
||||
在頂級 `[log]` 部分中可以放置以下配置：
|
||||
|
||||
- `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 日誌記錄器的日誌輸出列表。
|
||||
|
||||
將逗號（`,`）設置為子日誌記錄器的模式意味著使其使用默認的全局 `MODE`。
|
||||
|
||||
## 快速示例
|
||||
|
||||
### 默認（空）配置
|
||||
|
||||
空配置等同於默認：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
ROOT_PATH = %(GITEA_WORK_DIR)/log
|
||||
MODE = console
|
||||
LEVEL = Info
|
||||
STACKTRACE_LEVEL = None
|
||||
logger.router.MODE = ,
|
||||
logger.xorm.MODE = ,
|
||||
logger.access.MODE =
|
||||
|
||||
; 這是“console”模式的配置選項（上面由 MODE=console 使用）
|
||||
[log.console]
|
||||
MODE = console
|
||||
FLAGS = stdflags
|
||||
PREFIX =
|
||||
COLORIZE = true
|
||||
```
|
||||
|
||||
這等同於將所有日誌發送到控制台，默認的 Golang 日誌也發送到控制台日誌。
|
||||
|
||||
這只是示例，這是默認值，不需要將其寫入配置文件中。
|
||||
|
||||
### 禁用路由器日誌並將一些訪問日誌記錄到文件中
|
||||
|
||||
禁用路由器日誌記錄器，訪問日誌（>=Warn）進入 `access.log`：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
logger.router.MODE =
|
||||
logger.access.MODE = access-file
|
||||
|
||||
[log.access-file]
|
||||
MODE = file
|
||||
LEVEL = Warn
|
||||
FILE_NAME = access.log
|
||||
```
|
||||
|
||||
### 為不同模式設置不同的日誌級別
|
||||
|
||||
默認日誌（>=Warn）進入 `gitea.log`，而錯誤日誌進入 `file-error.log`：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
LEVEL = Warn
|
||||
MODE = file, file-error
|
||||
|
||||
; 默認情況下，“file”模式將記錄日誌到 %(log.ROOT_PATH)/gitea.log，因此我們不需要設置它
|
||||
; [log.file]
|
||||
; 默認情況下，MODE（實際上是此日誌記錄器的輸出寫入器）取自部分名稱，因此我們也不需要設置它
|
||||
; MODE = file
|
||||
|
||||
[log.file-error]
|
||||
MODE = file
|
||||
LEVEL = Error
|
||||
FILE_NAME = file-error.log
|
||||
```
|
||||
|
||||
## 日誌輸出（模式和寫入器）
|
||||
|
||||
Gitea 提供以下日誌輸出寫入器：
|
||||
|
||||
- `console` - 日誌記錄到 `stdout`（或如果在配置中設置，則記錄到 `stderr`）
|
||||
- `file` - 日誌記錄到文件
|
||||
- `conn` - 日誌記錄到套接字（網絡或 unix）
|
||||
|
||||
### 通用配置
|
||||
|
||||
某些配置對所有日誌輸出模式都是通用的：
|
||||
|
||||
- `MODE` 是日誌輸出寫入器的模式。它將默認為 ini 部分中的模式名稱。因此 `[log.console]` 將默認為 `MODE = console`。
|
||||
- `LEVEL` 是此輸出的最低級別。
|
||||
- `STACKTRACE_LEVEL` 是此輸出將打印堆棧跟蹤的最低級別。
|
||||
- `COLORIZE` 將默認為 `true`，如描述的那樣，否則將默認為 `false`。
|
||||
|
||||
#### `EXPRESSION`
|
||||
|
||||
`EXPRESSION` 代表日誌事件必須匹配的正則表達式，以便由輸出寫入器記錄。
|
||||
日誌消息（去除顏色）必須匹配，或者 `longfilename:linenumber:functionname` 必須匹配。
|
||||
注意：整個消息或字符串不需要完全匹配。
|
||||
|
||||
請注意，此表達式將在寫入器的 goroutine 中運行，但不在日誌事件 goroutine 中運行。
|
||||
|
||||
#### `FLAGS`
|
||||
|
||||
`FLAGS` 代表在每條消息之前打印的前置日誌上下文信息。它是一個逗號分隔的字符串集。值的順序無關緊要。
|
||||
|
||||
默認為 `stdflags`（= `date,time,medfile,shortfuncname,levelinitial`）
|
||||
|
||||
可能的值是：
|
||||
|
||||
- `none` 或 `,` - 無標誌。
|
||||
- `date` - 當地時區的日期：`2009/01/23`。
|
||||
- `time` - 當地時區的時間：`01:23:23`。
|
||||
- `microseconds` - 微秒分辨率：`01:23:23.123123`。假設時間。
|
||||
- `longfile` - 完整文件名和行號：`/a/b/c/d.go:23`。
|
||||
- `shortfile` - 最後的文件名元素和行號：`d.go:23`。
|
||||
- `funcname` - 調用者的函數名稱：`runtime.Caller()`。
|
||||
- `shortfuncname` - 函數名稱的最後部分。覆蓋 `funcname`。
|
||||
- `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`。
|
||||
|
||||
設置：
|
||||
|
||||
- `STDERR`：**false**：日誌記錄器是否應打印到 `stderr` 而不是 `stdout`。
|
||||
|
||||
### 文件模式
|
||||
|
||||
在此模式下，日誌記錄器將日誌消息保存到文件中。
|
||||
|
||||
設置：
|
||||
|
||||
- `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**：壓縮級別。詳細信息請參見下文。
|
||||
|
||||
`MAX_SIZE_SHIFT` 定義了文件的最大大小，通過左移 1 給定的次數（`1 << x`）。
|
||||
v1.17.3 時的確切行為可以在 [這裡](https://github.com/go-gitea/gitea/blob/v1.17.3/modules/setting/log.go#L185) 看到。
|
||||
|
||||
`COMPRESSION_LEVEL` 的有用值從 1（最佳速度）到 9（最佳壓縮）。也可以選擇 [DefaultCompression](https://pkg.go.dev/compress/gzip#pkg-constants)（-1）和 [HuffmanOnly](https://pkg.go.dev/compress/flate#HuffmanOnly)（-2）。
|
||||
請注意，更好的壓縮可能會帶來更高的資源使用。
|
||||
|
||||
### 連接模式
|
||||
|
||||
在此模式下，日誌記錄器將通過網絡套接字發送日誌消息。
|
||||
|
||||
設置：
|
||||
|
||||
- `ADDR`：**:7020**：設置要連接的地址。
|
||||
- `PROTOCOL`：**tcp**：設置協議，可以是“tcp”、“unix”或“udp”。
|
||||
- `RECONNECT`：**false**：連接丟失時嘗試重新連接。
|
||||
- `RECONNECT_ON_MSG`：**false**：為每條消息重新連接主機。
|
||||
|
||||
### “路由器”日誌記錄器
|
||||
|
||||
當 Gitea 的路由處理程序工作時，路由器日誌記錄器記錄以下消息類型：
|
||||
|
||||
- `started` 消息將在 TRACE 級別記錄
|
||||
- `polling`/`completed` 路由將在 INFO 級別記錄。例外：“/assets” 靜態資源請求也在 TRACE 級別記錄。
|
||||
- `slow` 路由將在 WARN 級別記錄
|
||||
- `failed` 路由將在 WARN 級別記錄
|
||||
|
||||
### “XORM”日誌記錄器
|
||||
|
||||
要使 XORM 輸出 SQL 日誌，應在 `[database]` 部分中將 `LOG_SQL` 設置為 `true`。
|
||||
|
||||
### “訪問”日誌記錄器
|
||||
|
||||
訪問日誌記錄器是 Gitea 1.9 以來的新日誌記錄器。它提供了符合 NCSA 通用日誌格式的日誌格式。它高度可配置，但更改其模板時應謹慎。此日誌記錄器的主要好處是 Gitea 現在可以以標準日誌格式記錄訪問，因此可以使用標準工具。
|
||||
|
||||
您可以使用 `logger.access.MODE = ...` 啟用此日誌記錄器。
|
||||
|
||||
如果需要，可以通過更改 `ACCESS_LOG_TEMPLATE` 的值來更改訪問日誌記錄器的格式。
|
||||
|
||||
請注意，訪問日誌記錄器將在 `INFO` 級別記錄，將此日誌記錄器的 `LEVEL` 設置為 `WARN` 或更高將導致沒有訪問日誌。
|
||||
|
||||
#### ACCESS_LOG_TEMPLATE
|
||||
|
||||
此值代表一個 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}}"`
|
||||
```
|
||||
|
||||
模板傳遞以下選項：
|
||||
|
||||
- `Ctx` 是 `context.Context`
|
||||
- `Identity` 是 `SignedUserName` 或 `"-"` 如果用戶未登錄
|
||||
- `Start` 是請求的開始時間
|
||||
- `ResponseWriter` 是 `http.ResponseWriter`
|
||||
|
||||
更改此模板時必須謹慎，因為它在標準的恐慌恢復陷阱之外運行。模板應該盡可能簡單，因為它在每個請求中運行。
|
||||
|
||||
## 釋放和重新打開、暫停和恢復日誌記錄
|
||||
|
||||
如果您在 Unix 上運行，您可能希望釋放和重新打開日誌以使用 `logrotate` 或其他工具。
|
||||
可以通過向運行的進程發送 `SIGUSR1`，或運行 `gitea manager logging release-and-reopen` 強制 Gitea 釋放並重新打開其日誌文件和連接。
|
||||
|
||||
或者，您可能希望暫停和恢復日誌記錄 - 這可以通過使用 `gitea manager logging pause` 和 `gitea manager logging resume` 命令來完成。請注意，暫停日誌記錄時，INFO 級別以下的日誌事件將不會存儲，僅存儲有限數量的事件。日誌記錄可能會暫時阻塞，暫停時會顯著減慢 Gitea 的速度 - 因此建議僅在非常短的時間內暫停。
|
||||
|
||||
## 在 Gitea 運行時添加和刪除日誌記錄
|
||||
|
||||
可以使用 `gitea manager logging add` 和 `remove` 子命令在 Gitea 運行時添加和刪除日誌記錄。
|
||||
此功能只能調整運行中的日誌系統，無法用於啟動訪問或路由器日誌記錄器，如果它們尚未初始化。如果您希望啟動這些系統，建議調整 app.ini 並（優雅地）重新啟動 Gitea 服務。
|
||||
|
||||
這些命令的主要目的是在運行系統上輕鬆添加臨時日誌記錄器，以調查問題，重新啟動可能會導致問題消失。
|
||||
|
||||
## 使用 `logrotate` 而不是內置日誌輪換
|
||||
|
||||
Gitea 包含內置日誌輪換，這應該足以滿足大多數部署需求。但是，如果您希望使用 `logrotate` 實用程序：
|
||||
|
||||
- 通過在 `app.ini` 中將 `LOG_ROTATE` 設置為 `false` 禁用內置日誌輪換。
|
||||
- 安裝 `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` 測試您的配置。
|
||||
- 如果您使用 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 /etc/logrotate.conf --force` 立即重新加載 `logrotate`。
|
||||
+252
@@ -0,0 +1,252 @@
|
||||
---
|
||||
date: "2019-10-23T17:00:00-03:00"
|
||||
slug: "mail-templates"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-tw/mail-templates
|
||||
---
|
||||
|
||||
# 郵件模板
|
||||
|
||||
為了製作某些操作的電子郵件主題和內容，Gitea 可以使用模板進行自定義。這些功能的模板位於 [`custom` 目錄](../administration/customizing-gitea.md)下。
|
||||
Gitea 有一個內部模板，作為默認值，如果沒有自定義替代品。
|
||||
|
||||
自定義模板在 Gitea 啟動時加載。對它們的更改在 Gitea 再次重啟之前不會被識別。
|
||||
|
||||
## 支持模板的郵件通知
|
||||
|
||||
目前，以下通知事件使用模板：
|
||||
|
||||
| 操作名稱 | 用途 |
|
||||
| ---------- | ---------------------------------------------------------- |
|
||||
| `new` | 創建了一個新問題或拉取請求。 |
|
||||
| `comment` | 在現有問題或拉取請求中創建了一個新評論。 |
|
||||
| `close` | 關閉了一個問題或拉取請求。 |
|
||||
| `reopen` | 重新打開了一個問題或拉取請求。 |
|
||||
| `review` | 拉取請求中的審查的主要評論。 |
|
||||
| `approve` | 拉取請求的批准審查的主要評論。 |
|
||||
| `reject` | 拉取請求的變更請求審查的主要評論。 |
|
||||
| `code` | 拉取請求中的代碼單一評論。 |
|
||||
| `assigned` | 用戶被分配到一個問題或拉取請求。 |
|
||||
| `default` | 任何不包括在上述類別中的操作，或當對應的類別模板不存在時。 |
|
||||
|
||||
特定消息類型的模板路徑為：
|
||||
|
||||
```sh
|
||||
custom/templates/mail/{action type}/{action name}.tmpl
|
||||
```
|
||||
|
||||
其中 `{action type}` 是 `issue` 或 `pull`（對於拉取請求）之一，`{action name}` 是上面列出的名稱之一。
|
||||
|
||||
例如，有關拉取請求評論的郵件的特定模板為：
|
||||
|
||||
```sh
|
||||
custom/templates/mail/pull/comment.tmpl
|
||||
```
|
||||
|
||||
但是，不需要為每個操作類型/名稱組合創建模板。
|
||||
使用回退系統來選擇事件的適當模板。使用此列表中的 _第一個存在的_ 模板：
|
||||
|
||||
- 所需 **操作類型** 和 **操作名稱** 的特定模板。
|
||||
- 操作類型 `issue` 和所需 **操作名稱** 的模板。
|
||||
- 操作類型 `issue` 和操作名稱 `default` 的模板。
|
||||
|
||||
唯一必需的模板是操作類型 `issue` 和操作名稱 `default`，它已嵌入 Gitea 中，除非用戶在 `custom` 目錄中覆蓋它。
|
||||
|
||||
## 模板語法
|
||||
|
||||
郵件模板是 UTF-8 編碼的文本文件，需要遵循以下格式之一：
|
||||
|
||||
```
|
||||
主題行的文本和宏
|
||||
------------
|
||||
郵件正文的文本和宏
|
||||
```
|
||||
|
||||
或
|
||||
|
||||
```
|
||||
郵件正文的文本和宏
|
||||
```
|
||||
|
||||
指定 _主題_ 部分是可選的（因此也是破折號分隔符）。使用時，_主題_ 和 _郵件正文_ 模板之間的分隔符需要至少三個破折號；分隔符行中不允許其他字符。
|
||||
|
||||
_主題_ 和 _郵件正文_ 由 [Golang 的模板引擎](https://go.dev/pkg/text/template/) 解析，
|
||||
並為每個通知提供一個 _元數據上下文_。上下文包含以下元素：
|
||||
|
||||
| 名稱 | 類型 | 可用性 | 用途 |
|
||||
| ------------------ | ---------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `.FallbackSubject` | string | 總是 | 默認主題行。見下文。 |
|
||||
| `.Subject` | string | 僅在正文中 | 解析後的 _主題_。 |
|
||||
| `.Body` | string | 總是 | 問題、拉取請求或評論的消息，從 Markdown 解析為 HTML 並進行了清理。不要與 _郵件正文_ 混淆。 |
|
||||
| `.Link` | string | 總是 | 發起問題、拉取請求或評論的地址。 |
|
||||
| `.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: `；否則為空字符串。 |
|
||||
| `.ActionType` | string | 總是 | `"issue"` 或 `"pull"`。將對應於實際的 _操作類型_，無論選擇了哪個模板。 |
|
||||
| `.ActionName` | string | 總是 | 它將是上述操作類型之一（`new`、`comment` 等），並將對應於實際的 _操作名稱_，無論選擇了哪個模板。 |
|
||||
| `.ReviewComments` | []models.Comment | 總是 | 審查中的代碼評論列表。評論文本將在 `.RenderedContent` 中，引用的代碼將在 `.Patch` 中。 |
|
||||
|
||||
所有名稱都是區分大小寫的。
|
||||
|
||||
### 模板的 _主題_ 部分
|
||||
|
||||
郵件 _主題_ 使用的模板引擎是 golang 的 [`text/template`](https://go.dev/pkg/text/template/)。
|
||||
請參閱鏈接的文檔以了解其語法的詳細信息。
|
||||
|
||||
主題的構建步驟如下：
|
||||
|
||||
- 根據通知類型和存在的模板選擇模板。
|
||||
- 解析並解析模板（例如 `{{.Issue.Index}}` 轉換為問題或拉取請求的編號）。
|
||||
- 所有空格字符（例如 `TAB`、`LF` 等）轉換為普通空格。
|
||||
- 刪除所有前導、尾隨和冗餘空格。
|
||||
- 字符串被截斷為其前 256 個符文（字符）。
|
||||
|
||||
如果最終結果是空字符串，**或** 沒有可用的主題模板（即選擇的模板不包括主題部分），將使用 Gitea 的 **內部默認值**。
|
||||
|
||||
內部默認（回退）主題相當於：
|
||||
|
||||
```sh
|
||||
{{.SubjectPrefix}}[{{.Repo}}] {{.Issue.Title}} (#{{.Issue.Index}})
|
||||
```
|
||||
|
||||
例如：`Re: [mike/stuff] New color palette (#38)`
|
||||
|
||||
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)，應該考慮到。
|
||||
|
||||
不支持附件（如圖像或外部樣式表）。但是，也可以引用其他模板，例如提供 `<style>` 元素的內容。外部模板必須放置在 `custom/mail` 下，並相對於該目錄引用。例如，`custom/mail/styles/base.tmpl` 可以使用 `{{template styles/base}}` 包含。
|
||||
|
||||
郵件以 `Content-Type: multipart/alternative` 發送，因此正文以 HTML 和文本格式發送。後者通過剝離 HTML 標記獲得。
|
||||
|
||||
## 故障排除
|
||||
|
||||
郵件的渲染方式直接取決於郵件應用程序的功能。許多郵件客戶端甚至不支持 HTML，因此它們顯示生成的郵件中包含的文本版本。
|
||||
|
||||
如果模板渲染失敗，只有在郵件發送時才會注意到。
|
||||
如果主題模板失敗，將使用默認主題，並且無論渲染成功的部分如何，都將使用 _郵件正文_。
|
||||
|
||||
如果有問題，請檢查 [Gitea 的日誌](../administration/logging-config.md) 以獲取錯誤消息。
|
||||
|
||||
## 示例
|
||||
|
||||
`custom/templates/mail/issue/default.tmpl`：
|
||||
|
||||
```html
|
||||
[{{.Repo}}] @{{.Doer.Name}}
|
||||
{{if eq .ActionName "new"}}
|
||||
created
|
||||
{{else if eq .ActionName "comment"}}
|
||||
commented on
|
||||
{{else if eq .ActionName "close"}}
|
||||
closed
|
||||
{{else if eq .ActionName "reopen"}}
|
||||
reopened
|
||||
{{else}}
|
||||
updated
|
||||
{{end}}
|
||||
{{if eq .ActionType "issue"}}
|
||||
issue
|
||||
{{else}}
|
||||
pull request
|
||||
{{end}}
|
||||
#{{.Issue.Index}}: {{.Issue.Title}}
|
||||
------------
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<title>{{.Subject}}</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
{{if .IsMention}}
|
||||
<p>
|
||||
You are receiving this because @{{.Doer.Name}} mentioned you.
|
||||
</p>
|
||||
{{end}}
|
||||
<p>
|
||||
<p>
|
||||
<a href="{{AppUrl}}/{{.Doer.LowerName}}">@{{.Doer.Name}}</a>
|
||||
{{if not (eq .Doer.FullName "")}}
|
||||
({{.Doer.FullName}})
|
||||
{{end}}
|
||||
{{if eq .ActionName "new"}}
|
||||
created
|
||||
{{else if eq .ActionName "close"}}
|
||||
closed
|
||||
{{else if eq .ActionName "reopen"}}
|
||||
reopened
|
||||
{{else}}
|
||||
updated
|
||||
{{end}}
|
||||
<a href="{{.Link}}">{{.Repo}}#{{.Issue.Index}}</a>.
|
||||
</p>
|
||||
{{if not (eq .Body "")}}
|
||||
<h3>Message content</h3>
|
||||
<hr>
|
||||
{{.Body}}
|
||||
{{end}}
|
||||
</p>
|
||||
<hr>
|
||||
<p>
|
||||
<a href="{{.Link}}">View it on Gitea</a>.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
此模板生成如下內容：
|
||||
|
||||
### 主題
|
||||
|
||||
> [mike/stuff] @rhonda commented on pull request #38: New color palette
|
||||
|
||||
### 郵件正文
|
||||
|
||||
> [@rhonda](#) (Rhonda Myers) updated [mike/stuff#38](#).
|
||||
>
|
||||
> #### Message content
|
||||
>
|
||||
> \_******\*\*******\*\*\*\*******\*\*******\_******\*\*******\*\*\*\*******\*\*******
|
||||
>
|
||||
> Mike, I think we should tone down the blues a little.
|
||||
> \_******\*\*******\*\*\*\*******\*\*******\_******\*\*******\*\*\*\*******\*\*******
|
||||
>
|
||||
> [View it on Gitea](#).
|
||||
|
||||
## 高級
|
||||
|
||||
模板系統包含幾個函數，可用於進一步處理和格式化消息。以下是其中一些的列表：
|
||||
|
||||
| 名稱 | 參數 | 可用性 | 用途 |
|
||||
| ---------------- | ----------- | ------ | ------------------------------------------- |
|
||||
| `AppUrl` | - | 任何 | Gitea 的 URL |
|
||||
| `AppName` | - | 任何 | 從 `app.ini` 設置，通常為 "Gitea" |
|
||||
| `AppDomain` | - | 任何 | Gitea 的主機名 |
|
||||
| `EllipsisString` | string, int | 任何 | 將字符串截斷為指定長度；根據需要添加省略號 |
|
||||
| `SanitizeHTML` | string | 僅正文 | 通過刪除任何危險的 HTML 標籤來清理文本 |
|
||||
| `SafeHTML` | string | 僅正文 | 將輸入作為 HTML，可以用於輸出原始 HTML 內容 |
|
||||
|
||||
這些是 _函數_，而不是元數據，因此必須這樣使用：
|
||||
|
||||
```html
|
||||
像這樣：{{SanitizeHTML "Escape<my
|
||||
>text"}} 或這樣：{{ "Escape<my
|
||||
>text" | SanitizeHTML}} 或這樣：{{AppUrl}} 但不能這樣： {{.AppUrl}}</my
|
||||
></my
|
||||
>
|
||||
```
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
date: "2019-09-06T01:35:00-03:00"
|
||||
slug: "repo-indexer"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-tw/repo-indexer
|
||||
---
|
||||
|
||||
# 存儲庫索引器
|
||||
|
||||
## 無需索引器的內置存儲庫代碼搜索
|
||||
|
||||
用戶可以在不設置存儲庫索引器的情況下進行存儲庫級別的代碼搜索。
|
||||
內置代碼搜索基於 `git grep` 命令，對於小型存儲庫來說快速且高效。
|
||||
通過設置存儲庫索引器可以實現更好的代碼搜索支持。
|
||||
|
||||
## 設置存儲庫索引器
|
||||
|
||||
Gitea 可以通過在您的 [`app.ini`](../administration/config-cheat-sheet.md) 中啟用此功能來搜索存儲庫文件：
|
||||
|
||||
```ini
|
||||
[indexer]
|
||||
; ...
|
||||
REPO_INDEXER_ENABLED = true
|
||||
REPO_INDEXER_PATH = indexers/repos.bleve
|
||||
MAX_FILE_SIZE = 1048576
|
||||
REPO_INDEXER_INCLUDE =
|
||||
REPO_INDEXER_EXCLUDE = resources/bin/**
|
||||
```
|
||||
|
||||
請記住，索引內容可能會消耗大量系統資源，特別是在首次創建索引或全局更新索引時（例如在升級 Gitea 之後）。
|
||||
|
||||
### 通過大小選擇要索引的文件
|
||||
|
||||
`MAX_FILE_SIZE` 選項將使索引器跳過所有大於指定值的文件。
|
||||
|
||||
### 通過路徑選擇要索引的文件
|
||||
|
||||
Gitea 應用來自 [`gobwas/glob` 庫](https://github.com/gobwas/glob) 的 glob 模式匹配來選擇將包含在索引中的文件。
|
||||
|
||||
限制文件列表可以防止索引被派生或不相關的文件（例如 lss、sym、map 等）污染，因此搜索結果更相關。它還可以幫助減少索引大小。
|
||||
|
||||
`REPO_INDEXER_EXCLUDE_VENDORED`（默認：true）從索引中排除供應商文件。
|
||||
|
||||
`REPO_INDEXER_INCLUDE`（默認：空）是一個逗號分隔的 glob 模式列表，用於**包含**在索引中的文件。空列表表示“_包含所有文件_”。
|
||||
`REPO_INDEXER_EXCLUDE`（默認：空）是一個逗號分隔的 glob 模式列表，用於**排除**索引中的文件。匹配此列表的文件將不會被索引。`REPO_INDEXER_EXCLUDE` 優先於 `REPO_INDEXER_INCLUDE`。
|
||||
|
||||
模式匹配如下：
|
||||
|
||||
- 要匹配所有具有 `.txt` 擴展名的文件，無論在哪個目錄，請使用 `**.txt`。
|
||||
- 要僅匹配存儲庫根級別的所有 `.txt` 擴展名文件，請使用 `*.txt`。
|
||||
- 要匹配 `resources/bin` 及以下的所有文件，請使用 `resources/bin/**`。
|
||||
- 要匹配 `resources/bin` 中**立即**的所有文件，請使用 `resources/bin/*`。
|
||||
- 要匹配所有名為 `Makefile` 的文件，請使用 `**Makefile`。
|
||||
- 匹配目錄無效；模式 `resources/bin` 不會包含/排除該目錄中的文件；`resources/bin/**` 會。
|
||||
- 所有文件和模式都會標準化為小寫，因此 `**Makefile`、`**makefile` 和 `**MAKEFILE` 是等效的。
|
||||
+385
@@ -0,0 +1,385 @@
|
||||
---
|
||||
date: "2018-05-22T11:00:00+00:00"
|
||||
slug: "reverse-proxies"
|
||||
sidebar_position: 16
|
||||
aliases:
|
||||
- /zh-tw/reverse-proxies
|
||||
---
|
||||
|
||||
# 反向代理
|
||||
|
||||
## 一般配置
|
||||
|
||||
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-Fowarded-Proto` 標頭正確傳遞給 Gitea，以使 Gitea 看到實際訪問的 URL。
|
||||
|
||||
### 使用子路徑
|
||||
|
||||
通常**不建議**將 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`：
|
||||
- 使反向代理將 `https://common.example.com/v2` 傳遞到 `http://gitea:3000/v2`。
|
||||
- 確保 URI 和標頭也正確傳遞（請參閱上述的一般配置）。
|
||||
|
||||
## Nginx
|
||||
|
||||
如果您希望 Nginx 服務您的 Gitea 實例，請將以下 `server` 部分添加到 `nginx.conf` 的 `http` 部分中。
|
||||
|
||||
確保 `client_max_body_size` 足夠大，否則在上傳大文件時會出現“413 Request Entity Too Large”錯誤。
|
||||
|
||||
```nginx
|
||||
server {
|
||||
...
|
||||
location / {
|
||||
client_max_body_size 512M;
|
||||
proxy_pass http://localhost:3000;
|
||||
proxy_set_header Connection $http_connection;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Nginx 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，
|
||||
您可以通過將以下 `server` 部分添加到 `nginx.conf` 的 `http` 部分中來設置 Nginx 以在子路徑下服務 Gitea：
|
||||
|
||||
```nginx
|
||||
server {
|
||||
...
|
||||
location ~ ^/(gitea|v2)($|/) {
|
||||
client_max_body_size 512M;
|
||||
|
||||
# 使 nginx 使用未轉義的 URI，保持“%2F”不變，刪除“/gitea”子路徑前綴，保持“/v2”不變。
|
||||
rewrite ^ $request_uri;
|
||||
rewrite ^/(gitea($|/))?(.*) /$3 break;
|
||||
proxy_pass http://127.0.0.1:3000$uri;
|
||||
|
||||
# 其他常見的 HTTP 標頭，請參閱上面的“Nginx”配置部分
|
||||
proxy_set_header Connection $http_connection;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
然後您**必須**在配置中正確設置 `[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/` 目錄感興趣，因此您可以刪除其餘部分。
|
||||
（您需要安裝 [Node with npm](https://nodejs.org/en/download/) 和 `make` 來生成靜態資源）
|
||||
|
||||
根據您的用戶基數規模，您可能希望將流量分為兩個不同的服務器，
|
||||
或使用 cdn 來存儲靜態文件。
|
||||
|
||||
### 單節點和單域
|
||||
|
||||
在您的配置中設置 `[server] STATIC_URL_PREFIX = /_/static`。
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name git.example.com;
|
||||
|
||||
location /_/static/assets/ {
|
||||
alias /path/to/gitea/public/;
|
||||
}
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:3000;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 兩個節點和兩個域
|
||||
|
||||
在您的配置中設置 `[server] STATIC_URL_PREFIX = http://cdn.example.com/gitea`。
|
||||
|
||||
```nginx
|
||||
# 運行 Gitea 的應用服務器
|
||||
server {
|
||||
listen 80;
|
||||
server_name git.example.com;
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:3000;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```nginx
|
||||
# 靜態內容交付服務器
|
||||
server {
|
||||
listen 80;
|
||||
server_name cdn.example.com;
|
||||
|
||||
location /gitea/ {
|
||||
alias /path/to/gitea/public/;
|
||||
}
|
||||
|
||||
location / {
|
||||
return 404;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Apache HTTPD
|
||||
|
||||
如果您希望 Apache HTTPD 服務您的 Gitea 實例，您可以將以下內容添加到您的 Apache HTTPD 配置中（通常位於 Ubuntu 的 `/etc/apache2/httpd.conf`）：
|
||||
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
...
|
||||
ProxyPreserveHost On
|
||||
ProxyRequests off
|
||||
AllowEncodedSlashes NoDecode
|
||||
ProxyPass / http://localhost:3000/ nocanon
|
||||
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
:::note
|
||||
必須啟用以下 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：
|
||||
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
...
|
||||
<Proxy *>
|
||||
Order allow,deny
|
||||
Allow from all
|
||||
</Proxy>
|
||||
AllowEncodedSlashes NoDecode
|
||||
# 注意：在 /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/`。
|
||||
|
||||
:::note
|
||||
必須啟用以下 Apache HTTPD 模塊：`proxy`、`proxy_http`。
|
||||
:::
|
||||
|
||||
## Caddy
|
||||
|
||||
如果您希望 Caddy 服務您的 Gitea 實例，您可以將以下服務器塊添加到您的 Caddyfile 中：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
reverse_proxy localhost:3000
|
||||
}
|
||||
```
|
||||
|
||||
## Caddy 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 Caddyfile 中的服務器塊來設置 Caddy 以在子路徑下服務 Gitea：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
route /git/* {
|
||||
uri strip_prefix /git
|
||||
reverse_proxy localhost:3000
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
然後在您的配置中設置 `[server] ROOT_URL = http://git.example.com/git/`。
|
||||
|
||||
## IIS
|
||||
|
||||
如果您希望使用 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) 中的前兩步操作。即：
|
||||
|
||||
- 使用 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`
|
||||
- 現在編輯您的網站的 `web.config` 以匹配以下內容：（根據需要更改 `127.0.0.1:3000` 和 `git.example.com`）
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<configuration>
|
||||
<system.web>
|
||||
<httpRuntime requestPathInvalidCharacters="" />
|
||||
</system.web>
|
||||
<system.webServer>
|
||||
<security>
|
||||
<requestFiltering>
|
||||
<hiddenSegments>
|
||||
<clear />
|
||||
</hiddenSegments>
|
||||
<denyUrlSequences>
|
||||
<clear />
|
||||
</denyUrlSequences>
|
||||
<fileExtensions allowUnlisted="true">
|
||||
<clear />
|
||||
</fileExtensions>
|
||||
</requestFiltering>
|
||||
</security>
|
||||
<rewrite>
|
||||
<rules useOriginalURLEncoding="false">
|
||||
<rule name="ReverseProxyInboundRule1" stopProcessing="true">
|
||||
<match url="(.*)" />
|
||||
<action type="Rewrite" url="http://127.0.0.1:3000{UNENCODED_URL}" />
|
||||
<serverVariables>
|
||||
<set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="HTTP_ACCEPT_ENCODING" />
|
||||
<set name="HTTP_ACCEPT_ENCODING" value="" />
|
||||
</serverVariables>
|
||||
</rule>
|
||||
</rules>
|
||||
<outboundRules>
|
||||
<rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
|
||||
<!-- 在此處正確設置模式 - 如果您只想接受 http 或 https -->
|
||||
<!-- 根據需要更改模式和操作值 -->
|
||||
<match filterByTags="A, Form, Img" pattern="^http(s)?://127.0.0.1:3000/(.*)" />
|
||||
<action type="Rewrite" value="http{R:1}://git.example.com/{R:2}" />
|
||||
</rule>
|
||||
<rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
|
||||
<match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
|
||||
<action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
|
||||
</rule>
|
||||
<preConditions>
|
||||
<preCondition name="ResponseIsHtml1">
|
||||
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
|
||||
</preCondition>
|
||||
<preCondition name="NeedsRestoringAcceptEncoding">
|
||||
<add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
|
||||
</preCondition>
|
||||
</preConditions>
|
||||
</outboundRules>
|
||||
</rewrite>
|
||||
<urlCompression doDynamicCompression="true" />
|
||||
<handlers>
|
||||
<clear />
|
||||
<add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
|
||||
</handlers>
|
||||
<!-- 將所有擴展名映射到相同的 MIME 類型，以便可以下載所有文件。 -->
|
||||
<staticContent>
|
||||
<clear />
|
||||
<mimeMap fileExtension="*" mimeType="application/octet-stream" />
|
||||
</staticContent>
|
||||
</system.webServer>
|
||||
</configuration>
|
||||
```
|
||||
|
||||
## HAProxy
|
||||
|
||||
如果您希望 HAProxy 服務您的 Gitea 實例，您可以將以下內容添加到您的 HAProxy 配置中
|
||||
|
||||
在前端部分添加一個 acl 以將調用重定向到 gitea.example.com 到正確的後端
|
||||
|
||||
```
|
||||
frontend http-in
|
||||
...
|
||||
acl acl_gitea hdr(host) -i gitea.example.com
|
||||
use_backend gitea if acl_gitea
|
||||
...
|
||||
```
|
||||
|
||||
添加先前定義的後端部分
|
||||
|
||||
```
|
||||
backend gitea
|
||||
server localhost:3000 check
|
||||
```
|
||||
|
||||
如果您將 http 內容重定向到 https，配置方式相同，只需記住 HAProxy 和 Gitea 之間的連接將通過 http 完成，因此您不必在 Gitea 的配置中啟用 https。
|
||||
|
||||
## HAProxy 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 HAProxy 配置中來設置 HAProxy 以在子路徑下服務 Gitea：
|
||||
|
||||
```
|
||||
frontend http-in
|
||||
...
|
||||
acl acl_gitea path_beg /gitea
|
||||
use_backend gitea if acl_gitea
|
||||
...
|
||||
```
|
||||
|
||||
使用該配置 http://example.com/gitea/ 將重定向到您的 Gitea 實例。
|
||||
|
||||
然後為後端部分
|
||||
|
||||
```
|
||||
backend gitea
|
||||
http-request replace-path /gitea\/?(.*) \/\1
|
||||
server localhost:3000 check
|
||||
```
|
||||
|
||||
添加的 http-request 將自動添加尾隨斜杠（如果需要），並在內部刪除 /gitea 從路徑中刪除，以便通過正確設置 http://example.com/gitea 作為根來使其與 Gitea 正確工作。
|
||||
|
||||
然後您**必須**在配置中正確設置 `[server] ROOT_URL = http://example.com/gitea/`。
|
||||
|
||||
## Traefik
|
||||
|
||||
如果您希望 traefik 服務您的 Gitea 實例，您可以將以下標籤部分添加到您的 `docker-compose.yaml`（假設提供者是 docker）。
|
||||
|
||||
```yaml
|
||||
gitea:
|
||||
image: docker.io/gitea/gitea
|
||||
...
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.gitea.rule=Host(`example.com`)"
|
||||
- "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000"
|
||||
```
|
||||
|
||||
此配置假設您在 traefik 端處理 HTTPS，並在 Gitea 和 traefik 之間使用 HTTP。
|
||||
|
||||
## Traefik 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 `docker-compose.yaml`（假設提供者是 docker）來設置 Traefik 以在子路徑下服務 Gitea：
|
||||
|
||||
```yaml
|
||||
gitea:
|
||||
image: docker.io/gitea/gitea
|
||||
...
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.gitea.rule=Host(`example.com`) && PathPrefix(`/gitea`)"
|
||||
- "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000"
|
||||
- "traefik.http.middlewares.gitea-stripprefix.stripprefix.prefixes=/gitea"
|
||||
- "traefik.http.routers.gitea.middlewares=gitea-stripprefix"
|
||||
```
|
||||
|
||||
此配置假設您在 traefik
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
---
|
||||
date: "2019-12-31T13:55:00+05:00"
|
||||
slug: "search-engines-indexation"
|
||||
sidebar_position: 60
|
||||
aliases:
|
||||
- /zh-tw/search-engines-indexation
|
||||
---
|
||||
|
||||
# 搜尋引擎索引
|
||||
|
||||
預設情況下，你的 Gitea 安裝會被搜尋引擎索引。
|
||||
如果你不希望你的儲存庫被搜尋引擎看到，請繼續閱讀。
|
||||
|
||||
## 使用 robots.txt 阻止搜尋引擎索引
|
||||
|
||||
要讓 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) 找到。
|
||||
|
||||
```txt
|
||||
User-agent: *
|
||||
Disallow: /
|
||||
```
|
||||
|
||||
如果你在子目錄中安裝了 Gitea，你需要在頂層目錄中建立或編輯 `robots.txt`。
|
||||
|
||||
```txt
|
||||
User-agent: *
|
||||
Disallow: /gitea/
|
||||
```
|
||||
@@ -0,0 +1,138 @@
|
||||
---
|
||||
date: "2019-08-17T10:20:00+01:00"
|
||||
slug: "signing"
|
||||
sidebar_position: 50
|
||||
aliases:
|
||||
- /zh-tw/signing
|
||||
---
|
||||
|
||||
# GPG 提交簽名
|
||||
|
||||
Gitea 會通過檢查提交是否由 Gitea 資料庫中的密鑰簽名，或提交是否符合 Git 的預設密鑰來驗證 GPG 提交簽名。
|
||||
|
||||
密鑰不會被檢查是否已過期或被撤銷，也不會與密鑰伺服器進行檢查。
|
||||
|
||||
如果找不到密鑰來驗證提交，提交將被標記為灰色未鎖定圖標。如果提交被標記為紅色未鎖定圖標，則表示該提交是由具有 ID 的密鑰簽名的。
|
||||
|
||||
:::note
|
||||
提交的簽名者不必是提交的作者或提交者。
|
||||
:::
|
||||
|
||||
## 自動簽名
|
||||
|
||||
Gitea 會在以下幾個地方自動生成提交：
|
||||
|
||||
- 儲存庫初始化
|
||||
- Wiki 更改
|
||||
- 使用編輯器或 API 進行的 CRUD 操作
|
||||
- 從拉取請求合併
|
||||
|
||||
根據配置和伺服器信任，您可能希望 Gitea 簽署這些提交。
|
||||
|
||||
## 為 Gitea 安裝和生成 GPG 密鑰
|
||||
|
||||
伺服器管理員需要決定如何最好地安裝簽名密鑰。目前，Gitea 使用伺服器的 `git` 命令生成所有提交，因此將使用伺服器的 `gpg` 進行簽名（如果已配置）。管理員應該審查 GPG 的最佳實踐，特別是建議僅安裝簽名的秘密子密鑰，而不安裝主簽名和認證的秘密密鑰。
|
||||
|
||||
## 一般配置
|
||||
|
||||
Gitea 的簽名配置可以在 `app.ini` 的 `[repository.signing]` 部分找到：
|
||||
|
||||
```ini
|
||||
...
|
||||
[repository.signing]
|
||||
SIGNING_KEY = default
|
||||
SIGNING_NAME =
|
||||
SIGNING_EMAIL =
|
||||
INITIAL_COMMIT = always
|
||||
CRUD_ACTIONS = pubkey, twofa, parentsigned
|
||||
WIKI = never
|
||||
MERGES = pubkey, twofa, basesigned, commitssigned
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
### `SIGNING_KEY`
|
||||
|
||||
首先要討論的是 `SIGNING_KEY`。有三個主要選項：
|
||||
|
||||
- `none` - 這會阻止 Gitea 簽署任何提交
|
||||
- `default` - Gitea 將默認使用 `git config` 中配置的密鑰
|
||||
- `KEYID` - Gitea 將使用 ID 為 `KEYID` 的 gpg 密鑰簽署提交。在這種情況下，您應該提供 `SIGNING_NAME` 和 `SIGNING_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`。
|
||||
|
||||
如果您為 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 密鑰。
|
||||
:::
|
||||
|
||||
### `INITIAL_COMMIT`
|
||||
|
||||
此選項決定 Gitea 在創建儲存庫時是否應該簽署初始提交。可能的值是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `always`: 始終簽署
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以作為逗號分隔的列表進行組合。提交將在所有選定選項都為真時簽署。
|
||||
|
||||
### `WIKI`
|
||||
|
||||
此選項決定 Gitea 是否應該簽署 Wiki 的提交。可能的值是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `parentsigned`: 僅在父提交已簽署時簽署。
|
||||
- `always`: 始終簽署
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以作為逗號分隔的列表進行組合。提交將在所有選定選項都為真時簽署。
|
||||
|
||||
### `CRUD_ACTIONS`
|
||||
|
||||
此選項決定 Gitea 是否應該簽署來自網頁編輯器或 API CRUD 操作的提交。可能的值是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `parentsigned`: 僅在父提交已簽署時簽署。
|
||||
- `always`: 始終簽署
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以作為逗號分隔的列表進行組合。更改將在所有選定選項都為真時簽署。
|
||||
|
||||
### `MERGES`
|
||||
|
||||
此選項決定 Gitea 是否應該簽署來自 PR 的合併提交。可能的選項是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `basesigned`: 僅在基礎儲存庫中的父提交已簽署時簽署。
|
||||
- `headsigned`: 僅在頭分支中的頭提交已簽署時簽署。
|
||||
- `commitssigned`: 僅在頭分支中到合併點的所有提交都已簽署時簽署。
|
||||
- `approved`: 僅簽署已批准的合併到受保護分支。
|
||||
- `always`: 始終簽署
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以作為逗號分隔的列表進行組合。合併將在所有選定選項都為真時簽署。
|
||||
|
||||
## 獲取簽名密鑰的公鑰
|
||||
|
||||
用於簽署 Gitea 提交的公鑰可以從 API 獲取：
|
||||
|
||||
```sh
|
||||
/api/v1/signing-key.gpg
|
||||
```
|
||||
|
||||
在有儲存庫特定密鑰的情況下，可以從以下位置獲取：
|
||||
|
||||
```sh
|
||||
/api/v1/repos/:username/:reponame/signing-key.gpg
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
date: "2021-01-22T00:00:00+02:00"
|
||||
title: "Contributing"
|
||||
slug: "contributing"
|
||||
sidebar_position: 35
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "Contributing"
|
||||
sidebar_position: 50
|
||||
identifier: "contributing"
|
||||
---
|
||||
+150
@@ -0,0 +1,150 @@
|
||||
---
|
||||
date: "2021-11-01T23:41:00+08:00"
|
||||
slug: "guidelines-backend"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-tw/guidelines-backend
|
||||
---
|
||||
|
||||
# 後端開發指南
|
||||
|
||||
## 背景
|
||||
|
||||
Gitea 使用 Golang 作為後端編程語言。它使用了許多第三方包，也自己編寫了一些包。
|
||||
例如，Gitea 使用 [Chi](https://github.com/go-chi/chi) 作為基本的 Web 框架。[Xorm](https://xorm.io) 是一個 ORM 框架，用於與數據庫交互。
|
||||
因此，管理這些包非常重要。在開始編寫後端代碼之前，請遵循以下指南。
|
||||
|
||||
## 包設計指南
|
||||
|
||||
### 包列表
|
||||
|
||||
為了保持代碼的可理解性並避免循環依賴，擁有良好的代碼結構非常重要。Gitea 後端分為以下幾個部分：
|
||||
|
||||
- `build`: 幫助構建 Gitea 的腳本。
|
||||
- `cmd`: 所有 Gitea 的實際子命令，包括 web、doctor、serv、hooks、admin 等等。`web` 將啟動 Web 服務。`serv` 和 `hooks` 將由 Git 或 OpenSSH 調用。其他子命令可以幫助維護 Gitea。
|
||||
- `tests`: 常見的測試工具函數
|
||||
- `tests/integration`: 集成測試，用於測試後端回歸
|
||||
- `tests/e2e`: 端到端測試，用於測試前端和後端的兼容性和視覺回歸。
|
||||
- `models`: 包含由 xorm 用於構建數據庫表的數據結構。它還包含查詢和更新數據庫的函數。應避免依賴其他 Gitea 代碼。可以在某些情況下例外，例如日誌記錄。
|
||||
- `models/db`: 基本的數據庫操作。所有其他 `models/xxx` 包應依賴於此包。`GetEngine` 函數應僅從 `models/` 調用。
|
||||
- `models/fixtures`: 單元測試和集成測試中使用的示
|
||||
|
||||
---
|
||||
|
||||
date: "2021-11-01T23:41:00+08:00"
|
||||
slug: "guidelines-backend"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
|
||||
- /zh-tw/guidelines-backend
|
||||
|
||||
---
|
||||
|
||||
# Guidelines for Backend Development
|
||||
|
||||
## Background
|
||||
|
||||
Gitea uses Golang as the backend programming language. It uses many third-party packages and also write some itself.
|
||||
For example, Gitea uses [Chi](https://github.com/go-chi/chi) as basic web framework. [Xorm](https://xorm.io) is an ORM framework that is used to interact with the database.
|
||||
So it's very important to manage these packages. Please take the below guidelines before you start to write backend code.
|
||||
|
||||
## Package Design Guideline
|
||||
|
||||
### Packages List
|
||||
|
||||
To maintain understandable code and avoid circular dependencies it is important to have a good code structure. The Gitea backend is divided into the following parts:
|
||||
|
||||
- `build`: Scripts to help build Gitea.
|
||||
- `cmd`: All Gitea actual sub commands includes web, doctor, serv, hooks, admin and etc. `web` will start the web service. `serv` and `hooks` will be invoked by Git or OpenSSH. Other sub commands could help to maintain Gitea.
|
||||
- `tests`: Common test utility functions
|
||||
- `tests/integration`: Integration tests, to test back-end regressions
|
||||
- `tests/e2e`: E2e tests, to test front-end and back-end compatibility and visual regressions.
|
||||
- `models`: Contains the data structures used by xorm to construct database tables. It also contains functions to query and update the database. Dependencies to other Gitea code should be avoided. You can make exceptions in cases such as logging.
|
||||
- `models/db`: Basic database operations. All other `models/xxx` packages should depend on this package. The `GetEngine` function should only be invoked from `models/`.
|
||||
- `models/fixtures`: Sample data used in unit tests and integration tests. One `yml` file means one table which will be loaded into database when beginning the tests.
|
||||
- `models/migrations`: Stores database migrations between versions. PRs that change a database structure **MUST** also have a migration step.
|
||||
- `modules`: Different modules to handle specific functionality in Gitea. Work in Progress: Some of them should be moved to `services`, in particular those that depend on models because they rely on the database.
|
||||
- `modules/setting`: Store all system configurations read from ini files and has been referenced by everywhere. But they should be used as function parameters when possible.
|
||||
- `modules/git`: Package to interactive with `Git` command line or Gogit package.
|
||||
- `public`: Compiled frontend files (javascript, images, css, etc.)
|
||||
- `routers`: Handling of server requests. As it uses other Gitea packages to serve the request, other packages (models, modules or services) must not depend on routers.
|
||||
- `routers/api` Contains routers for `/api/v1` aims to handle RESTful API requests.
|
||||
- `routers/install` Could only respond when system is in INSTALL mode (INSTALL_LOCK=false).
|
||||
- `routers/private` will only be invoked by internal sub commands, especially `serv` and `hooks`.
|
||||
- `routers/web` will handle HTTP requests from web browsers or Git SMART HTTP protocols.
|
||||
- `services`: Support functions for common routing operations or command executions. Uses `models` and `modules` to handle the requests.
|
||||
- `templates`: Golang templates for generating the html output.
|
||||
|
||||
### Package Dependencies
|
||||
|
||||
Since Golang doesn't support import cycles, we have to decide the package dependencies carefully. There are some levels between those packages. Below is the ideal package dependencies direction.
|
||||
|
||||
`cmd` -> `routers` -> `services` -> `models` -> `modules`
|
||||
|
||||
From left to right, left packages could depend on right packages, but right packages MUST not depend on left packages. The sub packages on the same level could depend on according this level's rules.
|
||||
|
||||
:::warning
|
||||
Why do we need database transactions outside of `models`? And how?
|
||||
Some actions should allow for rollback when database record insertion/update/deletion failed.
|
||||
So services must be allowed to create a database transaction. Here is some example,
|
||||
|
||||
```go
|
||||
// services/repository/repository.go
|
||||
func CreateXXXX() error {
|
||||
return db.WithTx(func(ctx context.Context) error {
|
||||
// do something, if err is returned, it will rollback automatically
|
||||
if err := issues.UpdateIssue(ctx, repoID); err != nil {
|
||||
// ...
|
||||
return err
|
||||
}
|
||||
// ...
|
||||
return nil
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
You should **not** use `db.GetEngine(ctx)` in `services` directly, but just write a function under `models/`.
|
||||
If the function will be used in the transaction, just let `context.Context` as the function's first parameter.
|
||||
|
||||
```go
|
||||
// models/issues/issue.go
|
||||
func UpdateIssue(ctx context.Context, repoID int64) error {
|
||||
e := db.GetEngine(ctx)
|
||||
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### Package Name
|
||||
|
||||
For the top level package, use a plural as package name, i.e. `services`, `models`, for sub packages, use singular,
|
||||
i.e. `services/user`, `models/repository`.
|
||||
|
||||
### Import Alias
|
||||
|
||||
Since there are some packages which use the same package name, it is possible that you find packages like `modules/user`, `models/user`, and `services/user`. When these packages are imported in one Go file, it's difficult to know which package we are using and if it's a variable name or an import name. So, we always recommend to use import aliases. To differ from package variables which are commonly in camelCase, just use **snake_case** for import aliases.
|
||||
i.e. `import user_service "code.gitea.io/gitea/services/user"`
|
||||
|
||||
### Implementing `io.Closer`
|
||||
|
||||
If a type implements `io.Closer`, calling `Close` multiple times must not fail or `panic` but return an error or `nil`.
|
||||
|
||||
### Important Gotchas
|
||||
|
||||
- Never write `x.Update(exemplar)` without an explicit `WHERE` clause:
|
||||
- This will cause all rows in the table to be updated with the non-zero values of the exemplar - including IDs.
|
||||
- You should usually write `x.ID(id).Update(exemplar)`.
|
||||
- If during a migration you are inserting into a table using `x.Insert(exemplar)` where the ID is preset:
|
||||
- You will need to `` SET IDENTITY_INSERT `table` ON `` for the MSSQL variant (the migration will fail otherwise)
|
||||
- However, you will also need to update the id sequence for postgres - the migration will silently pass here but later insertions will fail:
|
||||
`` SELECT setval('table_name_id_seq', COALESCE((SELECT MAX(id)+1 FROM `table_name`), 1), false) ``
|
||||
|
||||
### Future Tasks
|
||||
|
||||
Currently, we are creating some refactors to do the following things:
|
||||
|
||||
- Correct that codes which doesn't follow the rules.
|
||||
- There are too many files in `models`, so we are moving some of them into a sub package `models/xxx`.
|
||||
- Some `modules` sub packages should be moved to `services` because they depend on `models`.
|
||||
+166
@@ -0,0 +1,166 @@
|
||||
---
|
||||
date: "2021-10-13T16:00:00+02:00"
|
||||
slug: "guidelines-frontend"
|
||||
sidebar_position: 30
|
||||
aliases:
|
||||
- /zh-tw/guidelines-frontend
|
||||
---
|
||||
|
||||
# Guidelines for Frontend Development
|
||||
|
||||
## Background
|
||||
|
||||
Gitea uses [Fomantic-UI](https://fomantic-ui.com/introduction/getting-started.html) (based on [jQuery](https://api.jquery.com)) and [Vue3](https://vuejs.org/) for its frontend.
|
||||
|
||||
The HTML pages are rendered by [Go HTML Template](https://pkg.go.dev/html/template).
|
||||
|
||||
The source files can be found in the following directories:
|
||||
|
||||
- **CSS styles:** `web_src/css/`
|
||||
- **JavaScript files:** `web_src/js/`
|
||||
- **Vue components:** `web_src/js/components/`
|
||||
- **Go HTML templates:** `templates/`
|
||||
|
||||
## General Guidelines
|
||||
|
||||
We recommend [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html) and [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)
|
||||
|
||||
### Gitea specific guidelines
|
||||
|
||||
1. Every feature (Fomantic-UI/jQuery module) should be put in separate files/directories.
|
||||
2. HTML ids and classes should use kebab-case, it's preferred to contain 2-3 feature related keywords.
|
||||
3. HTML ids and classes used in JavaScript should be unique for the whole project, and should contain 2-3 feature related keywords. We recommend to use the `js-` prefix for classes that are only used in JavaScript.
|
||||
4. CSS styling for classes provided by frameworks should not be overwritten. Always use new class names with 2-3 feature related keywords to overwrite framework styles. Gitea's helper CSS classes in `helpers.less` could be helpful.
|
||||
5. The backend can pass complex data to the frontend by using `ctx.PageData["myModuleData"] = map[]{}`, but do not expose whole models to the frontend to avoid leaking sensitive data.
|
||||
6. Simple pages and SEO-related pages use Go HTML Template render to generate static Fomantic-UI HTML output. Complex pages can use Vue3.
|
||||
7. Clarify variable types, prefer `elem.disabled = true` instead of `elem.setAttribute('disabled', 'anything')`, prefer `$el.prop('checked', var === 'yes')` instead of `$el.prop('checked', var)`.
|
||||
8. Use semantic elements, prefer `<button class="ui button">` instead of `<div class="ui button">`.
|
||||
9. Avoid unnecessary `!important` in CSS, add comments to explain why it's necessary if it can't be avoided.
|
||||
10. Avoid mixing different events in one event listener, prefer to use individual event listeners for every event.
|
||||
11. Custom event names are recommended to use `ce-` prefix.
|
||||
12. Prefer using Tailwind CSS which is available via `tw-` prefix, e.g. `tw-relative`. Gitea's helper CSS classes use `gt-` prefix (`gt-ellipsis`), while Gitea's own private framework-level CSS classes use `g-` prefix (`g-modal-confirm`).
|
||||
13. Avoid inline scripts & styles as much as possible, it's recommended to put JS code into JS files and use CSS classes. If inline scripts & styles are unavoidable, explain the reason why it can't be avoided.
|
||||
|
||||
### Accessibility / ARIA
|
||||
|
||||
In history, Gitea heavily uses Fomantic UI which is not an accessibility-friendly framework.
|
||||
Gitea uses some patches to make Fomantic UI more accessible (see `aria.md` and related JS files),
|
||||
but there are still many problems which need a lot of work and time to fix.
|
||||
|
||||
### Framework Usage
|
||||
|
||||
Mixing different frameworks together is discouraged, it makes the code difficult to be maintained.
|
||||
A JavaScript module should follow one major framework and follow the framework's best practice.
|
||||
|
||||
Recommended implementations:
|
||||
|
||||
- Vue + Vanilla JS
|
||||
- Fomantic-UI (jQuery)
|
||||
- htmx (partial page reloads for otherwise static components)
|
||||
- Vanilla JS
|
||||
|
||||
Discouraged implementations:
|
||||
|
||||
- Vue + Fomantic-UI (jQuery)
|
||||
- jQuery + Vanilla JS
|
||||
- htmx + any other framework which requires heavy JS code, or unnecessary features like htmx scripting (`hx-on`)
|
||||
|
||||
To make UI consistent, Vue components can use Fomantic-UI CSS classes.
|
||||
We use htmx for simple interactions. You can see an example for simple interactions where htmx should be used in this [PR](https://github.com/go-gitea/gitea/pull/28908). Do not use htmx if you require more advanced reactivity, use another framework (Vue/Vanilla JS).
|
||||
Although mixing different frameworks is discouraged,
|
||||
it should also work if the mixing is necessary and the code is well-designed and maintainable.
|
||||
|
||||
### Typescript
|
||||
|
||||
Gitea is in the process of migrating to type-safe Typescript. Here are some specific guidelines regarding Typescript in the codebase:
|
||||
|
||||
#### Use type aliases instead of interfaces
|
||||
|
||||
Prefer to use type aliases because they can represent any type and are generally more flexible to use than interfaces.
|
||||
|
||||
#### Use separate type imports
|
||||
|
||||
We use `verbatimModuleSyntax` so type and non-type imports from the same file must be split into two `import type` statements. This enables the typescript compiler to completely eliminate the type import statements during compilation.
|
||||
|
||||
#### Use `@ts-expect-error` instead of `@ts-ignore`
|
||||
|
||||
Both annotations should be avoided, but if you have to use them, use `@ts-expect-error` because it will not leave ineffective statements after the issue is fixed.
|
||||
|
||||
### `async` Functions
|
||||
|
||||
Only mark a function as `async` if and only if there are `await` calls
|
||||
or `Promise` returns inside the function.
|
||||
|
||||
It's not recommended to use `async` event listeners, which may lead to problems.
|
||||
The reason is that the code after await is executed outside the event dispatch.
|
||||
Reference: https://github.com/github/eslint-plugin-github/blob/main/docs/rules/async-preventdefault.md
|
||||
|
||||
If an event listener must be `async`, the `e.preventDefault()` should be before any `await`,
|
||||
it's recommended to put it at the beginning of the function.
|
||||
|
||||
If we want to call an `async` function in a non-async context,
|
||||
it's recommended to use `const _promise = asyncFoo()` to tell readers
|
||||
that this is done by purpose, we want to call the async function and ignore the Promise.
|
||||
Some lint rules and IDEs also have warnings if the returned Promise is not handled.
|
||||
|
||||
### Fetching data
|
||||
|
||||
To fetch data, use the wrapper functions `GET`, `POST` etc. from `modules/fetch.js`. They
|
||||
accept a `data` option for the content, will automatically set CSRF token and return a
|
||||
Promise for a [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response).
|
||||
|
||||
### HTML Attributes and `dataset`
|
||||
|
||||
The usage of `dataset` is forbidden, its camel-casing behaviour makes it hard to grep for attributes.
|
||||
However, there are still some special cases, so the current guideline is:
|
||||
|
||||
- For legacy code:
|
||||
|
||||
- `$.data()` should be refactored to `$.attr()`.
|
||||
- `$.data()` can be used to bind some non-string data to elements in rare cases, but it is highly discouraged.
|
||||
|
||||
- For new code:
|
||||
- `node.dataset` should not be used, use `node.getAttribute` instead.
|
||||
- never bind any user data to a DOM node, use a suitable design pattern to describe the relation between node and data.
|
||||
|
||||
### Show/Hide Elements
|
||||
|
||||
- Vue components are recommended to use `v-if` and `v-show` to show/hide elements.
|
||||
- Go template code should use `.tw-hidden` and `showElem()/hideElem()/toggleElem()`, see more details in `.tw-hidden`'s comment.
|
||||
|
||||
### Styles and Attributes in Go HTML Template
|
||||
|
||||
It's recommended to use:
|
||||
|
||||
```html
|
||||
<div
|
||||
class="gt-name1 gt-name2 {{if .IsFoo}}gt-foo{{end}}"
|
||||
{{if
|
||||
.IsFoo}}data-foo{{end}}
|
||||
></div>
|
||||
```
|
||||
|
||||
instead of:
|
||||
|
||||
```html
|
||||
<div
|
||||
class="gt-name1 gt-name2{{if .IsFoo}} gt-foo{{end}}"
|
||||
{{if
|
||||
.IsFoo}}
|
||||
data-foo{{end}}
|
||||
></div>
|
||||
```
|
||||
|
||||
to make the code more readable.
|
||||
|
||||
### Legacy Code
|
||||
|
||||
A lot of legacy code already existed before this document's written. It's recommended to refactor legacy code to follow the guidelines.
|
||||
|
||||
### Vue3 and JSX
|
||||
|
||||
Gitea is using Vue3 now. We decided not to introduce JSX to keep the HTML and the JavaScript code separated.
|
||||
|
||||
### UI Examples
|
||||
|
||||
Gitea uses some self-made UI elements and customizes others to integrate them better into the general UI approach. When running Gitea in development mode (`RUN_MODE=dev`), a page with some standardized UI examples is available under `http(s)://your-gitea-url:port/devtest`.
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
date: "2023-02-14T00:00:00+00:00"
|
||||
slug: "guidelines-refactoring"
|
||||
sidebar_position: 40
|
||||
aliases:
|
||||
- /zh-tw/guidelines-refactoring
|
||||
---
|
||||
|
||||
# 重構指南
|
||||
|
||||
## 背景
|
||||
|
||||
自 2014 年 2 月 12 日編寫第一行代碼以來，Gitea 已經成長為一個大型項目。
|
||||
因此，代碼庫變得越來越大。代碼庫越大，維護起來就越困難。
|
||||
存在許多過時的機制，許多框架混合在一起，一些遺留代碼可能會導致錯誤並阻礙新功能。
|
||||
為了使代碼庫更易於維護並使 Gitea 更好，開發人員應牢記使用現代機制來重構舊代碼。
|
||||
|
||||
本文檔是重構代碼庫的指南集合。
|
||||
|
||||
## 重構建議
|
||||
|
||||
- 更多地考慮未來，而不僅僅解決當前問題。
|
||||
- 減少模糊性，減少衝突，提高可維護性。
|
||||
- 描述重構，例如：
|
||||
- 為什麼需要重構。
|
||||
- 如何解決遺留問題。
|
||||
- 重構的優缺點。
|
||||
- 僅進行必要的更改，盡可能保持舊邏輯。
|
||||
- 引入一些中間步驟，使重構更易於審查，完整的重構計劃可以在幾個 PR 中完成。
|
||||
- 如果存在分歧，應邀請 TOC（技術監督委員會）幫助做出決定。
|
||||
- 添加必要的測試以確保重構正確。
|
||||
- 非錯誤重構優先在里程碑的開始進行，這樣在發布之前更容易發現問題。
|
||||
|
||||
## 審查和合併建議
|
||||
|
||||
- 重構 PR 不應長時間保持打開狀態（通常為 7 天），應盡快審查。
|
||||
- 重構 PR 應盡快合併，不應被其他 PR 阻塞。
|
||||
- 如果 TOC 沒有異議，重構 PR 可以在 7 天後由一名核心成員批准（非作者）後合併。
|
||||
- 容忍一些臟/臨時的中間步驟，如果最終結果是好的。
|
||||
- 如果重構是必要的，容忍一些回歸錯誤，並盡快修復錯誤。
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "localization"
|
||||
sidebar_position: 70
|
||||
aliases:
|
||||
- /zh-tw/localization
|
||||
---
|
||||
|
||||
# 本地化
|
||||
|
||||
Gitea 的本地化通過我們的 [Crowdin 項目](https://crowdin.com/project/gitea) 進行。
|
||||
|
||||
對 **英文** 翻譯的更改，可以通過拉取請求更改
|
||||
[英文語言文件](https://github.com/go-gitea/gitea/blob/main/options/locale/locale_en-US.ini) 中的相應鍵。
|
||||
|
||||
對 **非英文** 翻譯的更改，請參考上面的 Crowdin 項目。
|
||||
|
||||
## 支持的語言
|
||||
|
||||
只要翻譯完成度達到 25% 或以上，Crowdin 項目中列出的任何語言都將被支持。
|
||||
|
||||
翻譯被接受後，將在下一次 Crowdin 同步後反映在主存儲庫中，通常是在任何 PR 合併後。
|
||||
|
||||
在撰寫本文時，這意味著更改的翻譯可能不會出現在隨後的 Gitea 發布之前。
|
||||
|
||||
如果您使用的是最新的構建，則應在同步更改後的更新中出現。
|
||||
|
||||
## 如何貢獻
|
||||
|
||||
不同語言有不同的翻譯指南。請訪問相應的頁面以獲取更多信息。
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
title: "Development"
|
||||
slug: "development"
|
||||
sidebar_position: 40
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "Development"
|
||||
sidebar_position: 40
|
||||
identifier: "development"
|
||||
---
|
||||
@@ -0,0 +1,108 @@
|
||||
---
|
||||
date: "2018-06-24:00:00+02:00"
|
||||
slug: "api-usage"
|
||||
sidebar_position: 40
|
||||
aliases:
|
||||
- /zh-tw/api-usage
|
||||
---
|
||||
|
||||
# API 使用
|
||||
|
||||
## 啟用/配置 API 訪問
|
||||
|
||||
預設情況下，`ENABLE_SWAGGER` 是啟用的，`MAX_RESPONSE_ITEMS` 設定為 50。更多資訊請參閱 [配置速查表](../administration/config-cheat-sheet.md)。
|
||||
|
||||
## 認證
|
||||
|
||||
Gitea 支援以下 API 認證方法：
|
||||
|
||||
- HTTP 基本認證
|
||||
- URL 查詢字串中的 `token=...` 參數
|
||||
- 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 令牌
|
||||
|
||||
可以通過向 `/users/:name/tokens` 發送 `POST` 請求來生成新令牌。
|
||||
|
||||
請注意，`/users/:name/tokens` 是一個特殊端點，需要使用 `BasicAuth` 和密碼進行認證，如下所示：
|
||||
|
||||
```sh
|
||||
$ curl -H "Content-Type: application/json" -d '{"name":"test"}' -u username:password https://gitea.your.host/api/v1/users/<username>/tokens
|
||||
{"id":1,"name":"test","sha1":"9fcb1158165773dd010fca5f0cf7174316c3e37d","token_last_eight":"16c3e37d"}
|
||||
```
|
||||
|
||||
`sha1`（令牌）只會返回一次，並且不會以明文形式存儲。當使用 `GET` 請求列出令牌時，它不會顯示；例如：
|
||||
|
||||
```sh
|
||||
$ curl --url https://yourusername:password@gitea.your.host/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 請求的示例：
|
||||
|
||||
```sh
|
||||
$ curl -H "X-Gitea-OTP: 123456" --url https://yourusername:yourpassword@gitea.your.host/api/v1/users/yourusername/tokens
|
||||
```
|
||||
|
||||
你也可以通過 Gitea 安裝的網頁界面創建 API 金鑰令牌：`Settings | Applications | Generate New Token`。
|
||||
|
||||
## OAuth2 提供者
|
||||
|
||||
從 Gitea 的 [OAuth2 提供者](development/oauth2-provider.md) 獲取的訪問令牌可以通過以下方法接受：
|
||||
|
||||
- HTTP 標頭中的 `Authorization bearer ...` 標頭
|
||||
- URL 查詢字串中的 `token=...` 參數
|
||||
- URL 查詢字串中的 `access_token=...` 參數
|
||||
|
||||
### 關於 `Authorization:` 標頭的更多資訊
|
||||
|
||||
由於歷史原因，Gitea 需要在授權標頭中的 API 金鑰令牌前包含單詞 `token`，如下所示：
|
||||
|
||||
```sh
|
||||
Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675
|
||||
```
|
||||
|
||||
例如，在 `curl` 命令中，這將如下所示：
|
||||
|
||||
```sh
|
||||
curl "http://localhost:4000/api/v1/repos/test1/test1/issues" \
|
||||
-H "accept: application/json" \
|
||||
-H "Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675" \
|
||||
-H "Content-Type: application/json" -d "{ \"body\": \"testing\", \"title\": \"test 20\"}" -i
|
||||
```
|
||||
|
||||
如上所述，使用的令牌與在 GET 請求中的 `token=` 字串中使用的令牌相同。
|
||||
|
||||
## 分頁
|
||||
|
||||
API 支援分頁。`page` 和 `limit` 參數用於指定頁碼和每頁的項目數量。如果有多頁，則返回 `Link` 標頭，其中包含下一頁、上一頁和最後一頁的鏈接。還返回 `x-total-count` 以指示項目總數。
|
||||
|
||||
```sh
|
||||
curl -v "http://localhost/api/v1/repos/search?limit=1"
|
||||
...
|
||||
< link: <http://localhost/api/v1/repos/search?limit=1&page=2>; rel="next",<http://localhost/api/v1/repos/search?limit=1&page=5252>; rel="last"
|
||||
...
|
||||
< x-total-count: 5252
|
||||
```
|
||||
|
||||
## API 指南
|
||||
|
||||
API 參考指南由 swagger 自動生成，可在以下位置獲取：
|
||||
`https://gitea.your.host/api/swagger`
|
||||
或在
|
||||
[Gitea 實例](https://gitea.com/api/swagger)
|
||||
|
||||
OpenAPI 文件位於：
|
||||
`https://gitea.your.host/swagger.v1.json`
|
||||
|
||||
## Sudo
|
||||
|
||||
API 允許管理員用戶以其他用戶的身份 sudo API 請求。只需添加 `sudo=` 參數或 `Sudo:` 請求標頭，並附上要 sudo 的用戶名。
|
||||
|
||||
## SDKs
|
||||
|
||||
- [官方 go-sdk](https://gitea.com/gitea/go-sdk)
|
||||
- [更多](https://gitea.com/gitea/awesome-gitea#user-content-sdk)
|
||||
+309
@@ -0,0 +1,309 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "hacking-on-gitea"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
- /zh-tw/hacking-on-gitea
|
||||
---
|
||||
|
||||
# Gitea 開發
|
||||
|
||||
## 快速開始
|
||||
|
||||
要快速建立一個可用的開發環境，你可以使用 Gitpod。
|
||||
|
||||
[](https://gitpod.io/#https://github.com/go-gitea/gitea)
|
||||
|
||||
## 安裝 Go
|
||||
|
||||
你應該[安裝 Go](https://go.dev/doc/install) 並正確設置你的 Go 環境。
|
||||
|
||||
接下來，[安裝 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@。
|
||||
:::
|
||||
|
||||
要 lint 模板文件，請確保安裝 [Python](https://www.python.org/) 和 [Poetry](https://python-poetry.org/)。
|
||||
|
||||
## 安裝 Make
|
||||
|
||||
Gitea 大量使用 Make 來自動化任務並改進開發。這個指南涵蓋了如何安裝 Make。
|
||||
|
||||
### 在 Linux 上
|
||||
|
||||
使用包管理器安裝。
|
||||
|
||||
在 Ubuntu/Debian 上：
|
||||
|
||||
```bash
|
||||
sudo apt-get install make
|
||||
```
|
||||
|
||||
在 Fedora/RHEL/CentOS 上：
|
||||
|
||||
```bash
|
||||
sudo yum install make
|
||||
```
|
||||
|
||||
### 在 Windows 上
|
||||
|
||||
以下三種 Make 發行版之一可以在 Windows 上運行：
|
||||
|
||||
- [單一二進制構建](http://www.equation.com/servlet/equation.cmd?fa=make)。複製到某處並添加到 `PATH`。
|
||||
- [32 位版本](http://www.equation.com/ftpdir/make/32/make.exe)
|
||||
- [64 位版本](http://www.equation.com/ftpdir/make/64/make.exe)
|
||||
- [MinGW-w64](https://www.mingw-w64.org) / [MSYS2](https://www.msys2.org/)。
|
||||
- MSYS2 是一組工具和庫，為你提供了一個易於使用的環境，用於構建、安裝和運行本地 Windows 軟件，它包括 MinGW-w64。
|
||||
- 在 MingGW-w64 中，二進制文件稱為 `mingw32-make.exe` 而不是 `make.exe`。將 `bin` 文件夾添加到 `PATH`。
|
||||
- 在 MSYS2 中，你可以直接使用 `make`。請參閱 [MSYS2 Porting](https://www.msys2.org/wiki/Porting/)。
|
||||
- 要使用 CGO_ENABLED（例如：SQLite3）編譯 Gitea，你可能需要使用 [tdm-gcc](https://jmeubank.github.io/tdm-gcc/) 而不是 MSYS2 gcc，因為 MSYS2 gcc 標頭缺少一些僅限 Windows 的 CRT 函數，如 `_beginthread`。
|
||||
- [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`。
|
||||
:::
|
||||
|
||||
## 下載和克隆 Gitea 源代碼
|
||||
|
||||
推薦的方法是使用 `git clone` 獲取源代碼。
|
||||
|
||||
```bash
|
||||
git clone https://github.com/go-gitea/gitea
|
||||
```
|
||||
|
||||
（由於 go 模塊的出現，不再需要從 `$GOPATH` 內構建 go 項目，因此不再推薦使用 `go get` 方法。）
|
||||
|
||||
## Fork Gitea
|
||||
|
||||
如上所述下載主要的 Gitea 源代碼。然後，在 GitHub 上 fork [Gitea repository](https://github.com/go-gitea/gitea)，並將 git 遠程 origin 切換到你的 fork 或添加你的 fork 作為另一個遠程：
|
||||
|
||||
```bash
|
||||
# 將原始 Gitea origin 重命名為 upstream
|
||||
git remote rename origin upstream
|
||||
git remote add origin "git@github.com:$GITHUB_USERNAME/gitea.git"
|
||||
git fetch --all --prune
|
||||
```
|
||||
|
||||
或：
|
||||
|
||||
```bash
|
||||
# 為我們的 fork 添加新遠程
|
||||
git remote add "$FORK_NAME" "git@github.com:$GITHUB_USERNAME/gitea.git"
|
||||
git fetch --all --prune
|
||||
```
|
||||
|
||||
為了能夠創建 pull request，fork 的倉庫應該被添加為 Gitea 源代碼的遠程。否則，無法推送更改。
|
||||
|
||||
## 構建 Gitea（基礎）
|
||||
|
||||
查看我們的[從源代碼構建](installation/from-source.md)的[說明](installation/from-source.md)。
|
||||
|
||||
從源代碼構建的最簡單推薦方法是：
|
||||
|
||||
```bash
|
||||
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) 了解我們的持續集成如何工作。
|
||||
|
||||
## 持續構建
|
||||
|
||||
要運行並在源文件更改時持續重建：
|
||||
|
||||
```bash
|
||||
# 前端和後端
|
||||
make watch
|
||||
|
||||
# 或：僅監視前端文件（html/js/css）
|
||||
make watch-frontend
|
||||
|
||||
# 或：僅監視後端文件（go）
|
||||
make watch-backend
|
||||
```
|
||||
|
||||
在 macOS 上，監視所有後端源文件可能會達到默認的打開文件限制，可以通過 `ulimit -n 12288` 為當前 shell 或在你的 shell 啟動文件中為所有未來的 shell 增加此限制。
|
||||
|
||||
### 格式化、代碼分析和拼寫檢查
|
||||
|
||||
我們的持續集成將拒絕未通過代碼 linter（包括格式檢查、代碼分析和拼寫檢查）的 PR。
|
||||
|
||||
你應該格式化你的代碼：
|
||||
|
||||
```bash
|
||||
make fmt
|
||||
```
|
||||
|
||||
並 lint 源代碼：
|
||||
|
||||
```bash
|
||||
# lint 前端和後端代碼
|
||||
make lint
|
||||
# 僅 lint 後端代碼
|
||||
make lint-backend
|
||||
```
|
||||
|
||||
**注意**：`gofmt` 的結果取決於當前的 Go 版本。你應該運行與持續集成服務器上相同版本的 Go，如上所述。
|
||||
|
||||
### 處理 JS 和 CSS
|
||||
|
||||
前端開發應遵循[前端開發指南](contributing/guidelines-frontend.md)
|
||||
|
||||
要使用前端資源構建，可以使用上述的 `watch-frontend` 目標或僅構建一次：
|
||||
|
||||
```bash
|
||||
make build && ./gitea
|
||||
```
|
||||
|
||||
在提交之前，確保 linter 通過：
|
||||
|
||||
```bash
|
||||
make lint-frontend
|
||||
```
|
||||
|
||||
### 配置本地 ElasticSearch 實例
|
||||
|
||||
使用 docker 啟動本地 ElasticSearch 實例：
|
||||
|
||||
```sh
|
||||
mkdir -p $(pwd)/data/elasticsearch
|
||||
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`：
|
||||
|
||||
```ini
|
||||
[indexer]
|
||||
ISSUE_INDEXER_TYPE = elasticsearch
|
||||
ISSUE_INDEXER_CONN_STR = http://elastic:changeme@localhost:9200
|
||||
REPO_INDEXER_ENABLED = true
|
||||
REPO_INDEXER_TYPE = elasticsearch
|
||||
REPO_INDEXER_CONN_STR = http://elastic:changeme@localhost:9200
|
||||
```
|
||||
|
||||
### 構建和添加 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` 標籤將僅更新用戶指定的標誌文件。
|
||||
|
||||
### 更新 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 的根本性更改將被拒絕。
|
||||
|
||||
一旦你創建或更改了一個 API 端點，請使用以下命令重新生成 Swagger 文檔：
|
||||
|
||||
```bash
|
||||
make generate-swagger
|
||||
```
|
||||
|
||||
你應該驗證生成的 Swagger 文件：
|
||||
|
||||
```bash
|
||||
make swagger-validate
|
||||
```
|
||||
|
||||
你應該提交更改的 swagger JSON 文件。持續集成服務器將使用以下命令檢查是否已完成此操作：
|
||||
|
||||
```bash
|
||||
make swagger-check
|
||||
```
|
||||
|
||||
:::note
|
||||
請注意，你應該使用 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)。
|
||||
|
||||
### 更改標誌
|
||||
|
||||
在更改 Gitea 標誌 SVG 時，你需要運行並提交以下命令的結果：
|
||||
|
||||
```bash
|
||||
make generate-images
|
||||
```
|
||||
|
||||
這將創建必要的 Gitea favicon 和其他圖標。
|
||||
|
||||
### 數據庫遷移
|
||||
|
||||
如果你對 `models/` 目錄中的任何數據庫持久化結構進行了重大更改，你將需要進行新的遷移。這些可以在 `models/migrations/` 中找到。你可以使用以下命令確保你的遷移適用於主要數據庫類型：
|
||||
|
||||
```bash
|
||||
make test-sqlite-migration # 使用 SQLite 進行測試，並根據需要切換到適當的數據庫
|
||||
```
|
||||
|
||||
## 測試
|
||||
|
||||
Gitea 運行兩種類型的測試：單元測試和集成測試。
|
||||
|
||||
### 單元測試
|
||||
|
||||
單元測試由 `*_test.go` 覆蓋在 `go test` 系統中。你可以設置環境變量 `GITEA_UNIT_TESTS_LOG_SQL=1` 以在詳細模式下運行測試時顯示所有 SQL 語句（即設置 `GOTESTFLAGS=-v`）。
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make test # 運行單元測試
|
||||
```
|
||||
|
||||
### 集成測試
|
||||
|
||||
單元測試無法完全測試 Gitea。因此，我們編寫了集成測試；然而，這些測試依賴於數據庫。
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build test-sqlite
|
||||
```
|
||||
|
||||
將在 SQLite 環境中運行集成測試。集成測試需要安裝 `git lfs`。其他數據庫測試可用，但可能需要調整本地環境。
|
||||
|
||||
查看 [`tests/integration/README.md`](https://github.com/go-gitea/gitea/blob/main/tests/integration/README.md) 以獲取更多信息以及如何運行單個測試。
|
||||
|
||||
### PR 測試
|
||||
|
||||
我們的持續集成將測試代碼是否通過其單元測試，並且所有支持的數據庫將在 Docker 環境中通過集成測試。還將測試從 Gitea 的幾個最近版本的遷移。
|
||||
|
||||
請提交你的 PR，並根據需要添加額外的測試和集成測試。
|
||||
|
||||
## 網站文檔
|
||||
|
||||
網站文檔位於 `docs/` 中。如果你更改了這些文檔，可以使用以下命令測試你的更改以確保它們通過持續集成：
|
||||
|
||||
```bash
|
||||
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) 以獲取更多信息。
|
||||
|
||||
## GoLand
|
||||
|
||||
點擊 `/main.go` 中 `func main()` 函數上的 `Run Application` 箭頭可以快速啟動可調試的 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`。
|
||||
|
||||
## 提交 PR
|
||||
|
||||
一旦你對更改感到滿意，請將它們推送並打開一個 pull request。建議允許 Gitea 管理員和所有者修改你的 PR 分支，因為我們需要在合併之前將其更新到 main，並且/或者可能能夠直接幫助修復問題。
|
||||
|
||||
任何 PR 需要兩個 Gitea 維護者的批准，並且需要通過持續集成。查看我們的 [`CONTRIBUTING.md`](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md) 文檔。
|
||||
|
||||
如果你需要更多幫助，請加入 [Discord](https://discord.gg/gitea) #Develop 聊天。
|
||||
|
||||
就是這樣！你已經準備好開發 Gitea 了。
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
date: "2019-04-15T17:29:00+08:00"
|
||||
slug: "integrations"
|
||||
sidebar_position: 65
|
||||
aliases:
|
||||
- /zh-tw/integrations
|
||||
---
|
||||
|
||||
# 整合
|
||||
|
||||
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) 倉庫中找到它們！
|
||||
|
||||
## 預填新文件名稱和內容
|
||||
|
||||
如果你想打開一個具有給定名稱和內容的新文件，你可以使用查詢參數：
|
||||
|
||||
```txt
|
||||
GET /{{org}}/{{repo}}/_new/{{filepath}}
|
||||
?filename={{filename}}
|
||||
&value={{content}}
|
||||
```
|
||||
|
||||
例如：
|
||||
|
||||
```txt
|
||||
GET https://git.example.com/johndoe/bliss/_new/articles/
|
||||
?filename=hello-world.md
|
||||
&value=Hello%2C%20World!
|
||||
```
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
date: "2019-04-15T17:29:00+08:00"
|
||||
slug: "migrations-interfaces"
|
||||
sidebar_position: 55
|
||||
aliases:
|
||||
- /zh-tw/migrations-interfaces
|
||||
---
|
||||
|
||||
# 遷移介面
|
||||
|
||||
完整的遷移在 Gitea 1.9.0 中引入。它定義了兩個介面來支持從其他 Git 主機平台遷移倉庫數據到 Gitea，或者在未來，將 Gitea 數據遷移到其他 Git 主機平台。
|
||||
|
||||
目前，已實現從 GitHub、GitLab 和其他 Gitea 實例的遷移。
|
||||
|
||||
首先，Gitea 在 [modules/migration](https://github.com/go-gitea/gitea/tree/main/modules/migration) 包中定義了一些標準對象。它們是 `Repository`、`Milestone`、`Release`、`ReleaseAsset`、`Label`、`Issue`、`Comment`、`PullRequest`、`Reaction`、`Review`、`ReviewComment`。
|
||||
|
||||
## 下載器介面
|
||||
|
||||
要從新的 Git 主機平台遷移，有兩個步驟需要更新。
|
||||
|
||||
- 你應該實現一個 `Downloader`，它將用於獲取倉庫信息。
|
||||
- 你應該實現一個 `DownloaderFactory`，它將用於檢測 URL 是否匹配並創建上述 `Downloader`。
|
||||
- 你需要在 `init()` 中通過 `RegisterDownloaderFactory` 註冊 `DownloaderFactory`。
|
||||
|
||||
你可以在 [downloader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/downloader.go) 中找到這些介面。
|
||||
|
||||
## 上傳器介面
|
||||
|
||||
目前，只實現了一個 `GiteaLocalUploader`，因此我們僅通過此 `Uploader` 將下載的數據保存到本地 Gitea 實例。其他上傳器目前不支持。
|
||||
|
||||
你可以在 [uploader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/uploader.go) 中找到這些介面。
|
||||
+216
@@ -0,0 +1,216 @@
|
||||
---
|
||||
date: "2023-06-01T08:40:00+08:00"
|
||||
slug: "oauth2-provider"
|
||||
sidebar_position: 41
|
||||
aliases:
|
||||
- /zh-tw/oauth2-provider
|
||||
---
|
||||
|
||||
# OAuth2 提供者
|
||||
|
||||
Gitea 支援作為 OAuth2 提供者，允許第三方應用程式在用戶同意的情況下訪問其資源。
|
||||
|
||||
當作為 OAuth2 提供者時，Gitea 會針對相關的 OAuth2 應用程式驗證每個授權請求。此應用程式可以由個別用戶、組織管理員或 Gitea 實例管理員設置。
|
||||
|
||||
無論是誰配置的應用程式，第一次授權嘗試都會在用戶的網頁瀏覽器中打開一個新頁面，提示他們授權應用程式。
|
||||
|
||||
## 配置
|
||||
|
||||
Gitea 中的 OAuth2 應用程式需要以下兩步配置：
|
||||
|
||||
### Gitea 步驟 1
|
||||
|
||||
- 名稱 (`/admin/applications/`)
|
||||
- 重定向 URL (`/admin/applications/`)
|
||||
|
||||
|
||||
|
||||
### Gitea 步驟 2
|
||||
|
||||
- 客戶端 ID (`/admin/applications/oauth2/_id_`)
|
||||
- 客戶端密鑰 (`/admin/applications/oauth2/_id_`)
|
||||
- 機密客戶端狀態 (`/admin/applications/oauth2/_id_`)
|
||||
|
||||
|
||||
|
||||
### 第三方步驟 3
|
||||
|
||||
第三方（中繼方）應用程式的請求必須包括：
|
||||
|
||||
- 憑證（客戶端 ID 和客戶端密鑰）
|
||||
- 所需的範圍和聲明（預期由 Gitea 提供）
|
||||
|
||||
MinIO 的示例：
|
||||
|
||||
|
||||
|
||||
### Gitea 的用戶批准步驟 3
|
||||
|
||||
例如，使用 Gitea 帳戶登錄 MinIO...
|
||||
|
||||
|
||||
...在成功登錄後將顯示批准彈出窗口：
|
||||
|
||||
|
||||
默認情況下，如果第三方設置範圍為 `openid`、`email`、`profile` 和 `groups`，並且用戶批准，應用程式將獲得用戶所有公共和私人資源（倉庫、問題、用戶信息等）的完全訪問權限。
|
||||
|
||||
> **注意：** 目前，如果期望限制訪問，設置 Gitea 中的 OAuth2 應用程式的管理員必須依賴第三方發送的範圍和知情用戶的批准決定。在應用程式設置過程中，管理員無法通過範圍設置限制訪問。
|
||||
|
||||
## 細粒度範圍
|
||||
|
||||
從 v1.23 版本開始，Gitea 支援細粒度範圍，允許第三方請求更有限的訪問權限。這些範圍以前僅適用於[個人訪問令牌](#scopes)，使用戶能夠限制對特定 URL 路徑的訪問。
|
||||
|
||||
範圍按高級 API 路徑分組，並進一步細化如下：
|
||||
|
||||
- `read`：`GET` 路徑
|
||||
- `write`：`POST`、`PUT`、`PATCH` 和 `DELETE` 路徑（以及 `GET`）
|
||||
|
||||
例如，第三方可以請求最小訪問權限，允許 Gitea 作為簡單的 OpenID Connect (OIDC) 提供者。如果第三方僅添加 `public-only` 到 'openid'，不添加其他或任何組合的範圍 `email`、`userinfo` 或 `groups`，Gitea 將作為基本的單一登錄提供者。此配置僅提供用戶可以使用正確憑證登錄的驗證，僅提供基本信息，如用戶名、電子郵件和公共組織和團隊成員資格列表。
|
||||
|
||||
當引入任何來自個人訪問令牌的細粒度範圍時，Gitea 將不允許完全訪問（如默認情況下）。相反，它將根據對倉庫、問題、ActivityPub、管理功能、組織、用戶、包或其他功能的讀寫權限構建細粒度訪問。
|
||||
|
||||
> **注意：** 如果第三方添加任何範圍以外的 OIDC 範圍：`openid`、`email`、`profile` 和 `groups` 或已在個人訪問令牌中找到的範圍，範圍將回退到完全訪問，如 v1.23 之前的情況。
|
||||
|
||||
顯示給用戶的批准頁面顯示第三方請求的範圍列表。一旦批准，此決定將被記住。如果第三方在未來的請求中更改其請求的範圍，整個流程將失敗，需要重新授權。
|
||||
|
||||
## 端點
|
||||
|
||||
| 端點 | URL |
|
||||
| ----------------------- | ----------------------------------- |
|
||||
| OpenID Connect 發現 | `/.well-known/openid-configuration` |
|
||||
| 授權端點 | `/login/oauth/authorize` |
|
||||
| 訪問令牌端點 | `/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)
|
||||
- [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth)
|
||||
|
||||
要作為第三方應用程式使用授權碼授權，需要通過設置中的“應用程式” (`/user/settings/applications`) 部分註冊新應用程式。要測試或調試，你可以使用網頁工具 https://oauthdebugger.com/。
|
||||
|
||||
## 範圍
|
||||
|
||||
Gitea 支援範圍訪問令牌，允許用戶限制令牌僅在選定的 URL 路徑上操作。範圍按高級 API 路徑分組，並進一步細化如下：
|
||||
|
||||
- `read`：`GET` 路徑
|
||||
- `write`：`POST`、`PUT`、`PATCH` 和 `DELETE` 路徑（以及 `GET`）
|
||||
|
||||
Gitea 令牌範圍如下：
|
||||
|
||||
| 名稱 | 描述 |
|
||||
| ----------------------------------------- | --------------------------------------------------------------------------------- |
|
||||
| **（無範圍）** | 不支援。即使是公共倉庫也需要範圍。 |
|
||||
| **activitypub** | `activitypub` API 路徑：ActivityPub 相關操作。 |
|
||||
| **read:activitypub** | 授予 ActivityPub 操作的讀取訪問權限。 |
|
||||
| **write:activitypub** | 授予 ActivityPub 操作的讀寫/刪除訪問權限。 |
|
||||
| **admin** | `/admin/*` API 路徑：全站管理操作（對非管理帳戶隱藏）。 |
|
||||
| **read:admin** | 授予管理操作的讀取訪問權限，例如獲取計劃任務或註冊用戶電子郵件。 |
|
||||
| **write:admin** | 授予管理操作的讀寫/刪除訪問權限，例如運行計劃任務或更新用戶帳戶。 |
|
||||
| **issue** | `issues/*`、`labels/*`、`milestones/*` API 路徑：問題相關操作。 |
|
||||
| **read:issue** | 授予問題操作的讀取訪問權限，例如獲取問題評論、問題附件和里程碑。 |
|
||||
| **write:issue** | 授予問題操作的讀寫/刪除訪問權限，例如發布或編輯問題評論或附件，並更新里程碑。 |
|
||||
| **misc** | 保留供未來使用。 |
|
||||
| **read:misc** | 保留供未來使用。 |
|
||||
| **write:misc** | 保留供未來使用。 |
|
||||
| **notification** | `notification/*` API 路徑：用戶通知操作。 |
|
||||
| **read:notification** | 授予用戶通知的讀取訪問權限，例如用戶訂閱的通知和閱讀新通知。 |
|
||||
| **write:notification** | 授予用戶通知的讀寫/刪除訪問權限，例如將通知標記為已讀。 |
|
||||
| **organization** | `orgs/*` 和 `teams/*` API 路徑：組織和團隊管理操作。 |
|
||||
| **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** | 授予用戶操作的讀寫/刪除訪問權限，例如更新用戶倉庫訂閱、關注的用戶和用戶設置。 |
|
||||
|
||||
## 預配置應用程式
|
||||
|
||||
Gitea 在啟動時默認為以下服務創建 OAuth 應用程式，因為我們認為這些應用程式是普遍有用的。
|
||||
|
||||
| 應用程式 | 描述 | 客戶端 ID |
|
||||
| --------------------------------------------------------------------------------- | ------------ | -------------------------------------- |
|
||||
| [git-credential-oauth](https://github.com/hickford/git-credential-oauth) | Git 憑證助手 | `a4792ccc-144e-407e-86c9-5e7d8d9c3269` |
|
||||
| [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` 參數進行控制。
|
||||
|
||||
## 客戶端類型
|
||||
|
||||
Gitea 支援機密和公共客戶端類型，[如 RFC 6749 定義](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1)。
|
||||
|
||||
對於公共客戶端，重定向 URI 為回送 IP 地址，例如 `http://127.0.0.1/` 允許任何端口。避免使用 `localhost`，[如 RFC 8252 建議](https://datatracker.ietf.org/doc/html/rfc8252#section-8.3)。
|
||||
|
||||
## 示例
|
||||
|
||||
### 機密客戶端
|
||||
|
||||
:::note
|
||||
此示例不使用 PKCE。
|
||||
:::
|
||||
|
||||
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 攻擊。
|
||||
|
||||
|
||||
|
||||
現在將要求用戶授權你的應用程式。如果他們授權，用戶將被重定向到 `REDIRECT_URL`，例如：
|
||||
|
||||
```curl
|
||||
https://[REDIRECT_URI]?code=RETURNED_CODE&state=STATE
|
||||
```
|
||||
|
||||
2. 使用重定向提供的 `code`，你可以請求新的應用程式和刷新令牌。訪問令牌端點接受 `application/json` 和 `application/x-www-form-urlencoded` 主體的 POST 請求，例如：
|
||||
|
||||
```curl
|
||||
POST https://[YOUR-GITEA-URL]/login/oauth/access_token
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"client_id": "YOUR_CLIENT_ID",
|
||||
"client_secret": "YOUR_CLIENT_SECRET",
|
||||
"code": "RETURNED_CODE",
|
||||
"grant_type": "authorization_code",
|
||||
"redirect_uri": "REDIRECT_URI"
|
||||
}
|
||||
```
|
||||
|
||||
回應：
|
||||
|
||||
```json
|
||||
{
|
||||
"access_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjowLCJleHAiOjE1NTUxNzk5MTIsImlhdCI6MTU1NTE3NjMxMn0.0-iFsAwBtxuckA0sNZ6QpBQmywVPz129u75vOM7wPJecw5wqGyBkmstfJHAjEOqrAf_V5Z-1QYeCh_Cz4RiKug",
|
||||
"token_type": "bearer",
|
||||
"expires_in": 3600,
|
||||
"refresh_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjoxLCJjbnQiOjEsImV4cCI6MTU1NzgwNDMxMiwiaWF0IjoxNTU1MTc2MzEyfQ.S_HZQBy4q9r5SEzNGNIoFClT43HPNDbUdHH-GYNYYdkRfft6XptJBkUQscZsGxOW975Yk6RbgtGvq1nkEcklOw"
|
||||
}
|
||||
```
|
||||
|
||||
`CLIENT_SECRET` 是為此應用程式生成的唯一密鑰。請注意，密鑰僅在你創建/註冊應用程式後可見，無法恢復。如果你丟失了密鑰，必須通過應用程式設置重新生成密鑰。
|
||||
|
||||
`access_token` 請求中的 `REDIRECT_URI` 必須與 `authorize` 請求中的 `REDIRECT_URI` 匹配。
|
||||
|
||||
3. 使用 `access_token` 進行 [API 請求](development/api-usage.md#oauth2-provider) 以訪問用戶的資源。
|
||||
|
||||
### 公共客戶端 (PKCE)
|
||||
|
||||
PKCE（代碼交換的證明密鑰）是 OAuth 流程的擴展，允許在不需要提供客戶端密鑰的情況下進行安全的憑證交換。
|
||||
|
||||
**注意**：請確保你已將你的 OAuth 應用程式註冊為公共客戶端。
|
||||
|
||||
為了實現這一點，你必須為每個授權請求提供一個 `code_verifier`。`code_verifier` 必須是一個隨機字串，最小長度為 43 個字符，最大長度為 128 個字符。它可以包含字母
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
date: "2017-01-20T15:00:00+08:00"
|
||||
title: "Help"
|
||||
slug: "help"
|
||||
sidebar_position: 5
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "Help"
|
||||
sidebar_position: 100
|
||||
identifier: "help"
|
||||
---
|
||||
@@ -0,0 +1,389 @@
|
||||
---
|
||||
date: "2019-04-05T16:00:00+02:00"
|
||||
slug: "faq"
|
||||
sidebar_position: 5
|
||||
aliases:
|
||||
- /zh-tw/faq
|
||||
---
|
||||
|
||||
# 常見問題
|
||||
|
||||
此頁面包含一些常見問題和答案。
|
||||
|
||||
如需更多幫助資源，請查看所有[支援選項](help/support.md)。
|
||||
|
||||
## 1.x 和 1.x.x 下載之間的區別，如何獲取最新的穩定版本並修復錯誤？
|
||||
|
||||
以版本 1.20.x 為例。
|
||||
|
||||
在我們的[下載頁面](https://dl.gitea.com/gitea/)上，您將看到 1.20 目錄以及 1.20.0、1.20.1 目錄。
|
||||
|
||||
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.x）下載將隨著提交合併到各自的分支而變化，它們包含在標籤發布之前的最新更改/修復。
|
||||
|
||||
如果錯誤修復針對 1.20.1，但 1.20.1 尚未發布，您可以獲取 "1.20-nightly" 構建以獲取錯誤修復。
|
||||
|
||||
## 如何找到配置文件 "app.ini"
|
||||
|
||||
這取決於您如何安裝 Gitea。如果您沒有手動設置自定義路徑或配置文件的路徑，
|
||||
那麼配置文件 (app
|
||||
|
||||
---
|
||||
|
||||
date: "2019-04-05T16:00:00+02:00"
|
||||
slug: "faq"
|
||||
sidebar_position: 5
|
||||
aliases:
|
||||
|
||||
- /zh-tw/faq
|
||||
|
||||
---
|
||||
|
||||
# FAQ
|
||||
|
||||
This page contains some common questions and answers.
|
||||
|
||||
For more help resources, check all [Support Options](help/support.md).
|
||||
|
||||
## Difference between 1.x and 1.x.x downloads, how can I get latest stable release with bug fixes?
|
||||
|
||||
Version 1.20.x will be used for this example.
|
||||
|
||||
On our [downloads page](https://dl.gitea.com/gitea/) you will see a 1.20 directory, as well as directories for 1.20.0, 1.20.1.
|
||||
|
||||
The 1.20 directory is the nightly build, which is built on each merged commit to the [`release/v1.20`](https://github.com/go-gitea/gitea/tree/release/v1.20) branch.
|
||||
|
||||
The 1.20.0 directory is a release build that was created when the [`v1.20.0`](https://github.com/go-gitea/gitea/releases/tag/v1.20.0) tag was created.
|
||||
|
||||
The nightly builds (1.x) downloads will change as commits are merged to their respective branch, they contain the latest changes/fixes before a tag release is built.
|
||||
|
||||
If a bug fix is targeted on 1.20.1 but 1.20.1 is not released yet, you can get the "1.20-nightly" build to get the bug fix.
|
||||
|
||||
## How to find the config file "app.ini"
|
||||
|
||||
It depends on how you installed Gitea. If you didn't set a path for custom path or config file manually,
|
||||
then the config file (app.ini) should exists in the "custom/conf" directory of your Gitea's working path.
|
||||
Some package vendors might use "/etc/gitea" to store the config file, while some others don't.
|
||||
|
||||
You could manually find the config file (app.ini) by checking Gitea's startup logs
|
||||
or reading the Gitea Web's Site Administrator -> Confugiraton Summary.
|
||||
|
||||
If you are using some isolated enviroments like container (docker),
|
||||
the path you see usually is not what it is in the host's filesystem.
|
||||
In this case you need to check the container's filesystem volume mapping
|
||||
and figure out the real path of the config file on the host.
|
||||
|
||||
## Where does Gitea store what file
|
||||
|
||||
- _`AppWorkPath`_
|
||||
- The `WORK_PATH` option in `app.ini`
|
||||
- Else the `--work-path` flag
|
||||
- Else Environment variable `GITEA_WORK_DIR`
|
||||
- Else a built-in value set at build time
|
||||
- Else the directory that contains the Gitea binary
|
||||
- `AppDataPath` (default for database, indexers, etc.)
|
||||
- `APP_DATA_PATH` from `app.ini`
|
||||
- Else _`AppWorkPath`_`/data`
|
||||
- _`CustomPath`_ (custom templates)
|
||||
- The `--custom-path` flag
|
||||
- Else Environment variable `GITEA_CUSTOM`
|
||||
- Else a built-in value set at build time
|
||||
- Else _`AppWorkPath`_`/custom`
|
||||
- HomeDir
|
||||
- Unix: Environment variable `HOME`
|
||||
- Windows: Environment variable `USERPROFILE`, else environment variables `HOMEDRIVE`+`HOMEPATH`
|
||||
- RepoRootPath
|
||||
- `ROOT` in the \[repository] section of `app.ini` if absolute
|
||||
- Else _`AppWorkPath`_`/ROOT` if `ROOT` in the \[repository] section of `app.ini` if relative
|
||||
- Default `%(APP_DATA_PATH)/gitea-repositories`
|
||||
- INI (config file)
|
||||
- `--config` flag
|
||||
- A possible built-in value set a build time
|
||||
- Else _`CustomPath`_`/conf/app.ini`
|
||||
- SQLite Database
|
||||
- `PATH` in `database` section of `app.ini`
|
||||
- Else `%(APP_DATA_PATH)/gitea.db`
|
||||
|
||||
## Not seeing a clone URL or the clone URL being incorrect
|
||||
|
||||
There are a few places that could make this show incorrectly.
|
||||
|
||||
1. If using a reverse proxy, make sure you have followed the correction directions in the [reverse proxy guide](../administration/reverse-proxies.md)
|
||||
2. Make sure you have correctly set `ROOT_URL` in the `server` section of your `app.ini`
|
||||
|
||||
If certain clone options aren't showing up (HTTP/S or SSH), the following options can be checked in your `app.ini`
|
||||
|
||||
- `DISABLE_HTTP_GIT`: if set to true, there will be no HTTP/HTTPS link
|
||||
- `DISABLE_SSH`: if set to true, there will be no SSH link
|
||||
- `SSH_EXPOSE_ANONYMOUS`: if set to false, SSH links will be hidden for anonymous users
|
||||
|
||||
## File upload fails with: 413 Request Entity Too Large
|
||||
|
||||
This error occurs when the reverse proxy limits the file upload size.
|
||||
|
||||
See the [reverse proxy guide](../administration/reverse-proxies.md) for a solution with nginx.
|
||||
|
||||
## Custom Templates not loading or working incorrectly
|
||||
|
||||
Gitea's custom templates must be added to the correct location or Gitea will not find and use them.
|
||||
|
||||
The correct path for the template(s) will be relative to the `CustomPath`
|
||||
|
||||
1. To find `CustomPath`, look for Custom File Root Path in Site Administration -> Configuration
|
||||
2. If you are still unable to find a path, the default can be [calculated above](#where-does-gitea-store-what-file)
|
||||
3. Once you have figured out the correct custom path, you can refer to the [customizing Gitea](../administration/customizing-gitea.md) page to add your template to the correct location.
|
||||
|
||||
## Does Gitea have a "GitHub/GitLab pages" feature?
|
||||
|
||||
Gitea doesn't provide a built-in Pages server. You need a dedicated domain to serve static pages to avoid CSRF security risks.
|
||||
|
||||
For simple usage, you can use a reverse proxy to rewrite & serve static contents from Gitea's raw file URLs.
|
||||
|
||||
And there are already available third-party services, like a standalone [pages server](https://codeberg.org/Codeberg/pages-server) or a [caddy plugin](https://github.com/42wim/caddy-gitea), that can provide the required functionality.
|
||||
|
||||
## Active user vs login prohibited user
|
||||
|
||||
In Gitea, an "active" user refers to a user that has activated their account via email.
|
||||
|
||||
A "login prohibited" user is a user that is not allowed to log in to Gitea anymore
|
||||
|
||||
## What is Swagger?
|
||||
|
||||
[Swagger](https://swagger.io/) is what Gitea uses for its API documentation.
|
||||
|
||||
All Gitea instances have the built-in API and there is no way to disable it completely.
|
||||
You can, however, disable showing its documentation by setting `ENABLE_SWAGGER` to `false` in the `api` section of your `app.ini`.
|
||||
For more information, refer to Gitea's [API docs](development/api-usage.md).
|
||||
|
||||
You can see the latest API (for example) on https://gitea.com/api/swagger
|
||||
|
||||
You can also see an example of the `swagger.json` file at https://gitea.com/swagger.v1.json
|
||||
|
||||
## Adjusting your server for public/private use
|
||||
|
||||
### Preventing spammers
|
||||
|
||||
There are multiple things you can combine to prevent spammers.
|
||||
|
||||
1. By whitelisting or blocklisting certain email domains
|
||||
2. By only whitelisting certain domains with OpenID (see below)
|
||||
3. Setting `ENABLE_CAPTCHA` to `true` in your `app.ini` and properly configuring `RECAPTCHA_SECRET` and `RECAPTCHA_SITEKEY`
|
||||
4. Settings `DISABLE_REGISTRATION` to `true` and creating new users via the [CLI](../administration/command-line.md), [API](development/api-usage.md), or Gitea's Admin UI
|
||||
|
||||
### Only allow/block certain email domains
|
||||
|
||||
You can configure `EMAIL_DOMAIN_WHITELIST` or `EMAIL_DOMAIN_BLOCKLIST` in your app.ini under `[service]`
|
||||
|
||||
### Only allow/block certain OpenID providers
|
||||
|
||||
You can configure `WHITELISTED_URIS` or `BLACKLISTED_URIS` under `[openid]` in your `app.ini`
|
||||
|
||||
:::note
|
||||
Whitelisted takes precedence, so if it is non-blank then blacklisted is ignored.
|
||||
:::
|
||||
|
||||
### Issue only users
|
||||
|
||||
The current way to achieve this is to create/modify a user with a max repo creation limit of 0.
|
||||
|
||||
### Restricted users
|
||||
|
||||
Restricted users are limited to a subset of the content based on their organization/team memberships and collaborations, ignoring the public flag on organizations/repos etc.\_\_
|
||||
|
||||
Example use case: A company runs a Gitea instance that requires login. Most repos are public (accessible/browsable by all co-workers).
|
||||
|
||||
At some point, a customer or third party needs access to a specific repo and only that repo. Making such a customer account restricted and granting any needed access using team membership(s) and/or collaboration(s) is a simple way to achieve that without the need to make everything private.
|
||||
|
||||
### Enable Fail2ban
|
||||
|
||||
Use [Fail2Ban](../administration/fail2ban-setup.md) to monitor and stop automated login attempts or other malicious behavior based on log patterns
|
||||
|
||||
## SSHD vs built-in SSH
|
||||
|
||||
SSHD is the built-in SSH server on most Unix systems.
|
||||
|
||||
Gitea also provides its own SSH server, for usage when SSHD is not available.
|
||||
|
||||
## Translation is incorrect/how to add more translations
|
||||
|
||||
Our translations are currently crowd-sourced on our [Crowdin project](https://crowdin.com/project/gitea)
|
||||
|
||||
Whether you want to change a translation or add a new one, it will need to be there as all translations are overwritten in our CI via the Crowdin integration.
|
||||
|
||||
## Push Hook / Webhook / Actions aren't running
|
||||
|
||||
If you can push but can't see push activities on the home dashboard, or the push doesn't trigger webhook and Actions workflows, it's likely that the git hooks are not working.
|
||||
|
||||
There are a few possibilities:
|
||||
|
||||
1. The git hooks are out of sync: run "Resynchronize pre-receive, update and post-receive hooks of all repositories" on the site admin panel
|
||||
2. The git repositories (and hooks) are stored on some filesystems (ex: mounted by NAS) which don't support script execution, make sure the filesystem supports `chmod a+x any-script`
|
||||
3. If you are using docker, make sure Docker Server (not the client) >= 20.10.6
|
||||
|
||||
## SSH issues
|
||||
|
||||
If you cannot reach repositories over `ssh`, but `https` works fine, consider looking into the following.
|
||||
|
||||
First, make sure you can access Gitea via SSH.
|
||||
|
||||
`ssh git@myremote.example`
|
||||
|
||||
If the connection is successful, you should receive an error message like the following:
|
||||
|
||||
```
|
||||
Hi there, You've successfully authenticated, but Gitea does not provide shell access.
|
||||
If this is unexpected, please log in with password and setup Gitea under another user.
|
||||
```
|
||||
|
||||
If you do not get the above message but still connect, it means your SSH key is **not** being managed by Gitea. This means hooks won't run, among other potential problems.
|
||||
|
||||
If you cannot connect at all, your SSH key may not be configured correctly locally.
|
||||
This is specific to SSH and not Gitea, so will not be covered here.
|
||||
|
||||
### SSH Common Errors
|
||||
|
||||
```
|
||||
Permission denied (publickey).
|
||||
fatal: Could not read from remote repository.
|
||||
```
|
||||
|
||||
This error signifies that the server rejected a log in attempt, check the
|
||||
following things:
|
||||
|
||||
- On the client:
|
||||
- Ensure the public and private ssh keys are added to the correct Gitea user.
|
||||
- Make sure there are no issues in the remote url. In particular, ensure the name of the
|
||||
Git user (before the `@`) is spelled correctly.
|
||||
- Ensure public and private ssh keys are correct on client machine.
|
||||
- On the server:
|
||||
|
||||
- Make sure the repository exists and is correctly named.
|
||||
- Check the permissions of the `.ssh` directory in the system user's home directory.
|
||||
- Verify that the correct public keys are added to `.ssh/authorized_keys`.
|
||||
|
||||
Try to run `Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys)` on the
|
||||
Gitea admin panel.
|
||||
|
||||
- Read Gitea logs.
|
||||
- Read /var/log/auth (or similar).
|
||||
- Check permissions of repositories.
|
||||
|
||||
The following is an example of a missing public SSH key where authentication
|
||||
succeeded, but some other setting is preventing SSH from reaching the correct
|
||||
repository.
|
||||
|
||||
```
|
||||
fatal: Could not read from remote repository.
|
||||
|
||||
Please make sure you have the correct access rights
|
||||
and the repository exists.
|
||||
```
|
||||
|
||||
In this case, look into the following settings:
|
||||
|
||||
- On the server:
|
||||
- Make sure that the `git` system user has a usable shell set
|
||||
- Verify this with `getent passwd git | cut -d: -f7`
|
||||
- `usermod` or `chsh` can be used to modify this.
|
||||
- Ensure that the `gitea serv` command in `.ssh/authorized_keys` uses the
|
||||
correct configuration file.
|
||||
|
||||
## Missing releases after migrating repository with tags
|
||||
|
||||
To migrate an repository _with_ all tags, you need to do two things:
|
||||
|
||||
- Push tags to the repository:
|
||||
|
||||
```
|
||||
git push --tags
|
||||
```
|
||||
|
||||
- (Re-)sync tags of all repositories within Gitea:
|
||||
|
||||
```
|
||||
gitea admin repo-sync-releases
|
||||
```
|
||||
|
||||
## How can I create users before starting Gitea
|
||||
|
||||
Gitea provides a sub-command `gitea migrate` to initialize the database, after which you can use the [admin CLI commands](../administration/command-line.md#admin) to add users like normal.
|
||||
|
||||
## How can I enable password reset
|
||||
|
||||
There is no setting for password resets. It is enabled when a [mail service](../administration/email-setup.md) is configured, and disabled otherwise.
|
||||
|
||||
## How can a user's password be changed
|
||||
|
||||
- As an **admin**, you can change any user's password (and optionally force them to change it on next login)...
|
||||
|
||||
- By navigating to your `Site Administration -> User Accounts` page and editing a user.
|
||||
- By using the [admin CLI commands](../administration/command-line.md#admin).
|
||||
|
||||
Keep in mind most commands will also need a [global flag](../administration/command-line.md#global-options) to point the CLI at the correct configuration.
|
||||
|
||||
- As a **user** you can change it...
|
||||
|
||||
- In your account `Settings -> Account` page (this method **requires** you to know your current password).
|
||||
- By using the `Forgot Password` link.
|
||||
|
||||
If the `Forgot Password/Account Recovery` page is disabled, please contact your administrator to configure a [mail service](../administration/email-setup.md).
|
||||
|
||||
## Warnings about struct defaults during database startup
|
||||
|
||||
Sometimes when there are migrations the old columns and default values may be left
|
||||
unchanged in the database schema. This may lead to warning such as:
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
These can safely be ignored, but you are able to stop these warnings by getting Gitea to recreate these tables using:
|
||||
|
||||
```
|
||||
gitea doctor recreate-table user
|
||||
```
|
||||
|
||||
This will cause Gitea to recreate the user table and copy the old data into the new table
|
||||
with the defaults set appropriately.
|
||||
|
||||
You can ask Gitea to recreate multiple tables using:
|
||||
|
||||
```
|
||||
gitea doctor recreate-table table1 table2 ...
|
||||
```
|
||||
|
||||
And if you would like Gitea to recreate all tables simply call:
|
||||
|
||||
```
|
||||
gitea doctor recreate-table
|
||||
```
|
||||
|
||||
It is highly recommended to back-up your database before running these commands.
|
||||
|
||||
## How to adopt repositories from disk
|
||||
|
||||
- Add your (bare) repositories to the correct spot for your configuration (`repository.ROOT`), ensuring they are in the correct layout `<REPO_ROOT>/[user]/[repo].git`.
|
||||
- **Note:** the directory names must be lowercase.
|
||||
- You can also check `<ROOT_URL>/admin/config` for the repository root path.
|
||||
- Ensure that the user/org exists that you want to adopt repositories for.
|
||||
- As an admin, go to `<ROOT_URL>/admin/repos/unadopted` and search.
|
||||
- Users can also be given similar permissions via config [`ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`](../administration/config-cheat-sheet.md#repository-repository).
|
||||
- If the above steps are done correctly, you should be able to select repositories to adopt.
|
||||
- If no repositories are found, enable [debug logging](../administration/config-cheat-sheet.md#repository-repository) to check for any specific errors.
|
||||
|
||||
## Gitea can't start on NFS
|
||||
|
||||
In most cases, it's caused by broken NFS lock system. You can try to stop Gitea process and
|
||||
run `flock -n /data-nfs/gitea/queues/LOCK echo 'lock acquired'` to see whether the lock can be acquired immediately.
|
||||
If the lock can't be acquired, NFS might report some errors like `lockd: cannot monitor node-3, statd: server rpc.statd not responding, timed out` in its server logs.
|
||||
|
||||
Then the NFS lock could be reset by:
|
||||
|
||||
```bash
|
||||
# /etc/init.d/nfs stop
|
||||
# rm -rf /var/lib/nfs/sm/*
|
||||
# /etc/init.d/nfs start
|
||||
```
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
date: "2018-05-21T15:00:00+00:00"
|
||||
slug: "support"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-tw/seek-help
|
||||
---
|
||||
|
||||
# 支援選項
|
||||
|
||||
- [付費商業支援](https://about.gitea.com/)
|
||||
- [Discord](https://discord.gg/Gitea)
|
||||
- [論壇](https://forum.gitea.com/)
|
||||
- [Matrix](https://matrix.to/#/#gitea-space:matrix.org)
|
||||
- 注意：大多數 Matrix 頻道與其在 Discord 中的對應頻道橋接，可能會在橋接過程中出現一些不穩定的情況。
|
||||
- 中文支援
|
||||
- [Discourse 中文分類](https://forum.gitea.com/c/5-category/5)
|
||||
- QQ 群 328432459
|
||||
|
||||
# 錯誤報告
|
||||
|
||||
如果您發現錯誤，請[在 GitHub 上創建問題](https://github.com/go-gitea/gitea/issues)。
|
||||
|
||||
:::note
|
||||
尋求支援時，最好準備以下信息，以便幫助您的人擁有所有需要的信息：
|
||||
:::
|
||||
|
||||
1. 您的 `app.ini`（必要時刪除任何敏感數據）。
|
||||
2. 您看到的任何錯誤消息。
|
||||
3. Gitea 日誌以及與情況相關的所有其他日誌。
|
||||
- 收集 `trace` / `debug` 級別的日誌更有用（請參閱下一節）。
|
||||
- 使用 systemd 時，使用 `journalctl --lines 1000 --unit gitea` 收集日誌。
|
||||
- 使用 docker 時，使用 `docker logs --tail 1000 <gitea-container>` 收集日誌。
|
||||
4. 可重現的步驟，以便其他人可以更快、更輕鬆地重現和理解問題。
|
||||
- 可以使用 [demo.gitea.com](https://demo.gitea.com) 重現問題。
|
||||
5. 如果您遇到緩慢/掛起/死鎖問題，請在問題發生時報告堆棧跟踪。
|
||||
轉到“網站管理” -> “監控” -> “堆棧跟踪” -> “下載診斷報告”。
|
||||
|
||||
# 高級錯誤報告提示
|
||||
|
||||
## 更多日誌配置選項
|
||||
|
||||
默認情況下，日誌輸出到控制台，級別為 `info`。
|
||||
如果您需要設置日誌級別和/或從文件中收集日誌，
|
||||
您可以將以下配置複製到您的 `app.ini`（刪除所有其他 `[log]` 部分），
|
||||
然後您將在 Gitea 的日誌目錄（默認：`%(GITEA_WORK_DIR)/log`）中找到 `*.log` 文件。
|
||||
|
||||
```ini
|
||||
; 要顯示所有 SQL 日誌，您還可以在 [database] 部分中設置 LOG_SQL=true
|
||||
[log]
|
||||
LEVEL=debug
|
||||
MODE=console,file
|
||||
```
|
||||
|
||||
## 通過命令行收集堆棧跟踪
|
||||
|
||||
Gitea 可以使用 Golang 的 pprof 處理程序和工具鏈來收集堆棧跟踪和其他運行時信息。
|
||||
|
||||
如果 Web UI 停止工作，您可以嘗試通過命令行收集堆棧跟踪：
|
||||
|
||||
1. 設置 `app.ini`：
|
||||
|
||||
```
|
||||
[server]
|
||||
ENABLE_PPROF = true
|
||||
```
|
||||
|
||||
2. 重啟 Gitea
|
||||
|
||||
3. 嘗試觸發錯誤，當請求卡住一段時間時，
|
||||
使用 `curl` 或瀏覽器訪問：`http://127.0.0.1:6060/debug/pprof/goroutine?debug=1` 獲取堆棧跟踪。
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
date: "2016-11-08T16:00:00+02:00"
|
||||
slug: /
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# 什麼是 Gitea？
|
||||
|
||||
Gitea 是一個無痛、自我託管的全方位軟體開發服務。它包括 Git 託管、代碼審查、團隊協作、包註冊表和 CI/CD。它類似於 GitHub、Bitbucket 和 GitLab。
|
||||
|
||||
Gitea 最初是從 [Gogs](https://gogs.io) 分叉出來的，幾乎所有的代碼都已經改變。請參閱 [Gitea 公告](https://blog.gitea.com/welcome-to-gitea/) 博客文章以了解分叉的理由。
|
||||
|
||||
:::warning
|
||||
|
||||
Gitea 不會從上游發送或挑選提交，因此如果您從 Gogs 升級到 Gitea，無法保證它能正常工作。建議的方法是將存儲庫從 Gogs 遷移到 Gitea。
|
||||
|
||||
:::
|
||||
|
||||
## 目的
|
||||
|
||||
這個項目的目標是提供最簡單、最快速、最無痛的方式來設置自我託管的 Git 服務。
|
||||
|
||||
使用 Go，可以在 Go 支持的 **所有平台** 上跨平台獨立完成，包括 Linux、macOS 和 Windows，支持 x86、amd64、ARM 和 PowerPC 架構。
|
||||
您可以使用 [在線演示](https://demo.gitea.com) 試用。
|
||||
|
||||
## 功能
|
||||
|
||||
- **代碼託管**
|
||||
|
||||
Gitea 支持創建和管理存儲庫、瀏覽提交歷史和代碼文件、審查和合併代碼提交、管理協作者、處理分支等。它還支持許多常見的 Git 功能，如標籤、挑選、鉤子、集成協作工具等。
|
||||
|
||||
- **輕量且快速**
|
||||
|
||||
Gitea 的設計目標之一是輕量且快速響應。與一些大型代碼託管平台不同，它保持精簡，在速度方面表現良好，適合資源有限的服務器環境。由於其輕量設計，Gitea 的資源消耗相對較低，在資源受限的環境中表現良好。
|
||||
|
||||
- **簡單部署和維護**
|
||||
|
||||
它可以輕鬆部署在各種服務器上，無需複雜的配置或依賴項。這使得個人開發者或小型團隊可以方便地設置和管理自己的 Git 服務。
|
||||
|
||||
- **安全性**
|
||||
|
||||
Gitea 非常重視安全性，提供用戶權限管理、訪問控制列表等功能，以確保代碼和數據的安全。
|
||||
|
||||
- **代碼審查**
|
||||
|
||||
代碼審查支持 Pull Request 工作流程和 AGit 工作流程。審查者可以在線瀏覽代碼並提供審查意見或反饋。提交者可以接收審查意見並在線回應或修改代碼。代碼審查可以幫助個人和組織提高代碼質量。
|
||||
|
||||
- **CI/CD**
|
||||
|
||||
Gitea Actions 支持 CI/CD 功能，與 GitHub Actions 兼容。用戶可以使用熟悉的 YAML 格式編寫工作流程，並重用各種現有的 Actions 插件。Actions 插件支持從任何 Git 網站下載。
|
||||
|
||||
- **項目管理**
|
||||
|
||||
Gitea 通過列和問題跟踪項目需求、功能和錯誤。問題支持分支、標籤、里程碑、分配、時間跟踪、截止日期、依賴項等功能。
|
||||
|
||||
- **工件存儲庫**
|
||||
|
||||
Gitea 支持超過 20 種不同類型的公共或私有軟件包管理，包括 Cargo、Chef、Composer、Conan、Conda、Container、Helm、Maven、npm、NuGet、Pub、PyPI、RubyGems、Vagrant 等。
|
||||
|
||||
- **開源社區支持**
|
||||
|
||||
Gitea 是基於 MIT 許可證的開源項目。它擁有活躍的開源社區，不斷開發和改進平台。該項目還積極歡迎社區貢獻，確保更新和創新。
|
||||
|
||||
- **多語言支持**
|
||||
|
||||
Gitea 提供多語言界面，滿足全球用戶需求，促進國際化和本地化。
|
||||
|
||||
有關更詳細的信息，請參閱：https://docs.gitea.com/installation/comparison#general-features
|
||||
|
||||
## 系統要求
|
||||
|
||||
- Raspberry Pi 3 足夠運行 Gitea 以應對小型工作負載。
|
||||
- 2 個 CPU 核心和 1GB RAM 通常足夠小型團隊/項目使用。
|
||||
- Gitea 應該在 UNIX 類系統上的專用非 root 系統帳戶下運行。
|
||||
- 注意：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)
|
||||
- ORM：[XORM](https://xorm.io)
|
||||
- UI 框架：
|
||||
- [jQuery](https://jquery.com)
|
||||
- [Fomantic UI](https://fomantic-ui.com)
|
||||
- [Vue3](https://vuejs.org)
|
||||
- 以及各種組件（請參閱 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/) 獲取更多第三方集成支持
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
title: "Installation"
|
||||
slug: "installation"
|
||||
sidebar_position: 10
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "Installation"
|
||||
sidebar_position: 10
|
||||
identifier: "installation"
|
||||
---
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
date: "2018-05-07T13:00:00+02:00"
|
||||
slug: "comparison"
|
||||
sidebar_position: 5
|
||||
aliases:
|
||||
- /zh-tw/comparison
|
||||
---
|
||||
|
||||
# 與其他 Git 託管的比較
|
||||
|
||||
為了幫助您決定 Gitea 是否適合您的需求，這裡是它與其他 Git 自託管選項的比較。
|
||||
|
||||
請注意，我們不會定期檢查其他產品的功能變更，因此此列表可能已過時。如果您發現需要在下表中更新的內容，請[打開一個問題](https://github.com/go-gitea/gitea/issues/new/choose)。
|
||||
|
||||
_表格中使用的符號：_
|
||||
|
||||
- _✓ - 支持_
|
||||
|
||||
- _⁄ - 支持但功能有限_
|
||||
|
||||
- _✘ - 不支持_
|
||||
|
||||
- _⚙️ - 通過第三方軟件支持_
|
||||
|
||||
## 一般功能
|
||||
|
||||
| 功能 | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
|
||||
| ------------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
|
||||
| 開源且免費 | ✓ | ✘ | ✓ | ✘ | ✘ | ✓ | ✓ |
|
||||
| 低 RAM/ CPU 使用量 | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ |
|
||||
| 多數據庫支持 | ✓ | ✘ | ⁄ | ⁄ | ✓ | ✓ | ✓ |
|
||||
| 多操作系統支持 | ✓ | ✘ | ✘ | ✘ | ✘ | ✓ | ✓ |
|
||||
| 易於升級 | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
| 遠程遙測 | **✘** | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 第三方渲染工具支持 | ✓ | ✘ | ✘ | ✘ | ✓ | ✘ | ✘ |
|
||||
| WebAuthn (2FA) | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ |
|
||||
| 廣泛的 API | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 內置包/容器註冊表 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 同步提交到外部倉庫（推送鏡像） | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
| 從外部倉庫同步提交（拉取鏡像） | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
| 淺色和深色主題 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 自定義主題支持 | ✓ | ✘ | ✘ | ✘ | ✓ | ✓ | ✓ |
|
||||
| Markdown 支持 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| CSV 支持 | ✓ | ✓ | ✘ | ✘ | ✓ | ✘ | ✘ |
|
||||
| 'GitHub / GitLab 頁面' | [⚙️][gitea-pages-server], [⚙️][gitea-caddy-plugin] | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Gists / Snippets | [⚙️][opengist] | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 特定倉庫的 wiki（作為倉庫本身） | ✓ | ✓ | ✓ | ✓ | / | ✘ | ✘ |
|
||||
| 部署令牌 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 具有寫權限的倉庫令牌 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| RSS 提要 | ✓ | ✓ | ✘ | ✘ | ✘ | ✓ | ✓ |
|
||||
| 內置 CI/CD | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 子組：組內組 | [✘](https://github.com/go-gitea/gitea/issues/1872) | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
|
||||
| 與其他實例的交互 | [/](https://github.com/go-gitea/gitea/issues/18240) | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ |
|
||||
| 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 等） | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 驗證提交者 | ⁄ | ? | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| GPG 簽名提交 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| SSH 簽名提交 | ✓ | ✓ | ✓ | ✓ | ? | ✘ | ✘ |
|
||||
| 拒絕未簽名的提交 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 從其他服務遷移倉庫 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 倉庫活動頁面 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 分支管理器 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 創建新分支 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| 網頁代碼編輯器 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 提交圖 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 模板倉庫 | ✓ | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ |
|
||||
| Git Blame | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 圖像更改的可視比較 | ✓ | ✓ | ? | ? | ? | ✘ | ✘ |
|
||||
|
||||
- Gitea 具有內置的倉庫級代碼搜索
|
||||
- 更好的代碼搜索支持可以通過[使用倉庫索引器](../administration/repo-indexer.md)來實現
|
||||
|
||||
## 問題跟踪器
|
||||
|
||||
| Feature | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
|
||||
| ----------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
|
||||
| Issue tracker | ✓ | ✓ | ✓ | ✓ | / | ✘ | ✘ |
|
||||
| Issue templates | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Labels | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Time tracking | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Multiple assignees for issues | ✓ | ✓ | ✘ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Related issues | ✘ | ⁄ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Confidential issues | [✘](https://github.com/go-gitea/gitea/issues/3217) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Comment reactions | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Lock Discussion | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Batch issue handling | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Projects | [/](https://github.com/go-gitea/gitea/issues/14710) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Create branch from issue | [✘](https://github.com/go-gitea/gitea/issues/20226) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Convert comment to new issue | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Issue search | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| Global issue search | [/](https://github.com/go-gitea/gitea/issues/2434) | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| Issue dependency | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ |
|
||||
| Create issue via email | [✘](https://github.com/go-gitea/gitea/issues/6226) | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| Service Desk | [✘](https://github.com/go-gitea/gitea/issues/6219) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
|
||||
## Pull/Merge requests
|
||||
|
||||
| Feature | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
|
||||
| ----------------------------------------------- | -------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
|
||||
| Pull/Merge requests | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Squash merging | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Rebase merging | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Pull/Merge request inline comments | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Pull/Merge request approval | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Pull/Merge require approval | ✓ | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Pull/Merge multiple reviewers | ✓ | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Merge conflict resolution | [✘](https://github.com/go-gitea/gitea/issues/9014) | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| Restrict push and merge access to certain users | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Revert specific commits | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| Pull/Merge requests templates | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
|
||||
| Cherry-picking changes | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ | ✓ |
|
||||
| Download Patch | ✓ | ✓ | ✓ | ✓ | / | ✓ | ✓ |
|
||||
| Merge queues | ✓ | ✓ | ✘ | ✓ | ✘ | ✘ | ✘ |
|
||||
|
||||
## 3rd-party integrations
|
||||
|
||||
| Feature | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
|
||||
| ---------------------------------------------- | -------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
|
||||
| Webhooks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Git Hooks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| AD / LDAP integration | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Multiple LDAP / AD server support | ✓ | ✘ | ✘ | ✓ | ✓ | ✓ | ✓ |
|
||||
| LDAP user synchronization | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ |
|
||||
| SAML 2.0 service provider | [✘](https://github.com/go-gitea/gitea/issues/5512) | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ |
|
||||
| OpenID Connect support | ✓ | ✓ | ✓ | ✓ | ? | ✘ | ✓ |
|
||||
| OAuth 2.0 integration (external authorization) | ✓ | ⁄ | ✓ | ✓ | ? | ✘ | ✓ |
|
||||
| Act as OAuth 2.0 provider | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| Two factor authentication (2FA) | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ |
|
||||
| Integration with the most common services | ✓ | ⁄ | ✓ | ✓ | ⁄ | ✓ | ✓ |
|
||||
| Incorporate external CI/CD | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
|
||||
[gitea-caddy-plugin]: https://github.com/42wim/caddy-gitea
|
||||
[gitea-pages-server]: https://codeberg.org/Codeberg/pages-server
|
||||
[opengist]: https://github.com/thomiceli/opengist
|
||||
+371
@@ -0,0 +1,371 @@
|
||||
---
|
||||
date: "2020-01-16"
|
||||
slug: "database-prep"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
- /zh-tw/database-prep
|
||||
---
|
||||
|
||||
# 數據庫準備
|
||||
|
||||
您需要一個數據庫來使用 Gitea。Gitea 支持 PostgreSQL (>= 12)、MySQL (>= 8.0)、MariaDB (>= 10.4)、SQLite（內置）和 MSSQL (>= 2012 SP4)。本頁將指導您準備數據庫。由於這些數據庫引擎在生產中廣泛使用，這裡將只涵蓋 PostgreSQL 和 MySQL。如果您計劃使用 SQLite，您可以忽略本章。
|
||||
|
||||
:::warning
|
||||
將一種數據庫類型轉換為另一種數據庫類型不是一個經過充分測試的過程，您可能會遇到問題。最好在第一次安裝時選擇最終的數據庫類型。請注意，SQLite 無法擴展；如果您預計您的實例將來會增長，您應該選擇另一種數據庫類型。
|
||||
:::
|
||||
|
||||
如果您使用不受支持的數據庫版本，請[與我們聯繫](/help/support)以獲取有關我們擴展支持合同的信息。我們可以為舊數據庫提供測試和支持，並將這些修復集成到 Gitea 代碼庫中。
|
||||
|
||||
數據庫實例可以與 Gitea 在同一台機器上（本地數據庫設置），也可以在不同的機器上（遠程數據庫）。
|
||||
|
||||
:::note
|
||||
以下所有步驟都要求您選擇的數據庫引擎已安裝在您的系統上。對於遠程數據庫設置，請在數據庫實例上安裝服務器應用程序，並在您的 Gitea 服務器上安裝客戶端程序。客戶端程序用於測試從 Gitea 服務器到數據庫的連接，而 Gitea 本身使用 Go 提供的數據庫驅動程序來完成相同的事情。此外，請確保服務器和客戶端使用相同的引擎版本，以便某些引擎功能正常工作。出於安全原因，請使用安全密碼保護 `root`（MySQL）或 `postgres`（PostgreSQL）數據庫超級用戶。這些步驟假設您在 Linux 上運行數據庫和 Gitea 服務器。
|
||||
:::
|
||||
|
||||
## MySQL/MariaDB
|
||||
|
||||
1. 對於遠程數據庫設置，您需要使 MySQL 監聽您的 IP 地址。在數據庫實例上的 `/etc/mysql/my.cnf` 中編輯 `bind-address` 選項：
|
||||
|
||||
```ini
|
||||
bind-address = 203.0.113.3
|
||||
```
|
||||
|
||||
2. 在數據庫實例上，以 root 身份登錄到數據庫控制台：
|
||||
|
||||
```sh
|
||||
mysql -u root -p
|
||||
```
|
||||
|
||||
按提示輸入密碼。
|
||||
|
||||
3. 創建將由 Gitea 使用的數據庫用戶，通過密碼進行身份驗證。本示例使用 `'gitea'` 作為密碼。請為您的實例使用安全密碼。
|
||||
|
||||
對於本地數據庫：
|
||||
|
||||
```sql
|
||||
SET old_passwords=0;
|
||||
CREATE USER 'gitea'@'%' IDENTIFIED BY 'gitea';
|
||||
```
|
||||
|
||||
對於遠程數據庫：
|
||||
|
||||
```sql
|
||||
SET old_passwords=0;
|
||||
CREATE USER 'gitea'@'192.0.2.10' IDENTIFIED BY 'gitea';
|
||||
```
|
||||
|
||||
其中 `192.0.2.
|
||||
|
||||
---
|
||||
|
||||
date: "2020-01-16"
|
||||
slug: "database-prep"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
|
||||
- /zh-tw/database-prep
|
||||
|
||||
---
|
||||
|
||||
# Database Preparation
|
||||
|
||||
You need a database to use Gitea. Gitea supports PostgreSQL (>= 12), MySQL (>= 8.0), MariaDB (>= 10.4), SQLite (builtin), and MSSQL (>= 2012 SP4). This page will guide into preparing database. Only PostgreSQL and MySQL will be covered here since those database engines are widely-used in production. If you plan to use SQLite, you can ignore this chapter.
|
||||
|
||||
:::warning
|
||||
Converting one database type to another is not a well-tested process and you may experience issues. It is better to choose the final database type at the type of the first installation. Be aware that SQLite does not scale; if you expect your instance to grow at a later time, you should choose another database type.
|
||||
:::
|
||||
|
||||
If you use an unsupported database version, please [get in touch](/help/support) with us for information on our Extended Support Contracts. We can provide testing and support for older databases and integrate those fixes into the Gitea codebase.
|
||||
|
||||
Database instance can be on same machine as Gitea (local database setup), or on different machine (remote database).
|
||||
|
||||
:::note
|
||||
All steps below requires that the database engine of your choice is installed on your system. For remote database setup, install the server application on database instance and client program on your Gitea server. The client program is used to test connection to the database from Gitea server, while Gitea itself use database driver provided by Go to accomplish the same thing. In addition, make sure you use same engine version for both server and client for some engine features to work. For security reason, protect `root` (MySQL) or `postgres` (PostgreSQL) database superuser with secure password. The steps assumes that you run Linux for both database and Gitea servers.
|
||||
:::
|
||||
|
||||
## MySQL/MariaDB
|
||||
|
||||
1. For remote database setup, you will need to make MySQL listen to your IP address. Edit `bind-address` option on `/etc/mysql/my.cnf` on database instance to:
|
||||
|
||||
```ini
|
||||
bind-address = 203.0.113.3
|
||||
```
|
||||
|
||||
2. On database instance, login to database console as root:
|
||||
|
||||
```sh
|
||||
mysql -u root -p
|
||||
```
|
||||
|
||||
Enter the password as prompted.
|
||||
|
||||
3. Create database user which will be used by Gitea, authenticated by password. This example uses `'gitea'` as password. Please use a secure password for your instance.
|
||||
|
||||
For local database:
|
||||
|
||||
```sql
|
||||
SET old_passwords=0;
|
||||
CREATE USER 'gitea'@'%' IDENTIFIED BY 'gitea';
|
||||
```
|
||||
|
||||
For remote database:
|
||||
|
||||
```sql
|
||||
SET old_passwords=0;
|
||||
CREATE USER 'gitea'@'192.0.2.10' IDENTIFIED BY 'gitea';
|
||||
```
|
||||
|
||||
where `192.0.2.10` is the IP address of your Gitea instance.
|
||||
|
||||
Replace username and password above as appropriate.
|
||||
|
||||
4. Create database with UTF-8 charset and case-sensitive collation.
|
||||
|
||||
`utf8mb4_bin` is a common collation for both MySQL/MariaDB.
|
||||
When Gitea starts, it will try to find a better collation (`utf8mb4_0900_as_cs` or `uca1400_as_cs`) and alter the database if it is possible.
|
||||
If you would like to use other collation, you can set `[database].CHARSET_COLLATION` in the `app.ini` file.
|
||||
|
||||
```sql
|
||||
CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_bin';
|
||||
```
|
||||
|
||||
Replace database name as appropriate.
|
||||
|
||||
5. Grant all privileges on the database to database user created above.
|
||||
|
||||
For local database:
|
||||
|
||||
```sql
|
||||
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea';
|
||||
FLUSH PRIVILEGES;
|
||||
```
|
||||
|
||||
For remote database:
|
||||
|
||||
```sql
|
||||
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'192.0.2.10';
|
||||
FLUSH PRIVILEGES;
|
||||
```
|
||||
|
||||
6. Quit from database console by `exit`.
|
||||
|
||||
7. On your Gitea server, test connection to the database:
|
||||
|
||||
```
|
||||
mysql -u gitea -h 203.0.113.3 -p giteadb
|
||||
```
|
||||
|
||||
where `gitea` is database username, `giteadb` is database name, and `203.0.113.3` is IP address of database instance. Omit `-h` option for local database.
|
||||
|
||||
You should be connected to the database.
|
||||
|
||||
## PostgreSQL
|
||||
|
||||
1. For remote database setup, configure PostgreSQL on database instance to listen to your IP address by editing `listen_addresses` on `postgresql.conf` to:
|
||||
|
||||
```ini
|
||||
listen_addresses = 'localhost, 203.0.113.3'
|
||||
```
|
||||
|
||||
2. PostgreSQL uses `md5` challenge-response encryption scheme for password authentication by default. Nowadays this scheme is not considered secure anymore. Use SCRAM-SHA-256 scheme instead by editing the `postgresql.conf` configuration file on the database server to:
|
||||
|
||||
```ini
|
||||
password_encryption = scram-sha-256
|
||||
```
|
||||
|
||||
Restart PostgreSQL to apply the setting.
|
||||
|
||||
3. On the database server, login to the database console as superuser:
|
||||
|
||||
```
|
||||
su -c "psql" - postgres
|
||||
```
|
||||
|
||||
4. Create database user (role in PostgreSQL terms) with login privilege and password. Please use a secure, strong password instead of `'gitea'` below:
|
||||
|
||||
```sql
|
||||
CREATE ROLE gitea WITH LOGIN PASSWORD 'gitea';
|
||||
```
|
||||
|
||||
Replace username and password as appropriate.
|
||||
|
||||
5. Create database with UTF-8 charset and owned by the database user created earlier. Any `libc` collations can be specified with `LC_COLLATE` and `LC_CTYPE` parameter, depending on expected content:
|
||||
|
||||
```sql
|
||||
CREATE DATABASE giteadb WITH OWNER gitea TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
|
||||
```
|
||||
|
||||
Replace database name as appropriate.
|
||||
|
||||
6. Allow the database user to access the database created above by adding the following authentication rule to `pg_hba.conf`.
|
||||
|
||||
For local database:
|
||||
|
||||
```ini
|
||||
local giteadb gitea scram-sha-256
|
||||
```
|
||||
|
||||
For remote database:
|
||||
|
||||
```ini
|
||||
host giteadb gitea 192.0.2.10/32 scram-sha-256
|
||||
```
|
||||
|
||||
Replace database name, user, and IP address of Gitea instance with your own.
|
||||
|
||||
:::note
|
||||
Rules on `pg_hba.conf` are evaluated sequentially, that is the first matching rule will be used for authentication. Your PostgreSQL installation may come with generic authentication rules that match all users and databases. You may need to place the rules presented here above such generic rules if it is the case.
|
||||
:::
|
||||
|
||||
Restart PostgreSQL to apply new authentication rules.
|
||||
|
||||
7. On your Gitea server, test connection to the database.
|
||||
|
||||
For local database:
|
||||
|
||||
```bash
|
||||
psql -U gitea -d giteadb
|
||||
```
|
||||
|
||||
For remote database:
|
||||
|
||||
```bash
|
||||
psql "postgres://gitea@203.0.113.3/giteadb"
|
||||
```
|
||||
|
||||
where `gitea` is database user, `giteadb` is database name, and `203.0.113.3` is IP address of your database instance.
|
||||
|
||||
You should be prompted to enter password for the database user, and connected to the database.
|
||||
|
||||
## Database Connection over TLS
|
||||
|
||||
If the communication between Gitea and your database instance is performed through a private network, or if Gitea and the database are running on the same server, this section can be omitted since the security between Gitea and the database instance is not critically exposed. If instead the database instance is on a public network, use TLS to encrypt the connection to the database, as it is possible for third-parties to intercept the traffic data.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- You need two valid TLS certificates, one for the database instance (database server) and one for the Gitea instance (database client). Both certificates must be signed by a trusted CA.
|
||||
- The database certificate must contain `TLS Web Server Authentication` in the `X509v3 Extended Key Usage` extension attribute, while the client certificate needs `TLS Web Client Authentication` in the corresponding attribute.
|
||||
- On the database server certificate, one of `Subject Alternative Name` or `Common Name` entries must be the fully-qualified domain name (FQDN) of the database instance (e.g. `db.example.com`). On the database client certificate, one of the entries mentioned above must contain the database username that Gitea will be using to connect.
|
||||
- You need domain name mappings of both Gitea and database servers to their respective IP addresses. Either set up DNS records for them or add local mappings to `/etc/hosts` (`%WINDIR%\System32\drivers\etc\hosts` in Windows) on each system. This allows the database connections to be performed by domain name instead of IP address. See documentation of your system for details.
|
||||
|
||||
### PostgreSQL TLS
|
||||
|
||||
The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both database client and server authenticate each other by sending their respective certificates to their respective opposite for validation. In other words, the server verifies client certificate, and the client verifies server certificate.
|
||||
|
||||
1. On the server with the database instance, place the following credentials:
|
||||
|
||||
- `/path/to/postgresql.crt`: Database instance certificate
|
||||
- `/path/to/postgresql.key`: Database instance private key
|
||||
- `/path/to/root.crt`: CA certificate chain to validate client certificates
|
||||
|
||||
2. Add following options to `postgresql.conf`:
|
||||
|
||||
```ini
|
||||
ssl = on
|
||||
ssl_ca_file = '/path/to/root.crt'
|
||||
ssl_cert_file = '/path/to/postgresql.crt'
|
||||
ssl_key_file = '/path/to/postgresql.key'
|
||||
ssl_min_protocol_version = 'TLSv1.2'
|
||||
```
|
||||
|
||||
3. Adjust credentials ownership and permission, as required by PostgreSQL:
|
||||
|
||||
```
|
||||
chown postgres:postgres /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
|
||||
chmod 0600 /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
|
||||
```
|
||||
|
||||
4. Edit `pg_hba.conf` rule to only allow Gitea database user to connect over SSL, and to require client certificate verification.
|
||||
|
||||
For PostgreSQL 12:
|
||||
|
||||
```ini
|
||||
hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=verify-full
|
||||
```
|
||||
|
||||
For PostgreSQL 11 and earlier:
|
||||
|
||||
```ini
|
||||
hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=1
|
||||
```
|
||||
|
||||
Replace database name, user, and IP address of Gitea instance as appropriate.
|
||||
|
||||
5. Restart PostgreSQL to apply configurations above.
|
||||
|
||||
6. On the server running the Gitea instance, place the following credentials under the home directory of the user who runs Gitea (e.g. `git`):
|
||||
|
||||
- `~/.postgresql/postgresql.crt`: Database client certificate
|
||||
- `~/.postgresql/postgresql.key`: Database client private key
|
||||
- `~/.postgresql/root.crt`: CA certificate chain to validate server certificate
|
||||
|
||||
:::note
|
||||
Those file names above are hardcoded in PostgreSQL and it is not possible to change them.
|
||||
:::
|
||||
|
||||
7. Adjust credentials, ownership and permission as required:
|
||||
|
||||
```
|
||||
chown git:git ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
|
||||
chown 0600 ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
|
||||
```
|
||||
|
||||
8. Test the connection to the database:
|
||||
|
||||
```
|
||||
psql "postgres://gitea@example.db/giteadb?sslmode=verify-full"
|
||||
```
|
||||
|
||||
You should be prompted to enter password for the database user, and then be connected to the database.
|
||||
|
||||
### MySQL/MariaDB TLS
|
||||
|
||||
While the MySQL driver used by Gitea also supports two-way TLS, Gitea currently supports only one-way TLS. See issue #10828 for details.
|
||||
|
||||
In one-way TLS, the database client verifies the certificate sent from server during the connection handshake, and the server assumes that the connected client is legitimate, since client certificate verification doesn't take place.
|
||||
|
||||
1. On the database instance, place the following credentials:
|
||||
|
||||
- `/path/to/mysql.crt`: Database instance certificate
|
||||
- `/path/to/mysql.key`: Database instance key
|
||||
- `/path/to/ca.crt`: CA certificate chain. This file isn't used on one-way TLS, but is used to validate client certificates on two-way TLS.
|
||||
|
||||
2. Add following options to `my.cnf`:
|
||||
|
||||
```ini
|
||||
[mysqld]
|
||||
ssl-ca = /path/to/ca.crt
|
||||
ssl-cert = /path/to/mysql.crt
|
||||
ssl-key = /path/to/mysql.key
|
||||
tls-version = TLSv1.2,TLSv1.3
|
||||
```
|
||||
|
||||
3. Adjust credentials ownership and permission:
|
||||
|
||||
```
|
||||
chown mysql:mysql /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
|
||||
chmod 0600 /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
|
||||
```
|
||||
|
||||
4. Restart MySQL to apply the setting.
|
||||
|
||||
5. The database user for Gitea may have been created earlier, but it would authenticate only against the IP addresses of the server running Gitea. To authenticate against its domain name, recreate the user, and this time also set it to require TLS for connecting to the database:
|
||||
|
||||
```sql
|
||||
DROP USER 'gitea'@'192.0.2.10';
|
||||
CREATE USER 'gitea'@'example.gitea' IDENTIFIED BY 'gitea' REQUIRE SSL;
|
||||
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'example.gitea';
|
||||
FLUSH PRIVILEGES;
|
||||
```
|
||||
|
||||
Replace database user name, password, and Gitea instance domain as appropriate.
|
||||
|
||||
6. Make sure that the CA certificate chain required to validate the database server certificate is on the system certificate store of both the database and Gitea servers. Consult your system documentation for instructions on adding a CA certificate to the certificate store.
|
||||
|
||||
7. On the server running Gitea, test connection to the database:
|
||||
|
||||
```
|
||||
mysql -u gitea -h example.db -p --ssl
|
||||
```
|
||||
|
||||
You should be connected to the database.
|
||||
@@ -0,0 +1,389 @@
|
||||
---
|
||||
date: "2017-06-19T12:00:00+02:00"
|
||||
slug: "install-from-binary"
|
||||
sidebar_position: 15
|
||||
aliases:
|
||||
- /zh-tw/install-from-binary
|
||||
---
|
||||
|
||||
# 從二進制安裝
|
||||
|
||||
所有下載都支持 SQLite、MySQL 和 PostgreSQL，並內置資產。這可能與 Gogs 不同。
|
||||
|
||||
## 下載
|
||||
|
||||
您可以從[下載頁面](https://dl.gitea.com/gitea/)找到與您的平台匹配的文件，然後導航到您要下載的版本。
|
||||
|
||||
### 選擇正確的文件
|
||||
|
||||
**對於 Linux**，您可能需要 `linux-amd64`。它適用於 64 位 Intel/AMD 平台，但還有其他可用平台，包括 `arm64`（例如 Raspberry PI 4）、`386`（即 32 位）、`arm-5` 和 `arm-6`。
|
||||
|
||||
**對於 Windows**，您可能需要 `windows-4.0-amd64`。它適用於所有現代版本的 Windows，但還有一個 `386` 平台可用，專為舊的 32 位版本的 Windows 設計。
|
||||
|
||||
:::info
|
||||
還有一個 `gogit-windows` 文件可用，它是為了解決一些[性能問題](https://github.com/go-gitea/gitea/pull/15482)而創建的，這些問題是一些 Windows 用戶在舊系統/版本上報告的。如果您遇到性能問題，應該考慮使用此文件，並讓我們知道它是否改善了性能。
|
||||
:::
|
||||
|
||||
**對於 macOS**，如果您的硬件使用 Apple Silicon，您應該選擇 `darwin-arm64`，或者對於 Intel 選擇 `darwin-amd64`。
|
||||
|
||||
**對於 FreeBSD**，您應該選擇 `freebsd12-amd64`，適用於 64 位 Intel/AMD 平台。
|
||||
|
||||
### 使用 wget 下載
|
||||
|
||||
複製以下命令並將 URL 替換為您希望下載的 URL。
|
||||
|
||||
```shell
|
||||
wget -O gitea https://dl.gitea.com/gitea/@version@/gitea-@version@-linux-amd64
|
||||
chmod +x gitea
|
||||
```
|
||||
|
||||
請注意，上述命令將下載 64 位 Linux 的 Gitea @version@。
|
||||
|
||||
## 驗證 GPG 簽名
|
||||
|
||||
Gitea 使用 [GPG 密鑰](https://keys.openpgp.org/search?q=teabot%40gitea.io) 簽署所有二進制文件，以防止二進制文件被未經授權的修改。
|
||||
要驗證二進制文件，請下載您下載的二進制文件的簽名文件，該文件以 `.asc` 結尾，並使用 GPG 命令行工具。
|
||||
|
||||
```sh
|
||||
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
|
||||
gpg --verify gitea-@version@-linux-amd64.asc gitea-@version@-linux-amd64
|
||||
```
|
||||
|
||||
查找文本 `Good signature from "Teabot <teabot@gitea.io>"` 以確認二進制文件良好，
|
||||
儘管有 `This key is not certified with a trusted signature!` 之類的警告。
|
||||
|
||||
## 推薦的服務器配置
|
||||
|
||||
:::note
|
||||
以下許多目錄也可以使用[環境變量](../administration/environment-variables.md)進行配置！
|
||||
值得注意的是，配置 `GITEA_WORK_DIR` 將告訴 Gitea 將其工作目錄設置在哪裡，並簡化安裝過程。
|
||||
:::
|
||||
|
||||
### 準備環境
|
||||
|
||||
檢查服務器上是否安裝了 Git。如果沒有，請先安裝它。Gitea 需要 Git 版本 >= 2.0。
|
||||
|
||||
```sh
|
||||
git --version
|
||||
```
|
||||
|
||||
創建一個用戶來運行 Gitea（例如 `git`）
|
||||
|
||||
```sh
|
||||
# 在 Ubuntu/Debian 上：
|
||||
adduser \
|
||||
--system \
|
||||
--shell /bin/bash \
|
||||
--gecos 'Git 版本控制' \
|
||||
--group \
|
||||
--disabled-password \
|
||||
--home /home/git \
|
||||
git
|
||||
|
||||
# 在 Fedora/RHEL/CentOS 上：
|
||||
groupadd --system git
|
||||
adduser \
|
||||
--system \
|
||||
--shell /bin/bash \
|
||||
--comment 'Git 版本控制' \
|
||||
--gid git \
|
||||
--home-dir /home/git \
|
||||
--create-home \
|
||||
git
|
||||
```
|
||||
|
||||
### 創建所需的目錄結構
|
||||
|
||||
```sh
|
||||
mkdir -p /var/lib/gitea/{custom,data,log}
|
||||
chown -R git:git /var/lib/gitea/
|
||||
chmod -R 750 /var/lib/gitea/
|
||||
mkdir /etc/gitea
|
||||
chown root:git /etc/gitea
|
||||
chmod 770 /etc/gitea
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
> `/etc/gitea` 暫時設置為用戶 `git` 的寫入權限，以便 Web 安裝程序可以寫入配置文件。安裝完成後，建議將權限設置為只讀：
|
||||
> :::
|
||||
|
||||
> ```sh
|
||||
> chmod 750 /etc/gitea
|
||||
> chmod 640 /etc/gitea/app.ini
|
||||
> ```
|
||||
|
||||
如果您不希望 Web 安裝程序能夠寫入配置文件，可以使配置文件對 Gitea 用戶（所有者/組 `root:git`，模式 `0640`）只讀，但您需要手動編輯配置文件以：
|
||||
|
||||
- 設置 `INSTALL_LOCK= true`，
|
||||
- 確保所有數據庫配置詳細信息正確設置
|
||||
- 確保設置了 `SECRET_KEY` 和 `INTERNAL_TOKEN` 值。（您可能需要使用 `gitea generate secret` 來生成這些密鑰。）
|
||||
- 確保設置了您需要的任何其他密鑰。
|
||||
|
||||
有關使用 `gitea generate secret` 的信息，請參閱[命令行文檔](../administration/command-line.md)。
|
||||
|
||||
### 配置 Gitea 的工作目錄
|
||||
|
||||
:::note
|
||||
如果您計劃將 Gitea 作為 Linux 服務運行，則可以跳過此步驟，因為服務文件允許您設置 `WorkingDirectory`。否則，請考慮（半）永久性地設置此環境變量，以便 Gitea 始終使用正確的工作目錄。
|
||||
:::
|
||||
|
||||
```sh
|
||||
export GITEA_WORK_DIR=/var/lib/gitea/
|
||||
```
|
||||
|
||||
### 將 Gitea 二進制文件複製到全局位置
|
||||
|
||||
```sh
|
||||
cp gitea /usr/local/bin/gitea
|
||||
```
|
||||
|
||||
### 添加 bash/zsh 自動補全（從 1.19 開始）
|
||||
|
||||
可以在 [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete) 找到啟用 bash 補全的腳本。這可以複製到 `/usr/share/bash-completion/completions/gitea`
|
||||
或在您的 `.bashrc` 中引用。
|
||||
|
||||
## 同樣，zsh 補全的腳本可以在 [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete) 中找到。這可以複製到 `/usr/share/zsh/_gitea` 或在您的
|
||||
|
||||
date: "2017-06-19T12:00:00+02:00"
|
||||
slug: "install-from-binary"
|
||||
sidebar_position: 15
|
||||
aliases:
|
||||
|
||||
- /zh-tw/install-from-binary
|
||||
|
||||
---
|
||||
|
||||
# Installation from binary
|
||||
|
||||
All downloads come with SQLite, MySQL and PostgreSQL support, and are built with
|
||||
embedded assets. This can be different from Gogs.
|
||||
|
||||
## Download
|
||||
|
||||
You can find the file matching your platform from the [downloads page](https://dl.gitea.com/gitea/) after navigating to the version you want to download.
|
||||
|
||||
### Choosing the right file
|
||||
|
||||
**For Linux**, you will likely want `linux-amd64`. It's for 64-bit Intel/AMD platforms, but there are other platforms available, including `arm64` (e.g. Raspberry PI 4), `386` (i.e. 32-bit), `arm-5`, and `arm-6`.
|
||||
|
||||
**For Windows**, you will likely want `windows-4.0-amd64`. It's for all modern versions of Windows, but there is also a `386` platform available designed for older, 32-bit versions of Windows.
|
||||
|
||||
:::info
|
||||
There is also a `gogit-windows` file available that was created to help with some [performance problems](https://github.com/go-gitea/gitea/pull/15482) reported by some Windows users on older systems/versions. You should consider using this file if you're experiencing performance issues, and let us know if it improves performance.
|
||||
:::
|
||||
|
||||
**For macOS**, you should choose `darwin-arm64` if your hardware uses Apple Silicon, or `darwin-amd64` for Intel.
|
||||
|
||||
**For FreeBSD**, you should choose `freebsd12-amd64` for 64-bit Intel/AMD platforms.
|
||||
|
||||
### Downloading with wget
|
||||
|
||||
Copy the commands below and replace the URL within the one you wish to download.
|
||||
|
||||
```shell
|
||||
wget -O gitea https://dl.gitea.com/gitea/@version@/gitea-@version@-linux-amd64
|
||||
chmod +x gitea
|
||||
```
|
||||
|
||||
Note that the above command will download Gitea @version@ for 64-bit Linux.
|
||||
|
||||
## Verify GPG signature
|
||||
|
||||
Gitea signs all binaries with a [GPG key](https://keys.openpgp.org/search?q=teabot%40gitea.io) to prevent against unwanted modification of binaries.
|
||||
To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the GPG command line tool.
|
||||
|
||||
```sh
|
||||
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
|
||||
gpg --verify gitea-@version@-linux-amd64.asc gitea-@version@-linux-amd64
|
||||
```
|
||||
|
||||
Look for the text `Good signature from "Teabot <teabot@gitea.io>"` to assert a good binary,
|
||||
despite warnings like `This key is not certified with a trusted signature!`.
|
||||
|
||||
## Recommended server configuration
|
||||
|
||||
:::note
|
||||
Many of the following directories can be configured using [Environment Variables](../administration/environment-variables.md) as well!
|
||||
Of note, configuring `GITEA_WORK_DIR` will tell Gitea where to base its working directory, as well as ease installation.
|
||||
:::
|
||||
|
||||
### Prepare environment
|
||||
|
||||
Check that Git is installed on the server. If it is not, install it first. Gitea requires Git version >= 2.0.
|
||||
|
||||
```sh
|
||||
git --version
|
||||
```
|
||||
|
||||
Create a user to run Gitea (e.g. `git`)
|
||||
|
||||
```sh
|
||||
# On Ubuntu/Debian:
|
||||
adduser \
|
||||
--system \
|
||||
--shell /bin/bash \
|
||||
--gecos 'Git Version Control' \
|
||||
--group \
|
||||
--disabled-password \
|
||||
--home /home/git \
|
||||
git
|
||||
|
||||
# On Fedora/RHEL/CentOS:
|
||||
groupadd --system git
|
||||
adduser \
|
||||
--system \
|
||||
--shell /bin/bash \
|
||||
--comment 'Git Version Control' \
|
||||
--gid git \
|
||||
--home-dir /home/git \
|
||||
--create-home \
|
||||
git
|
||||
```
|
||||
|
||||
### Create required directory structure
|
||||
|
||||
```sh
|
||||
mkdir -p /var/lib/gitea/{custom,data,log}
|
||||
chown -R git:git /var/lib/gitea/
|
||||
chmod -R 750 /var/lib/gitea/
|
||||
mkdir /etc/gitea
|
||||
chown root:git /etc/gitea
|
||||
chmod 770 /etc/gitea
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
> `/etc/gitea` is temporarily set with write permissions for user `git` so that the web installer can write the configuration file. After the installation is finished, it is recommended to set permissions to read-only using:
|
||||
> :::
|
||||
|
||||
> ```sh
|
||||
> chmod 750 /etc/gitea
|
||||
> chmod 640 /etc/gitea/app.ini
|
||||
> ```
|
||||
|
||||
If you don't want the web installer to be able to write to the config file, it is possible to make the config file read-only for the Gitea user (owner/group `root:git`, mode `0640`) however you will need to edit your config file manually to:
|
||||
|
||||
- Set `INSTALL_LOCK= true`,
|
||||
- Ensure all database configuration details are set correctly
|
||||
- Ensure that the `SECRET_KEY` and `INTERNAL_TOKEN` values are set. (You may want to use the `gitea generate secret` to generate these secret keys.)
|
||||
- Ensure that any other secret keys you need are set.
|
||||
|
||||
See the [command line documentation](../administration/command-line.md) for information on using `gitea generate secret`.
|
||||
|
||||
### Configure Gitea's working directory
|
||||
|
||||
:::note
|
||||
If you plan on running Gitea as a Linux service, you can skip this step, as the service file allows you to set `WorkingDirectory`. Otherwise, consider setting this environment variable (semi-)permanently so that Gitea consistently uses the correct working directory.
|
||||
:::
|
||||
|
||||
```sh
|
||||
export GITEA_WORK_DIR=/var/lib/gitea/
|
||||
```
|
||||
|
||||
### Copy the Gitea binary to a global location
|
||||
|
||||
```sh
|
||||
cp gitea /usr/local/bin/gitea
|
||||
```
|
||||
|
||||
### Adding bash/zsh autocompletion (from 1.19)
|
||||
|
||||
A script to enable bash-completion can be found at [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete). This can be copied to `/usr/share/bash-completion/completions/gitea`
|
||||
or sourced within your `.bashrc`.
|
||||
|
||||
Similarly a script for zsh-completion can be found at [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete). This can be copied to `/usr/share/zsh/_gitea` or sourced within your
|
||||
`.zshrc`.
|
||||
|
||||
YMMV and these scripts may need further improvement.
|
||||
|
||||
## Running Gitea
|
||||
|
||||
After you complete the above steps, you can run Gitea two ways:
|
||||
|
||||
### 1. Creating a service file to start Gitea automatically (recommended)
|
||||
|
||||
See how to create [Linux service](installation/run-as-service-in-ubuntu.md)
|
||||
|
||||
### 2. Running from command-line/terminal
|
||||
|
||||
```sh
|
||||
GITEA_WORK_DIR=/var/lib/gitea/ /usr/local/bin/gitea web -c /etc/gitea/app.ini
|
||||
```
|
||||
|
||||
## Updating to a new version
|
||||
|
||||
You can update to a new version of Gitea by stopping Gitea, replacing the binary at `/usr/local/bin/gitea` and restarting the instance.
|
||||
The binary file name should not be changed during the update to avoid problems in existing repositories.
|
||||
|
||||
It is recommended that you make a [backup](../administration/backup-and-restore.md) before updating your installation.
|
||||
|
||||
If you have carried out the installation steps as described above, the binary should
|
||||
have the generic name `gitea`. Do not change this, i.e. to include the version number.
|
||||
|
||||
### 1. Restarting Gitea with systemd (recommended)
|
||||
|
||||
As we explained before, we recommend to use systemd as the service manager. In this case, `systemctl restart gitea` should be fine.
|
||||
|
||||
### 2. Restarting Gitea without systemd
|
||||
|
||||
To restart your Gitea instance, we recommend to use SIGHUP signal. If you know your Gitea PID, use `kill -1 $GITEA_PID`, otherwise you can use `killall -1 gitea`.
|
||||
|
||||
To gracefully stop the Gitea instance, a simple `kill $GITEA_PID` or `killall gitea` is enough.
|
||||
|
||||
:::note
|
||||
We don't recommend to use the SIGKILL signal (`-9`); you may be forcefully stopping some of Gitea's internal tasks, and it will not gracefully stop (tasks in queues, indexers, etc.)
|
||||
:::
|
||||
|
||||
See below for troubleshooting instructions to repair broken repositories after
|
||||
an update of your Gitea version.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Old glibc versions
|
||||
|
||||
Older Linux distributions (such as Debian 7 and CentOS 6) may not be able to load the
|
||||
Gitea binary, usually producing an error such as `./gitea: /lib/x86_64-linux-gnu/libc.so.6:
|
||||
version 'GLIBC\_2.14' not found (required by ./gitea)`. This is due to the integrated
|
||||
SQLite support in the binaries provided by dl.gitea.com. In this situation, it is usually
|
||||
possible to [install from source](installation/from-source.md), without including
|
||||
SQLite support.
|
||||
|
||||
### Running Gitea on another port
|
||||
|
||||
For errors like `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000:
|
||||
bind: address already in use`, Gitea needs to be started on another free port. This
|
||||
is possible using `./gitea web -p $PORT`. It's possible another instance of Gitea
|
||||
is already running.
|
||||
|
||||
### Running Gitea on Raspbian
|
||||
|
||||
As of v1.8, there is a problem with the arm7 version of Gitea, and it doesn't run on Raspberry Pis and similar devices.
|
||||
|
||||
It is recommended to switch to the arm6 version, which has been tested and shown to work on Raspberry Pis and similar devices.
|
||||
|
||||
<!---
|
||||
please remove after fixing the arm7 bug
|
||||
--->
|
||||
|
||||
### Git error after updating to a new version of Gitea
|
||||
|
||||
If during the update, the binary file name has been changed to a new version of Gitea,
|
||||
Git Hooks in existing repositories will not work any more. In that case, a Git
|
||||
error will be displayed when pushing to the repository.
|
||||
|
||||
```
|
||||
remote: ./hooks/pre-receive.d/gitea: line 2: [...]: No such file or directory
|
||||
```
|
||||
|
||||
The `[...]` part of the error message will contain the path to your previous Gitea
|
||||
binary.
|
||||
|
||||
To solve this, go to the admin options and run the task `Resynchronize pre-receive,
|
||||
update and post-receive hooks of all repositories` to update all hooks to contain
|
||||
the new binary path. Please note that this overwrites all Git Hooks, including ones
|
||||
with customizations made.
|
||||
|
||||
If you aren't using the Gitea built-in SSH server, you will also need to re-write
|
||||
the authorized key file by running the `Update the '.ssh/authorized_keys' file with
|
||||
Gitea SSH keys.` task in the admin options.
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "install-from-package"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-tw/install-from-package
|
||||
---
|
||||
|
||||
# 從包安裝
|
||||
|
||||
## 官方包
|
||||
|
||||
### macOS
|
||||
|
||||
目前，在 MacOS 上安裝的唯一支持方法是 [Homebrew](http://brew.sh/)。
|
||||
按照[從二進制部署](installation/from-binary.md)指南可能有效，
|
||||
但不受支持。要通過 `brew` 安裝 Gitea：
|
||||
|
||||
```
|
||||
brew install gitea
|
||||
```
|
||||
|
||||
## 非官方包
|
||||
|
||||
### Alpine Linux
|
||||
|
||||
Alpine Linux 在其社區存儲庫中有 [Gitea](https://pkgs.alpinelinux.org/packages?name=gitea&branch=edge)，該存儲庫遵循最新的穩定版本。
|
||||
|
||||
```sh
|
||||
apk add gitea
|
||||
```
|
||||
|
||||
### Arch Linux
|
||||
|
||||
滾動發行版在其官方額外存儲庫中有 [Gitea](https://www.archlinux.org/packages/extra/x86_64/gitea/)，並且隨著新的 Gitea 發行版提供包更新。
|
||||
|
||||
```sh
|
||||
pacman -S gitea
|
||||
```
|
||||
|
||||
### Arch Linux ARM
|
||||
|
||||
Arch Linux ARM 提供 [aarch64](https://archlinuxarm.org/packages/aarch64/gitea)、[armv7h](https://archlinuxarm.org/packages/armv7h/gitea) 和 [armv6h](https://archlinuxarm.org/packages/armv6h/gitea) 的包。
|
||||
|
||||
```sh
|
||||
pacman -S gitea
|
||||
```
|
||||
|
||||
### Gentoo Linux
|
||||
|
||||
滾動發行版在其官方社區存儲庫中有 [Gitea](https://packages.gentoo.org/packages/www-apps/gitea)，並且隨著新的 Gitea 發行版提供包更新。
|
||||
|
||||
```sh
|
||||
emerge gitea -va
|
||||
```
|
||||
|
||||
### Canonical Snap
|
||||
|
||||
有一個 [Gitea Snap](https://snapcraft.io/gitea) 包，它遵循最新的穩定版本。
|
||||
_注意：Gitea snap 包是[嚴格隔離的](https://snapcraft.io/docs/snap-confinement)。嚴格隔離的快照完全隔離運行，因此某些 Gitea 功能可能無法與隔離一起使用_
|
||||
|
||||
```sh
|
||||
snap install gitea
|
||||
```
|
||||
|
||||
### SUSE 和 openSUSE
|
||||
|
||||
OpenSUSE 構建服務提供 [openSUSE 和 SLE](https://software.opensuse.org/download/package?package=gitea&project=devel%3Atools%3Ascm) 的包
|
||||
在開發軟件配置管理存儲庫中
|
||||
|
||||
### Windows
|
||||
|
||||
[Chocolatey](https://chocolatey.org/) 提供了一個適用於 Windows 的 [Gitea](https://chocolatey.org/packages/gitea) 包。
|
||||
|
||||
```sh
|
||||
choco install gitea
|
||||
```
|
||||
|
||||
或者按照[從二進制部署](installation/from-binary.md)指南進行操作。
|
||||
|
||||
### FreeBSD
|
||||
|
||||
有一個 FreeBSD 端口 `www/gitea` 可用。要安裝預構建的二進制包：
|
||||
|
||||
```
|
||||
pkg install gitea
|
||||
```
|
||||
|
||||
要獲取最新版本，或使用自定義選項構建端口，
|
||||
[從端口安裝](https://www.freebsd.org/doc/handbook/ports-using.html)：
|
||||
|
||||
```
|
||||
su -
|
||||
cd /usr/ports/www/gitea
|
||||
make install clean
|
||||
```
|
||||
|
||||
該端口使用標準的 FreeBSD 文件系統佈局：配置文件位於 `/usr/local/etc/gitea`，
|
||||
捆綁的模板、選項、插件和主題位於 `/usr/local/share/gitea`，啟動腳本
|
||||
位於 `/usr/local/etc/rc.d/gitea`。
|
||||
|
||||
要使 Gitea 作為服務運行，請運行 `sysrc gitea_enable=YES` 並使用 `service gitea start` 啟動它。
|
||||
|
||||
### 其他
|
||||
|
||||
存在各種其他第三方 Gitea 包。
|
||||
要查看策劃列表，請前往 [awesome-gitea](https://gitea.com/gitea/awesome-gitea/src/branch/master/README.md#user-content-packages)。
|
||||
|
||||
您知道有現有的包不在列表中嗎？發送 PR 以將其添加！
|
||||
@@ -0,0 +1,372 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "install-from-source"
|
||||
sidebar_position: 30
|
||||
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)。
|
||||
|
||||
接下來，[安裝帶有 npm 的 Node.js](https://nodejs.org/en/download/)，這是構建 JavaScript 和 CSS 文件所必需的。支持的最低 Node.js 版本是 @minNodeVersion@，建議使用最新的 LTS 版本。
|
||||
|
||||
:::note
|
||||
需要 Go 版本 @minGoVersion@ 或更高版本。但是，建議獲取與我們的持續集成相同的版本，請參閱[在 Gitea 上進行黑客攻擊](development/hacking-on-gitea.md) 中的建議
|
||||
:::
|
||||
|
||||
## 下載
|
||||
|
||||
首先，我們必須檢索源代碼。由於 go 模塊的出現，最簡單的方法是直接使用 Git，因為我們不再需要在 GOPATH 中構建 Gitea。
|
||||
|
||||
```bash
|
||||
git clone https://github.com/go-gitea/gitea
|
||||
```
|
||||
|
||||
（本文檔的早期版本建議使用 `go get`。這不再是必需的。）
|
||||
|
||||
決定要構建和安裝的 Gitea 版本。目前，有多種選擇可供選擇。`main` 分支代表當前的開發版本。要使用 main 構建，請跳到[構建部分](#build)。
|
||||
|
||||
要使用標記的版本，可以使用以下命令：
|
||||
|
||||
```bash
|
||||
git branch -a
|
||||
git checkout @sourceBranch@
|
||||
```
|
||||
|
||||
要驗證拉取請求，請首先啟用新分支（`xyz` 是 PR id；例如 [#2663](https://github.com/go-gitea/gitea/pull/2663) 的 `2663`）：
|
||||
|
||||
```bash
|
||||
git fetch origin pull/xyz/head:pr-xyz
|
||||
```
|
||||
|
||||
要從特定標記版本（如 @sourceVersion@）的源代碼構建 Gitea，請列出可用標記並檢出特定標記。
|
||||
|
||||
使用以下命令列出可用標籤。
|
||||
|
||||
```bash
|
||||
git tag -l
|
||||
git checkout @sourceVersion@ # 或 git checkout pr-xyz
|
||||
```
|
||||
|
||||
## 構建
|
||||
|
||||
要從源代碼構建，系統上必須存在以下程序：
|
||||
|
||||
- `go` @minGoVersion@ 或更高版本，請參閱[此處](https://go.dev/dl/)
|
||||
- `node` @minNodeVersion@ 或更高版本，帶有 `npm`，請參閱[此處](https://nodejs.org/en/download/)
|
||||
- `make`，請參閱[此處](development/hacking-on-gitea.md#installing-make)
|
||||
|
||||
提供了各種[make 任務](https://github.com/go-gitea/gitea/blob/main/Makefile)，以使構建過程盡可能簡單。
|
||||
|
||||
根據要求，可以包括以下構建標籤。
|
||||
|
||||
- `bindata`：構建單個整體二進制文件，包含所有資產。生產構建所需。
|
||||
- `sqlite sqlite_unlock_notify`：啟用對 [SQLite3](https://sqlite.org/) 數據庫的支持。僅建議用於小型安裝。
|
||||
- `pam`：啟用對 PAM（Linux 可插拔身份驗證模塊）的支持。可用於驗證本地用戶或擴展身份驗證到 PAM 可用的方法。
|
||||
- `gogit`：（實驗性）使用 go-git 變體的 Git 命令。
|
||||
|
||||
將所有資產（JS/CSS/模板等）捆綁到二進制文件中。使用 `bindata` 構建標籤是生產部署所必需的。當您開發/測試 Gitea 或能夠正確分離資產時，可以排除 `bindata`。
|
||||
|
||||
要包括所有資產，請使用 `bindata` 標籤：
|
||||
|
||||
```bash
|
||||
TAGS="bindata" make build
|
||||
```
|
||||
|
||||
在我們的持續集成系統的默認發布構建中，構建標籤是：`TAGS="bindata sqlite sqlite_unlock_notify"`。因此，從源代碼構建的最簡單推薦方法是：
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
```
|
||||
|
||||
`build` 目標分為兩個子目標：
|
||||
|
||||
- `make backend` 需要 [Go @minGoVersion@](https://go.dev/dl/) 或更高版本。
|
||||
- `make frontend` 需要 [Node.js @minNodeVersion@](https://nodejs.org/en/download/) 或更高版本。
|
||||
|
||||
如果存在預構建的前端文件，則可以僅構建後端：
|
||||
|
||||
```bash
|
||||
TAGS="bindata" make backend
|
||||
```
|
||||
|
||||
## 測試
|
||||
|
||||
按照上述步驟操作後，工作目錄中將有一個 `gitea` 二進制文件。
|
||||
可以從此目錄進行測試或移動到具有測試數據的目錄。當 Gitea 從命令行手動啟動時，可以通過按 `Ctrl + C` 將其終止。
|
||||
|
||||
```bash
|
||||
./gitea web
|
||||
```
|
||||
|
||||
## 更改默認路徑
|
||||
|
||||
Gitea 將從 _`CustomPath`_ 中搜索許多內容。默認情況下，這是運行 Gitea 時當前工作目錄中的 `custom/` 目錄。它還將在 `$(CustomPath)/conf/app.ini` 中查找其配置文件，並將當前工作目錄用作許多可配置值的相對基本路徑 _`AppWorkPath`_。最後，靜態文件將從 _`StaticRootPath`_ 提供，默認為 _`AppWorkPath`_。
|
||||
|
||||
這些值雖然在開發時很有用，但可能會與下游用戶的偏好發生衝突。
|
||||
|
||||
一種選擇是使用腳本文件來影子 `gitea` 二進制文件並在運行 Gitea 之前創建適當的環境。但是，在構建時，您可以使用 `make` 的 `LDFLAGS` 環境變量更改這些默認值。適當的設置如下
|
||||
|
||||
- 要設置 _`CustomPath`_，請使用 `LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=custom-path\""`
|
||||
- 對
|
||||
|
||||
---
|
||||
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "install-from-source"
|
||||
sidebar_position: 30
|
||||
aliases:
|
||||
|
||||
- /zh-tw/install-from-source
|
||||
|
||||
---
|
||||
|
||||
# Installation from source
|
||||
|
||||
You should [install go](https://go.dev/doc/install) and set up your go
|
||||
environment correctly. In particular, it is recommended to set the `$GOPATH`
|
||||
environment variable and to add the go bin directory or directories
|
||||
`${GOPATH//://bin:}/bin` to the `$PATH`. See the Go wiki entry for
|
||||
[GOPATH](https://github.com/golang/go/wiki/GOPATH).
|
||||
|
||||
Next, [install Node.js with npm](https://nodejs.org/en/download/) which is
|
||||
required to build the JavaScript and CSS files. The minimum supported Node.js
|
||||
version is @minNodeVersion@ and the latest LTS version is recommended.
|
||||
|
||||
:::note
|
||||
Go version @minGoVersion@ or higher is required. However, it is recommended to
|
||||
obtain the same version as our continuous integration, see the advice given in
|
||||
[Hacking on Gitea](development/hacking-on-gitea.md)
|
||||
:::
|
||||
|
||||
## Download
|
||||
|
||||
First, we must retrieve the source code. Since, the advent of go modules, the
|
||||
simplest way of doing this is to use Git directly as we no longer have to have
|
||||
Gitea built from within the GOPATH.
|
||||
|
||||
```bash
|
||||
git clone https://github.com/go-gitea/gitea
|
||||
```
|
||||
|
||||
(Previous versions of this document recommended using `go get`. This is
|
||||
no longer necessary.)
|
||||
|
||||
Decide which version of Gitea to build and install. Currently, there are
|
||||
multiple options to choose from. The `main` branch represents the current
|
||||
development version. To build with main, skip to the [build section](#build).
|
||||
|
||||
To work with tagged releases, the following commands can be used:
|
||||
|
||||
```bash
|
||||
git branch -a
|
||||
git checkout @sourceBranch@
|
||||
```
|
||||
|
||||
To validate a Pull Request, first enable the new branch (`xyz` is the PR id;
|
||||
for example `2663` for [#2663](https://github.com/go-gitea/gitea/pull/2663)):
|
||||
|
||||
```bash
|
||||
git fetch origin pull/xyz/head:pr-xyz
|
||||
```
|
||||
|
||||
To build Gitea from source at a specific tagged release (like @sourceVersion@), list the
|
||||
available tags and check out the specific tag.
|
||||
|
||||
List available tags with the following.
|
||||
|
||||
```bash
|
||||
git tag -l
|
||||
git checkout @sourceVersion@ # or git checkout pr-xyz
|
||||
```
|
||||
|
||||
## Build
|
||||
|
||||
To build from source, the following programs must be present on the system:
|
||||
|
||||
- `go` @minGoVersion@ or higher, see [here](https://go.dev/dl/)
|
||||
- `node` @minNodeVersion@ or higher with `npm`, see [here](https://nodejs.org/en/download/)
|
||||
- `make`, see [here](development/hacking-on-gitea.md#installing-make)
|
||||
|
||||
Various [make tasks](https://github.com/go-gitea/gitea/blob/main/Makefile)
|
||||
are provided to keep the build process as simple as possible.
|
||||
|
||||
Depending on requirements, the following build tags can be included.
|
||||
|
||||
- `bindata`: Build a single monolithic binary, with all assets included. Required for production build.
|
||||
- `sqlite sqlite_unlock_notify`: Enable support for a
|
||||
[SQLite3](https://sqlite.org/) database. Suggested only for tiny
|
||||
installations.
|
||||
- `pam`: Enable support for PAM (Linux Pluggable Authentication Modules). Can
|
||||
be used to authenticate local users or extend authentication to methods
|
||||
available to PAM.
|
||||
- `gogit`: (EXPERIMENTAL) Use go-git variants of Git commands.
|
||||
|
||||
Bundling all assets (JS/CSS/templates, etc) into the binary. Using the `bindata` build tag is required for
|
||||
production deployments. You could exclude `bindata` when you are developing/testing Gitea or able to separate the assets correctly.
|
||||
|
||||
To include all assets, use the `bindata` tag:
|
||||
|
||||
```bash
|
||||
TAGS="bindata" make build
|
||||
```
|
||||
|
||||
In the default release build of our continuous integration system, the build
|
||||
tags are: `TAGS="bindata sqlite sqlite_unlock_notify"`. The simplest
|
||||
recommended way to build from source is therefore:
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
```
|
||||
|
||||
The `build` target is split into two sub-targets:
|
||||
|
||||
- `make backend` which requires [Go @minGoVersion@](https://go.dev/dl/) or greater.
|
||||
- `make frontend` which requires [Node.js @minNodeVersion@](https://nodejs.org/en/download/) or greater.
|
||||
|
||||
If pre-built frontend files are present it is possible to only build the backend:
|
||||
|
||||
```bash
|
||||
TAGS="bindata" make backend
|
||||
```
|
||||
|
||||
## Test
|
||||
|
||||
After following the steps above, a `gitea` binary will be available in the working directory.
|
||||
It can be tested from this directory or moved to a directory with test data. When Gitea is
|
||||
launched manually from command line, it can be killed by pressing `Ctrl + C`.
|
||||
|
||||
```bash
|
||||
./gitea web
|
||||
```
|
||||
|
||||
## Changing default paths
|
||||
|
||||
Gitea will search for a number of things from the _`CustomPath`_. By default this is
|
||||
the `custom/` directory in the current working directory when running Gitea. It will also
|
||||
look for its configuration file _`CustomConf`_ in `$(CustomPath)/conf/app.ini`, and will use the
|
||||
current working directory as the relative base path _`AppWorkPath`_ for a number configurable
|
||||
values. Finally the static files will be served from _`StaticRootPath`_ which defaults to the _`AppWorkPath`_.
|
||||
|
||||
These values, although useful when developing, may conflict with downstream users preferences.
|
||||
|
||||
One option is to use a script file to shadow the `gitea` binary and create an appropriate
|
||||
environment before running Gitea. However, when building you can change these defaults
|
||||
using the `LDFLAGS` environment variable for `make`. The appropriate settings are as follows
|
||||
|
||||
- To set the _`CustomPath`_ use `LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=custom-path\""`
|
||||
- For _`CustomConf`_ you should use `-X \"code.gitea.io/gitea/modules/setting.CustomConf=conf.ini\"`
|
||||
- For _`AppWorkPath`_ you should use `-X \"code.gitea.io/gitea/modules/setting.AppWorkPath=working-path\"`
|
||||
- For _`StaticRootPath`_ you should use `-X \"code.gitea.io/gitea/modules/setting.StaticRootPath=static-root-path\"`
|
||||
- To change the default PID file location use `-X \"code.gitea.io/gitea/cmd.PIDFile=/run/gitea.pid\"`
|
||||
|
||||
Add as many of the strings with their preceding `-X` to the `LDFLAGS` variable and run `make build`
|
||||
with the appropriate `TAGS` as above.
|
||||
|
||||
Running `gitea help` will allow you to review what the computed settings will be for your `gitea`.
|
||||
|
||||
## Cross Build
|
||||
|
||||
The `go` compiler toolchain supports cross-compiling to different architecture targets that are supported by the toolchain. See [`GOOS` and `GOARCH` environment variable](https://go.dev/doc/install/source#environment) for the list of supported targets. Cross compilation is helpful if you want to build Gitea for less-powerful systems (such as Raspberry Pi).
|
||||
|
||||
To cross build Gitea with build tags (`TAGS`), you also need a C cross compiler which targets the same architecture as selected by the `GOOS` and `GOARCH` variables. For example, to cross build for Linux ARM64 (`GOOS=linux` and `GOARCH=arm64`), you need the `aarch64-unknown-linux-gnu-gcc` cross compiler. This is required because Gitea build tags uses `cgo`'s foreign-function interface (FFI).
|
||||
|
||||
Cross-build Gitea for Linux ARM64, without any tags:
|
||||
|
||||
```
|
||||
GOOS=linux GOARCH=arm64 make build
|
||||
```
|
||||
|
||||
Cross-build Gitea for Linux ARM64, with recommended build tags:
|
||||
|
||||
```
|
||||
CC=aarch64-unknown-linux-gnu-gcc GOOS=linux GOARCH=arm64 TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
```
|
||||
|
||||
Replace `CC`, `GOOS`, and `GOARCH` as appropriate for your architecture target.
|
||||
|
||||
You will sometimes need to build a static compiled image. To do this you will need to add:
|
||||
|
||||
```
|
||||
LDFLAGS="-linkmode external -extldflags '-static' $LDFLAGS" TAGS="netgo osusergo $TAGS" make build
|
||||
```
|
||||
|
||||
This can be combined with `CC`, `GOOS`, and `GOARCH` as above.
|
||||
|
||||
### Adding bash/zsh autocompletion (from 1.19)
|
||||
|
||||
A script to enable bash-completion can be found at [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete). This should be altered as appropriate and can be `source` in your `.bashrc`
|
||||
or copied as `/usr/share/bash-completion/completions/gitea`.
|
||||
|
||||
Similarly, a script for zsh-completion can be found at [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete). This can be copied to `/usr/share/zsh/_gitea` or sourced within your
|
||||
`.zshrc`.
|
||||
|
||||
YMMV and these scripts may need further improvement.
|
||||
|
||||
## Compile or cross-compile using Linux with Zig
|
||||
|
||||
Follow [Getting Started of Zig](https://ziglang.org/learn/getting-started/#installing-zig) to install zig.
|
||||
|
||||
- Compile (Linux ➝ Linux)
|
||||
|
||||
```sh
|
||||
CC="zig cc -target x86_64-linux-gnu" \
|
||||
CGO_ENABLED=1 \
|
||||
CGO_CFLAGS="-O2 -g -pthread" \
|
||||
CGO_LDFLAGS="-linkmode=external -v"
|
||||
GOOS=linux \
|
||||
GOARCH=amd64 \
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" \
|
||||
make build
|
||||
```
|
||||
|
||||
- Cross-compile (Linux ➝ Windows)
|
||||
|
||||
```sh
|
||||
CC="zig cc -target x86_64-windows-gnu" \
|
||||
CGO_ENABLED=1 \
|
||||
CGO_CFLAGS="-O2 -g -pthread" \
|
||||
GOOS=windows \
|
||||
GOARCH=amd64 \
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" \
|
||||
make build
|
||||
```
|
||||
|
||||
## Compile or cross-compile with Zig using Windows
|
||||
|
||||
Compile with `GIT BASH`.
|
||||
|
||||
- Compile (Windows ➝ Windows)
|
||||
|
||||
```sh
|
||||
CC="zig cc -target x86_64-windows-gnu" \
|
||||
CGO_ENABLED=1 \
|
||||
CGO_CFLAGS="-O2 -g -pthread" \
|
||||
GOOS=windows \
|
||||
GOARCH=amd64 \
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" \
|
||||
make build
|
||||
```
|
||||
|
||||
- Cross-compile (Windows ➝ Linux)
|
||||
|
||||
```sh
|
||||
CC="zig cc -target x86_64-linux-gnu" \
|
||||
CGO_ENABLED=1 \
|
||||
CGO_CFLAGS="-O2 -g -pthread" \
|
||||
CGO_LDFLAGS="-linkmode=external -v"
|
||||
GOOS=linux \
|
||||
GOARCH=amd64 \
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" \
|
||||
make build
|
||||
```
|
||||
|
||||
## Source Maps
|
||||
|
||||
By default, gitea generates reduced source maps for frontend files to conserve space. This can be controlled with the `ENABLE_SOURCEMAP` environment variable:
|
||||
|
||||
- `ENABLE_SOURCEMAP=true` generates all source maps, the default for development builds
|
||||
- `ENABLE_SOURCEMAP=reduced` generates limited source maps, the default for production builds
|
||||
- `ENABLE_SOURCEMAP=false` generates no source maps
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "install-on-cloud-provider"
|
||||
sidebar_position: 90
|
||||
aliases:
|
||||
- /zh-tw/install-on-cloud-provider
|
||||
---
|
||||
|
||||
# 在雲提供商上安裝
|
||||
|
||||
## Cloudron
|
||||
|
||||
Gitea 可在 [Cloudron](https://cloudron.io) 上一鍵安裝。
|
||||
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。
|
||||
|
||||
## Linode
|
||||
|
||||
[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 作為應用程序。
|
||||
|
||||
要將 Gitea 部署到 alwaysdata，請查看 [alwaysdata Marketplace](https://www.alwaysdata.com/en/marketplace/gitea/)。
|
||||
|
||||
## Exoscale
|
||||
|
||||
[Exoscale](https://www.exoscale.com/) 在其市場中提供由 [Glasskube](https://glasskube.eu/) 管理的 Gitea。
|
||||
|
||||
Exoscale 是一家歐洲雲服務提供商。
|
||||
|
||||
該包由開源 [Glasskube Kubernetes Operator](https://github.com/glasskube/operator) 維護和更新。
|
||||
|
||||
要將 Gitea 部署到 Exoscale，請查看 [Exoscale Marketplace](https://www.exoscale.com/marketplace/listing/glasskube-gitea/)。
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
date: "2020-03-19T19:27:00+02:00"
|
||||
slug: "install-on-kubernetes"
|
||||
sidebar_position: 80
|
||||
aliases:
|
||||
- /zh-tw/install-on-kubernetes
|
||||
---
|
||||
|
||||
# 在 Kubernetes 上安裝
|
||||
|
||||
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/)
|
||||
|
||||
## 健康檢查端點
|
||||
|
||||
Gitea 帶有一個健康檢查端點 `/api/healthz`，您可以在 kubernetes 中這樣配置它：
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /api/healthz
|
||||
port: http
|
||||
initialDelaySeconds: 200
|
||||
timeoutSeconds: 5
|
||||
periodSeconds: 10
|
||||
successThreshold: 1
|
||||
failureThreshold: 10
|
||||
```
|
||||
|
||||
成功的健康檢查響應將返回 http 代碼 `200`，示例如下：
|
||||
|
||||
```json
|
||||
HTTP/1.1 200 OK
|
||||
|
||||
{
|
||||
"status": "pass",
|
||||
"description": "Gitea: Git with a cup of tea",
|
||||
"checks": {
|
||||
"cache:ping": [
|
||||
{
|
||||
"status": "pass",
|
||||
"time": "2022-02-19T09:16:08Z"
|
||||
}
|
||||
],
|
||||
"database:ping": [
|
||||
{
|
||||
"status": "pass",
|
||||
"time": "2022-02-19T09:16:08Z"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
有關更多信息，請參考 kubernetes 文檔 [定義 liveness HTTP 請求](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request)
|
||||
+65
@@ -0,0 +1,65 @@
|
||||
---
|
||||
date: "2017-07-21T12:00:00+02:00"
|
||||
slug: "linux-service"
|
||||
sidebar_position: 40
|
||||
aliases:
|
||||
- /zh-tw/linux-service
|
||||
---
|
||||
|
||||
# 作為 Linux 服務運行
|
||||
|
||||
您可以使用 systemd 或 supervisor 將 Gitea 作為 Linux 服務運行。以下步驟在 Ubuntu 16.04 上測試，但應該適用於任何 Linux 發行版（稍作修改）。
|
||||
|
||||
## 使用 systemd
|
||||
|
||||
將示例 [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) 複製到 `/etc/systemd/system/gitea.service`，然後使用您喜歡的編輯器編輯該文件。
|
||||
|
||||
取消註釋需要在此主機上啟用的任何服務，例如 MySQL。
|
||||
|
||||
更改用戶、主目錄和其他所需的啟動值。如果使用默認端口，請更改 PORT 或刪除 -p 標誌。
|
||||
|
||||
在啟動時啟用並啟動 Gitea：
|
||||
|
||||
```
|
||||
sudo systemctl enable gitea
|
||||
sudo systemctl start gitea
|
||||
```
|
||||
|
||||
如果您擁有 systemd 版本 220 或更高版本，您可以一次性啟用並立即啟動 Gitea：
|
||||
|
||||
```
|
||||
sudo systemctl enable gitea --now
|
||||
```
|
||||
|
||||
## 使用 supervisor
|
||||
|
||||
通過在終端中運行以下命令安裝 supervisor：
|
||||
|
||||
```
|
||||
sudo apt install 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)。
|
||||
|
||||
使用您喜歡的編輯器，更改用戶 (`git`) 和主目錄 (`/home/git`) 設置以匹配部署環境。如果使用默認端口，請更改 PORT 或刪除 -p 標誌。
|
||||
|
||||
最後在啟動時啟用並啟動 supervisor：
|
||||
|
||||
```
|
||||
sudo systemctl enable supervisor
|
||||
sudo systemctl start supervisor
|
||||
```
|
||||
|
||||
如果您擁有 systemd 版本 220 或更高版本，您可以一次性啟用並立即啟動 supervisor：
|
||||
|
||||
```
|
||||
sudo systemctl enable supervisor --now
|
||||
```
|
||||
+89
@@ -0,0 +1,89 @@
|
||||
---
|
||||
date: "2021-09-02T16:00:00+08:00"
|
||||
slug: "upgrade-from-gitea"
|
||||
sidebar_position: 100
|
||||
aliases:
|
||||
- /zh-tw/upgrade-from-gitea
|
||||
---
|
||||
|
||||
# 從舊版 Gitea 升級
|
||||
|
||||
按照以下步驟確保順利升級到新版本的 Gitea。
|
||||
|
||||
## 檢查變更日誌中的重大變更
|
||||
|
||||
為了使 Gitea 更好，一些重大變更是不可避免的，特別是對於大里程碑版本。
|
||||
在升級之前，請閱讀 [Gitea 博客上的變更日誌](https://blog.gitea.com/)
|
||||
並檢查這些重大變更是否會影響您的 Gitea 實例。
|
||||
|
||||
## 驗證沒有已棄用的配置選項
|
||||
|
||||
Gitea 的新版本通常會帶有更改的配置語法或選項，這些選項通常會在站點管理面板頂部顯示至少一個發布週期。如果這些警告未解決，Gitea 可能會拒絕在下一版本中啟動。
|
||||
|
||||
## 降級備份
|
||||
|
||||
Gitea 保持對補丁版本的兼容性，其前兩個字段相同（`a.b.x` -> `a.b.y`），
|
||||
這些補丁版本可以使用相同的數據庫結構進行升級和降級。
|
||||
否則（`a.b.?` -> `a.c.?`），較新的 Gitea 版本將升級舊數據庫
|
||||
到可能與舊版本不同的新結構。
|
||||
|
||||
例如：
|
||||
|
||||
| 從 | 到 | 結果 |
|
||||
| ----- | ----- | ------------------------------------------------------------------------------------------------- |
|
||||
| 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，請使用備份進行降級。 |
|
||||
|
||||
**由於您無法運行升級後的數據庫的舊版 Gitea，
|
||||
在數據庫升級之前應始終進行備份。**
|
||||
|
||||
如果您在生產環境中使用 Gitea，強烈建議在升級之前進行備份，
|
||||
即使升級是在補丁版本之間進行的。
|
||||
|
||||
備份步驟：
|
||||
|
||||
- 停止 Gitea 實例
|
||||
- 備份數據庫
|
||||
- 備份 Gitea 配置
|
||||
- 備份 `APP_DATA_PATH` 中的 Gitea 數據文件
|
||||
- 備份 Gitea 外部存儲（例如：S3/MinIO 或其他使用的存儲）
|
||||
|
||||
如果您使用雲服務或具有快照功能的文件系統，
|
||||
為 Gitea 數據卷和相關對象存儲創建快照更方便。
|
||||
|
||||
在所有步驟準備就緒後，下載新版本，停止應用程序，執行備份，
|
||||
然後啟動新應用程序。在每次啟動時，Gitea 會驗證數據庫是否是最新的，並自動
|
||||
執行任何必要的遷移。根據數據庫的大小，這可能會在
|
||||
首次啟動期間需要一些額外時間，期間應用程序將不可用。
|
||||
|
||||
## 使用 Docker 升級
|
||||
|
||||
- `docker pull` 最新的 Gitea 版本。
|
||||
- 停止運行的實例，備份數據。
|
||||
- 使用 `docker` 或 `docker-compose` 啟動較新的 Gitea Docker 容器。
|
||||
|
||||
## 從包升級
|
||||
|
||||
- 停止運行的實例，備份數據。
|
||||
- 使用您的包管理器將 Gitea 升級到最新版本。
|
||||
- 啟動 Gitea 實例。
|
||||
|
||||
## 從二進制文件升級
|
||||
|
||||
- 將最新的 Gitea 二進制文件下載到臨時目錄。
|
||||
- 停止運行的實例，備份數據。
|
||||
- 用下載的二進制文件替換已安裝的 Gitea 二進制文件。
|
||||
- 啟動 Gitea 實例。
|
||||
|
||||
可以在 Gitea 的源代碼樹中找到一個自動執行這些步驟的腳本，用於在 Linux 上部署 [`contrib/upgrade.sh`](https://github.com/go-gitea/gitea/blob/main/contrib/upgrade.sh)。
|
||||
|
||||
## 注意自定義模板
|
||||
|
||||
Gitea 的模板結構和變量可能會在版本之間發生變化，如果您使用自定義模板，
|
||||
請注意您的模板是否與您使用的 Gitea 版本兼容。
|
||||
|
||||
如果自定義模板與 Gitea 版本不匹配，您可能會遇到：
|
||||
`50x` 服務器錯誤，頁面組件丟失或故障，頁面佈局異常，...
|
||||
刪除或更新不兼容的模板，Gitea 網頁將再次正常工作。
|
||||
+71
@@ -0,0 +1,71 @@
|
||||
---
|
||||
date: "2016-12-21T15:00:00-02:00"
|
||||
slug: "windows-service"
|
||||
sidebar_position: 50
|
||||
aliases:
|
||||
- /zh-tw/windows-service
|
||||
---
|
||||
|
||||
# 註冊為 Windows 服務
|
||||
|
||||
## 先決條件
|
||||
|
||||
在 C:\gitea\custom\conf\app.ini 中進行以下更改：
|
||||
|
||||
```ini title="app.ini"
|
||||
RUN_USER = COMPUTERNAME$
|
||||
```
|
||||
|
||||
將 Gitea 設置為以本地系統用戶身份運行。
|
||||
|
||||
COMPUTERNAME 是命令行中 `echo %COMPUTERNAME%` 的響應。如果響應是 `USER-PC`，則 `RUN_USER = USER-PC$`
|
||||
|
||||
### 使用絕對路徑
|
||||
|
||||
如果您使用 SQLite3，請更改 `PATH` 以包含完整路徑：
|
||||
|
||||
```ini title="app.ini"
|
||||
[database]
|
||||
PATH = c:/gitea/data/gitea.db
|
||||
```
|
||||
|
||||
## 註冊 Gitea
|
||||
|
||||
要將 Gitea 註冊為 Windows 服務，請以管理員身份打開命令提示符 (cmd)，
|
||||
然後運行以下命令：
|
||||
|
||||
```sh
|
||||
sc.exe create gitea start= auto binPath= "\"C:\gitea\gitea.exe\" web --config \"C:\gitea\custom\conf\app.ini\""
|
||||
```
|
||||
|
||||
不要忘記將 `C:\gitea` 替換為正確的 Gitea 目錄。
|
||||
|
||||
打開“Windows 服務”，搜索名為“gitea”的服務，右鍵單擊它並單擊
|
||||
“運行”。如果一切正常，Gitea 將在 `http://localhost:3000`（或配置的端口）上可訪問。
|
||||
|
||||
### 服務啟動類型
|
||||
|
||||
觀察到在加載系統期間啟動時，Gitea 服務可能會在 Windows 事件日誌中記錄超時並且無法啟動。
|
||||
在這種情況下，將啟動類型更改為“自動延遲”。這可以在服務創建期間完成，也可以通過運行配置命令完成
|
||||
|
||||
```sh
|
||||
sc.exe config gitea start= delayed-auto
|
||||
```
|
||||
|
||||
### 添加啟動依賴項
|
||||
|
||||
要向 Gitea Windows 服務添加啟動依賴項（例如 Mysql、Mariadb），請以管理員身份運行以下命令：
|
||||
|
||||
```sh
|
||||
sc.exe config gitea depend= mariadb
|
||||
```
|
||||
|
||||
這將確保當 Windows 機器重新啟動時，Gitea 的自動啟動將推遲到數據庫準備就緒，從而減少啟動失敗。
|
||||
|
||||
## 註銷 Gitea
|
||||
|
||||
要將 Gitea 註銷為 Windows 服務，請以管理員身份打開命令提示符 (cmd) 並運行：
|
||||
|
||||
```sh
|
||||
sc.exe delete gitea
|
||||
```
|
||||
+362
@@ -0,0 +1,362 @@
|
||||
---
|
||||
date: "2020-02-09T20:00:00+02:00"
|
||||
slug: "install-with-docker-rootless"
|
||||
sidebar_position: 60
|
||||
aliases:
|
||||
- /zh-tw/install-with-docker-rootless
|
||||
---
|
||||
|
||||
# 使用 Docker（無根）安裝
|
||||
|
||||
Gitea 在其 Docker Hub 組織中提供自動更新的 Docker 映像。可以
|
||||
始終使用最新的穩定標籤或使用另一個處理更新的服務
|
||||
Docker 映像。
|
||||
|
||||
無根映像使用 Gitea 內部 SSH 提供 Git 協議，不支持 OpenSSH。
|
||||
|
||||
此參考設置指導用戶通過基於 `docker-compose` 的設置，但 `docker-compose` 的安裝
|
||||
不在本文檔的範圍內。要安裝 `docker-compose` 本身，請遵循
|
||||
官方[安裝說明](https://docs.docker.com/compose/install/)。
|
||||
|
||||
## 基礎
|
||||
|
||||
最簡單的設置只是創建一個卷和一個網絡，並啟動 `docker.gitea.com/gitea:latest-rootless`
|
||||
作為服務的映像。由於沒有可用的數據庫，可以使用 SQLite3 進行初始化。
|
||||
|
||||
為 `data` 和 `config` 創建一個目錄：
|
||||
|
||||
```sh
|
||||
mkdir -p gitea/{data,config}
|
||||
cd gitea
|
||||
touch docker-compose.yml
|
||||
```
|
||||
|
||||
然後將以下內容粘貼到名為 `docker-compose.yml` 的文件中：
|
||||
|
||||
```yaml
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
restart: always
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:2222"
|
||||
```
|
||||
|
||||
請注意，卷應由配置文件中指定的 UID/GID 的用戶/組擁有。默認情況下，docker 中的 Gitea 將使用 uid:1000 gid:1000。如果需要，您可以使用以下命令設置這些文件夾的所有權：
|
||||
|
||||
```sh
|
||||
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 服務器，請調整
|
||||
端口部分。通常只需更改主機端口並保持容器內的端口不變。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
restart: always
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- - "3000:3000"
|
||||
- - "2222:2222"
|
||||
+ - "80:3000"
|
||||
+ - "22:2222"
|
||||
```
|
||||
|
||||
## MySQL 數據庫
|
||||
|
||||
要將 Gitea 與 MySQL 數據庫結合使用，請將這些更改應用到
|
||||
上面創建的 `docker-compose.yml` 文件。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
+ environment:
|
||||
+ - GITEA__database__DB_TYPE=mysql
|
||||
+ - GITEA__database__HOST=db:3306
|
||||
+ - GITEA__database__NAME=gitea
|
||||
+ - GITEA__database__USER=gitea
|
||||
+ - GITEA__database__PASSWD=gitea
|
||||
restart: always
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:2222"
|
||||
+ depends_on:
|
||||
+ - db
|
||||
+
|
||||
+ db:
|
||||
+ image: docker.io/library/mysql:8
|
||||
+ restart: always
|
||||
+ environment:
|
||||
+ - MYSQL_ROOT_PASSWORD=gitea
|
||||
+ - MYSQL_USER=gitea
|
||||
+ - MYSQL_PASSWORD=gitea
|
||||
+ - MYSQL_DATABASE=gitea
|
||||
+ volumes:
|
||||
+ - ./mysql:/var/lib/mysql
|
||||
```
|
||||
|
||||
## PostgreSQL 數據庫
|
||||
|
||||
要將 Gitea 與 PostgreSQL 數據庫結合使用，請將這些更改應用到
|
||||
上面創建的 `docker-compose.yml` 文件。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
environment:
|
||||
+ - GITEA__database__DB_TYPE=postgres
|
||||
+ - GITEA__database__HOST=db:5432
|
||||
+ - GITEA__database__NAME=gitea
|
||||
+ - GITEA__database__USER=gitea
|
||||
+ - GITEA__database__PASSWD=gitea
|
||||
restart: always
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:2222"
|
||||
+ depends_on:
|
||||
+ - db
|
||||
+
|
||||
+ db:
|
||||
+ image: docker.io/library/postgres:14
|
||||
+ restart: always
|
||||
+ environment:
|
||||
+ - POSTGRES_USER=gitea
|
||||
+ - POSTGRES_PASSWORD=gitea
|
||||
+ - POSTGRES_DB=gitea
|
||||
+ volumes:
|
||||
+ - ./postgres:/var/lib/postgresql/data
|
||||
```
|
||||
|
||||
## 命名卷
|
||||
|
||||
要使用命名卷而不是主機卷，請在 `docker-compose.yml` 配置中定義並使用命名卷。此更改將自動
|
||||
創建所需的卷。您不需要擔心命名卷的權限；Docker 會自動處理。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
+volumes:
|
||||
+ gitea-data:
|
||||
+ driver: local
|
||||
+ gitea-config:
|
||||
+ driver: local
|
||||
+
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
restart: always
|
||||
volumes:
|
||||
- - ./data:/var/lib/gitea
|
||||
+ - gitea-data:/var/lib/gitea
|
||||
- - ./config:/etc/gitea
|
||||
+ - gitea-config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:2222"
|
||||
```
|
||||
|
||||
MySQL 或 PostgreSQL 容器需要單獨創建。
|
||||
|
||||
## 自定義用戶
|
||||
|
||||
您可以選擇使用自定義用戶（遵循 --user 標誌定義 https://docs.docker.com/engine/reference/run/#user）。
|
||||
例如，要克隆主機用戶 `git` 定義，請使用命令 `id -u git` 並將其添加到 `docker-compose.yml` 文件中：
|
||||
請確保掛載的文件夾可由用戶寫入。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
restart: always
|
||||
+ user: 1001
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:2222"
|
||||
```
|
||||
|
||||
## 啟動
|
||||
|
||||
:::note
|
||||
從 2023 年 7 月起，Compose V1 停止接收更新。它也不再可用於 Docker Desktop 的新版本中。
|
||||
|
||||
Compose V2 包含在所有當前支持的 Docker Desktop 版本中。請使用 V2 進行以下操作。
|
||||
:::
|
||||
|
||||
要基於 `docker-compose` 啟動此設置，請執行 `docker-compose up -d`，
|
||||
在後台啟動 Gitea。使用 `docker-compose ps` 將顯示 Gitea 是否
|
||||
正確啟動。可以使用 `docker-compose logs` 查看日誌。
|
||||
|
||||
要關閉設置，請執行 `docker-compose down`。這將停止
|
||||
並殺死容器。卷將仍然存在。
|
||||
|
||||
:::note
|
||||
如果在 http 上使用非 3000 端口，請更改 app.ini 以匹配
|
||||
`LOCAL_ROOT_URL = http://localhost:3000/`。
|
||||
:::
|
||||
|
||||
## 安裝
|
||||
|
||||
通過 `docker-compose` 啟動 Docker 設置後，應該可以使用
|
||||
喜愛的瀏覽器完成安裝。訪問 http://server-ip:3000 並按照
|
||||
安裝向導進行操作。如果數據庫是使用 `docker-compose` 設置啟動的，
|
||||
如上所述，請注意 `db` 必須用作數據庫主機名。
|
||||
|
||||
## 自定義
|
||||
|
||||
[此處](../administration/customizing-gitea.md) 描述的自定義文件應
|
||||
放置在 `/var/lib/gitea/custom` 目錄中。如果使用主機卷，則可以很容易地訪問這些
|
||||
文件；對於命名卷，這是通過另一個容器或直接訪問
|
||||
`/var/lib/docker/volumes/gitea_gitea/_/var_lib_gitea` 來完成的。配置文件將保存在
|
||||
安裝後的 `/etc/gitea/app.ini` 中。
|
||||
|
||||
## 升級
|
||||
|
||||
:::warning
|
||||
:exclamation::exclamation: **確保您已將數據卷掛載到 Docker 容器外的某個位置** :exclamation::exclamation:
|
||||
:::
|
||||
|
||||
要將您的安裝升級到最新版本：
|
||||
|
||||
```bash
|
||||
# 編輯 `docker-compose.yml` 以更新版本（如果已指定）
|
||||
# 拉取新映像
|
||||
docker-compose pull
|
||||
# 啟動新容器，自動刪除舊容器
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
## 從標準映像升級
|
||||
|
||||
- 備份您的設置
|
||||
- 將卷掛載點從 /data 更改為 /var/lib/gitea
|
||||
- 如果您使用了自定義 app.ini，請將其移動到掛載到 /etc/gitea 的新卷中
|
||||
- 將文件夾（在卷內）重命名為 gitea 為 custom
|
||||
- 如有需要，編輯 app.ini
|
||||
- 設置 START_SSH_SERVER = true
|
||||
- 使用映像 docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
|
||||
## 使用環境變量管理部署
|
||||
|
||||
除了上述環境變量外，`app.ini` 中的任何設置都可以設置
|
||||
或使用形式為 `GITEA__SECTION_NAME__KEY_NAME` 的環境變量覆蓋。
|
||||
這些設置在每次 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` 文件中設置。
|
||||
|
||||
這些設置也可以通過定義形式為的環境變量來設置或覆蓋：
|
||||
`GITEA__section_name__KEY_NAME__FILE` 指向文件。
|
||||
|
||||
```bash
|
||||
...
|
||||
services:
|
||||
server:
|
||||
environment:
|
||||
- GITEA__mailer__ENABLED=true
|
||||
- GITEA__mailer__FROM=${GITEA__mailer__FROM:?GITEA__mailer__FROM not set}
|
||||
- GITEA__mailer__PROTOCOL=smtp
|
||||
- GITEA__mailer__HOST=${GITEA__mailer__HOST:?GITEA__mailer__HOST not set}
|
||||
- GITEA__mailer__IS_TLS_ENABLED=true
|
||||
- GITEA__mailer__USER=${GITEA__mailer__USER:-apikey}
|
||||
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
|
||||
```
|
||||
|
||||
要設置所需的 TOKEN 和 SECRET 值，請考慮使用 Gitea 的內置[生成實用程序函數](../administration/command-line.md#generate)。
|
||||
|
||||
# SSH 容器透傳
|
||||
|
||||
由於 SSH 在容器內運行，因此如果需要 SSH 支持，則需要將 SSH 從主機透傳到容器。一種選擇是將容器 SSH 運行在非標準端口上（或將主機端口移動到非標準端口）。另一種可能更直接的方法是將 SSH 命令從主機轉發到容器。以下說明了這種設置。
|
||||
|
||||
本指南假設您已在主機上創建了一個名為 `git` 的用戶，該用戶有權運行 `docker exec`，並且 Gitea 容器名為 `gitea`。您需要修改該用戶的 shell 以使用 `docker exec` 將命令轉發到容器內的 `sh` 可執行文件。
|
||||
|
||||
首先，在主機上創建文件 `/usr/local/bin/gitea-shell`，內容如下：
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
/usr/bin/docker exec -i --env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea sh "$@"
|
||||
```
|
||||
|
||||
請注意，docker 命令中的 `gitea` 是容器的名稱。如果您命名不同，請不要忘記更改它。
|
||||
|
||||
您還應確保已正確設置 shell 包裝器的權限：
|
||||
|
||||
```bash
|
||||
sudo chmod +x /usr/local/bin/gitea-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` 中添加以下塊：
|
||||
|
||||
```bash
|
||||
Match User git
|
||||
AuthorizedKeysCommandUser 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` 選項。）
|
||||
|
||||
剩下的就是重啟 SSH 服務器：
|
||||
|
||||
```bash
|
||||
sudo systemctl restart sshd
|
||||
```
|
||||
|
||||
**注意**
|
||||
|
||||
這實際上並未使用 docker SSH - 它只是使用周圍的命令。
|
||||
理論上，您可以不運行內部 SSH 服務器。
|
||||
@@ -0,0 +1,345 @@
|
||||
---
|
||||
date: "2020-03-19T19:27:00+02:00"
|
||||
slug: "install-with-docker"
|
||||
sidebar_position: 70
|
||||
aliases:
|
||||
- /zh-tw/install-with-docker
|
||||
---
|
||||
|
||||
# 使用 Docker 安裝
|
||||
|
||||
Gitea 在其 Docker Hub 組織中提供自動更新的 Docker 映像。可以始終使用最新的穩定標籤或使用其他服務來處理 Docker 映像的更新。
|
||||
|
||||
此參考設置指導用戶基於 `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`）
|
||||
|
||||
```yaml
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- ./gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "222:22"
|
||||
```
|
||||
|
||||
## 端口
|
||||
|
||||
要在不同的端口上綁定集成的 OpenSSH 守護進程和 Web 服務器，請調整端口部分。通常只需更改主機端口並保持容器內的端口不變。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- ./gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- - "3000:3000"
|
||||
- - "222:22"
|
||||
+ - "8080:3000"
|
||||
+ - "2221:22"
|
||||
```
|
||||
|
||||
## 數據庫
|
||||
|
||||
### MySQL 數據庫
|
||||
|
||||
要將 Gitea 與 MySQL 數據庫結合使用，請對上面創建的 `docker-compose.yml` 文件進行以下更改。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
+ - GITEA__database__DB_TYPE=mysql
|
||||
+ - GITEA__database__HOST=db:3306
|
||||
+ - GITEA__database__NAME=gitea
|
||||
+ - GITEA__database__USER=gitea
|
||||
+ - GITEA__database__PASSWD=gitea
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- ./gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "222:22"
|
||||
+ depends_on:
|
||||
+ - db
|
||||
+
|
||||
+ db:
|
||||
+ image: docker.io/library/mysql:8
|
||||
+ restart: always
|
||||
+ environment:
|
||||
+ - MYSQL_ROOT_PASSWORD=gitea
|
||||
+ - MYSQL_USER=gitea
|
||||
+ - MYSQL_PASSWORD=gitea
|
||||
+ - MYSQL_DATABASE=gitea
|
||||
+ networks:
|
||||
+ - gitea
|
||||
+ volumes:
|
||||
+ - ./mysql:/var/lib/mysql
|
||||
```
|
||||
|
||||
### PostgreSQL 數據庫
|
||||
|
||||
要將 Gitea 與 PostgreSQL 數據庫結合使用，請對上面創建的 `docker-compose.yml` 文件進行以下更改。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
+ - GITEA__database__DB_TYPE=postgres
|
||||
+ - GITEA__database__HOST=db:5432
|
||||
+ - GITEA__database__NAME=gitea
|
||||
+ - GITEA__database__USER=gitea
|
||||
+ - GITEA__database__PASSWD=gitea
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- ./gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "222:22"
|
||||
+ depends_on:
|
||||
+ - db
|
||||
+
|
||||
+ db:
|
||||
+ image: docker.io/library/postgres:14
|
||||
+ restart: always
|
||||
+ environment:
|
||||
+ - POSTGRES_USER=gitea
|
||||
+ - POSTGRES_PASSWORD=gitea
|
||||
+ - POSTGRES_DB=gitea
|
||||
+ networks:
|
||||
+ - gitea
|
||||
+ volumes:
|
||||
+ - ./postgres:/var/lib/postgresql/data
|
||||
```
|
||||
|
||||
## 命名卷
|
||||
|
||||
要使用命名卷而不是主機卷，請在 `docker-compose.yml` 配置中定義並使用命名卷。此更改將自動創建所需的卷。使用命名卷時，您不需要擔心權限問題；Docker 會自動處理。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
+volumes:
|
||||
+ gitea:
|
||||
+ driver: local
|
||||
+
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- - ./gitea:/data
|
||||
+ - gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "222:22"
|
||||
```
|
||||
|
||||
MySQL 或 PostgreSQL 容器需要單獨創建。
|
||||
|
||||
## 啟動
|
||||
|
||||
:::note
|
||||
從 2023 年 7 月起，Compose V1 停止接收更新。它也不再包含在 Docker Desktop 的新版本中。
|
||||
|
||||
Compose V2 包含在所有當前支持的 Docker Desktop 版本中。請使用 V2 進行以下操作。
|
||||
:::
|
||||
|
||||
要基於 `docker-compose` 啟動此設置，請執行 `docker-compose up -d`，以在後台啟動 Gitea。使用 `docker-compose ps` 將顯示 Gitea 是否正確啟動。可以使用 `docker-compose logs` 查看日誌。
|
||||
|
||||
要關閉設置，請執行 `docker-compose down`。這將停止並殺死容器。卷仍然存在。
|
||||
|
||||
:::note
|
||||
如果在 http 上使用非 3000 端口，請更改 app.ini 以匹配 `LOCAL_ROOT_URL = http://localhost:3000/`。
|
||||
:::
|
||||
|
||||
## 安裝
|
||||
|
||||
通過 `docker-compose` 啟動 Docker 設置後，應該可以使用喜愛的瀏覽器來完成安裝。訪問 http://server-ip:3000 並按照安裝向導進行操作。如果數據庫是使用上述 `docker-compose` 設置啟動的，請注意，數據庫主機名必須使用 `db`。
|
||||
|
||||
## 使用環境變量配置 Gitea 內的用戶
|
||||
|
||||
- `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`。
|
||||
|
||||
## 升級
|
||||
|
||||
:::warning
|
||||
確保您已將卷數據保存到 Docker 容器外的某個位置
|
||||
:::
|
||||
|
||||
要將您的安裝升級到最新版本：
|
||||
|
||||
```bash
|
||||
# 編輯 `docker-compose.yml` 以更新版本（如果已指定）
|
||||
# 拉取新映像
|
||||
docker-compose pull
|
||||
# 啟動新容器，自動刪除舊容器
|
||||
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)。
|
||||
|
||||
這些環境變量可以在 `docker-compose.yml` 中傳遞給 Docker 容器。以下示例將在設置所需的環境變量 `GITEA__mailer__FROM`、`GITEA__mailer__HOST`、`GITEA__mailer__PASSWD` 時啟用 SMTP 郵件服務器。
|
||||
|
||||
這些設置也可以通過定義形式為 `GITEA__section_name__KEY_NAME__FILE` 的環境變量並指向文件的內容來設置或覆蓋。
|
||||
|
||||
```yaml
|
||||
---
|
||||
services:
|
||||
server:
|
||||
environment:
|
||||
- GITEA__mailer__ENABLED=true
|
||||
- GITEA__mailer__FROM=${GITEA__mailer__FROM:?GITEA__mailer__FROM not set}
|
||||
- GITEA__mailer__PROTOCOL=smtps
|
||||
- GITEA__mailer__SMTP_ADDR=${GITEA__mailer__SMTP_ADDR:?GITEA__mailer__SMTP_ADDR not set}
|
||||
- GITEA__mailer__SMTP_PORT=${GITEA__mailer__SMTP_PORT:?GITEA__mailer__SMTP_PORT not set}
|
||||
- GITEA__mailer__USER=${GITEA__mailer__USER:-apikey}
|
||||
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
|
||||
```
|
||||
|
||||
Gitea 將自動為每個新安裝生成新的密鑰/令牌並將其寫入 app.ini。如果您想手動設置密鑰/令牌，可以使用以下 Docker 命令來使用 Gitea 的內置[生成實用程序函數](../administration/command-line.md#generate)。安裝後請勿丟失/更改您的 SECRET_KEY，否則加密數據將無法解密。
|
||||
|
||||
以下命令將輸出新的 `SECRET_KEY` 和 `INTERNAL_TOKEN` 到 `stdout`，然後您可以將其放置在您的環境變量中。
|
||||
|
||||
```bash
|
||||
docker run -it --rm docker.gitea.com/gitea:1 gitea generate secret SECRET_KEY
|
||||
docker run -it --rm docker.gitea.com/gitea:1 gitea generate secret INTERNAL_TOKEN
|
||||
```
|
||||
|
||||
```yaml
|
||||
---
|
||||
services:
|
||||
server:
|
||||
environment:
|
||||
- GITEA__security__SECRET_KEY=[value returned by generate secret SECRET_KEY]
|
||||
- GITEA__security__INTERNAL_TOKEN=[value returned by generate secret INTERNAL_TOKEN]
|
||||
```
|
||||
|
||||
## SSH 容器透傳
|
||||
|
||||
由於 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` 文件。
|
||||
7. 將選擇第一個匹配的條目，假設這是 Gitea 條目，則現在將執行 `command=`。
|
||||
8. SSH 服務器為 `git` 用戶創建一個用戶會話，並使用 `git` 用戶的 shell 運行 `command=`
|
||||
9. 這將運行 `gitea serv`，接管 SSH 會話的其餘部分並管理 gitea 的身份驗證和授權。
|
||||
|
||||
現在，要使 SSH 透傳工作，我們需要主機 SSH 匹配公鑰，然後在 Docker 上運行 `gitea serv`。有多種方法可以做到這一點。然而，所有這些都需要將有關 Docker 的一些信息傳遞給主機。
|
||||
|
||||
### SSHing Shim（使用 authorized_keys）
|
||||
|
||||
在此選項中，主機只需使用 gitea 創建的 `authorized_keys`，但在第 9 步中，主機運行的 `gitea` 命令是一個 shim，實際上運行 ssh 進入 docker，然後運行真正的 docker `gitea` 本身。
|
||||
|
||||
- 要使轉發工作，容器的 SSH 端口（22）需要在 `docker-compose.yml` 中映射到主機端口 2222。由於此端口不需要暴露給外界，因此可以映射到主機的 `localhost`：
|
||||
|
||||
```yaml
|
||||
ports:
|
||||
# [...]
|
||||
- "127.0.0.1:2222:22"
|
||||
```
|
||||
|
||||
- 接下來在主機上創建與容器值 `USER_UID`/`USER_GID` 共享相同 `UID`/`GID` 的 `git` 用戶。這些值可以在 `docker-compose.yml` 中設置為環境變量：
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
```
|
||||
|
||||
- 將主機的 `/home/git/.ssh` 安裝到容器中。這確保了 `authorized_keys` 文件在主機 `git` 用戶和容器 `git` 用戶之間共享，否則 SSH 身份驗證無法在容器內工作。
|
||||
|
||||
```yaml
|
||||
volumes:
|
||||
- /home/git/.ssh/:/data/git/.ssh
|
||||
```
|
||||
|
||||
- 現在需要在主機
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
date: "2016-12-27T16:00:00+02:00"
|
||||
title: "Usage"
|
||||
slug: "usage"
|
||||
sidebar_position: 35
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "Usage"
|
||||
sidebar_position: 30
|
||||
identifier: "usage"
|
||||
---
|
||||
@@ -0,0 +1,366 @@
|
||||
---
|
||||
date: "2023-04-27T15:00:00+08:00"
|
||||
slug: "act-runner"
|
||||
sidebar_position: 20
|
||||
---
|
||||
|
||||
# Act Runner
|
||||
|
||||
本頁將詳細介紹 [act runner](https://gitea.com/gitea/act_runner)，這是 Gitea Actions 的 runner。
|
||||
|
||||
## 要求
|
||||
|
||||
目前 runner 支持兩種運行模式。一種是在 docker 容器中運行，另一種是在主機上運行。如果選擇在 [docker](https://docker.com) 容器中運行作業，建議先 [安裝 docker](https://docs.docker.com/engine/install/) 並確保 docker 守護進程正在運行。
|
||||
|
||||
其他與 Docker API 兼容的 OCI 容器引擎也應該可以工作，但未經測試。
|
||||
|
||||
但是，如果您確定只想在主機上直接運行作業，則不需要 docker。
|
||||
|
||||
有多種方法可以安裝 act runner。
|
||||
|
||||
## 使用二進制文件安裝
|
||||
|
||||
### 下載二進制文件
|
||||
|
||||
您可以從 [發布頁面](https://gitea.com/gitea/act_runner/releases) 下載二進制文件。
|
||||
但是，如果您想使用最新的夜間構建，可以從 [下載頁面](https://dl.gitea.com/act_runner/) 下載。
|
||||
|
||||
下載二進制文件時，請確保下載了適合您平台的正確文件。
|
||||
如果您使用的是類 Unix 操作系統，可以通過運行以下命令進行檢查。
|
||||
|
||||
```bash
|
||||
chmod +x act_runner
|
||||
./act_runner --version
|
||||
```
|
||||
|
||||
如果看到版本信息，則表示您已下載了正確的二進制文件。
|
||||
|
||||
### 獲取註冊令牌
|
||||
|
||||
您可以在不同級別註冊 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`。
|
||||
|
||||
如果看不到設置頁面，請確保您具有正確的權限並且已啟用 Actions。
|
||||
|
||||
註冊令牌的格式是一個隨機字符串 `D0gvfu2iHfUjNqCYVljVyRV14fISpJxxxxxxxxxx`。
|
||||
|
||||
註冊令牌也可以從 gitea [命令行界面](../../administration/command-line.md#actions-generate-runner-token) 獲取：
|
||||
|
||||
```
|
||||
gitea --config /etc/gitea/app.ini actions generate-runner-token
|
||||
```
|
||||
|
||||
令牌在註銷並使用 web 界面中的令牌重置鏈接替換為新令牌之前，對註冊多個 runner 有效。
|
||||
|
||||
### 配置
|
||||
|
||||
配置是通過配置文件完成的。它是可選的，當未指定配置文件時，將使用默認配置。您可以通過運行以下命令生成配置文件：
|
||||
|
||||
```bash
|
||||
./act_runner generate-config
|
||||
```
|
||||
|
||||
默認配置是安全的，可以直接使用。
|
||||
|
||||
```bash
|
||||
./act_runner generate-config > config.yaml
|
||||
./act_runner --config config.yaml [command]
|
||||
```
|
||||
|
||||
### 註冊 runner
|
||||
|
||||
在運行 act runner 之前需要註冊，因為 runner 需要知道從哪裡獲取作業。這對於 Gitea 實例識別 runner 也很重要。
|
||||
|
||||
如果使用二進制包安裝，可以通過運行以下命令註冊 act runner。
|
||||
|
||||
```bash
|
||||
./act_runner register
|
||||
```
|
||||
|
||||
或者，您可以使用 `--config` 選項指定前面提到的配置文件。
|
||||
|
||||
```bash
|
||||
./act_runner --config config.yaml register
|
||||
```
|
||||
|
||||
您將被要求逐步輸入註冊信息，包括：
|
||||
|
||||
- Gitea 實例 URL，例如 `https://gitea.com/` 或 `http://192.168.8.8:3000/`。
|
||||
- 註冊令牌。
|
||||
- runner 名稱，可選。如果留空，將使用主機名。
|
||||
- runner 標籤，可選。如果留空，將使用默認標籤。
|
||||
|
||||
您可能會對 runner 標籤感到困惑，稍後將解釋。
|
||||
|
||||
如果您想以非交互方式註冊 runner，可以使用參數進行註冊。
|
||||
|
||||
```bash
|
||||
./act_runner register --no-interactive --instance <instance_url> --token <registration_token> --name <runner_name> --labels <runner_labels>
|
||||
```
|
||||
|
||||
註冊 runner 後，您可以在當前目錄中找到一個名為 `.runner` 的新文件。
|
||||
該文件存儲註冊信息。
|
||||
請不要手動編輯它。
|
||||
如果該文件丟失或損壞，您可以簡單地刪除它並重新註冊。
|
||||
|
||||
如果您想將註冊信息存儲在其他位置，可以在配置文件中指定，
|
||||
並且不要忘記指定 `--config` 選項。
|
||||
|
||||
### 在命令行中啟動 runner
|
||||
|
||||
註冊 runner 後，可以通過運行以下命令運行它：
|
||||
|
||||
```shell
|
||||
./act_runner daemon
|
||||
```
|
||||
|
||||
或
|
||||
|
||||
```bash
|
||||
./act_runner daemon --config config.yaml
|
||||
```
|
||||
|
||||
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` 用戶的主目錄進行調整。
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Gitea Actions runner
|
||||
Documentation=https://gitea.com/gitea/act_runner
|
||||
After=docker.service
|
||||
|
||||
[Service]
|
||||
ExecStart=/usr/local/bin/act_runner daemon --config /etc/act_runner/config.yaml
|
||||
ExecReload=/bin/kill -s HUP $MAINPID
|
||||
WorkingDirectory=/var/lib/act_runner
|
||||
TimeoutSec=0
|
||||
RestartSec=10
|
||||
Restart=always
|
||||
User=act_runner
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
然後：
|
||||
|
||||
```bash
|
||||
# 加載新的 systemd 單元文件
|
||||
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)。
|
||||
|
||||
### 使用 LaunchDaemon(macOS) 啟動 runner
|
||||
|
||||
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"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
||||
<plist version="1.0">
|
||||
<dict>
|
||||
<key>Label</key>
|
||||
<string>com.gitea.act_runner</string>
|
||||
<key>ProgramArguments</key>
|
||||
<array>
|
||||
<string>/usr/local/bin/act_runner</string>
|
||||
<string>daemon</string>
|
||||
<string>--config</string>
|
||||
<string>/etc/act_runner/config.yaml</string>
|
||||
</array>
|
||||
<key>RunAtLoad</key>
|
||||
<true/>
|
||||
<key>KeepAlive</key>
|
||||
<true/>
|
||||
<key>WorkingDirectory</key>
|
||||
<string>/var/lib/act_runner</string>
|
||||
<key>StandardOutPath</key>
|
||||
<string>/var/lib/act_runner/act_runner.log</string>
|
||||
<key>StandardErrorPath</key>
|
||||
<string>/var/lib/act_runner/act_runner.err</string>
|
||||
<key>EnvironmentVariables</key>
|
||||
<dict>
|
||||
<key>PATH</key>
|
||||
<string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
|
||||
<key>HOME</key>
|
||||
<string>/var/lib/act_runner</string>
|
||||
</dict>
|
||||
<key>UserName</key>
|
||||
<string>_act_runner</string>
|
||||
</dict>
|
||||
</plist>
|
||||
```
|
||||
|
||||
然後：
|
||||
|
||||
```bash
|
||||
sudo launchctl load /Library/LaunchDaemon/com.gitea.act_runner.plist
|
||||
```
|
||||
|
||||
您還可以設置 Linux 服務或 Windows 服務，以便 runner 自動運行。
|
||||
|
||||
## 使用 docker 映像安裝
|
||||
|
||||
### 拉取映像
|
||||
|
||||
您可以從 [docker hub](https://hub.docker.com/r/gitea/act_runner/tags) 使用 docker 映像。
|
||||
就像二進制文件一樣，您可以使用 `nightly` 標籤使用最新的夜間構建，而 `latest` 標籤是最新的穩定版本。
|
||||
|
||||
```bash
|
||||
docker pull docker.io/gitea/act_runner:latest # 用於最新的穩定版本
|
||||
```
|
||||
|
||||
如果您想測試新功能，也可以使用 nightly 映像
|
||||
|
||||
```bash
|
||||
docker pull docker.io/gitea/act_runner:nightly # 用於最新的夜間構建
|
||||
```
|
||||
|
||||
### 配置
|
||||
|
||||
配置是可選的，但您也可以使用 docker 生成配置文件：
|
||||
|
||||
```bash
|
||||
docker run --entrypoint="" --rm -it docker.io/gitea/act_runner:latest act_runner generate-config > config.yaml
|
||||
```
|
||||
|
||||
使用 docker 映像時，可以使用 `CONFIG_FILE` 環境變量指定配置文件。確保該文件已作為卷掛載到容器中：
|
||||
|
||||
```bash
|
||||
docker run -v $PWD/config.yaml:/config.yaml -e CONFIG_FILE=/config.yaml ...
|
||||
```
|
||||
|
||||
您可能會注意到上面的命令都是不完整的，因為現在還不是運行 act runner 的時候。
|
||||
在運行 act runner 之前，我們需要先將其註冊到您的 Gitea 實例。
|
||||
|
||||
### 使用 docker 啟動 runner
|
||||
|
||||
如果您使用的是 docker 映像，行為會略有不同。在這種情況下，註冊和運行結合為一步，因此您需要在運行 act runner 時指定註冊信息。
|
||||
|
||||
使用 docker run 快速啟動如下。您需要從上述步驟中獲取 `<registration_token>`，並為 `<runner_name>` 提供一個特殊的唯一名稱
|
||||
|
||||
```bash
|
||||
docker run \
|
||||
-e GITEA_INSTANCE_URL=<instance_url> \
|
||||
-e GITEA_RUNNER_REGISTRATION_TOKEN=<registration_token> \
|
||||
-e GITEA_RUNNER_NAME=<runner_name> \
|
||||
--name my_runner \
|
||||
-d docker.io/gitea/act_runner:nightly
|
||||
```
|
||||
|
||||
有更多參數可以配置它。
|
||||
|
||||
```bash
|
||||
docker run \
|
||||
-v $PWD/config.yaml:/config.yaml \
|
||||
-v $PWD/data:/data \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
-e CONFIG_FILE=/config.yaml \
|
||||
-e GITEA_INSTANCE_URL=<instance_url> \
|
||||
-e GITEA_RUNNER_REGISTRATION_TOKEN=<registration_token> \
|
||||
-e GITEA_RUNNER_NAME=<runner_name> \
|
||||
-e GITEA_RUNNER_LABELS=<runner_labels> \
|
||||
--name my_runner \
|
||||
-d docker.io/gitea/act_runner:nightly
|
||||
```
|
||||
|
||||
您可能會注意到我們已將 `/var/run/docker.sock` 掛載到容器中。
|
||||
這是因為 act runner 將在 docker 容器中運行作業，因此需要與 docker 守護進程通信。
|
||||
如前所述，如果您想在主機上直接運行作業，可以刪除它。
|
||||
需要明確的是，“主機”實際上是指現在運行 act runner 的容器，而不是主機機器。
|
||||
|
||||
### 使用 docker compose 啟動 runner
|
||||
|
||||
您還可以使用以下 `docker-compose.yml` 設置 runner：
|
||||
|
||||
```yml
|
||||
version: "3.8"
|
||||
services:
|
||||
runner:
|
||||
image: docker.io/gitea/act_runner:nightly
|
||||
environment:
|
||||
CONFIG_FILE: /config.yaml
|
||||
GITEA_INSTANCE_URL: "${INSTANCE_URL}"
|
||||
GITEA_RUNNER_REGISTRATION_TOKEN: "${REGISTRATION_TOKEN}"
|
||||
GITEA_RUNNER_NAME: "${RUNNER_NAME}"
|
||||
GITEA_RUNNER_LABELS: "${RUNNER_LABELS}"
|
||||
volumes:
|
||||
- ./config.yaml:/config.yaml
|
||||
- ./data:/data
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
```
|
||||
|
||||
使用 docker 時，不需要進入容器並手動運行 `./act_runner daemon` 命令。容器成功啟動後，它將顯示為您的 Gitea 實例中的活動 runner。
|
||||
|
||||
## 高級配置
|
||||
|
||||
### 使用 docker 映像啟動 runner 時配置緩存
|
||||
|
||||
如果您不打算在工作流中使用 `actions/cache`，可以忽略此部分。
|
||||
|
||||
如果在沒有任何額外配置的情況下使用 `actions/cache`，它將返回以下錯誤：
|
||||
|
||||
> Failed to restore: getCacheEntry failed: connect ETIMEDOUT IP:PORT
|
||||
|
||||
發生此錯誤是因為 runner 容器和作業容器位於不同的網絡上，因此作業容器無法訪問 runner 容器。
|
||||
|
||||
因此，必須配置緩存操作以確保其正常運行。請按照以下步驟操作：
|
||||
|
||||
- 1.獲取運行 runner 容器的主機的 LAN IP 地址。
|
||||
- 2.查找運行 runner 容器的主機上的可用端口號。
|
||||
- 3.在配置文件中配置以下設置：
|
||||
|
||||
```yaml
|
||||
cache:
|
||||
enabled: true
|
||||
dir: ""
|
||||
# 使用第 1 步中獲取的 LAN IP
|
||||
host: "192.168.8.17"
|
||||
# 使用第 2 步中獲取的端口號
|
||||
port: 8088
|
||||
```
|
||||
|
||||
- 4.啟動容器時，將緩存端口映射到主機：
|
||||
|
||||
```bash
|
||||
docker run \
|
||||
--name gitea-docker-runner \
|
||||
-p 8088:8088 \
|
||||
-d docker.io/gitea/act_runner:nightly
|
||||
```
|
||||
|
||||
### 標籤
|
||||
|
||||
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-22.04:docker://node:16-bullseye` 為例。
|
||||
這意味著 runner 可以運行 `runs-on: ubuntu-22.04` 的作業，並且作業將在 docker 容器中運行，映像為 `node:16-bullseye`。
|
||||
|
||||
如果默認映像不足以滿足您的需求，並且您有足夠的磁盤空間使用更好更大的映像，可以將其更改為 `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)）。
|
||||
重新啟動 runner 後，它將使用這些新標籤，即通過調用 `./act_runner daemon --config config.yaml`。
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
date: "2023-02-25T00:00:00+00:00"
|
||||
slug: "badge"
|
||||
sidebar_position: 110
|
||||
---
|
||||
|
||||
# 徽章
|
||||
|
||||
Gitea 內置了徽章系統，允許您在其他地方顯示倉庫的狀態。您可以使用以下徽章：
|
||||
|
||||
## 工作流程徽章
|
||||
|
||||
Gitea Actions 工作流程徽章是一個顯示最新工作流程運行狀態的徽章。
|
||||
它設計為與 [GitHub Actions 工作流程徽章](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge) 兼容。
|
||||
|
||||
您可以使用以下 URL 獲取徽章：
|
||||
|
||||
```
|
||||
https://your-gitea-instance.com/{owner}/{repo}/actions/workflows/{workflow_file}/badge.svg?branch={branch}&event={event}
|
||||
```
|
||||
|
||||
- `{owner}`: 倉庫的所有者。
|
||||
- `{repo}`: 倉庫的名稱。
|
||||
- `{workflow_file}`: 工作流程文件的名稱。
|
||||
- `{branch}`: 可選。工作流程的分支。默認為倉庫的默認分支。
|
||||
- `{event}`: 可選。工作流程的事件。默認為無。
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
date: "2023-04-27T15:00:00+08:00"
|
||||
slug: "comparison"
|
||||
sidebar_position: 120
|
||||
---
|
||||
|
||||
# 與 GitHub Actions 的比較
|
||||
|
||||
儘管 Gitea Actions 設計為與 GitHub Actions 兼容，但它們之間仍存在一些差異。
|
||||
|
||||
## 附加功能
|
||||
|
||||
### 絕對操作 URL
|
||||
|
||||
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/)。
|
||||
|
||||
### 支持非標準語法 @yearly, @monthly, @weekly, @daily, @hourly 在計劃中
|
||||
|
||||
GitHub Actions 不支持這一點。https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
|
||||
|
||||
## 不支持的工作流程語法
|
||||
|
||||
### `concurrency`
|
||||
|
||||
用於一次運行一個作業。
|
||||
請參閱 [使用並發](https://docs.github.com/en/actions/using-jobs/using-concurrency)。
|
||||
|
||||
目前 Gitea Actions 忽略它。
|
||||
|
||||
### `run-name`
|
||||
|
||||
從工作流程生成的工作流程運行的名稱。
|
||||
請參閱 [GitHub Actions 的工作流程語法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#run-name)。
|
||||
|
||||
目前 Gitea Actions 忽略它。
|
||||
|
||||
### `permissions` 和 `jobs.<job_id>.permissions`
|
||||
|
||||
請參閱 [GitHub Actions 的工作流程語法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions)。
|
||||
|
||||
目前 Gitea Actions 忽略它。
|
||||
|
||||
### `jobs.<job_id>.timeout-minutes`
|
||||
|
||||
請參閱 [GitHub Actions 的工作流程語法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes)。
|
||||
|
||||
目前 Gitea Actions 忽略它。
|
||||
|
||||
### `jobs.<job_id>.continue-on-error`
|
||||
|
||||
請參閱 [GitHub Actions 的工作流程語法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error)。
|
||||
|
||||
目前 Gitea Actions 忽略它。
|
||||
|
||||
### `jobs.<job_id>.environment`
|
||||
|
||||
請參閱 [GitHub Actions 的工作流程語法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment)。
|
||||
|
||||
目前 Gitea Actions 忽略它。
|
||||
|
||||
### 複雜的 `runs-on`
|
||||
|
||||
請參閱 [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_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) 以跟踪此功能。
|
||||
|
||||
### 問題匹配器
|
||||
|
||||
問題匹配器是一種掃描操作輸出以查找指定正則表達式模式並在 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)
|
||||
|
||||
目前 Gitea Actions 忽略它。
|
||||
|
||||
### 表達式
|
||||
|
||||
對於 [表達式](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`。
|
||||
我們已經限制了此選項僅允許兩個值（`github` 和 `self`）。
|
||||
當設置為 `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`。
|
||||
|
||||
如果您的 Gitea 實例位於內部網或受限區域，您可以將 URL 設置為 `self`，以便默認僅從您自己的實例下載操作。
|
||||
當然，您仍然可以在工作流程中使用絕對 URL。
|
||||
|
||||
有關 `[actions].DEFAULT_ACTIONS_URL` 配置的更多詳細信息，請參閱 [配置備忘單](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
|
||||
### 上下文可用性
|
||||
|
||||
不檢查上下文可用性，因此您可以在更多地方使用 env 上下文。
|
||||
請參閱 [上下文可用性](https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability)。
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
date: "2023-04-27T15:00:00+08:00"
|
||||
slug: "design"
|
||||
sidebar_position: 140
|
||||
---
|
||||
|
||||
# Gitea Actions 的設計
|
||||
|
||||
Gitea Actions 有多個組件。本文件將分別描述它們。
|
||||
|
||||
## Act
|
||||
|
||||
[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 不支持它
|
||||
- 為每個作業啟動一個新容器，而不是重用，以確保隔離。
|
||||
|
||||
這些修改沒有理由合併到上游。
|
||||
如果用戶只想在本地運行受信任的操作，這些修改沒有意義。
|
||||
|
||||
然而，未來可能會有重疊，例如兩個項目都需要的錯誤修復或新功能。
|
||||
在這些情況下，我們將把更改貢獻回上游倉庫。
|
||||
|
||||
## Act runner
|
||||
|
||||
Gitea 的 runner 被稱為 act runner，因為它基於 act。
|
||||
|
||||
像其他 CI runner 一樣，我們將其設計為 Gitea 的外部部分，這意味著它應該在與 Gitea 不同的服務器上運行。
|
||||
|
||||
為了確保 runner 連接到正確的 Gitea 實例，我們需要使用令牌註冊它。
|
||||
此外，runner 將向 Gitea 介紹自己並通過報告其標籤來聲明它可以運行的作業類型。
|
||||
|
||||
前面提到過，工作流程文件中的 `runs-on: ubuntu-latest` 意味著作業將在具有 `ubuntu-latest` 標籤的 runner 上運行。
|
||||
但是 runner 如何知道運行 `ubuntu-latest`？答案在於將標籤映射到環境。
|
||||
這就是為什麼在註冊期間添加自定義標籤時，您需要輸入一些複雜的內容，如 `my_custom_label:docker://centos:7`。
|
||||
這意味著 runner 可以接受需要在 `my_custom_label` 上運行的作業，並將其通過 docker 容器運行，映像為 `centos:7`。
|
||||
|
||||
然而，docker 並不是唯一的選擇。
|
||||
act 還支持直接在主機上運行作業。
|
||||
這是通過標籤如 `linux_arm:host` 實現的。
|
||||
這個標籤表示 runner 可以接受需要在 `linux_arm` 上運行的作業，並直接在主機上運行它。
|
||||
|
||||
標籤的設計遵循格式 `label[:schema[:args]]`。
|
||||
如果省略 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` 的作業。
|
||||
|
||||
## 通信協議
|
||||
|
||||
由於 act runner 是 Gitea 的獨立部分，我們需要一個協議來讓 runner 與 Gitea 實例通信。
|
||||
然而，我們認為讓 Gitea 監聽一個新端口不是一個好主意。
|
||||
相反，我們希望重用 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/) 上找到。
|
||||
|
||||
## 網絡架構
|
||||
|
||||
讓我們來看看整體網絡架構。
|
||||
這將幫助您排除一些問題，並解釋為什麼用 Gitea 實例的回環地址註冊 runner 是個壞主意。
|
||||
|
||||
|
||||
|
||||
圖片中標記了四個網絡連接，箭頭的方向表示建立連接的方向。
|
||||
|
||||
### 連接 1，act runner 到 Gitea 實例
|
||||
|
||||
act runner 必須能夠連接到 Gitea 以接收任務並發送回執行結果。
|
||||
|
||||
### 連接 2，作業容器到 Gitea 實例
|
||||
|
||||
作業容器與 runner 有不同的網絡命名空間，即使它們在同一台機器上。
|
||||
如果工作流程中有 `actions/checkout@v4`，它們需要連接到 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 映像，這也需要訪問互聯網。
|
||||
|
||||
然而，訪問互聯網並不是絕對必要的。
|
||||
您可以配置您的 Gitea 實例從您的內聯設施中獲取操作或映像。
|
||||
|
||||
事實上，您的 Gitea 實例可以同時作為操作市場和映像註冊表。
|
||||
您可以將操作倉庫從 GitHub 鏡像到您的 Gitea 實例，並正常使用它們。
|
||||
而 [Gitea 容器註冊表](usage/packages/container.md) 可以用作 Docker 映像註冊表。
|
||||
|
||||
### 連接 4，作業容器到互聯網
|
||||
|
||||
當使用如 `actions/setup-go@v5` 的操作時，可能需要從互聯網下載資源以在作業容器中設置 Go 語言環境。
|
||||
因此，訪問互聯網是這些操作成功完成所必需的。
|
||||
|
||||
然而，這也是可選的。
|
||||
您可以使用自己的自定義操作來避免依賴互聯網訪問，或者您可以使用打包的 Docker 映像來運行已安裝所有依賴項的作業。
|
||||
|
||||
## 總結
|
||||
|
||||
使用 Gitea Actions 只需要確保 runner 可以連接到 Gitea 實例。
|
||||
訪問互聯網是可選的，但沒有它將需要一些額外的工作。
|
||||
換句話說：runner 最好能夠自己查詢互聯網，但您不需要將其暴露在互聯網上（無論是入站還是出站）。
|
||||
|
||||
如果您在使用 Gitea Actions 時遇到任何網絡問題，希望上圖可以幫助您排除它們。
|
||||
@@ -0,0 +1,166 @@
|
||||
---
|
||||
date: "2023-04-27T15:00:00+08:00"
|
||||
slug: "faq"
|
||||
sidebar_position: 200
|
||||
---
|
||||
|
||||
# 常見問題
|
||||
|
||||
這頁包含了一些關於 Gitea Actions 的常見問題和解答。
|
||||
|
||||
## 是否可以預設禁用新倉庫的 Actions？
|
||||
|
||||
可以，當你為實例啟用 Actions 時，你可以選擇預設為所有新倉庫啟用 `actions` 單元。
|
||||
|
||||
```ini
|
||||
[repository]
|
||||
; 移除 repo.actions 將不會為新創建的倉庫啟用 actions。
|
||||
DEFAULT_REPO_UNITS = ...,repo.actions
|
||||
```
|
||||
|
||||
## 我們應該在工作流程文件中使用 `${{ github.xyz }}` 還是 `${{ gitea.xyz }}`？
|
||||
|
||||
你可以使用 `github.xyz`，Gitea 也能正常運作。
|
||||
如前所述，Gitea Actions 設計上與 GitHub Actions 兼容。
|
||||
然而，我們建議使用 `gitea.xyz`，以防 Gitea 添加了 GitHub 沒有的功能，避免在工作流程文件中出現不同種類的 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) 下載腳本。
|
||||
但如果你想從其他地方（如 gitea.com）而不是 GitHub 使用 actions 怎麼辦？
|
||||
|
||||
好消息是你可以指定 URL 前綴來從任何地方使用 actions。
|
||||
這是 Gitea Actions 的一個額外語法。
|
||||
例如：
|
||||
|
||||
- `uses: https://gitea.com/xxx/xxx@xxx`
|
||||
- `uses: https://github.com/xxx/xxx@xxx`
|
||||
- `uses: http://your_gitea_instance.com/xxx@xxx`
|
||||
|
||||
注意，`https://` 或 `http://` 前綴是必要的！
|
||||
|
||||
這是與 GitHub Actions 的一個區別，後者僅支持來自 GitHub 的 actions 腳本。
|
||||
但這應該允許用戶在運行 Actions 時有更多的靈活性。
|
||||
|
||||
另外，如果你希望你的 runners 默認從你自己的 Gitea 實例下載 actions，你可以通過設置 `[actions].DEFAULT_ACTIONS_URL` 來配置。
|
||||
參見 [配置備忘單](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
|
||||
## 如何限制 runners 的權限？
|
||||
|
||||
Runners 只具有連接到你的 Gitea 實例的權限。
|
||||
當任何 runner 接收到一個要運行的任務時，它將臨時獲得與該任務相關的倉庫的有限權限。
|
||||
如果你想給 runner 更多的權限，允許它訪問更多的私有倉庫或外部系統，你可以傳遞 [secrets](usage/actions/secrets.md) 給它。
|
||||
|
||||
對 Actions 進行精細的權限控制是一項複雜的工作。
|
||||
未來，我們將為 Gitea 添加更多選項，使其更具可配置性，例如允許更多的寫入訪問倉庫或讀取同一組織中所有倉庫的訪問權限。
|
||||
|
||||
## 如何避免被黑客攻擊？
|
||||
|
||||
有兩種類型的可能攻擊：未知的 runner 竊取你的倉庫中的代碼或 secrets，或惡意腳本控制你的 runner。
|
||||
|
||||
避免前者意味著不允許你不認識的人為你的倉庫、組織或實例註冊 runners。
|
||||
|
||||
後者則有點複雜。
|
||||
如果你為你的公司使用私人 Gitea 實例，你可能不需要擔心安全問題，因為你信任你的同事並且可以追究他們的責任。
|
||||
|
||||
對於公共實例，情況有點不同。
|
||||
以下是我們在 [gitea.com](http://gitea.com/) 上的做法：
|
||||
|
||||
- 我們只為 "gitea" 組織註冊 runners，因此我們的 runners 不會執行來自其他倉庫的任務。
|
||||
- 我們的 runners 總是使用隔離的容器運行任務。雖然可以直接在主機上這樣做，但我們選擇不這樣做以提高安全性。
|
||||
- 要運行 fork pull requests 的 actions，需要批准。參見 [#22803](https://github.com/go-gitea/gitea/pull/22803)。
|
||||
- 如果有人在 [gitea.com](http://gitea.com/) 上為他們的倉庫或組織註冊了他們自己的 runner，我們不反對，只是不會在我們的組織中使用它。然而，他們應該注意確保該 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)。
|
||||
|
||||
```yaml
|
||||
defaults:
|
||||
run:
|
||||
shell: powershell
|
||||
```
|
||||
|
||||
## 為什麼選擇 GitHub Actions？為什麼不選擇與 GitLab CI/CD 兼容的東西？
|
||||
|
||||
[@lunny](https://gitea.com/lunny) 在 [實現 actions 的問題](https://github.com/go-gitea/gitea/issues/13539) 中解釋了這一點。
|
||||
此外，Actions 不僅僅是一個 CI/CD 系統，還是一個自動化工具。
|
||||
|
||||
開源世界中還實現了許多 [marketplace actions](https://github.com/marketplace?type=actions)。
|
||||
能夠重用它們是令人興奮的。
|
||||
|
||||
## 如果它在多個標籤上運行，例如 `runs-on: [label_a, label_b]` 會怎樣？
|
||||
|
||||
這是有效的語法。
|
||||
這意味著它應該在具有 `label_a` **和** `label_b` 標籤的 runners 上運行，參見 [GitHub Actions 的工作流程語法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on)。
|
||||
不幸的是，act runner 不這樣工作。
|
||||
如前所述，我們將標籤映射到環境：
|
||||
|
||||
- `ubuntu` → `ubuntu:22.04`
|
||||
- `centos` → `centos:8`
|
||||
|
||||
但我們需要將標籤組映射到環境，例如：
|
||||
|
||||
- `[ubuntu]` → `ubuntu:22.04`
|
||||
- `[with-gpu]` → `linux:with-gpu`
|
||||
- `[ubuntu, with-gpu]` → `ubuntu:22.04_with-gpu`
|
||||
|
||||
我們還需要重新設計任務如何分配給 runners。
|
||||
具有 `ubuntu`、`centos` 或 `with-gpu` 的 runner 並不一定表示它可以接受具有 `[centos, with-gpu]` 的任務。
|
||||
因此，runner 應該通知 Gitea 實例它只能接受具有 `[ubuntu]`、`[centos]`、`[with-gpu]` 和 `[ubuntu, with-gpu]` 的任務。
|
||||
這不是技術問題，只是在早期設計中被忽略了。
|
||||
參見 [runtime.go#L65](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L65)。
|
||||
|
||||
目前，act runner 嘗試匹配標籤中的每個人並使用它找到的第一個匹配。
|
||||
|
||||
## runner 的代理標籤和自定義標籤有什麼區別？
|
||||
|
||||
|
||||
|
||||
代理標籤是在註冊期間由 runner 向 Gitea 實例報告的。
|
||||
另一方面，自定義標籤是由 Gitea 管理員或組織或倉庫的所有者手動添加的（取決於 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 來創建你自己的版本：如果你能並且認為你的更改也會幫助其他人，請將更改貢獻回來。
|
||||
|
||||
## Gitea 支持哪些工作流程觸發事件？
|
||||
|
||||
所有列在此表中的事件都是支持的事件，並且與 GitHub 兼容。
|
||||
對於僅由 GitHub 支持的事件，請參見 GitHub 的 [文檔](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows)。
|
||||
|
||||
| 觸發事件 | 活動類型 |
|
||||
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
|
||||
| create | 不適用 |
|
||||
| delete | 不適用 |
|
||||
| fork | 不適用 |
|
||||
| gollum | 不適用 |
|
||||
| push | 不適用 |
|
||||
| issues | `opened`、`edited`、`closed`、`reopened`、`assigned`、`unassigned`、`milestoned`、`demilestoned`、`labeled`、`unlabeled` |
|
||||
| issue_comment | `created`、`edited`、`deleted` |
|
||||
| pull_request | `opened`、`edited`、`closed`、`reopened`、`assigned`、`unassigned`、`synchronize`、`labeled`、`unlabeled` |
|
||||
| pull_request_review | `submitted`、`edited` |
|
||||
| pull_request_review_comment | `created`、`edited` |
|
||||
| release | `published`、`edited` |
|
||||
| registry_package | `published` |
|
||||
|
||||
> 對於 `pull_request` 事件，在 [GitHub Actions](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) 中，`ref` 是 `refs/pull/:prNumber/merge`，這是合併提交預覽的引用。然而，Gitea 沒有這樣的引用。
|
||||
> 因此，Gitea Actions 中的 `ref` 是 `refs/pull/:prNumber/head`，它指向 pull request 的 head，而不是合併提交的預覽。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
date: "2023-04-27T15:00:00+08:00"
|
||||
slug: "overview"
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Overview
|
||||
|
||||
Starting with Gitea **1.19**, Gitea Actions are available as a built-in CI/CD solution.
|
||||
|
||||
## Name
|
||||
|
||||
It is similar and compatible to [GitHub Actions](https://github.com/features/actions), and its name is inspired by it too.
|
||||
To avoid confusion, we have clarified the spelling here:
|
||||
|
||||
- "Gitea Actions" (with an "s", both words capitalized) is the name of the Gitea feature.
|
||||
- "GitHub Actions" is the name of the GitHub feature.
|
||||
- "Actions" could refer to either of the above, depending on the context. So it refers to "Gitea Actions" in this document.
|
||||
- "action" or "actions" refer to some scripts/plugins to be used, like "actions/checkout@v4" or "actions/cache@v3".
|
||||
|
||||
## Runners
|
||||
|
||||
Just like other CI/CD solutions, Gitea doesn't run the jobs itself, but delegates the jobs to runners.
|
||||
The runner of Gitea Actions is called [act runner](https://gitea.com/gitea/act_runner), it is a standalone program and also written in Go.
|
||||
It is based on a [fork](https://gitea.com/gitea/act) of [nektos/act](http://github.com/nektos/act).
|
||||
|
||||
Because the runner is deployed independently, there could be potential security issues.
|
||||
To avoid them, please follow two simple rules:
|
||||
|
||||
- Don't use a runner you don't trust for your repository, organization or instance.
|
||||
- Don't provide a runner to a repository, organization or instance you don't trust.
|
||||
|
||||
For Gitea instances used internally, such as instances used by enterprises or individuals, neither of these two rules is a problem, they are naturally so.
|
||||
However, for public Gitea instances, such as [gitea.com](https://gitea.com), these two rules should be kept in mind when adding or using runners.
|
||||
|
||||
## Status
|
||||
|
||||
Gitea Actions is still under development, so there may be some bugs and missing features.
|
||||
And breaking changes may be made before it's stable (v1.20 or later).
|
||||
|
||||
If the situation changes, we will update it here.
|
||||
So please refer to the content here when you find outdated articles elsewhere.
|
||||
@@ -0,0 +1,138 @@
|
||||
---
|
||||
date: "2023-04-27T15:00:00+08:00"
|
||||
slug: "quickstart"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# Quick Start
|
||||
|
||||
This page will guide you through the process of using Gitea Actions.
|
||||
|
||||
## Set up Gitea
|
||||
|
||||
First of all, you need a Gitea instance.
|
||||
You can follow the [documentation](installation/from-package.md) to set up a new instance or upgrade your existing one.
|
||||
It doesn't matter how you install or run Gitea, as long as its version is 1.19.0 or higher.
|
||||
|
||||
Since 1.21.0, Actions are enabled by default. If you are using versions before 1.21.0, you need to add the following to the configuration file to enable it:
|
||||
|
||||
```ini
|
||||
[actions]
|
||||
ENABLED=true
|
||||
```
|
||||
|
||||
If you want to learn more or encounter any problems while configuring it, please refer to the [Configuration Cheat Sheet](../../administration/config-cheat-sheet.md#actions-actions).
|
||||
|
||||
### Set up runner
|
||||
|
||||
Gitea Actions requires [act runner](https://gitea.com/gitea/act_runner) to run the jobs.
|
||||
In order to avoid consuming too many resources and affecting the Gitea instance, it is recommended to start runners on separate machines from the Gitea instance.
|
||||
|
||||
You can use the [pre-built binaries](http://dl.gitea.com/act_runner) or the [docker images](https://hub.docker.com/r/gitea/act_runner/tags) to set up the runner.
|
||||
|
||||
Before proceeding any further, we suggest running it as a command line with pre-built binaries to ensure that it works with your environment, especially if you are running a runner on your local host.
|
||||
And it could be easier to debug if something goes wrong.
|
||||
|
||||
The runner can run the jobs in isolated Docker containers, so you need to make sure that the Docker has been installed and Docker daemon is running.
|
||||
While it is not strictly necessary, because the runner can also run the jobs directly on the host, it depends on how you configure it.
|
||||
However, it is recommended to use Docker to run the jobs, because it is more secure and easier to manage.
|
||||
|
||||
Before running a runner, you should first register it to your Gitea instance using the following command:
|
||||
|
||||
```bash
|
||||
./act_runner register --no-interactive --instance <instance> --token <token>
|
||||
```
|
||||
|
||||
There are two arguments required, `instance` and `token`.
|
||||
|
||||
`instance` refers to the address of your Gitea instance, like `http://192.168.8.8:3000` or `https://gitea.com`.
|
||||
The runner and job containers (which are started by the runner to execute jobs) will connect to this address.
|
||||
This means that it could be different from the `ROOT_URL` of your Gitea instance, which is configured for web access.
|
||||
It is always a bad idea to use a loopback address such as `127.0.0.1` or `localhost`.
|
||||
If you are unsure which address to use, the LAN address is usually the right choice.
|
||||
|
||||
`token` is used for authentication and identification, such as `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`.
|
||||
Each token can be used to create multiple runners, until it is replaced with a new token using the reset link.
|
||||
You can obtain different levels of 'tokens' from the following places to create the corresponding level of 'runners':
|
||||
|
||||
- Instance level: The admin settings page, like `<your_gitea.com>/admin/actions/runners`.
|
||||
- Organization level: The organization settings page, like `<your_gitea.com>/<org>/settings/actions/runners`.
|
||||
- Repository level: The repository settings page, like `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`.
|
||||
|
||||
|
||||
|
||||
After registering, a new file named `.runner` will appear in the current directory.
|
||||
This file stores the registration information.
|
||||
Please do not edit it manually.
|
||||
If this file is missing or corrupted, you can simply remove it and register again.
|
||||
|
||||
Finally, it's time to start the runner:
|
||||
|
||||
```bash
|
||||
./act_runner daemon
|
||||
```
|
||||
|
||||
And you can see the new runner in the management page:
|
||||
|
||||
|
||||
|
||||
You can find more information by visiting [Act runner](usage/actions/act-runner.md).
|
||||
|
||||
### Use Actions
|
||||
|
||||
Even if Actions is enabled for the Gitea instance, repositories still disable Actions by default.
|
||||
|
||||
To enable it, go to the settings page of your repository like `your_gitea.com/<owner>/repo/settings` and enable `Enable Repository Actions`.
|
||||
|
||||
|
||||
|
||||
The next steps may be rather complicated.
|
||||
You will need to study [the workflow syntax](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) for Actions and write the workflow files you want.
|
||||
|
||||
However, we can just start from a simple demo:
|
||||
|
||||
```yaml
|
||||
name: Gitea Actions Demo
|
||||
run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
Explore-Gitea-Actions:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event."
|
||||
- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!"
|
||||
- run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v4
|
||||
- run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner."
|
||||
- run: echo "🖥️ The workflow is now ready to test your code on the runner."
|
||||
- name: List files in the repository
|
||||
run: |
|
||||
ls ${{ gitea.workspace }}
|
||||
- run: echo "🍏 This job's status is ${{ job.status }}."
|
||||
```
|
||||
|
||||
:::warning
|
||||
|
||||
Certain actions may not function correctly within SHA256 repositories or when Gitea runs on subpath. This includes [actions/checkout](https://github.com/actions/checkout/issues/1843).
|
||||
|
||||
:::
|
||||
|
||||
You can upload it as a file with the extension `.yaml` in the directory `.gitea/workflows/` of the repository, for example `.gitea/workflows/demo.yaml`.
|
||||
You might notice that this is fairly similar from the [Quickstart for GitHub Actions](https://docs.github.com/en/actions/quickstart).
|
||||
That is because Gitea Actions is designed to be compatible with GitHub Actions wherever possible.
|
||||
|
||||
Be careful, the demo file contains some emojis.
|
||||
Please make sure your database supports them, especially when using MySQL.
|
||||
If the charset is not `utf8mb4`, errors will occur, such as `Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`.
|
||||
See [Database Preparation](../../installation/database-preparation.md#mysqlmariadb) for more information.
|
||||
|
||||
Alternatively, you can remove all emojis from the demo file and try again.
|
||||
|
||||
The line `on: [push]` indicates that the workflow will be triggered when you push commits to this repository.
|
||||
However, when you upload the YAML file, it also pushes a commit, so you should see a new task in the Actions tab.
|
||||
|
||||
|
||||
|
||||
Great job! You have successfully started working with Actions.
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
date: "2024-07-10T09:23:00+02:00"
|
||||
slug: "secrets"
|
||||
sidebar_position: 50
|
||||
---
|
||||
|
||||
# Secrets
|
||||
|
||||
Secrets allow you to store sensitive information in your user, organization or repository.
|
||||
Secrets are available on Gitea 1.19+ and are only visible in 1.20+ when ACTIONS are enabled.
|
||||
|
||||
# Naming your secrets
|
||||
|
||||
The following rules apply to secret names:
|
||||
|
||||
- Secret names can only contain alphanumeric characters (`[a-z]`, `[A-Z]`, `[0-9]`) or underscores (`_`). Spaces are not allowed.
|
||||
|
||||
- Secret names must not start with the `GITHUB_` and `GITEA_` prefix.
|
||||
|
||||
- Secret names must not start with a number.
|
||||
|
||||
- Secret names are not case-sensitive.
|
||||
|
||||
- Secret names must be unique at the level they are created at.
|
||||
|
||||
For example, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.
|
||||
|
||||
### Using secrets
|
||||
|
||||
After creating configuration variables, they will be automatically filled in the `secrets` context.
|
||||
They can be accessed through expressions like `${{ secrets.SECRET_NAME }}` in the workflow.
|
||||
|
||||
### Precedence
|
||||
|
||||
If a secret with the same name exists at multiple levels, the secret at the lowest level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
date: "2024-04-10T22:21:00+08:00"
|
||||
slug: "actions-variables"
|
||||
sidebar_position: 25
|
||||
---
|
||||
|
||||
# 變數
|
||||
|
||||
您可以在用戶、組織和倉庫級別創建配置變數。
|
||||
變數的級別取決於您創建它的位置。創建變數時，鍵將被轉換為大寫。您需要在 yaml 文件中使用大寫。
|
||||
|
||||
## 命名規則
|
||||
|
||||
以下規則適用於變數名稱：
|
||||
|
||||
- 變數名稱只能包含字母數字字符 (`[a-z]`, `[A-Z]`, `[0-9]`) 或下劃線 (`_`)。不允許使用空格。
|
||||
- 變數名稱不得以 `GITHUB_` 和 `GITEA_` 前綴開頭。
|
||||
- 變數名稱不得以數字開頭。
|
||||
- 變數名稱不區分大小寫。
|
||||
- 變數名稱在創建它們的級別上必須是唯一的。
|
||||
- 變數名稱不得以 `CI` 開頭。
|
||||
|
||||
## 使用變數
|
||||
|
||||
創建配置變數後，它們將自動填充到 `vars` 上下文中。
|
||||
可以通過表達式 `${{ vars.VARIABLE_NAME }}` 在工作流程中訪問它們。
|
||||
|
||||
## 優先級
|
||||
|
||||
如果在多個級別存在同名變數，則最低級別的變數優先：
|
||||
倉庫變數將始終優先於組織/用戶變數。
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "agit"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-tw/agit-setup
|
||||
---
|
||||
|
||||
# AGit
|
||||
|
||||
在 Gitea `1.13` 版本中，添加了對 [AGit](https://git-repo.info/zh/2020/03/agit-flow-and-git-repo/) 的支援。AGit 允許用戶在沒有倉庫寫入權限的情況下直接創建拉取請求，也不需要分叉倉庫。這有助於減少重複倉庫的數量，降低不必要的磁盤使用量。
|
||||
|
||||
:::note
|
||||
伺服器端需要 Git 版本 2.29 或更高版本才能正常運行。
|
||||
:::
|
||||
|
||||
## 使用 AGit 創建 PR
|
||||
|
||||
AGit 允許在推送代碼到遠程倉庫時創建 PR（合併請求）。
|
||||
通過在推送時使用特定的 refspec（git 中已知的位置標識符），可以實現這一功能。
|
||||
下面的示例說明了這一點：
|
||||
|
||||
```shell
|
||||
git push origin HEAD:refs/for/main
|
||||
```
|
||||
|
||||
該命令的結構如下：
|
||||
|
||||
- `HEAD`：目標分支
|
||||
- `refs/<for|draft|for-review>/<branch>`：目標 PR 類型
|
||||
- `for`：創建一個以 `<branch>` 為目標分支的普通 PR
|
||||
- `draft`/`for-review`：目前被靜默忽略
|
||||
- `<branch>/<session>`：要打開 PR 的目標分支
|
||||
- `-o <topic|title|description>`：PR 的選項
|
||||
- `title`：PR 的標題
|
||||
- `topic`：PR 應該打開的分支名稱
|
||||
- `description`：PR 的描述
|
||||
- `force-push=true`: 是否強制更新目標分支
|
||||
- 注意: 如果不傳值，只用 `-o force-push` 也同樣可以正常工作。
|
||||
|
||||
下面是另一個高級示例，用於創建一個以 `topic`、`title` 和 `description` 為參數的新 PR，目標分支是 `main`：
|
||||
|
||||
```shell
|
||||
git push origin HEAD:refs/for/main -o topic="Topic of my PR" -o title="Title of the PR" -o description="# The PR Description\nThis can be **any** markdown content.\n- [x] Ok"
|
||||
```
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
date: "2022-09-01T20:50:42+0000"
|
||||
slug: "agit"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-tw/agit-setup
|
||||
- /agit-setup
|
||||
---
|
||||
|
||||
# AGit
|
||||
|
||||
在 Gitea `1.13` 版本中，添加了對 [AGit](https://git-repo.info/en/2020/03/agit-flow-and-git-repo/) 的支援。AGit 允許用戶在沒有倉庫寫入權限的情況下直接創建拉取請求，也不需要分叉倉庫。這有助於減少重複倉庫的數量，降低不必要的磁盤使用量。
|
||||
|
||||
:::note
|
||||
伺服器端需要 Git 版本 2.29 或更高版本才能正常運行。
|
||||
:::
|
||||
|
||||
## 使用 AGit 創建 PR
|
||||
|
||||
AGit 允許在推送代碼到遠程倉庫時創建 PR（合併請求）。
|
||||
通過在推送時使用特定的 refspec（git 中已知的位置標識符），可以實現這一功能。
|
||||
下面的示例說明了這一點：
|
||||
|
||||
```shell
|
||||
git push origin HEAD:refs/for/main
|
||||
```
|
||||
|
||||
該命令的結構如下：
|
||||
|
||||
- `HEAD`：目標分支
|
||||
- `origin`：目標倉庫（不是分叉！）
|
||||
- `HEAD`：包含您提議更改的本地分支
|
||||
- `refs/<for|draft|for-review>/<branch>`：目標 PR 類型和配置
|
||||
- `for`：創建一個以 `<branch>` 為目標分支的普通 PR
|
||||
- `draft`/`for-review`：目前被靜默忽略
|
||||
- `<branch>/`：您希望將更改合併到的分支
|
||||
- `-o <topic|title|description>`：PR 的選項
|
||||
- `topic`：此更改的主題。它將成為等待審查的更改分支的名稱。這是觸發拉取請求所必需的。
|
||||
- `title`：PR 的標題（可選但建議），僅用於尚未關聯 PR 的主題。
|
||||
- `description`：PR 的描述（可選但建議），僅用於尚未關聯 PR 的主題。
|
||||
- `force-push=true`: 是否強制更新目標分支。
|
||||
- 注意: 省略值並僅使用 `-o force-push` 也可以正常工作。
|
||||
|
||||
下面是另一個高級示例，用於創建一個以 `topic`、`title` 和 `description` 為參數的新 PR，目標分支是 `main`：
|
||||
|
||||
```shell
|
||||
git push origin HEAD:refs/for/main -o topic="topic_of_my_PR" -o title="Title of the PR" -o description="# The PR Description\nThis can be **any** markdown content.\n- [x] Ok"
|
||||
```
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
date: "2023-08-14T00:00:00+00:00"
|
||||
slug: "blame"
|
||||
sidebar_position: 13
|
||||
aliases:
|
||||
- /zh-tw/blame
|
||||
---
|
||||
|
||||
# Blame 文件視圖
|
||||
|
||||
Gitea 支援查看文件的逐行修訂歷史，也稱為 blame 視圖。
|
||||
您還可以在命令行中使用 [`git blame`](https://git-scm.com/docs/git-blame) 查看文件內行的修訂歷史。
|
||||
|
||||
1. 導航到並打開您要查看行歷史的文件。
|
||||
1. 點擊文件標題欄中的 `Blame` 按鈕。
|
||||
1. 新視圖顯示文件的逐行修訂歷史，左側顯示作者和提交信息。
|
||||
1. 要導航到較舊的提交，點擊  圖標。
|
||||
|
||||
## 在 blame 視圖中忽略提交
|
||||
|
||||
所有在 `.git-blame-ignore-revs` 文件中指定的修訂都會在 blame 視圖中隱藏。
|
||||
這對於隱藏重新格式化的更改並保留 `git blame` 的好處特別有用。
|
||||
被忽略的提交更改或添加的行將歸咎於更改該行或附近行的上一個提交。
|
||||
`.git-blame-ignore-revs` 文件必須位於倉庫的根目錄中。
|
||||
有關文件格式的更多信息，請參見 [git blame --ignore-revs-file 文檔](https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-file)。
|
||||
|
||||
### 在 blame 視圖中繞過 `.git-blame-ignore-revs`
|
||||
|
||||
如果文件的 blame 視圖顯示有關忽略修訂的消息，您可以通過附加 url 參數 `?bypass-blame-ignore=true` 查看正常的 blame 視圖。
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
date: "2024-01-31T00:00:00+00:00"
|
||||
slug: "blocking-user"
|
||||
sidebar_position: 25
|
||||
aliases:
|
||||
- /zh-tw/webhooks
|
||||
---
|
||||
|
||||
# 封鎖用戶
|
||||
|
||||
Gitea 支援封鎖用戶，以限制他們如何與您和您的內容互動。
|
||||
|
||||
您可以在帳戶設置中、從用戶的個人資料或從用戶創建的評論中封鎖用戶。
|
||||
用戶不會直接收到封鎖通知，但當他們嘗試與您互動時，他們可能會注意到他們被封鎖。
|
||||
組織所有者也可以封鎖任何不是組織成員的人。
|
||||
如果被封鎖的用戶具有管理員權限，即使被封鎖，他們仍然可以執行所有操作。
|
||||
|
||||
### 當您封鎖用戶時
|
||||
|
||||
- 用戶停止關注您
|
||||
- 您停止關注用戶
|
||||
- 用戶的星標從您的倉庫中移除
|
||||
- 您的星標從他們的倉庫中移除
|
||||
- 用戶停止關注您的倉庫
|
||||
- 您停止關注他們的倉庫
|
||||
- 用戶的問題分配從您的倉庫中移除
|
||||
- 您的問題分配從他們的倉庫中移除
|
||||
- 用戶被移除為您倉庫的合作者
|
||||
- 您被移除為他們倉庫的合作者
|
||||
- 任何待處理的倉庫轉移到或從被封鎖的用戶取消
|
||||
|
||||
### 當您封鎖用戶時，用戶無法
|
||||
|
||||
- 關注您
|
||||
- 關注您的倉庫
|
||||
- 星標您的倉庫
|
||||
- 分叉您的倉庫
|
||||
- 將倉庫轉移給您
|
||||
- 在您的倉庫上打開問題或拉取請求
|
||||
- 評論您創建的問題或拉取請求
|
||||
- 評論您倉庫上的問題或拉取請求
|
||||
- 對您在問題或拉取請求上的評論做出反應
|
||||
- 對您倉庫上的問題或拉取請求的評論做出反應
|
||||
- 將您分配到問題或拉取請求
|
||||
- 將您添加為他們倉庫的合作者
|
||||
- 通過 @提及您的用戶名向您發送通知
|
||||
- 被添加為團隊成員（如果被組織封鎖）
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
date: "2021-02-02"
|
||||
slug: "clone-filters"
|
||||
sidebar_position: 25
|
||||
aliases:
|
||||
- /zh-tw/clone-filters
|
||||
---
|
||||
|
||||
# 克隆過濾器（部分克隆）
|
||||
|
||||
Git 引入了 `--filter` 選項到 `git clone` 命令，該選項過濾掉大文件和對象（如 blobs），以創建倉庫的部分克隆。
|
||||
克隆過濾器對於大型倉庫和/或計量連接特別有用，在這種情況下，完整克隆（沒有 `--filter`）可能會很昂貴（因為必須下載所有歷史數據）。
|
||||
|
||||
這需要 Gitea 伺服器和客戶端上的 Git 版本 2.22 或更高版本。為了使克隆過濾器正常工作，請確保客戶端上的 Git 版本至少與伺服器上的版本相同（或更高）。以管理員身份登錄到 Gitea 伺服器，前往站點管理 -> 配置以查看伺服器的 Git 版本。
|
||||
|
||||
默認情況下，克隆過濾器是啟用的，除非 `[git]` 下的 `DISABLE_PARTIAL_CLONE` 設置為 `true`。
|
||||
|
||||
請參閱 [GitHub 博客文章：了解部分克隆](https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/)
|
||||
以了解克隆過濾器的常見用例（無 blob 和無樹克隆），以及
|
||||
[GitLab 文檔：部分克隆](https://docs.gitlab.com/ee/topics/git/partial_clone.html)
|
||||
以了解更高級的用例（如按文件大小過濾和移除過濾器以將部分克隆轉換為完整克隆）。
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
date: "2023-05-24T16:00:00+00:00"
|
||||
slug: "code-owners"
|
||||
sidebar_position: 30
|
||||
aliases:
|
||||
- /zh-tw/code-owners
|
||||
---
|
||||
|
||||
# 代碼所有者
|
||||
|
||||
Gitea 維護代碼所有者文件。它會按以下順序在以下位置查找：
|
||||
|
||||
- `./CODEOWNERS`
|
||||
- `./docs/CODEOWNERS`
|
||||
- `./.gitea/CODEOWNERS`
|
||||
|
||||
並在找到的第一個文件處停止。
|
||||
|
||||
文件格式：`<regexp rule> <@user or @org/team> [@user or @org/team]...`
|
||||
|
||||
正則表達式以 golang Regex 格式指定。
|
||||
正則表達式可以以 `!` 開頭表示否定規則 - 匹配除指定文件外的所有文件。
|
||||
|
||||
示例文件：
|
||||
|
||||
```bash
|
||||
.*\\.go @user1 @user2 # 這是評論
|
||||
|
||||
# 這也是評論
|
||||
# 您可以為用戶或團隊分配代碼所有權
|
||||
frontend/src/.*\\.js @org1/team1 @org1/team2 @user3
|
||||
|
||||
# 您可以使用否定模式
|
||||
!frontend/src/.* @org1/team3 @user5
|
||||
|
||||
# 您可以使用 go 正則表達式的強大功能
|
||||
docs/(aws|google|azure)/[^/]*\\.(md|txt) @user8 @org1/team4
|
||||
!/assets/.*\\.(bin|exe|msi) @user9
|
||||
```
|
||||
|
||||
### 轉義
|
||||
|
||||
您可以使用 `\` 轉義字符 `#`、` `（空格）和 `\`，例如：
|
||||
|
||||
```
|
||||
dir/with\#hashtag @user1
|
||||
path\ with\ space @user2
|
||||
path/with\\backslash @user3
|
||||
```
|
||||
|
||||
某些字符（`.+*?()|[]{}^$\`）應在正則表達式內使用 `\\` 轉義，例如：
|
||||
|
||||
```
|
||||
path/\\.with\\.dots
|
||||
path/with\\+plus
|
||||
```
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
date: "2022-12-01T00:00:00+00:00"
|
||||
slug: "incoming-email"
|
||||
sidebar_position: 13
|
||||
aliases:
|
||||
- /zh-tw/incoming-email
|
||||
---
|
||||
|
||||
# 收件郵件
|
||||
|
||||
Gitea 支援通過收件郵件執行多種操作。本頁描述了如何設置此功能。
|
||||
|
||||
## 要求
|
||||
|
||||
處理收件郵件消息需要一個啟用 IMAP 的電子郵件帳戶。
|
||||
推薦的策略是使用 [電子郵件子地址](https://en.wikipedia.org/wiki/Email_address#Sub-addressing) 但捕獲所有郵箱也可以工作。
|
||||
接收電子郵件地址包含一個用戶/操作特定的令牌，該令牌告訴 Gitea 應執行哪個操作。
|
||||
該令牌預期在 `To` 和 `Delivered-To` 標頭字段中。
|
||||
|
||||
Gitea 嘗試檢測自動回覆以跳過，電子郵件伺服器也應配置以減少收件噪音（垃圾郵件、新聞簡報）。
|
||||
|
||||
## 配置
|
||||
|
||||
要啟用處理收件郵件消息，您必須在配置文件中配置 `email.incoming` 部分。
|
||||
|
||||
`REPLY_TO_ADDRESS` 包含電子郵件客戶端將回覆的地址。
|
||||
此地址需要包含 `%{token}` 佔位符，該佔位符將被描述用戶/操作的令牌替換。
|
||||
此佔位符必須僅出現在地址的用戶部分（在 `@` 之前）。
|
||||
|
||||
使用電子郵件子地址的示例可能如下所示：`incoming+%{token}@example.com`
|
||||
|
||||
如果使用捕獲所有郵箱，佔位符可以出現在地址的用戶部分的任何位置：`incoming+%{token}@example.com`、`incoming_%{token}@example.com`、`%{token}@example.com`
|
||||
|
||||
## 安全性
|
||||
|
||||
選擇用於接收收件郵件的域時要小心。
|
||||
建議在子域上接收收件郵件，例如 `incoming.example.com` 以防止與 `example.com` 上運行的其他服務的潛在安全問題。
|
||||
+318
@@ -0,0 +1,318 @@
|
||||
---
|
||||
date: "2018-05-10T16:00:00+02:00"
|
||||
slug: "issue-pull-request-templates"
|
||||
sidebar_position: 15
|
||||
aliases:
|
||||
- /zh-tw/issue-pull-request-templates
|
||||
---
|
||||
|
||||
# 問題和拉取請求模板
|
||||
|
||||
一些項目有一個標準的問題列表，當用戶創建問題或拉取請求時需要回答。Gitea 支援將模板添加到倉庫的**默認分支**，以便在用戶創建問題和拉取請求時自動填充表單。這將減少獲取一些澄清細節的初始來回。
|
||||
目前無法在全局範圍內提供通用的問題/拉取請求模板。
|
||||
|
||||
此外，新問題頁面的 URL 可以後綴 `?title=Issue+Title&body=Issue+Text`，表單將使用這些字符串填充。如果存在模板，這些字符串將被使用而不是模板。
|
||||
|
||||
## 文件名
|
||||
|
||||
問題模板的可能文件名：
|
||||
|
||||
- `ISSUE_TEMPLATE.md`
|
||||
- `ISSUE_TEMPLATE.yaml`
|
||||
- `ISSUE_TEMPLATE.yml`
|
||||
- `issue_template.md`
|
||||
- `issue_template.yaml`
|
||||
- `issue_template.yml`
|
||||
- `.gitea/ISSUE_TEMPLATE.md`
|
||||
- `.gitea/ISSUE_TEMPLATE.yaml`
|
||||
- `.gitea/ISSUE_TEMPLATE.yml`
|
||||
- `.gitea/issue_template.md`
|
||||
- `.gitea/issue_template.yaml`
|
||||
- `.gitea/issue_template.yml`
|
||||
- `.github/ISSUE_TEMPLATE.md`
|
||||
- `.github/ISSUE_TEMPLATE.yaml`
|
||||
- `.github/ISSUE_TEMPLATE.yml`
|
||||
- `.github/issue_template.md`
|
||||
- `.github/issue_template.yaml`
|
||||
- `.github/issue_template.yml`
|
||||
|
||||
問題配置的可能文件名：
|
||||
|
||||
- `.gitea/ISSUE_TEMPLATE/config.yaml`
|
||||
- `.gitea/ISSUE_TEMPLATE/config.yml`
|
||||
- `.gitea/issue_template/config.yaml`
|
||||
- `.gitea/issue_template/config.yml`
|
||||
- `.github/ISSUE_TEMPLATE/config.yaml`
|
||||
- `.github/ISSUE_TEMPLATE/config.yml`
|
||||
- `.github/issue_template/config.yaml`
|
||||
- `.github/issue_template/config.yml`
|
||||
|
||||
拉取請求模板的可能文件名：
|
||||
|
||||
- `PULL_REQUEST_TEMPLATE.md`
|
||||
- `PULL_REQUEST_TEMPLATE.yaml`
|
||||
- `PULL_REQUEST_TEMPLATE.yml`
|
||||
- `pull_request_template.md`
|
||||
- `pull_request_template.yaml`
|
||||
- `pull_request_template.yml`
|
||||
- `.gitea/PULL_REQUEST_TEMPLATE.md`
|
||||
- `.gitea/PULL_REQUEST_TEMPLATE.yaml`
|
||||
- `.gitea/PULL_REQUEST_TEMPLATE.yml`
|
||||
- `.gitea/pull_request_template.md`
|
||||
- `.gitea/pull_request_template.yaml`
|
||||
- `.gitea/pull_request_template.yml`
|
||||
- `.github/PULL_REQUEST_TEMPLATE.md`
|
||||
- `.github/PULL_REQUEST_TEMPLATE.yaml`
|
||||
- `.github/PULL_REQUEST_TEMPLATE.yml`
|
||||
- `.github/pull_request_template.md`
|
||||
- `.github/pull_request_template.yaml`
|
||||
- `.github/pull_request_template.yml`
|
||||
|
||||
## 目錄名
|
||||
|
||||
或者，用戶可以在特殊目錄中創建多個問題模板，並允許用戶選擇一個更具針對性地解決他們的問題。
|
||||
|
||||
問題模板的可能目錄名：
|
||||
|
||||
- `ISSUE_TEMPLATE`
|
||||
- `issue_template`
|
||||
- `.gitea/ISSUE_TEMPLATE`
|
||||
- `.gitea/issue_template`
|
||||
- `.github/ISSUE_TEMPLATE`
|
||||
- `.github/issue_template`
|
||||
- `.gitlab/ISSUE_TEMPLATE`
|
||||
- `.gitlab/issue_template`
|
||||
|
||||
目錄內可以有多個 markdown（`.md`）或 yaml（`.yaml`/`.yml`）問題模板。
|
||||
|
||||
## markdown 模板語法
|
||||
|
||||
```md
|
||||
---
|
||||
name: "模板名稱"
|
||||
about: "此模板用於測試！"
|
||||
title: "[TEST] "
|
||||
ref: "main"
|
||||
assignees: ["user1"]
|
||||
labels:
|
||||
- bug
|
||||
- "需要幫助"
|
||||
---
|
||||
|
||||
這是模板！
|
||||
```
|
||||
|
||||
在上述示例中，當用戶看到他們可以提交的問題列表時，這將顯示為 `模板名稱`，描述為 `此模板用於測試！`。提交問題時，問題標題將預填充為 `[TEST]`，而問題正文將預填充為 `這是模板！`。
|
||||
問題將分配給 `user1`。
|
||||
問題還將分配兩個標籤，
|
||||
`bug` 和 `需要幫助`，問題將引用 `main`。
|
||||
|
||||
## yaml 模板語法
|
||||
|
||||
此示例 YAML 配置文件使用多個輸入定義了一個問題表單來報告錯誤。
|
||||
|
||||
```yaml
|
||||
name: 錯誤報告
|
||||
about: 提交錯誤報告
|
||||
title: "[Bug]: "
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
感謝您花時間填寫此錯誤報告！
|
||||
# 一些僅在創建問題後可見的 markdown
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
此問題是由問題**模板**創建的 :)
|
||||
visible: [content]
|
||||
- type: input
|
||||
id: contact
|
||||
attributes:
|
||||
label: 聯繫方式
|
||||
description: 如果我們需要更多信息，如何與您聯繫？
|
||||
placeholder: 例如 email@example.com
|
||||
validations:
|
||||
required: false
|
||||
- type: textarea
|
||||
id: what-happened
|
||||
attributes:
|
||||
label: 發生了什麼？
|
||||
description: 也告訴我們，您期望發生什麼？
|
||||
placeholder: 告訴我們您看到的！
|
||||
value: "發生了錯誤！"
|
||||
validations:
|
||||
required: true
|
||||
- type: dropdown
|
||||
id: version
|
||||
attributes:
|
||||
label: 您運行的軟件版本是什麼？
|
||||
description: 您運行的軟件版本是什麼？
|
||||
options:
|
||||
- 1.0.2（默認）
|
||||
- 1.0.3（邊緣）
|
||||
validations:
|
||||
required: true
|
||||
- type: dropdown
|
||||
id: browsers
|
||||
attributes:
|
||||
label: 您在哪些瀏覽器上看到問題？
|
||||
multiple: true
|
||||
options:
|
||||
- Firefox
|
||||
- Chrome
|
||||
- Safari
|
||||
- Microsoft Edge
|
||||
- type: textarea
|
||||
id: logs
|
||||
attributes:
|
||||
label: 相關日誌輸出
|
||||
description: 請複製並粘貼任何相關的日誌輸出。這將自動格式化為代碼，因此不需要反引號。
|
||||
render: shell
|
||||
- type: checkboxes
|
||||
id: terms
|
||||
attributes:
|
||||
label: 行為準則
|
||||
hide_label: true
|
||||
description: 提交此問題即表示您同意遵守我們的[行為準則](https://example.com)
|
||||
options:
|
||||
- label: 我同意遵守此項目的行為準則
|
||||
required: true
|
||||
- label: 我也已閱讀 CONTRIBUTION.MD
|
||||
required: true
|
||||
visible: [form]
|
||||
- label: 這是一個僅在創建問題後可見的待辦事項
|
||||
visible: [content]
|
||||
```
|
||||
|
||||
### Markdown
|
||||
|
||||
您可以使用 `markdown` 元素在表單中顯示 Markdown，為用戶提供額外的上下文，但默認情況下不會提交。
|
||||
|
||||
屬性：
|
||||
|
||||
| 鍵 | 描述 | 必需 | 類型 | 默認值 | 有效值 |
|
||||
| ----- | -------------------------------- | ---- | ------ | ------ | ------ |
|
||||
| value | 渲染的文本。支持 Markdown 格式。 | 必需 | 字符串 | - | - |
|
||||
|
||||
visible: 默認為 **[form]**
|
||||
|
||||
### Textarea
|
||||
|
||||
您可以使用 `textarea` 元素在表單中添加多行文本字段。貢獻者還可以在 `textarea` 字段中附加文件。
|
||||
|
||||
屬性：
|
||||
|
||||
| 鍵 | 描述 | 必需 | 類型 | 默認值 | 有效值 |
|
||||
| ----------- | -------------------------------------------------------------------------------------------------- | ---- | ------ | -------- | ------------------ |
|
||||
| label | 預期用戶輸入的簡要描述，也顯示在表單中。 | 必需 | 字符串 | - | - |
|
||||
| hide_label | 如果為 true，則標籤通常用作標題不可見。 | 可選 | 布爾值 | false | - |
|
||||
| description | 文本區的描述，以提供上下文或指導，顯示在表單中。 | 可選 | 字符串 | 空字符串 | - |
|
||||
| placeholder | 當空時在文本區中呈現的半透明佔位符。 | 可選 | 字符串 | 空字符串 | - |
|
||||
| value | 預填充在文本區中的文本。 | 可選 | 字符串 | - | - |
|
||||
| render | 如果提供了值，提交的文本將格式化為代碼塊。提供此鍵時，文本區將不會擴展以附加文件或 Markdown 編輯。 | 可選 | 字符串 | - | Gitea 已知的語言。 |
|
||||
|
||||
驗證：
|
||||
|
||||
| 鍵 | 描述 | 必需 | 類型 | 默認值 | 有效值 |
|
||||
| -------- | ---------------------------- | ---- | ------ | ------ | ------ |
|
||||
| required | 在元素完成之前阻止表單提交。 | 可選 | 布爾值 | false | - |
|
||||
|
||||
visible: 默認為 **[form, content]**
|
||||
|
||||
### Input
|
||||
|
||||
您可以使用 `input` 元素在表單中添加單行文本字段。
|
||||
|
||||
屬性：
|
||||
|
||||
| 鍵 | 描述 | 必需 | 類型 | 默認值 | 有效值 |
|
||||
| ----------- | ------------------------------------------------ | ---- | ------ | -------- | ------ |
|
||||
| label | 預期用戶輸入的簡要描述，也顯示在表單中。 | 必需 | 字符串 | - | - |
|
||||
| hide_label | 如果為 true，則標籤通常用作標題不可見。 | 可選 | 布爾值 | false | - |
|
||||
| description | 該字段的描述，以提供上下文或指導，顯示在表單中。 | 可選 | 字符串 | 空字符串 | - |
|
||||
| placeholder | 當空時在字段中呈現的半透明佔位符。 | 可選 | 字符串 | 空字符串 | - |
|
||||
| value | 預填充在字段中的文本。 | 可選 | 字符串 | - | - |
|
||||
|
||||
驗證：
|
||||
|
||||
| 鍵 | 描述 | 必需 | 類型 | 默認值 | 有效值 |
|
||||
| --------- | ------------------------------------------------ | ---- | ------ | ------ | ------------------------------------------------------------------- |
|
||||
| required | 在元素完成之前阻止表單提交。 | 可選 | 布爾值 | false | - |
|
||||
| is_number | 在元素填寫數字之前阻止表單提交。 | 可選 | 布爾值 | false | - |
|
||||
| regex | 在元素填寫與正則表達式匹配的值之前阻止表單提交。 | 可選 | 字符串 | - | 一個 [正則表達式](https://en.wikipedia.org/wiki/Regular_expression) |
|
||||
|
||||
visible: 默認為 **[form, content]**
|
||||
|
||||
### Dropdown
|
||||
|
||||
您可以使用 `dropdown` 元素在表單中添加下拉菜單。
|
||||
|
||||
屬性：
|
||||
|
||||
| 鍵 | 描述 | 必需 | 類型 | 默認值 | 有效值 |
|
||||
| ----------- | --------------------------------------------------------------------------- | ---- | ---------- | -------- | ------ |
|
||||
| label | 預期用戶輸入的簡要描述，顯示在表單中。 | 必需 | 字符串 | - | - |
|
||||
| hide_label | 如果為 true，則標籤通常用作標題不可見。 | 可選 | 布爾值 | false | - |
|
||||
| description | 下拉菜單的描述，以提供額外的上下文或指導，顯示在表單中。 | 可選 | 字符串 | 空字符串 | - |
|
||||
| multiple | 確定用戶是否可以選擇多個選項。 | 可選 | 布爾值 | false | - |
|
||||
| list | 如果為 true，顯示為列表。如果為 false，則將項目打印在一行上，並用逗號分隔。 | 可選 | 布爾值 | false | - |
|
||||
| options | 用戶可以選擇的選項數組。不能為空，所有選擇必須是不同的。 | 必需 | 字符串數組 | - | - |
|
||||
|
||||
驗證：
|
||||
|
||||
| 鍵 | 描述 | 必需 | 類型 | 默認值 | 有效值 |
|
||||
| -------- | ---------------------------- | ---- | ------ | ------ | ------ |
|
||||
| required | 在元素完成之前阻止表單提交。 | 可選 | 布爾值 | false | - |
|
||||
|
||||
visible: 默認為 **[form, content]**
|
||||
|
||||
### Checkboxes
|
||||
|
||||
您可以使用 `checkboxes` 元素在表單中添加一組複選框。
|
||||
|
||||
屬性：
|
||||
|
||||
| 鍵 | 描述 | 必需 | 類型 | 默認值 | 有效值 |
|
||||
| ----------- | ---------------------------------------------------- | ---- | ------ | -------- | ------ |
|
||||
| label | 預期用戶輸入的簡要描述，顯示在表單中。 | 必需 | 字符串 | - | - |
|
||||
| hide_label | 如果為 true，則標籤通常用作標題不可見。 | 可選 | 布爾值 | false | - |
|
||||
| description | 一組複選框的描述，顯示在表單中。支持 Markdown 格式。 | 必需 | 字符串 | 空字符串 | - |
|
||||
| options | 用戶可以選擇的複選框數組。語法見下文。 | 必需 | 數組 | - | - |
|
||||
|
||||
對於選項數組中的每個值，您可以設置以下鍵。
|
||||
|
||||
| 鍵 | 描述 | 必需 | 類型 | 默認值 | 選項 |
|
||||
| -------- | -------------------------------------------------------------------------------------------- | ---- | ---------- | ------ | ---- |
|
||||
| label | 選項的標識符，顯示在表單中。支持 Markdown 格式，用於粗體或斜體文本格式和超鏈接。 | 必需 | 字符串 | - | - |
|
||||
| required | 在元素完成之前阻止表單提交。 | 可選 | 布爾值 | false | - |
|
||||
| visible | 特定複選框僅在表單中顯示，在創建的問題中顯示，或兩者都顯示。有效選項是 "form" 和 "content"。 | 可選 | 字符串數組 | false | - |
|
||||
|
||||
visible: 默認為 **[form, content]**
|
||||
|
||||
## 問題配置語法
|
||||
|
||||
這是一個問題配置文件的示例
|
||||
|
||||
```yaml
|
||||
blank_issues_enabled: true
|
||||
contact_links:
|
||||
- name: Gitea
|
||||
url: https://gitea.com
|
||||
about: 訪問 Gitea 網站
|
||||
```
|
||||
|
||||
### 可能的選項
|
||||
|
||||
| 鍵 | 描述 | 類型 | 默認值 |
|
||||
| -------------------- | ---------------------------------- | ------------ | ------ |
|
||||
| blank_issues_enabled | 如果設置為 false，用戶必須使用模板 | 布爾值 | true |
|
||||
| contact_links | 自定義鏈接顯示在選擇框中 | 聯繫鏈接數組 | 空數組 |
|
||||
|
||||
### 聯繫鏈接
|
||||
|
||||
| 鍵 | 描述 | 類型 | 必需 |
|
||||
| ----- | ---------------- | ------ | ---- |
|
||||
| name | 您的鏈接名稱 | 字符串 | true |
|
||||
| url | 您的鏈接 URL | 字符串 | true |
|
||||
| about | 您的鏈接簡短描述 | 字符串 | true |
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
date: "2023-03-04T19:00:00+00:00"
|
||||
slug: "labels"
|
||||
sidebar_position: 13
|
||||
aliases:
|
||||
- /zh-tw/labels
|
||||
---
|
||||
|
||||
# 標籤
|
||||
|
||||
您可以使用標籤來分類問題和拉取請求，並改善對它們的概覽。
|
||||
|
||||
## 創建標籤
|
||||
|
||||
對於倉庫，可以通過轉到 `問題` 並點擊 `標籤` 來創建標籤。
|
||||
|
||||
對於組織，您可以定義組織範圍內的標籤，這些標籤將與所有組織倉庫共享，包括已存在的倉庫和新創建的倉庫。組織範圍內的標籤可以在組織 `設置` 中創建。
|
||||
|
||||
標籤必須有一個必需的名稱、一個必需的顏色、一個可選的描述，並且必須是排他性的或非排他性的（請參見下文的 `範圍標籤`）。
|
||||
|
||||
創建倉庫時，您可以使用 `問題標籤` 選項確保存在某些標籤。此選項列出了一些在您的實例中[全局配置的標籤集](../administration/customizing-gitea.md#labels)。創建倉庫時，將創建其包含的所有標籤。
|
||||
|
||||
## 範圍標籤
|
||||
|
||||
範圍標籤用於確保最多只有一個具有相同範圍的標籤分配給問題或拉取請求。例如，如果標籤 `kind/bug` 和 `kind/enhancement` 設置了排他選項，則一個問題只能被分類為 bug 或 enhancement。
|
||||
|
||||
範圍標籤的名稱中必須包含 `/`（不能在名稱的任一端）。標籤的範圍基於**最後一個** `/` 確定，因此例如標籤 `scope/subscope/item` 的範圍是 `scope/subscope`。
|
||||
|
||||
## 按標籤篩選
|
||||
|
||||
問題和拉取請求列表可以按標籤篩選。選擇多個標籤顯示分配了所有選定標籤的問題和拉取請求。
|
||||
|
||||
按住 alt 點擊標籤，將從列表中排除具有所選標籤的問題和拉取請求。
|
||||
@@ -0,0 +1,147 @@
|
||||
---
|
||||
date: "2019-11-21T17:00:00-03:00"
|
||||
slug: "automatically-linked-references"
|
||||
sidebar_position: 15
|
||||
aliases:
|
||||
- /zh-tw/automatically-linked-references
|
||||
---
|
||||
|
||||
# 自動鏈接引用
|
||||
|
||||
當發佈問題、拉取請求或評論時，文本描述會被解析以查找引用。這些引用將顯示為問題視圖中的鏈接，並在某些情況下產生某些操作。
|
||||
|
||||
同樣，當提交消息被列出時，它們會被解析，並且當它們被推送到主分支時可以觸發操作。
|
||||
|
||||
為了防止創建意外引用，有一些規則來識別它們。例如，它們不應包含在代碼文本中。它們還應該與周圍文本合理地分開（例如，使用空格）。
|
||||
|
||||
## 用戶、團隊和組織提及
|
||||
|
||||
當找到 `@username` 形式的文本並且 `username` 與現有用戶的名稱匹配時，會創建一個提及引用。這將通過將文本更改為該用戶的個人資料鏈接來顯示，並根據用戶是否具有訪問內容的必要權限，可能會為被提及的用戶創建通知。
|
||||
|
||||
示例：
|
||||
|
||||
> [@John](#)，你能看看這個嗎？
|
||||
|
||||
這對於團隊和組織也是有效的：
|
||||
|
||||
> [@Documenters](#)，我們需要計劃這個。
|
||||
> [@CoolCompanyInc](#)，這個問題關係到我們所有人！
|
||||
|
||||
當適用時，團隊將收到郵件通知，但整個組織不會。
|
||||
|
||||
提交消息不會產生用戶通知。
|
||||
|
||||
## 提交
|
||||
|
||||
可以使用其 SHA1 哈希或至少七個字符的一部分來引用提交。它們將顯示為對應提交的鏈接。
|
||||
|
||||
示例：
|
||||
|
||||
> 這個錯誤是在 [e59ff077](#) 中引入的
|
||||
|
||||
## 問題和拉取請求
|
||||
|
||||
可以使用簡單的 `#1234` 表示法創建對其他問題或拉取請求的引用，其中 _1234_ 是同一倉庫中問題或拉取請求的編號。這些引用將顯示為指向引用內容的鏈接。
|
||||
|
||||
創建此類引用的效果是，在引用的文檔中創建一個通知，前提是引用的創建者對其具有閱讀權限。
|
||||
|
||||
示例：
|
||||
|
||||
> 這似乎與 [#1234](#) 有關
|
||||
|
||||
也可以使用 `owner/repository#1234` 的形式引用其他倉庫中的問題和拉取請求：
|
||||
|
||||
> 這似乎與 [mike/compiler#1234](#) 有關
|
||||
|
||||
或者，也可以使用 `!1234` 表示法。即使在 Gitea 中，拉取請求也是一種問題，`#1234` 形式將始終鏈接到問題；如果鏈接的條目恰好是拉取請求，Gitea 會適當地重定向。使用 `!1234` 表示法，將創建一個拉取請求鏈接，如果需要，將重定向到問題。
|
||||
然而，如果使用外部跟蹤器，這種區分可能很重要，因為鏈接到問題和拉取請求並不可以互換。
|
||||
|
||||
## 拉取請求和提交消息中的可操作引用
|
||||
|
||||
有時提交或拉取請求可能會修復或恢復記錄在特定問題中的問題。Gitea 支援通過在引用前加上特定關鍵字來關閉和重新打開引用的問題。常見的關鍵字包括 "closes"、"fixes"、"reopens" 等。此列表可以由站點管理員[自定義](../administration/config-cheat-sheet.md)。
|
||||
|
||||
示例：
|
||||
|
||||
> 此 PR _closes_ [#1234](#)
|
||||
|
||||
如果接受可操作引用，這將在引用的問題上創建一個通知，宣布當合併引用的 PR 時將關閉該問題。
|
||||
|
||||
要接受可操作引用，必須滿足以下條件之一：
|
||||
|
||||
- 評論者在創建引用時具有關閉或重新打開問題的權限。
|
||||
- 引用在提交消息中。
|
||||
- 引用作為拉取請求描述的一部分發佈。
|
||||
|
||||
在最後一種情況下，只有在合併拉取請求的人具有權限時，問題才會被關閉或重新打開。
|
||||
|
||||
此外，只有拉取請求和提交消息可以創建操作，只有問題可以通過這種方式關閉或重新打開。
|
||||
|
||||
默認關鍵字是：
|
||||
|
||||
- **關閉**：close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved
|
||||
- **重新打開**：reopen, reopens, reopened
|
||||
|
||||
## 拉取請求和提交消息中的時間跟蹤
|
||||
|
||||
當提交或合併拉取請求導致自動關閉問題時，可以通過提交消息添加解決此問題所花費的時間。
|
||||
|
||||
要指定解決問題所花費的時間，您需要在問題號後指定格式為 `@<number><time-unit>` 的時間。在一條提交消息中，您可以為每個問題指定多個修復問題和花費的時間。
|
||||
|
||||
支援的時間單位（`<time-unit>`）：
|
||||
|
||||
- `m` - 分鐘
|
||||
- `h` - 小時
|
||||
- `d` - 天（等於 8 小時）
|
||||
- `w` - 週（等於 5 天）
|
||||
- `mo` - 月（等於 4 週）
|
||||
|
||||
指定時間的數字（`<number>`）也可以是小數，例如 `@1.5h` 代表一個半小時。可以組合多個時間單位，例如 `@1h10m` 代表 1 小時 10 分鐘。
|
||||
|
||||
提交消息示例：
|
||||
|
||||
> Fixed #123 spent @1h, refs #102, fixes #124 @1.5h
|
||||
|
||||
這將導致在問題 #123 上添加 1 小時，在問題 #124 上添加 1.5 小時。
|
||||
|
||||
## 外部跟蹤器
|
||||
|
||||
Gitea 支援使用外部問題跟蹤器，並且可以在拉取請求中創建對外部託管問題的引用。然而，如果外部跟蹤器使用編號來識別問題，它們將與 Gitea 中託管的拉取請求無法區分。為了解決這個問題，Gitea 允許使用 `!` 標記來識別拉取請求。例如：
|
||||
|
||||
> 這是問題 [#1234](#)，鏈接到外部跟蹤器。
|
||||
> 這是拉取請求 [!1234](#)，鏈接到 Gitea 中的拉取請求。
|
||||
|
||||
`!` 和 `#` 可以互換使用於問題和拉取請求，除了這種情況，需要區分。如果倉庫使用外部跟蹤器，squash 合併的提交消息將默認使用 `!` 作為引用。
|
||||
|
||||
## 問題和拉取請求引用摘要
|
||||
|
||||
此表說明了不同種類的問題和拉取請求的交叉引用。
|
||||
在示例中，`User1/Repo1` 指的是使用引用的倉庫，而 `UserZ/RepoZ` 表示不同的倉庫。
|
||||
|
||||
| User1/Repo1 中的引用 | Repo1 問題是外部的 | RepoZ 問題是外部的 | 應渲染 |
|
||||
| --------------------- | :----------------: | :----------------: | ----------------------------------------------- |
|
||||
| `#1234` | no | - | 指向 `User1/Repo1` 中問題/拉取請求 1234 的鏈接 |
|
||||
| `!1234` | no | - | 指向 `User1/Repo1` 中問題/拉取請求 1234 的鏈接 |
|
||||
| `#1234` | yes | - | 指向 `User1/Repo1` 的外部問題 1234 的鏈接 |
|
||||
| `!1234` | yes | - | 指向 `User1/Repo1` 的拉取請求 1234 的鏈接 |
|
||||
| `User1/Repo1#1234` | no | - | 指向 `User1/Repo1` 中問題/拉取請求 1234 的鏈接 |
|
||||
| `User1/Repo1!1234` | no | - | 指向 `User1/Repo1` 中問題/拉取請求 1234 的鏈接 |
|
||||
| `User1/Repo1#1234` | yes | - | 指向 `User1/Repo1` 的外部問題 1234 的鏈接 |
|
||||
| `User1/Repo1!1234` | yes | - | 指向 `User1/Repo1` 的拉取請求 1234 的鏈接 |
|
||||
| `UserZ/RepoZ#1234` | - | no | 指向 `UserZ/RepoZ` 中問題/拉取請求 1234 的鏈接 |
|
||||
| `UserZ/RepoZ!1234` | - | no | 指向 `UserZ/RepoZ` 中問題/拉取請求 1234 的鏈接 |
|
||||
| `UserZ/RepoZ#1234` | - | yes | 指向 `UserZ/RepoZ` 的外部問題 1234 的鏈接 |
|
||||
| `UserZ/RepoZ!1234` | - | yes | 指向 `UserZ/RepoZ` 的拉取請求 1234 的鏈接 |
|
||||
| **字母數字問題 ID：** | - | - | - |
|
||||
| `AAA-1234` | yes | - | 指向 `User1/Repo1` 的外部問題 `AAA-1234` 的鏈接 |
|
||||
| `!1234` | yes | - | 指向 `User1/Repo1` 的拉取請求 1234 的鏈接 |
|
||||
| `User1/Repo1!1234` | yes | - | 指向 `User1/Repo1` 的拉取請求 1234 的鏈接 |
|
||||
| _不支援_ | - | yes | 指向 `UserZ/RepoZ` 的外部問題 `AAA-1234` 的鏈接 |
|
||||
| `UserZ/RepoZ!1234` | - | yes | 指向 `UserZ/RepoZ` 中的拉取請求 1234 的鏈接 |
|
||||
|
||||
_最後一部分是針對使用字母數字格式的外部問題跟蹤器的倉庫。_
|
||||
|
||||
_**-**：不適用。_
|
||||
|
||||
:::note
|
||||
在具有不同類型問題（外部與內部）的倉庫之間的自動引用尚未完全支援，可能會渲染無效鏈接。
|
||||
:::
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
---
|
||||
date: "2022-08-31T17:35:40+08:00"
|
||||
slug: "merge-message-templates"
|
||||
sidebar_position: 15
|
||||
aliases:
|
||||
- /zh-tw/merge-message-templates
|
||||
---
|
||||
|
||||
# 合併消息模板
|
||||
|
||||
## 文件名
|
||||
|
||||
PR 默認合併消息模板的可能文件名：
|
||||
|
||||
- `.gitea/default_merge_message/MERGE_TEMPLATE.md`
|
||||
- `.gitea/default_merge_message/REBASE_TEMPLATE.md`
|
||||
- `.gitea/default_merge_message/REBASE-MERGE_TEMPLATE.md`
|
||||
- `.gitea/default_merge_message/SQUASH_TEMPLATE.md`
|
||||
- `.gitea/default_merge_message/MANUALLY-MERGED_TEMPLATE.md`
|
||||
- `.gitea/default_merge_message/REBASE-UPDATE-ONLY_TEMPLATE.md`
|
||||
|
||||
## 變量
|
||||
|
||||
您可以在這些模板中使用以下變量，這些變量包含在 `${}` 中，遵循 [os.Expand](https://pkg.go.dev/os#Expand) 語法：
|
||||
|
||||
- BaseRepoOwnerName: 此拉取請求的基礎倉庫所有者名稱
|
||||
- BaseRepoName: 此拉取請求的基礎倉庫名稱
|
||||
- BaseBranch: 此拉取請求的基礎倉庫目標分支名稱
|
||||
- HeadRepoOwnerName: 此拉取請求的頭部倉庫所有者名稱
|
||||
- HeadRepoName: 此拉取請求的頭部倉庫名稱
|
||||
- HeadBranch: 此拉取請求的頭部倉庫分支名稱
|
||||
- PullRequestTitle: 拉取請求的標題
|
||||
- PullRequestDescription: 拉取請求的描述
|
||||
- PullRequestPosterName: 拉取請求的發起人名稱
|
||||
- PullRequestIndex: 拉取請求的索引號
|
||||
- PullRequestReference: 帶索引號的拉取請求引用字符。例如 #1, !2
|
||||
- ClosingIssues: 返回包含所有將被此拉取請求關閉的問題的字符串。例如 `close #1, close #2`
|
||||
- ReviewedOn: 此提交所屬的拉取請求。例如 `Reviewed-on: https://gitea.com/foo/bar/pulls/1`
|
||||
- ReviewedBy: 在合併前批准拉取請求的人。例如 `Reviewed-by: Jane Doe <jane.doe@example.com>`
|
||||
|
||||
## 重新基準
|
||||
|
||||
在沒有合併提交的情況下重新基準，`REBASE_TEMPLATE.md` 修改最後一次提交的消息。此模板中還提供以下變量：
|
||||
|
||||
- CommitTitle: 提交的標題
|
||||
- CommitBody: 提交的正文
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
date: "2024-09-11T09:30:00+08:00"
|
||||
slug: "migration"
|
||||
sidebar_position: 45
|
||||
---
|
||||
|
||||
# 遷移
|
||||
|
||||
您可以將倉庫從其他 Git 服務遷移到您的 Gitea 實例。
|
||||
|
||||
## 如何從 Gogs/GitHub/GitLab 遷移到 Gitea
|
||||
|
||||
要從 Gogs 遷移到 Gitea：
|
||||
|
||||
- [Gogs 版本 0.11.46.0418](https://github.com/go-gitea/gitea/issues/4286)
|
||||
|
||||
要從 GitHub 遷移到 Gitea，您可以使用 Gitea 的內置遷移表單。
|
||||
|
||||
為了遷移問題、拉取請求等項目，您需要至少輸入您的用戶名。
|
||||
|
||||
[示例（需要登錄）](https://demo.gitea.com/repo/migrate)
|
||||
|
||||
要從 GitLab 遷移到 Gitea，您可以使用這個非官方工具：
|
||||
|
||||
https://github.com/loganinak/MigrateGitlabToGogs
|
||||
|
||||
## 如何從 AWS CodeCommit 遷移到 Gitea
|
||||
|
||||
- 要使用 AWS CodeCommit API，Gitea 需要訪問密鑰 ID 和秘密訪問密鑰。出於安全原因，我們建議創建一個具有最低必要權限的新用戶，並為遷移生成訪問密鑰 ID 和秘密訪問密鑰。此用戶所需的最低權限如下：
|
||||
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"codecommit:GetRepository",
|
||||
"codecommit:GitPull",
|
||||
"codecommit:ListPullRequests",
|
||||
"codecommit:GetPullRequest",
|
||||
"codecommit:GetCommentsForPullRequest"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:codecommit:<region>:<account>:<Repo-to-Migrate>
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- 如果您不需要遷移拉取請求，可以刪除 `ListPullRequests`、`GetPullRequest` 和 `GetCommentsForPullRequest` 操作。
|
||||
|
||||
- 有關如何創建 IAM 用戶並分配權限的說明，您可以參考此 [AWS 文檔](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html)。
|
||||
|
||||
- 要克隆此倉庫，Gitea 需要 HTTPS Git 憑據。您可以根據此 [AWS 文檔](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html) 創建 HTTPS Git 憑據。
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
---
|
||||
date: "2023-08-22T14:21:00+08:00"
|
||||
slug: "multi-factor-authentication"
|
||||
weight: 15
|
||||
---
|
||||
|
||||
# 多因素身份驗證 (MFA)
|
||||
|
||||
多因素身份驗證（也稱為 MFA 或 2FA）通過要求除密碼外的時間敏感憑據來增強安全性。
|
||||
如果密碼後來被洩露，則無法登錄 Gitea，帳戶將保持安全。
|
||||
Gitea 支援 TOTP（基於時間的一次性密碼）令牌和使用 Webauthn API 的基於 FIDO 的硬件密鑰。
|
||||
|
||||
可以在用戶設置頁面的“安全”選項卡中配置 MFA。
|
||||
|
||||
## MFA 考慮事項
|
||||
|
||||
在用戶上啟用 MFA 會影響 Git HTTP 協議如何與 Git CLI 一起使用。
|
||||
此界面不支援 MFA，並且在啟用 MFA 時嘗試正常使用密碼將不再可能。
|
||||
如果 SSH 不是 Git 操作的選項，可以在用戶設置頁面的“應用程序”選項卡中生成訪問令牌。
|
||||
此訪問令牌可以像密碼一樣使用，以允許 Git CLI 通過 HTTP 工作。
|
||||
|
||||
:::warning
|
||||
由於其本質，訪問令牌繞過了 MFA 的安全性優勢。
|
||||
它必須保持安全，並且應僅作為最後的手段使用。
|
||||
:::
|
||||
|
||||
Gitea API 支援在 `X-Gitea-OTP` 標頭中提供相關的 TOTP 密碼，如 [API 使用](development/api-usage.md) 中所述。
|
||||
應盡可能使用此方法代替訪問令牌。
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
date: "2023-03-25T00:00:00+00:00"
|
||||
slug: "alpine"
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# Alpine 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Alpine](https://pkgs.alpinelinux.org/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Alpine 註冊表，您需要使用像 `curl` 這樣的 HTTP 客戶端來上傳，並使用像 `apk` 這樣的套件管理器來消費套件。
|
||||
|
||||
以下範例使用 `apk`。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊 Alpine 註冊表，請將 URL 添加到已知的 apk 來源列表中（`/etc/apk/repositories`）：
|
||||
|
||||
```
|
||||
https://gitea.example.com/api/packages/{owner}/alpine/<branch>/<repository>
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| ------------ | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `branch` | 要使用的分支。 |
|
||||
| `repository` | 要使用的倉庫。 |
|
||||
|
||||
如果註冊表是私有的，請在 URL 中提供憑證。您可以使用密碼或 [個人訪問令牌](development/api-usage.md#authentication)：
|
||||
|
||||
```
|
||||
https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/alpine/<branch>/<repository>
|
||||
```
|
||||
|
||||
Alpine 註冊表文件使用 RSA 密鑰簽名，該密鑰必須為 apk 所知。下載公鑰並將其存儲在 `/etc/apk/keys/` 中：
|
||||
|
||||
```shell
|
||||
curl -JO https://gitea.example.com/api/packages/{owner}/alpine/key
|
||||
```
|
||||
|
||||
之後更新本地套件索引：
|
||||
|
||||
```shell
|
||||
apk update
|
||||
```
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布 Alpine 套件（`*.apk`），請執行 HTTP `PUT` 操作，請求體中包含套件內容。
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/alpine/{branch}/{repository}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------------ | ------------------------------------------------------------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `branch` | 分支可能與操作系統的發行版本匹配，例如：`v3.17`。 |
|
||||
| `repository` | 倉庫可以用來[分組套件](https://wiki.alpinelinux.org/wiki/Repositories) 或者只是 `main` 或類似的。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/file.apk \
|
||||
https://gitea.example.com/api/packages/testuser/alpine/v3.17/main
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
您不能將同名文件兩次發布到套件中。您必須先刪除現有的套件文件。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ---------------------------------------- |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件名稱、版本、分支、倉庫或架構無效。 |
|
||||
| `409 Conflict` | 套件中已存在具有相同參數組合的套件文件。 |
|
||||
|
||||
## 刪除套件
|
||||
|
||||
要刪除 Alpine 套件，請執行 HTTP `DELETE` 操作。如果沒有文件剩餘，這也會刪除套件版本。
|
||||
|
||||
```
|
||||
DELETE https://gitea.example.com/api/packages/{owner}/alpine/{branch}/{repository}/{architecture}/{filename}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `branch` | 要使用的分支。 |
|
||||
| `repository` | 要使用的倉庫。 |
|
||||
| `architecture` | 套件架構。 |
|
||||
| `filename` | 要刪除的文件。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_token_or_password -X DELETE \
|
||||
https://gitea.example.com/api/packages/testuser/alpine/v3.17/main/test-package-1.0.0.apk
|
||||
```
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ---------------- | ------------------ |
|
||||
| `204 No Content` | 成功 |
|
||||
| `404 Not Found` | 未找到套件或文件。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從 Alpine 註冊表安裝套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
# 使用最新版本
|
||||
apk add {package_name}
|
||||
# 使用特定版本
|
||||
apk add {package_name}={package_version}
|
||||
```
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
date: "2023-05-15T00:00:00+00:00"
|
||||
slug: "arch"
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Arch 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Arch](https://archlinux.org/packages/) 套件。該註冊表可以作為一個完全運行的 [Arch linux 鏡像](https://wiki.archlinux.org/title/mirrors)，直接連接到 `/etc/pacman.conf`。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Arch 註冊表，您需要使用像 `curl` 這樣的 HTTP 客戶端來上傳，並使用像 `pacman` 這樣的套件管理器來消費套件。
|
||||
|
||||
以下範例使用 `pacman`。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
在您可以使用套件註冊表之前，您需要下載套件驗證密鑰並將註冊表添加到 pacman 配置中。
|
||||
|
||||
下載套件驗證密鑰。
|
||||
|
||||
```sh
|
||||
wget https://gitea.example.com/api/packages/{owner}/arch/repository.key
|
||||
```
|
||||
|
||||
顯示密鑰的 ID（帶有十六進制字符的長行）。
|
||||
|
||||
```sh
|
||||
gpg --show-keys repository.key
|
||||
```
|
||||
|
||||
將密鑰添加到 pacman 並簽署它（使用上一步中的密鑰 ID）。
|
||||
|
||||
```sh
|
||||
pacman-key --add repository.key
|
||||
pacman-key --lsign-key {key id}
|
||||
```
|
||||
|
||||
現在將註冊表配置添加到 `/etc/pacman.conf`。
|
||||
|
||||
```conf
|
||||
[{owner}.gitea.example.com]
|
||||
SigLevel = Required
|
||||
Server = https://gitea.example.com/api/packages/{owner}/arch/{repository}/{architecture}
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| -------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `repository` | 要使用的倉庫。 |
|
||||
| `architecture` | 要使用的架構。 |
|
||||
|
||||
請參閱擁有者的套件概述以查看可用的 `repository` 和 `architecture`。
|
||||
|
||||
如果註冊表是私有的，請在 URL 中提供憑證。您可以使用密碼或 [個人訪問令牌](development/api-usage.md#authentication)：
|
||||
|
||||
```
|
||||
Server = https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/arch/{repository}/{architecture}
|
||||
```
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布 Arch 套件，請執行 HTTP `PUT` 操作，請求體中包含套件內容。
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/arch/{repository}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------------ | -------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `repository` | 倉庫可以用來分組套件或只是 `core` 或類似的。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/file.pkg.tar.zst \
|
||||
https://gitea.example.com/api/packages/testuser/arch/core
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
您不能將同名文件兩次發布到套件中。您必須先刪除現有的套件文件。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ------------------------------------------ |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件的某些部分無效。錯誤消息包含更多信息。 |
|
||||
| `409 Conflict` | 套件中已存在具有相同參數組合的套件文件。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要安裝套件，請運行 pacman 同步命令：
|
||||
|
||||
```sh
|
||||
pacman -Sy {package_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
## 刪除套件
|
||||
|
||||
要刪除 Arch 套件，請執行 HTTP `DELETE` 操作。如果沒有文件剩餘，這也會刪除套件版本。
|
||||
|
||||
```
|
||||
DELETE https://gitea.example.com/api/packages/{owner}/arch/{repository}/{package_name}/{package_version}/{architecture}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `repository` | 要使用的倉庫。 |
|
||||
| `architecture` | 套件架構。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_token_or_password -X DELETE \
|
||||
https://gitea.example.com/api/packages/testuser/arch/core/test-package/1.0.0/x86-64
|
||||
```
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ---------------- | ------------------ |
|
||||
| `204 No Content` | 成功 |
|
||||
| `404 Not Found` | 未找到套件或文件。 |
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
date: "2022-11-20T00:00:00+00:00"
|
||||
slug: "cargo"
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Cargo 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Cargo](https://doc.rust-lang.org/stable/cargo/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Cargo 套件註冊表，您需要 [Rust 和 Cargo](https://www.rust-lang.org/tools/install)。
|
||||
|
||||
Cargo 將可用套件的信息存儲在一個 git 存儲庫中的套件索引中。
|
||||
此存儲庫是使用註冊表所必需的。
|
||||
以下部分描述了如何創建它。
|
||||
|
||||
## 索引存儲庫
|
||||
|
||||
Cargo 將可用套件的信息存儲在一個 git 存儲庫中的套件索引中。
|
||||
在 Gitea 中，此存儲庫具有特殊名稱 `_cargo-index`。
|
||||
上傳套件後，其元數據會自動寫入索引。
|
||||
此存儲庫的內容不應手動修改。
|
||||
|
||||
用戶或組織的套件設置頁面允許創建索引存儲庫以及配置文件。
|
||||
如果需要，此操作將重寫配置文件。
|
||||
這在例如 Gitea 實例域名更改時很有用。
|
||||
|
||||
如果出現 Gitea 中存儲的套件與索引存儲庫中的信息不同步的情況，設置頁面允許重建索引存儲庫。
|
||||
此操作會遍歷註冊表中的所有套件並將其信息寫入索引。
|
||||
如果有很多套件，這個過程可能需要一些時間。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表，必須更新 Cargo 配置。
|
||||
將以下文本添加到當前用戶主目錄中的配置文件（例如 `~/.cargo/config.toml`）：
|
||||
|
||||
```
|
||||
[registry]
|
||||
default = "gitea"
|
||||
|
||||
[registries.gitea]
|
||||
index = "sparse+https://gitea.example.com/api/packages/{owner}/cargo/" # Sparse index
|
||||
# index = "https://gitea.example.com/{owner}/_cargo-index.git" # Git
|
||||
|
||||
# [net]
|
||||
# git-fetch-with-cli = true
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
如果註冊表是私有的或您想發布新套件，您必須配置您的憑證。
|
||||
將憑證部分添加到當前用戶主目錄中的憑證文件（例如 `~/.cargo/credentials.toml`）：
|
||||
|
||||
```
|
||||
[registries.gitea]
|
||||
token = "Bearer {token}"
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | ------------------------------------------------------------ |
|
||||
| `token` | 您的 [個人訪問令牌](development/api-usage.md#authentication) |
|
||||
|
||||
## Git vs Sparse
|
||||
|
||||
目前，cargo 支持兩種從註冊表中獲取 crate 的方式：Git 索引和 sparse 索引。
|
||||
Sparse 索引是最新的方法，與 git 相比，在更新 crate 時提供了更好的性能。
|
||||
自 Rust 1.68 起，sparse 是 crates.io 的默認方法。
|
||||
|
||||
## 發布套件
|
||||
|
||||
在您的項目中運行以下命令來發布套件：
|
||||
|
||||
```shell
|
||||
cargo publish
|
||||
```
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
cargo add {package_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
cargo publish
|
||||
cargo add
|
||||
cargo install
|
||||
cargo yank
|
||||
cargo unyank
|
||||
cargo search
|
||||
```
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
date: "2023-01-20T00:00:00+00:00"
|
||||
slug: "chef"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# Chef 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Chef](https://chef.io/) 食譜。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Chef 套件註冊表，您必須使用 [`knife`](https://docs.chef.io/workstation/knife/)。
|
||||
|
||||
## 認證
|
||||
|
||||
Chef 套件註冊表不使用用戶名：密碼認證，而是使用私鑰：公鑰對進行簽名請求。
|
||||
訪問套件擁有者設置頁面以創建必要的密鑰對。
|
||||
只有公鑰存儲在 Gitea 中。如果您丟失了私鑰的訪問權限，您必須重新生成密鑰對。
|
||||
[配置 `knife`](https://docs.chef.io/workstation/knife_setup/) 以使用下載的私鑰和您的 Gitea 用戶名作為 `client_name`。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要[配置 `knife`](https://docs.chef.io/workstation/knife_setup/) 以使用 Gitea 套件註冊表，請將 URL 添加到 `~/.chef/config.rb` 文件中。
|
||||
|
||||
```
|
||||
knife[:supermarket_site] = 'https://gitea.example.com/api/packages/{owner}/chef'
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布 Chef 套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
knife supermarket share {package_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
knife supermarket install {package_name}
|
||||
```
|
||||
|
||||
您可以選擇指定套件版本：
|
||||
|
||||
```shell
|
||||
knife supermarket install {package_name} {package_version}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
|
||||
## 刪除套件
|
||||
|
||||
如果您想從註冊表中刪除套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
knife supermarket unshare {package_name}
|
||||
```
|
||||
|
||||
您可以選擇指定套件版本：
|
||||
|
||||
```shell
|
||||
knife supermarket unshare {package_name}/versions/{package_version}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "composer"
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
# Composer 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Composer](https://getcomposer.org/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Composer 套件註冊表，您可以使用 [Composer](https://getcomposer.org/download/) 來消費套件，並使用像 `curl` 這樣的 HTTP 上傳客戶端來發布套件。
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布 Composer 套件，請執行 HTTP PUT 操作，請求體中包含套件內容。
|
||||
套件內容必須是包含 `composer.json` 文件的壓縮 PHP 項目。
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/composer
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
如果 `composer.json` 文件不包含 `version` 屬性，您必須將其作為查詢參數提供：
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/composer?version={x.y.z}
|
||||
```
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/project.zip \
|
||||
https://gitea.example.com/api/packages/testuser/composer
|
||||
```
|
||||
|
||||
或者將套件版本作為查詢參數指定：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/project.zip \
|
||||
https://gitea.example.com/api/packages/testuser/composer?version=1.0.3
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ---------------------------------- |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件無效。 |
|
||||
| `409 Conflict` | 已存在具有相同參數組合的套件文件。 |
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表，您需要將其添加到 Composer 的 `config.json` 文件中（通常可以在 `<user-home-dir>/.composer/config.json` 下找到）：
|
||||
|
||||
```json
|
||||
{
|
||||
"repositories": [
|
||||
{
|
||||
"type": "composer",
|
||||
"url": "https://gitea.example.com/api/packages/{owner}/composer"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
要使用憑證訪問套件註冊表，您必須在 `auth.json` 文件中指定它們，如下所示：
|
||||
|
||||
```json
|
||||
{
|
||||
"http-basic": {
|
||||
"gitea.example.com": {
|
||||
"username": "{username}",
|
||||
"password": "{password}"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ---------- | ------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `username` | 您的 Gitea 用戶名。 |
|
||||
| `password` | 您的 Gitea 密碼或個人訪問令牌。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
composer require {package_name}
|
||||
```
|
||||
|
||||
您可以選擇指定套件版本：
|
||||
|
||||
```shell
|
||||
composer require {package_name}:{package_version}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "conan"
|
||||
sidebar_position: 20
|
||||
---
|
||||
|
||||
# Conan 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Conan](https://conan.io/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Conan 套件註冊表，您需要使用 [conan](https://conan.io/downloads.html) 命令行工具來消費和發布套件。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表，您需要配置一個新的 Conan 遠程：
|
||||
|
||||
```shell
|
||||
conan remote add {remote} https://gitea.example.com/api/packages/{owner}/conan
|
||||
conan user --remote {remote} --password {password} {username}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ---------- | ------------------------------------------------------------------------------------------------------------------- |
|
||||
| `remote` | 遠程名稱。 |
|
||||
| `username` | 您的 Gitea 用戶名。 |
|
||||
| `password` | 您的 Gitea 密碼。如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。 |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
conan remote add gitea https://gitea.example.com/api/packages/testuser/conan
|
||||
conan user --remote gitea --password password123 testuser
|
||||
```
|
||||
|
||||
## 發布套件
|
||||
|
||||
運行以下命令來發布 Conan 套件：
|
||||
|
||||
```shell
|
||||
conan upload --remote={remote} {recipe}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------- | -------------- |
|
||||
| `remote` | 遠程名稱。 |
|
||||
| `recipe` | 要上傳的配方。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
conan upload --remote=gitea ConanPackage/1.2@gitea/final
|
||||
```
|
||||
|
||||
您不能將同名文件兩次發布到套件中。您必須先刪除現有的套件或文件。
|
||||
|
||||
Gitea Conan 套件註冊表完全支持 [修訂](https://docs.conan.io/en/latest/versioning/revisions.html)。
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝 Conan 套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
conan install --remote={remote} {recipe}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------- | -------------- |
|
||||
| `remote` | 遠程名稱。 |
|
||||
| `recipe` | 要下載的配方。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
conan install --remote=gitea ConanPackage/1.2@gitea/final
|
||||
```
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
conan install
|
||||
conan get
|
||||
conan info
|
||||
conan search
|
||||
conan upload
|
||||
conan user
|
||||
conan download
|
||||
conan remove
|
||||
```
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
date: "2022-12-28T00:00:00+00:00"
|
||||
slug: "conda"
|
||||
sidebar_position: 25
|
||||
---
|
||||
|
||||
# Conda 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Conda](https://docs.conda.io/en/latest/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Conda 套件註冊表，您需要使用 [conda](https://docs.conda.io/projects/conda/en/stable/user-guide/install/index.html)。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表並提供憑證，請編輯您的 `.condarc` 文件：
|
||||
|
||||
```yaml
|
||||
channel_alias: https://gitea.example.com/api/packages/{owner}/conda
|
||||
channels:
|
||||
- https://gitea.example.com/api/packages/{owner}/conda
|
||||
default_channels:
|
||||
- https://gitea.example.com/api/packages/{owner}/conda
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
請參閱 [官方文檔](https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html) 以了解各個設置的說明。
|
||||
|
||||
如果您需要提供憑證，您可以將它們嵌入到頻道 URL 中（`https://user:password@gitea.example.com/...`）。
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布套件，請執行 HTTP PUT 操作，請求體中包含套件內容。
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/conda/{channel}/{filename}
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| ---------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `channel` | 套件的 [頻道](https://conda.io/projects/conda/en/latest/user-guide/concepts/channels.html)。（可選） |
|
||||
| `filename` | 文件名。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/package-1.0.conda \
|
||||
https://gitea.example.com/api/packages/testuser/conda/package-1.0.conda
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ---------------------------------- |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件無效。 |
|
||||
| `409 Conflict` | 已存在具有相同參數組合的套件文件。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝套件，請執行以下命令之一：
|
||||
|
||||
```shell
|
||||
conda install {package_name}
|
||||
conda install {package_name}={package_version}
|
||||
conda install -c {channel} {package_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | -------------------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
| `channel` | 套件的頻道。（可選） |
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "container"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
# 容器註冊表
|
||||
|
||||
為您的用戶或組織發布符合 [Open Container Initiative](https://opencontainers.org/) 規範的映像。
|
||||
容器註冊表遵循 OCI 規範，支持所有兼容的映像，如 [Docker](https://www.docker.com/) 和 [Helm Charts](https://helm.sh/)。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用容器註冊表，您可以使用特定映像類型的工具。
|
||||
以下範例使用 `docker` 客戶端。
|
||||
|
||||
## 登錄到容器註冊表
|
||||
|
||||
要推送映像或如果映像在私有註冊表中，您必須進行身份驗證：
|
||||
|
||||
```shell
|
||||
docker login gitea.example.com
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
## 映像命名規則
|
||||
|
||||
映像必須遵循以下命名規則：
|
||||
|
||||
`{registry}/{owner}/{image}`
|
||||
|
||||
在構建您的 docker 映像時，使用上述命名規則，這看起來像這樣：
|
||||
|
||||
```shell
|
||||
# 使用標籤構建映像
|
||||
docker build -t {registry}/{owner}/{image}:{tag} .
|
||||
# 使用標籤命名現有映像
|
||||
docker tag {some-existing-image}:{tag} {registry}/{owner}/{image}:{tag}
|
||||
```
|
||||
|
||||
其中您的註冊表是您的 gitea 實例的域名（例如 gitea.example.com）。
|
||||
例如，以下是所有者 `testuser` 的所有有效映像名稱：
|
||||
|
||||
`gitea.example.com/testuser/myimage`
|
||||
|
||||
`gitea.example.com/testuser/my-image`
|
||||
|
||||
`gitea.example.com/testuser/my/image`
|
||||
|
||||
:::note
|
||||
註冊表僅支持不區分大小寫的標籤名稱。因此 `image:tag` 和 `image:Tag` 被視為相同的映像和標籤。
|
||||
:::
|
||||
|
||||
## 推送映像
|
||||
|
||||
通過執行以下命令推送映像：
|
||||
|
||||
```shell
|
||||
docker push gitea.example.com/{owner}/{image}:{tag}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 映像的擁有者。 |
|
||||
| `image` | 映像的名稱。 |
|
||||
| `tag` | 映像的標籤。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
docker push gitea.example.com/testuser/myimage:latest
|
||||
```
|
||||
|
||||
## 拉取映像
|
||||
|
||||
通過執行以下命令拉取映像：
|
||||
|
||||
```shell
|
||||
docker pull gitea.example.com/{owner}/{image}:{tag}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 映像的擁有者。 |
|
||||
| `image` | 映像的名稱。 |
|
||||
| `tag` | 映像的標籤。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
docker pull gitea.example.com/testuser/myimage:latest
|
||||
```
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
date: "2023-01-01T00:00:00+00:00"
|
||||
slug: "cran"
|
||||
sidebar_position: 35
|
||||
---
|
||||
|
||||
# CRAN 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [R](https://www.r-project.org/) 套件到類似 [CRAN](https://cran.r-project.org/) 的註冊表。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 CRAN 套件註冊表，您需要安裝 [R](https://cran.r-project.org/)。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表，您需要將其添加到 `Rprofile.site`，可以是系統級別、用戶級別（`~/.Rprofile`）或項目級別：
|
||||
|
||||
```
|
||||
options("repos" = c(getOption("repos"), c(gitea="https://gitea.example.com/api/packages/{owner}/cran")))
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
如果您需要提供憑證，您可以將它們嵌入到 URL 中（`https://user:password@gitea.example.com/...`）。
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布 R 套件，請執行 HTTP `PUT` 操作，請求體中包含套件內容。
|
||||
|
||||
源套件：
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/cran/src
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
二進制套件：
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/cran/bin?platform={platform}&rversion={rversion}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ---------- | ----------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `platform` | 平台名稱。 |
|
||||
| `rversion` | 二進制的 R 版本。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/package.zip \
|
||||
https://gitea.example.com/api/packages/testuser/cran/bin?platform=windows&rversion=4.2
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ---------------------------------- |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件無效。 |
|
||||
| `409 Conflict` | 已存在具有相同參數組合的套件文件。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝 R 套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
install.packages("{package_name}")
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
install.packages("testpackage")
|
||||
```
|
||||
@@ -0,0 +1,123 @@
|
||||
---
|
||||
date: "2023-01-07T00:00:00+00:00"
|
||||
slug: "debian"
|
||||
sidebar_position: 40
|
||||
---
|
||||
|
||||
# Debian 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Debian](https://www.debian.org/distrib/packages) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Debian 註冊表，您需要使用像 `curl` 這樣的 HTTP 客戶端來上傳，並使用像 `apt` 這樣的套件管理器來消費套件。
|
||||
|
||||
以下範例使用 `apt`。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊 Debian 註冊表，請將 URL 添加到已知的 apt 來源列表中：
|
||||
|
||||
```shell
|
||||
echo "deb [signed-by=/etc/apt/keyrings/gitea-{owner}.asc] https://gitea.example.com/api/packages/{owner}/debian {distribution} {component}" | sudo tee -a /etc/apt/sources.list.d/gitea.list
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| -------------- | ---------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `distribution` | 要使用的發行版。 |
|
||||
| `component` | 要使用的組件。 |
|
||||
|
||||
如果註冊表是私有的，請在 URL 中提供憑證。您可以使用密碼或 [個人訪問令牌](development/api-usage.md#authentication)：
|
||||
|
||||
```shell
|
||||
echo "deb [signed-by=/etc/apt/keyrings/gitea-{owner}.asc] https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/debian {distribution} {component}" | sudo tee -a /etc/apt/sources.list.d/gitea.list
|
||||
```
|
||||
|
||||
Debian 註冊表文件使用 PGP 密鑰簽名，該密鑰必須為 apt 所知：
|
||||
|
||||
```shell
|
||||
sudo curl https://gitea.example.com/api/packages/{owner}/debian/repository.key -o /etc/apt/keyrings/gitea-{owner}.asc
|
||||
```
|
||||
|
||||
之後更新本地套件索引：
|
||||
|
||||
```shell
|
||||
apt update
|
||||
```
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布 Debian 套件（`*.deb`），請執行 HTTP `PUT` 操作，請求體中包含套件內容。
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/debian/pool/{distribution}/{component}/upload
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | ---------------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `distribution` | 發行版可能與操作系統的發行名稱匹配，例如：`bionic`。 |
|
||||
| `component` | 組件可以用來分組套件或只是 `main` 或類似的。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/file.deb \
|
||||
https://gitea.example.com/api/packages/testuser/debian/pool/bionic/main/upload
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
如果已經存在同名、同版本、同發行版、同組件和同架構的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ---------------------------------- |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件無效。 |
|
||||
| `409 Conflict` | 已存在具有相同參數組合的套件文件。 |
|
||||
|
||||
## 刪除套件
|
||||
|
||||
要刪除 Debian 套件，請執行 HTTP `DELETE` 操作。如果沒有文件剩餘，這也會刪除套件版本。
|
||||
|
||||
```
|
||||
DELETE https://gitea.example.com/api/packages/{owner}/debian/pool/{distribution}/{component}/{package_name}/{package_version}/{architecture}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
| `distribution` | 套件發行版。 |
|
||||
| `component` | 套件組件。 |
|
||||
| `architecture` | 套件架構。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_token_or_password -X DELETE \
|
||||
https://gitea.example.com/api/packages/testuser/debian/pool/bionic/main/test-package/1.0.0/amd64
|
||||
```
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ---------------- | ------------------ |
|
||||
| `204 No Content` | 成功 |
|
||||
| `404 Not Found` | 未找到套件或文件。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從 Debian 註冊表安裝套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
# 使用最新版本
|
||||
apt install {package_name}
|
||||
# 使用特定版本
|
||||
apt install {package_name}={package_version}
|
||||
```
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "generic"
|
||||
sidebar_position: 500
|
||||
---
|
||||
|
||||
# 通用套件註冊表
|
||||
|
||||
為您的用戶或組織發布通用文件，如發布的二進制文件或其他輸出。
|
||||
|
||||
## 認證到套件註冊表
|
||||
|
||||
要認證到套件註冊表，您需要提供[自定義 HTTP 標頭或使用 HTTP 基本認證](development/api-usage.md#authentication)。
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布通用套件，請執行 HTTP PUT 操作，請求體中包含套件內容。
|
||||
您不能將同名文件兩次發布到套件中。您必須先刪除現有的套件版本。
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/generic/{package_name}/{package_version}/{file_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。它只能包含小寫字母（`a-z`）、大寫字母（`A-Z`）、數字（`0-9`）、點（`.`）、連字符（`-`）、加號（`+`）或下劃線（`_`）。 |
|
||||
| `package_version` | 套件版本，一個沒有尾隨或前導空格的非空字符串。 |
|
||||
| `file_name` | 文件名。它只能包含小寫字母（`a-z`）、大寫字母（`A-Z`）、數字（`0-9`）、點（`.`）、連字符（`-`）、加號（`+`）或下劃線（`_`）。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/file.bin \
|
||||
https://gitea.example.com/api/packages/testuser/generic/test_package/1.0.0/file.bin
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ---------------------------------- |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件名稱和/或版本和/或文件名無效。 |
|
||||
| `409 Conflict` | 套件中已存在同名文件。 |
|
||||
|
||||
## 下載套件
|
||||
|
||||
要下載通用套件，請執行 HTTP GET 操作。
|
||||
|
||||
```
|
||||
GET https://gitea.example.com/api/packages/{owner}/generic/{package_name}/{package_version}/{file_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
| `file_name` | 文件名。 |
|
||||
|
||||
文件內容在響應體中提供。響應內容類型為 `application/octet-stream`。
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_token_or_password \
|
||||
https://gitea.example.com/api/packages/testuser/generic/test_package/1.0.0/file.bin
|
||||
```
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| --------------- | ------------------ |
|
||||
| `200 OK` | 成功 |
|
||||
| `404 Not Found` | 未找到套件或文件。 |
|
||||
|
||||
## 刪除套件
|
||||
|
||||
要刪除通用套件，請執行 HTTP DELETE 操作。這將刪除此版本的所有文件。
|
||||
|
||||
```
|
||||
DELETE https://gitea.example.com/api/packages/{owner}/generic/{package_name}/{package_version}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_token_or_password -X DELETE \
|
||||
https://gitea.example.com/api/packages/testuser/generic/test_package/1.0.0
|
||||
```
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ---------------- | ------------ |
|
||||
| `204 No Content` | 成功 |
|
||||
| `404 Not Found` | 未找到套件。 |
|
||||
|
||||
## 刪除套件文件
|
||||
|
||||
要刪除通用套件的文件，請執行 HTTP DELETE 操作。如果沒有文件剩餘，這也會刪除套件版本。
|
||||
|
||||
```
|
||||
DELETE https://gitea.example.com/api/packages/{owner}/generic/{package_name}/{package_version}/{filename}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
| `filename` | 文件名。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_token_or_password -X DELETE \
|
||||
https://gitea.example.com/api/packages/testuser/generic/test_package/1.0.0/file.bin
|
||||
```
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ---------------- | ------------------ |
|
||||
| `204 No Content` | 成功 |
|
||||
| `404 Not Found` | 未找到套件或文件。 |
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
date: "2023-05-10T00:00:00+00:00"
|
||||
slug: "go"
|
||||
sidebar_position: 45
|
||||
---
|
||||
|
||||
# Go 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 Go 套件。
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布 Go 套件，請執行 HTTP `PUT` 操作，請求體中包含套件內容。
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
套件必須遵循[文檔結構](https://go.dev/ref/mod#zip-files)。
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/go/upload
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
要認證到套件註冊表，您需要提供[自定義 HTTP 標頭或使用 HTTP 基本認證](development/api-usage.md#authentication)：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/file.zip \
|
||||
https://gitea.example.com/api/packages/testuser/go/upload
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | -------------------------- |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件無效。 |
|
||||
| `409 Conflict` | 已存在具有相同名稱的套件。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要安裝 Go 套件，請指示 Go 使用套件註冊表作為代理：
|
||||
|
||||
```shell
|
||||
# 使用最新版本
|
||||
GOPROXY=https://gitea.example.com/api/packages/{owner}/go go install {package_name}
|
||||
# 或者
|
||||
GOPROXY=https://gitea.example.com/api/packages/{owner}/go go install {package_name}@latest
|
||||
# 使用特定版本
|
||||
GOPROXY=https://gitea.example.com/api/packages/{owner}/go go install {package_name}@{package_version}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
|
||||
如果套件的擁有者是私有的，您需要[提供憑證](https://go.dev/ref/mod#private-module-proxy-auth)。
|
||||
|
||||
有關 `GOPROXY` 環境變量以及如何防止數據洩漏的更多信息，請參閱[文檔](https://go.dev/ref/mod#private-modules)。
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
date: "2022-04-14T00:00:00+00:00"
|
||||
slug: "helm"
|
||||
sidebar_position: 50
|
||||
---
|
||||
|
||||
# Helm Chart 註冊表
|
||||
|
||||
為您的用戶或組織發布 [Helm](https://helm.sh/) 圖表。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Helm Chart 註冊表，請使用簡單的 HTTP 客戶端，如 `curl` 或 [`helm cm-push`](https://github.com/chartmuseum/helm-push/) 插件。
|
||||
|
||||
## 發布套件
|
||||
|
||||
通過運行以下命令發布套件：
|
||||
|
||||
```shell
|
||||
curl --user {username}:{password} -X POST --upload-file ./{chart_file}.tgz https://gitea.example.com/api/packages/{owner}/helm/api/charts
|
||||
```
|
||||
|
||||
或使用 `helm cm-push` 插件：
|
||||
|
||||
```shell
|
||||
helm repo add --username {username} --password {password} {repo} https://gitea.example.com/api/packages/{owner}/helm
|
||||
helm cm-push ./{chart_file}.tgz {repo}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------------ | ------------------------------------------------------------------------------------------------------------------- |
|
||||
| `username` | 您的 Gitea 用戶名。 |
|
||||
| `password` | 您的 Gitea 密碼。如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。 |
|
||||
| `repo` | 倉庫的名稱。 |
|
||||
| `chart_file` | Helm Chart 存檔。 |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從註冊表中安裝 Helm 圖表，請執行以下命令：
|
||||
|
||||
```shell
|
||||
helm repo add --username {username} --password {password} {repo} https://gitea.example.com/api/packages/{owner}/helm
|
||||
helm repo update
|
||||
helm install {name} {repo}/{chart}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ---------- | ------------------------------- |
|
||||
| `username` | 您的 Gitea 用戶名。 |
|
||||
| `password` | 您的 Gitea 密碼或個人訪問令牌。 |
|
||||
| `repo` | 倉庫的名稱。 |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `name` | 本地名稱。 |
|
||||
| `chart` | Helm Chart 的名稱。 |
|
||||
@@ -0,0 +1,154 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "maven"
|
||||
sidebar_position: 60
|
||||
---
|
||||
|
||||
# Maven 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Maven](https://maven.apache.org) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Maven 套件註冊表，您可以使用 [Maven](https://maven.apache.org/install.html) 或 [Gradle](https://gradle.org/install/)。
|
||||
以下範例使用 `Maven` 和 `Gradle Groovy`。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表，您首先需要將訪問令牌添加到 [`settings.xml`](https://maven.apache.org/settings.html) 文件中：
|
||||
|
||||
```xml
|
||||
<settings>
|
||||
<servers>
|
||||
<server>
|
||||
<id>gitea</id>
|
||||
<configuration>
|
||||
<httpHeaders>
|
||||
<property>
|
||||
<name>Authorization</name>
|
||||
<value>token {access_token}</value>
|
||||
</property>
|
||||
</httpHeaders>
|
||||
</configuration>
|
||||
</server>
|
||||
</servers>
|
||||
</settings>
|
||||
```
|
||||
|
||||
之後將以下部分添加到您的項目 `pom.xml` 文件中：
|
||||
|
||||
```xml
|
||||
<repositories>
|
||||
<repository>
|
||||
<id>gitea</id>
|
||||
<url>https://gitea.example.com/api/packages/{owner}/maven</url>
|
||||
</repository>
|
||||
</repositories>
|
||||
<distributionManagement>
|
||||
<repository>
|
||||
<id>gitea</id>
|
||||
<url>https://gitea.example.com/api/packages/{owner}/maven</url>
|
||||
</repository>
|
||||
<snapshotRepository>
|
||||
<id>gitea</id>
|
||||
<url>https://gitea.example.com/api/packages/{owner}/maven</url>
|
||||
</snapshotRepository>
|
||||
</distributionManagement>
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | -------------------------------------------------------------- |
|
||||
| `access_token` | 您的 [個人訪問令牌](development/api-usage.md#authentication)。 |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
### Gradle 變體
|
||||
|
||||
當您計劃在項目中添加來自 Gitea 實例的一些套件時，應該將其添加到倉庫部分：
|
||||
|
||||
```groovy
|
||||
repositories {
|
||||
// 其他倉庫
|
||||
maven { url "https://gitea.example.com/api/packages/{owner}/maven" }
|
||||
}
|
||||
```
|
||||
|
||||
在 Groovy gradle 中，您可以在發布部分中包含以下腳本：
|
||||
|
||||
```groovy
|
||||
publishing {
|
||||
// 發布的其他設置
|
||||
repositories {
|
||||
maven {
|
||||
name = "Gitea"
|
||||
url = uri("https://gitea.example.com/api/packages/{owner}/maven")
|
||||
|
||||
credentials(HttpHeaderCredentials) {
|
||||
name = "Authorization"
|
||||
value = "token {access_token}"
|
||||
}
|
||||
|
||||
authentication {
|
||||
header(HttpHeaderAuthentication)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布套件，只需運行：
|
||||
|
||||
```shell
|
||||
mvn deploy
|
||||
```
|
||||
|
||||
或者在使用 gradle 的情況下，調用帶有任務 `publishAllPublicationsToGiteaRepository` 的 `gradle`：
|
||||
|
||||
```groovy
|
||||
./gradlew publishAllPublicationsToGiteaRepository
|
||||
```
|
||||
|
||||
如果您想將預構建的套件發布到註冊表，可以使用 [`mvn deploy:deploy-file`](https://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html)：
|
||||
|
||||
```shell
|
||||
mvn deploy:deploy-file -Durl=https://gitea.example.com/api/packages/{owner}/maven -DrepositoryId=gitea -Dfile=/path/to/package.jar
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝 Maven 套件，請在項目 `pom.xml` 文件中添加新的依賴項：
|
||||
|
||||
```xml
|
||||
<dependency>
|
||||
<groupId>com.test.package</groupId>
|
||||
<artifactId>test_project</artifactId>
|
||||
<version>1.0.0</version>
|
||||
</dependency>
|
||||
```
|
||||
|
||||
在 gradle groovy 中類似：
|
||||
|
||||
```groovy
|
||||
implementation "com.test.package:test_project:1.0.0"
|
||||
```
|
||||
|
||||
之後運行：
|
||||
|
||||
```shell
|
||||
mvn install
|
||||
```
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
mvn install
|
||||
mvn deploy
|
||||
mvn dependency:get:
|
||||
```
|
||||
@@ -0,0 +1,132 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "npm"
|
||||
sidebar_position: 70
|
||||
---
|
||||
|
||||
# NPM 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [npm](https://www.npmjs.com/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 npm 套件註冊表，您需要 [Node.js](https://nodejs.org/en/download/) 以及一個包管理器，如 [Yarn](https://classic.yarnpkg.com/en/docs/install) 或 [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm/) 本身。
|
||||
|
||||
註冊表支持[範圍](https://docs.npmjs.com/misc/scope/)和非範圍套件。
|
||||
|
||||
以下範例使用 `npm` 工具和範圍 `@test`。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表，您需要配置一個新的包源。
|
||||
|
||||
```shell
|
||||
npm config set {scope}:registry=https://gitea.example.com/api/packages/{owner}/npm/
|
||||
npm config set -- '//gitea.example.com/api/packages/{owner}/npm/:_authToken' "{token}"
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------------------------------------------------------- |
|
||||
| `scope` | 套件的範圍。 |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `token` | 您的 [個人訪問令牌](development/api-usage.md#authentication)。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
npm config set @test:registry=https://gitea.example.com/api/packages/testuser/npm/
|
||||
npm config set -- '//gitea.example.com/api/packages/testuser/npm/:_authToken' "personal_access_token"
|
||||
```
|
||||
|
||||
或不使用範圍：
|
||||
|
||||
```shell
|
||||
npm config set registry https://gitea.example.com/api/packages/testuser/npm/
|
||||
npm config set -- '//gitea.example.com/api/packages/testuser/npm/:_authToken' "personal_access_token"
|
||||
```
|
||||
|
||||
## 發布套件
|
||||
|
||||
在您的項目中運行以下命令來發布套件：
|
||||
|
||||
```shell
|
||||
npm publish
|
||||
```
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
## 取消發布套件
|
||||
|
||||
運行以下命令來刪除套件：
|
||||
|
||||
```shell
|
||||
npm unpublish {package_name}[@{package_version}]
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
npm unpublish @test/test_package
|
||||
npm unpublish @test/test_package@1.0.0
|
||||
```
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
npm install {package_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
npm install @test/test_package
|
||||
```
|
||||
|
||||
## 標記套件
|
||||
|
||||
註冊表支持[版本標籤](https://docs.npmjs.com/adding-dist-tags-to-packages/)，可以通過 `npm dist-tag` 進行管理：
|
||||
|
||||
```shell
|
||||
npm dist-tag add {package_name}@{version} {tag}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | ---------- |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `version` | 套件版本。 |
|
||||
| `tag` | 標籤名稱。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
npm dist-tag add test_package@1.0.2 release
|
||||
```
|
||||
|
||||
標籤名稱不能是有效版本。所有可解析為版本的標籤名稱都會被拒絕。
|
||||
|
||||
## 搜索套件
|
||||
|
||||
註冊表支持[搜索](https://docs.npmjs.com/cli/v7/commands/npm-search/)，但不支持特殊搜索限定符，如 `author:gitea`。
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
npm install
|
||||
npm ci
|
||||
npm publish
|
||||
npm unpublish
|
||||
npm dist-tag
|
||||
npm view
|
||||
npm search
|
||||
```
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "nuget"
|
||||
sidebar_position: 80
|
||||
---
|
||||
|
||||
# NuGet 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [NuGet](https://www.nuget.org/) 套件。套件註冊表支持 V2 和 V3 API 協議，您還可以使用 [NuGet 符號包](https://docs.microsoft.com/zh-tw/nuget/create-packages/symbol-packages-snupkg)。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 NuGet 套件註冊表，您可以使用命令行界面工具以及各種 IDE（如 Visual Studio）中的 NuGet 功能。
|
||||
有關 NuGet 客戶端的更多信息，請參閱[官方文檔](https://docs.microsoft.com/zh-tw/nuget/install-nuget-client-tools)。
|
||||
以下範例使用 `dotnet nuget` 工具。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表，您需要配置一個新的 NuGet 源：
|
||||
|
||||
```shell
|
||||
dotnet nuget add source --name {source_name} --username {username} --password {password} https://gitea.example.com/api/packages/{owner}/nuget/index.json
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------------- | ------------------------------------------------------------------------------------------------------------------- |
|
||||
| `source_name` | 所需的源名稱。 |
|
||||
| `username` | 您的 Gitea 用戶名。 |
|
||||
| `password` | 您的 Gitea 密碼。如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。 |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
dotnet nuget add source --name gitea --username testuser --password password123 https://gitea.example.com/api/packages/testuser/nuget/index.json
|
||||
```
|
||||
|
||||
您可以在沒有憑證的情況下添加源，並在發布套件時使用 [`--api-key`](https://docs.microsoft.com/zh-tw/dotnet/core/tools/dotnet-nuget-push) 參數。在這種情況下，您需要提供 [個人訪問令牌](development/api-usage.md#authentication)。
|
||||
|
||||
## 發布套件
|
||||
|
||||
運行以下命令來發布套件：
|
||||
|
||||
```shell
|
||||
dotnet nuget push --source {source_name} {package_file}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | -------------------------- |
|
||||
| `source_name` | 所需的源名稱。 |
|
||||
| `package_file` | 套件 `.nupkg` 文件的路徑。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
dotnet nuget push --source gitea test_package.1.0.0.nupkg
|
||||
```
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
### 符號包
|
||||
|
||||
NuGet 套件註冊表支持符號服務器。嵌入在符號包（`.snupkg`）中的 PDB 文件可以被客戶端請求。
|
||||
為此，請將 NuGet 套件註冊表註冊為符號源：
|
||||
|
||||
```
|
||||
https://gitea.example.com/api/packages/{owner}/nuget/symbols
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------------- |
|
||||
| `owner` | 套件註冊表的擁有者。 |
|
||||
|
||||
例如：
|
||||
|
||||
```
|
||||
https://gitea.example.com/api/packages/testuser/nuget/symbols
|
||||
```
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝 NuGet 套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
dotnet add package --source {source_name} --version {package_version} {package_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | -------------- |
|
||||
| `source_name` | 所需的源名稱。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
dotnet add package --source gitea --version 1.0.0 test_package
|
||||
```
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
dotnet add
|
||||
dotnet nuget push
|
||||
dotnet nuget delete
|
||||
```
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "overview"
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# 概述
|
||||
|
||||
從 Gitea **1.17** 開始，套件註冊表可以用作常見套件管理器的公共或私有註冊表。
|
||||
|
||||
## 支持的套件管理器
|
||||
|
||||
目前支持以下套件管理器：
|
||||
|
||||
| 名稱 | 語言 | 套件客戶端 |
|
||||
| ---------------------------------------- | ---------- | --------------------------- |
|
||||
| [Alpine](usage/packages/alpine.md) | - | `apk` |
|
||||
| [Arch](usage/packages/arch.md) | - | `pacman` |
|
||||
| [Cargo](usage/packages/cargo.md) | Rust | `cargo` |
|
||||
| [Chef](usage/packages/chef.md) | - | `knife` |
|
||||
| [Composer](usage/packages/composer.md) | PHP | `composer` |
|
||||
| [Conan](usage/packages/conan.md) | C++ | `conan` |
|
||||
| [Conda](usage/packages/conda.md) | - | `conda` |
|
||||
| [Container](usage/packages/container.md) | - | 任何符合 OCI 的客戶端 |
|
||||
| [CRAN](usage/packages/cran.md) | R | - |
|
||||
| [Debian](usage/packages/debian.md) | - | `apt` |
|
||||
| [Generic](usage/packages/generic.md) | - | 任何 HTTP 客戶端 |
|
||||
| [Go](usage/packages/go.md) | Go | `go` |
|
||||
| [Helm](usage/packages/helm.md) | - | 任何 HTTP 客戶端，`cm-push` |
|
||||
| [Maven](usage/packages/maven.md) | Java | `mvn`，`gradle` |
|
||||
| [npm](usage/packages/npm.md) | JavaScript | `npm`，`yarn`，`pnpm` |
|
||||
| [NuGet](usage/packages/nuget.md) | .NET | `nuget` |
|
||||
| [Pub](usage/packages/pub.md) | Dart | `dart`，`flutter` |
|
||||
| [PyPI](usage/packages/pypi.md) | Python | `pip`，`twine` |
|
||||
| [RPM](usage/packages/rpm.md) | - | `yum`，`dnf`，`zypper` |
|
||||
| [RubyGems](usage/packages/rubygems.md) | Ruby | `gem`，`Bundler` |
|
||||
| [Swift](usage/packages/swift.md) | Swift | `swift` |
|
||||
| [Vagrant](usage/packages/vagrant.md) | - | `vagrant` |
|
||||
|
||||
**以下段落僅適用於套件未全局禁用的情況！**
|
||||
|
||||
## 存儲庫-套件
|
||||
|
||||
套件始終屬於擁有者（用戶或組織），而不是存儲庫。
|
||||
要將（已上傳的）套件鏈接到存儲庫，請打開該套件的設置頁面並選擇要鏈接此套件的存儲庫。
|
||||
整個套件將被鏈接，而不僅僅是單個版本。
|
||||
|
||||
鏈接套件會顯示在存儲庫的套件列表中，並在套件網站上顯示指向存儲庫的鏈接（以及指向存儲庫問題的鏈接）。
|
||||
|
||||
## 訪問限制
|
||||
|
||||
| 套件擁有者類型 | 用戶 | 組織 |
|
||||
| -------------- | -------------------------------------------- | -------------------------------------------- |
|
||||
| **讀** 訪問 | 公共，如果用戶也是公共的；否則僅對此用戶可見 | 公共，如果組織是公共的，否則僅對組織成員可見 |
|
||||
| **寫** 訪問 | 僅限擁有者 | 具有管理或寫入訪問權限的組織成員 |
|
||||
|
||||
注意：這些訪問限制[可能會更改](https://github.com/go-gitea/gitea/issues/19270)，將通過專用的組織團隊權限添加更細粒度的控制。
|
||||
|
||||
## 創建或上傳套件
|
||||
|
||||
根據套件的類型，使用相應的套件管理器。請查看特定套件管理器的子頁面以獲取說明。
|
||||
|
||||
## 查看套件
|
||||
|
||||
您可以在存儲庫頁面上查看存儲庫的套件。
|
||||
|
||||
1. 轉到存儲庫。
|
||||
1. 在導航欄中轉到 **Packages**。
|
||||
|
||||
要查看有關套件的更多詳細信息，請選擇套件的名稱。
|
||||
|
||||
## 下載套件
|
||||
|
||||
要從存儲庫下載套件：
|
||||
|
||||
1. 在導航欄中轉到 **Packages**。
|
||||
1. 選擇套件的名稱以查看詳細信息。
|
||||
1. 在 **Assets** 部分中，選擇要下載的套件文件的名稱。
|
||||
|
||||
## 刪除套件
|
||||
|
||||
在套件註冊表中發布套件後，您無法編輯它。相反，您必須刪除並重新創建它。
|
||||
|
||||
要從存儲庫中刪除套件：
|
||||
|
||||
1. 在導航欄中轉到 **Packages**。
|
||||
1. 選擇套件的名稱以查看詳細信息。
|
||||
1. 單擊 **Delete package** 以永久刪除套件。
|
||||
|
||||
## 禁用套件註冊表
|
||||
|
||||
套件註冊表會自動啟用。要為單個存儲庫禁用它：
|
||||
|
||||
1. 在導航欄中轉到 **Settings**。
|
||||
1. 禁用 **Enable Repository Packages Registry**。
|
||||
|
||||
禁用套件註冊表不會刪除以前發布的套件。
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
date: "2022-07-31T00:00:00+00:00"
|
||||
slug: "pub"
|
||||
sidebar_position: 90
|
||||
---
|
||||
|
||||
# Pub 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Pub](https://dart.dev/guides/packages) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Pub 套件註冊表，您需要使用工具 [dart](https://dart.dev/tools/dart-tool) 和/或 [flutter](https://docs.flutter.dev/reference/flutter-cli)。
|
||||
|
||||
以下範例使用 dart。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表並提供憑證，請執行：
|
||||
|
||||
```shell
|
||||
dart pub token add https://gitea.example.com/api/packages/{owner}/pub
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
您需要提供您的 [個人訪問令牌](development/api-usage.md#authentication)。
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布套件，請編輯 `pubspec.yaml` 並添加以下行：
|
||||
|
||||
```yaml
|
||||
publish_to: https://gitea.example.com/api/packages/{owner}/pub
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
|
||||
現在您可以通過運行以下命令來發布套件：
|
||||
|
||||
```shell
|
||||
dart pub publish
|
||||
```
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝 Pub 套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
dart pub add {package_name} --hosted-url=https://gitea.example.com/api/packages/{owner}/pub/
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
# 使用最新版本
|
||||
dart pub add mypackage --hosted-url=https://gitea.example.com/api/packages/testuser/pub/
|
||||
# 指定版本
|
||||
dart pub add mypackage:1.0.8 --hosted-url=https://gitea.example.com/api/packages/testuser/pub/
|
||||
```
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "pypi"
|
||||
sidebar_position: 100
|
||||
---
|
||||
|
||||
# PyPI 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [PyPI](https://pypi.org/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 PyPI 套件註冊表，您需要使用工具 [pip](https://pypi.org/project/pip/) 來消費和 [twine](https://pypi.org/project/twine/) 來發布套件。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表，您需要編輯本地 `~/.pypirc` 文件。添加
|
||||
|
||||
```ini
|
||||
[distutils]
|
||||
index-servers = gitea
|
||||
|
||||
[gitea]
|
||||
repository = https://gitea.example.com/api/packages/{owner}/pypi
|
||||
username = {username}
|
||||
password = {password}
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| ---------- | ------------------------------------------------------------------------------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `username` | 您的 Gitea 用戶名。 |
|
||||
| `password` | 您的 Gitea 密碼。如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。 |
|
||||
|
||||
## 發布套件
|
||||
|
||||
運行以下命令來發布套件：
|
||||
|
||||
```shell
|
||||
python3 -m twine upload --repository gitea /path/to/files/*
|
||||
```
|
||||
|
||||
套件文件的擴展名為 `.tar.gz` 和 `.whl`。
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝 PyPI 套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
pip install --index-url https://{username}:{password}@gitea.example.com/api/packages/{owner}/pypi/simple --no-deps {package_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | ------------------------------- |
|
||||
| `username` | 您的 Gitea 用戶名。 |
|
||||
| `password` | 您的 Gitea 密碼或個人訪問令牌。 |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
pip install --index-url https://testuser:password123@gitea.example.com/api/packages/testuser/pypi/simple --no-deps test_package
|
||||
```
|
||||
|
||||
您可以使用 `--extra-index-url` 代替 `--index-url`，但這會使您容易受到依賴混淆攻擊，因為 `pip` 在檢查指定的自定義存儲庫之前會先檢查官方 PyPi 存儲庫。請閱讀 `pip` 文檔以獲取更多信息。
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
pip install
|
||||
twine upload
|
||||
```
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
date: "2023-03-08T00:00:00+00:00"
|
||||
slug: "rpm"
|
||||
sidebar_position: 105
|
||||
---
|
||||
|
||||
# RPM 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [RPM](https://rpm.org/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 RPM 註冊表，您需要使用像 `yum`、`dnf` 或 `zypper` 這樣的套件管理器來消費套件。
|
||||
|
||||
以下範例使用 `dnf`。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊 RPM 註冊表，請將 URL 添加到已知來源列表中：
|
||||
|
||||
```shell
|
||||
dnf config-manager --add-repo https://gitea.example.com/api/packages/{owner}/rpm/{group}.repo
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| ------- | ----------------------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `group` | 可選：所有內容，例如空的，`el7`，`rocky/el9`，`test/fc38`。 |
|
||||
|
||||
範例：
|
||||
|
||||
```shell
|
||||
# 沒有分組
|
||||
dnf config-manager --add-repo https://gitea.example.com/api/packages/testuser/rpm.repo
|
||||
|
||||
# 使用分組 'centos/el7'
|
||||
dnf config-manager --add-repo https://gitea.example.com/api/packages/testuser/rpm/centos/el7.repo
|
||||
```
|
||||
|
||||
如果註冊表是私有的，請在 URL 中提供憑證。您可以使用密碼或 [個人訪問令牌](development/api-usage.md#authentication)：
|
||||
|
||||
```shell
|
||||
dnf config-manager --add-repo https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/rpm/{group}.repo
|
||||
```
|
||||
|
||||
您還需要將憑證添加到創建的 `.repo` 文件中的 URL 中，位於 `/etc/yum.repos.d`。
|
||||
|
||||
## 發布套件
|
||||
|
||||
要發布 RPM 套件（`*.rpm`），請執行 HTTP PUT 操作，請求體中包含套件內容。
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/rpm/{group}/upload
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | ----------------------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `group` | 可選：所有內容，例如空的，`el7`，`rocky/el9`，`test/fc38`。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
# 沒有分組
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/file.rpm \
|
||||
https://gitea.example.com/api/packages/testuser/rpm/upload
|
||||
|
||||
# 使用分組 'centos/el7'
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/file.rpm \
|
||||
https://gitea.example.com/api/packages/testuser/rpm/centos/el7/upload
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
您不能將同名文件兩次發布到套件中。您必須先刪除現有的套件版本。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ------------------------------------ |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件無效。 |
|
||||
| `409 Conflict` | 套件中已存在具有相同參數組合的文件。 |
|
||||
|
||||
## 刪除套件
|
||||
|
||||
要刪除 RPM 套件，請執行 HTTP DELETE 操作。如果沒有文件剩餘，這也會刪除套件版本。
|
||||
|
||||
```
|
||||
DELETE https://gitea.example.com/api/packages/{owner}/rpm/{group}/package/{package_name}/{package_version}/{architecture}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | ---------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `group` | 可選：套件分組。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本。 |
|
||||
| `architecture` | 套件架構。 |
|
||||
|
||||
使用 HTTP 基本身份驗證的範例請求：
|
||||
|
||||
```shell
|
||||
# 沒有分組
|
||||
curl --user your_username:your_token_or_password -X DELETE \
|
||||
https://gitea.example.com/api/packages/testuser/rpm/package/test-package/1.0.0/x86_64
|
||||
|
||||
# 使用分組 'centos/el7'
|
||||
curl --user your_username:your_token_or_password -X DELETE \
|
||||
https://gitea.example.com/api/packages/testuser/rpm/centos/el7/package/test-package/1.0.0/x86_64
|
||||
```
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ---------------- | ------------------ |
|
||||
| `204 No Content` | 成功 |
|
||||
| `404 Not Found` | 未找到套件或文件。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從 RPM 註冊表中安裝套件，請執行以下命令：
|
||||
|
||||
```shell
|
||||
# 使用最新版本
|
||||
dnf install {package_name}
|
||||
# 使用特定版本
|
||||
dnf install {package_name}-{package_version}.{architecture}
|
||||
```
|
||||
@@ -0,0 +1,115 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "rubygems"
|
||||
sidebar_position: 110
|
||||
---
|
||||
|
||||
# RubyGems 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [RubyGems](https://guides.rubygems.org/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 RubyGems 套件註冊表，您需要使用 [gem](https://guides.rubygems.org/command-reference/) 命令行工具來消費和發布套件。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表，請編輯 `~/.gem/credentials` 文件並添加：
|
||||
|
||||
```ini
|
||||
---
|
||||
https://gitea.example.com/api/packages/{owner}/rubygems: Bearer {token}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ------- | -------------------------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `token` | 您的 [個人訪問令牌](development/api-usage.md#authentication)。 |
|
||||
|
||||
例如：
|
||||
|
||||
```
|
||||
---
|
||||
https://gitea.example.com/api/packages/testuser/rubygems: Bearer 3bd626f84b01cd26b873931eace1e430a5773cc4
|
||||
```
|
||||
|
||||
## 發布套件
|
||||
|
||||
運行以下命令來發布套件：
|
||||
|
||||
```shell
|
||||
gem push --host {host} {package_file}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | ------------------------ |
|
||||
| `host` | 套件註冊表的 URL。 |
|
||||
| `package_file` | 套件 `.gem` 文件的路徑。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
gem push --host https://gitea.example.com/api/packages/testuser/rubygems test_package-1.0.0.gem
|
||||
```
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝套件，您可以使用 [Bundler](https://bundler.io) 或 `gem`。
|
||||
|
||||
### Bundler
|
||||
|
||||
在您的 `Gemfile` 中添加一個新的 `source` 塊：
|
||||
|
||||
```
|
||||
source "https://gitea.example.com/api/packages/{owner}/rubygems" do
|
||||
gem "{package_name}"
|
||||
end
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
例如：
|
||||
|
||||
```
|
||||
source "https://gitea.example.com/api/packages/testuser/rubygems" do
|
||||
gem "test_package"
|
||||
end
|
||||
```
|
||||
|
||||
之後運行以下命令：
|
||||
|
||||
```shell
|
||||
bundle install
|
||||
```
|
||||
|
||||
### gem
|
||||
|
||||
執行以下命令：
|
||||
|
||||
```shell
|
||||
gem install --host https://gitea.example.com/api/packages/{owner}/rubygems {package_name}
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
gem install --host https://gitea.example.com/api/packages/testuser/rubygems test_package
|
||||
```
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
gem install
|
||||
bundle install
|
||||
gem push
|
||||
```
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
date: "2022-11-01T00:00:00+00:00"
|
||||
slug: "storage"
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# 存儲
|
||||
|
||||
本文檔描述了套件註冊表的存儲及其管理方式。
|
||||
|
||||
## 去重
|
||||
|
||||
套件註冊表具有內置的上傳 blob 去重功能。
|
||||
如果上傳了兩個相同的文件，則文件系統上只會保存一個 blob。
|
||||
這確保了不會為重複的文件浪費空間。
|
||||
|
||||
如果上傳了兩個包含相同文件的套件，這兩個套件將顯示相同的大小，但在文件系統上它們只需要一半的大小。
|
||||
每當刪除套件時，只會刪除對底層 blob 的引用。
|
||||
此時不會刪除 blob，因此它們仍然需要文件系統上的空間。
|
||||
當上傳新套件時，現有的 blob 可能會再次被引用。
|
||||
|
||||
這些未引用的 blob 會被[清理作業](../../administration/config-cheat-sheet.md#cron---cleanup-expired-packages-croncleanup_packages)刪除。
|
||||
配置設置 `OLDER_THAN` 配置了未引用的 blob 在刪除前保留的時間。
|
||||
|
||||
## 清理規則
|
||||
|
||||
隨著時間的推移，套件註冊表可能會變得很大而不進行清理。
|
||||
建議刪除不必要的套件並設置清理規則以自動管理套件註冊表的使用。
|
||||
每個套件擁有者（用戶或組織）管理應用於其套件的清理規則。
|
||||
|
||||
| 設置 | 描述 |
|
||||
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 啟用 | 打開或關閉清理規則。 |
|
||||
| 類型 | 每個規則管理特定的套件類型。 |
|
||||
| 將模式應用於完整的套件名稱 | 如果啟用，下面的模式將應用於完整的套件名稱（`package/version`）。否則僅應用於版本（`version`）。 |
|
||||
| 保留最新的 | 每個套件要*始終*保留的版本數量。 |
|
||||
| 保留匹配的版本 | 確定要保留的版本的正則表達式模式。空模式不保留任何版本，而 `.+` 保留所有版本。即使未配置，容器註冊表也會始終保留 `latest` 版本。 |
|
||||
| 刪除早於的版本 | 只刪除早於選定天數的版本。 |
|
||||
| 刪除匹配的版本 | 確定要刪除的版本的正則表達式模式。空模式或 `.+` 將導致刪除所有套件，如果沒有其他設置告訴否則。 |
|
||||
|
||||
每個清理規則都可以顯示受影響套件的預覽。
|
||||
這可以用來檢查清理規則是否配置正確。
|
||||
|
||||
### 正則表達式示例
|
||||
|
||||
正則表達式模式會自動用 `\A` 和 `\z` 錨點包圍。
|
||||
不要在正則表達式模式中包含任何 `\A`、`\z`、`^` 或 `$` 符號，因為它們不是必需的。
|
||||
這些模式是不區分大小寫的，這與 Gitea 中套件註冊表的行為相匹配。
|
||||
|
||||
| 模式 | 描述 |
|
||||
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------- |
|
||||
| `.*` | 匹配所有可能的版本。 |
|
||||
| `v.+` | 匹配以 `v` 開頭的版本。 |
|
||||
| `release` | 只匹配版本 `release`。 |
|
||||
| `release.*` | 匹配命名為或以 `release` 開頭的版本。 |
|
||||
| `.+-temp-.+` | 匹配包含 `-temp-` 的版本。 |
|
||||
| `v.+\|release` | 匹配以 `v` 開頭的版本或命名為 `release` 的版本。 |
|
||||
| `package/v.+\|other/release` | 匹配套件 `package` 的以 `v` 開頭的版本或套件 `other` 的版本 `release`。這需要啟用設置*將模式應用於完整的套件名稱*。 |
|
||||
|
||||
### 清理規則的工作原理
|
||||
|
||||
清理規則是[清理作業](../../administration/config-cheat-sheet.md#cron---cleanup-expired-packages-croncleanup_packages)的一部分，並定期運行。
|
||||
|
||||
清理規則：
|
||||
|
||||
1. 收集擁有者註冊表的所有套件類型的所有套件。
|
||||
2. 對於每個套件，它收集所有版本。
|
||||
3. 根據*保留最新的*值從列表中排除版本。
|
||||
4. 排除與*保留匹配的版本*值匹配的任何版本。
|
||||
5. 排除比*刪除早於的版本*值更新的版本。
|
||||
6. 排除與*刪除匹配的版本*值不匹配的任何版本。
|
||||
7. 刪除剩餘的版本。
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
date: "2023-01-10T00:00:00+00:00"
|
||||
slug: "swift"
|
||||
sidebar_position: 115
|
||||
---
|
||||
|
||||
# Swift 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Swift](https://www.swift.org/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Swift 套件註冊表，您需要使用 [swift](https://www.swift.org/getting-started/) 來消費和使用 HTTP 客戶端（如 `curl`）來發布套件。
|
||||
|
||||
## 配置套件註冊表
|
||||
|
||||
要註冊套件註冊表並提供憑證，請執行：
|
||||
|
||||
```shell
|
||||
swift package-registry set https://gitea.example.com/api/packages/{owner}/swift
|
||||
swift package-registry login https://gitea.example.com/api/packages/{owner}/swift --username {username} --password {password}
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| ---------- | ------------------------------------------------------------------------------------------------------------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `username` | 您的 Gitea 用戶名。 |
|
||||
| `password` | 您的 Gitea 密碼。如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。 |
|
||||
|
||||
登錄是可選的，僅在套件註冊表是私有時需要。
|
||||
|
||||
## 發布套件
|
||||
|
||||
首先，您需要打包套件的內容：
|
||||
|
||||
```shell
|
||||
swift package archive-source
|
||||
```
|
||||
|
||||
要發布套件，請執行 HTTP PUT 請求，請求體中包含套件內容。
|
||||
|
||||
```shell --user your_username:your_password_or_token \
|
||||
curl -X PUT --user {username}:{password} \
|
||||
-H "Accept: application/vnd.swift.registry.v1+json" \
|
||||
-F source-archive=@/path/to/package.zip \
|
||||
-F metadata={metadata} \
|
||||
https://gitea.example.com/api/packages/{owner}/swift/{scope}/{name}/{version}
|
||||
```
|
||||
|
||||
| 佔位符 | 描述 |
|
||||
| ---------- | ------------------------------------------------------------------------------------------------------------------- |
|
||||
| `username` | 您的 Gitea 用戶名。 |
|
||||
| `password` | 您的 Gitea 密碼。如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。 |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `scope` | 套件範圍。 |
|
||||
| `name` | 套件名稱。 |
|
||||
| `version` | 套件版本。 |
|
||||
| `metadata` | （可選）套件的元數據。JSON 編碼的 https://schema.org/SoftwareSourceCode 子集 |
|
||||
|
||||
如果已經存在同名同版本的套件，您不能發布該套件。您必須先刪除現有的套件。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ------------------------------------ |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件無效。 |
|
||||
| `409 Conflict` | 套件中已存在具有相同參數組合的文件。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝 Swift 套件，請在 `Package.swift` 文件的依賴項列表中添加：
|
||||
|
||||
```
|
||||
dependencies: [
|
||||
.package(id: "{scope}.{name}", from:"{version}")
|
||||
]
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| --------- | ---------- |
|
||||
| `scope` | 套件範圍。 |
|
||||
| `name` | 套件名稱。 |
|
||||
| `version` | 套件版本。 |
|
||||
|
||||
之後執行以下命令來安裝它：
|
||||
|
||||
```shell
|
||||
swift package resolve
|
||||
```
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
date: "2022-08-23T00:00:00+00:00"
|
||||
slug: "vagrant"
|
||||
sidebar_position: 120
|
||||
---
|
||||
|
||||
# Vagrant 套件註冊表
|
||||
|
||||
為您的用戶或組織發布 [Vagrant](https://www.vagrantup.com/) 套件。
|
||||
|
||||
## 需求
|
||||
|
||||
要使用 Vagrant 套件註冊表，您需要 [Vagrant](https://www.vagrantup.com/downloads) 和一個用於發送 HTTP 請求的工具，如 `curl`。
|
||||
|
||||
## 發布套件
|
||||
|
||||
通過執行 HTTP PUT 請求來發布 Vagrant box：
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/vagrant/{package_name}/{package_version}/{provider}.box
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| ----------------- | ------------------------------------------------------------------ |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
| `package_version` | 套件版本，符合 semver。 |
|
||||
| `provider` | [支持的提供者名稱](https://www.vagrantup.com/docs/providers)之一。 |
|
||||
|
||||
上傳 Hyper-V box 的範例：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/your/vagrant.box \
|
||||
https://gitea.example.com/api/packages/testuser/vagrant/test_system/1.0.0/hyperv.box
|
||||
```
|
||||
|
||||
如果您使用 2FA 或 OAuth，請使用 [個人訪問令牌](development/api-usage.md#authentication) 代替密碼。
|
||||
|
||||
如果已經存在同名、同版本和同提供者的 box，您不能發布該 box。您必須先刪除現有的套件。
|
||||
|
||||
服務器響應以下 HTTP 狀態碼。
|
||||
|
||||
| HTTP 狀態碼 | 含義 |
|
||||
| ----------------- | ------------------------------------ |
|
||||
| `201 Created` | 套件已發布。 |
|
||||
| `400 Bad Request` | 套件無效。 |
|
||||
| `409 Conflict` | 套件中已存在具有相同參數組合的文件。 |
|
||||
|
||||
## 安裝套件
|
||||
|
||||
要從套件註冊表中安裝 box，請執行以下命令：
|
||||
|
||||
```shell
|
||||
vagrant box add "https://gitea.example.com/api/packages/{owner}/vagrant/{package_name}"
|
||||
```
|
||||
|
||||
| 參數 | 描述 |
|
||||
| -------------- | -------------- |
|
||||
| `owner` | 套件的擁有者。 |
|
||||
| `package_name` | 套件名稱。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
vagrant box add "https://gitea.example.com/api/packages/testuser/vagrant/test_system"
|
||||
```
|
||||
|
||||
這將安裝套件的最新版本。要添加特定版本，請使用 `--box-version` 參數。
|
||||
如果註冊表是私有的，您可以在 `VAGRANT_CLOUD_TOKEN` 環境變量中傳遞您的 [個人訪問令牌](development/api-usage.md#authentication)。
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
vagrant box add
|
||||
```
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
date: "2021-12-13:10:10+08:00"
|
||||
slug: "permissions"
|
||||
sidebar_position: 14
|
||||
aliases:
|
||||
- /zh-tw/permissions
|
||||
---
|
||||
|
||||
# 權限
|
||||
|
||||
Gitea 支援倉庫的權限，以便您可以為不同的人提供不同的訪問權限。首先，我們需要了解 `單元`。
|
||||
|
||||
## 單元
|
||||
|
||||
在 Gitea 中，我們稱倉庫的子模塊為 `單元`。現在我們有以下可能的單元。
|
||||
|
||||
| 名稱 | 描述 | 權限 |
|
||||
| ---------- | ------------------------------- | --------- |
|
||||
| 代碼 | 訪問源代碼、文件、提交和分支。 | 讀取 寫入 |
|
||||
| 問題 | 組織錯誤報告、任務和里程碑。 | 讀取 寫入 |
|
||||
| 拉取請求 | 啟用拉取請求和代碼審查。 | 讀取 寫入 |
|
||||
| 發佈 | 跟蹤項目版本和下載。 | 讀取 寫入 |
|
||||
| 維基 | 與合作者編寫和共享文檔。 | 讀取 寫入 |
|
||||
| 外部維基 | 鏈接到外部維基 | 讀取 |
|
||||
| 外部跟蹤器 | 鏈接到外部問題跟蹤器 | 讀取 |
|
||||
| 項目 | 模板倉庫的 URL | 讀取 寫入 |
|
||||
| 包 | 與此倉庫鏈接的包 | 讀取 寫入 |
|
||||
| 操作 | 審查操作日誌或重新啟動/取消管道 | 讀取 寫入 |
|
||||
| 設置 | 管理倉庫 | 管理 |
|
||||
|
||||
有了不同的權限，人們可以對這些單元執行不同的操作。
|
||||
|
||||
| 名稱 | 讀取 | 寫入 | 管理 |
|
||||
| ---------- | -------------------------------- | ----------------------- | -------- |
|
||||
| 代碼 | 查看代碼樹、文件、提交、分支等。 | 推送代碼。 | - |
|
||||
| 問題 | 查看問題並創建新問題。 | 添加標籤、分配、關閉 | - |
|
||||
| 拉取請求 | 查看拉取請求並創建新拉取請求。 | 添加標籤、分配、關閉 | - |
|
||||
| 發佈 | 查看發佈並下載文件。 | 創建/編輯發佈 | - |
|
||||
| 維基 | 查看維基頁面。克隆維基倉庫。 | 創建/編輯維基頁面，推送 | - |
|
||||
| 外部維基 | 鏈接到外部維基 | - | - |
|
||||
| 外部跟蹤器 | 鏈接到外部問題跟蹤器 | - | - |
|
||||
| 項目 | 查看項目的列 | 更改列中的問題 | - |
|
||||
| 包 | 查看包 | 上傳/刪除包 | - |
|
||||
| 操作 | 查看操作日誌 | 批准/取消/重新啟動 | - |
|
||||
| 設置 | - | - | 管理倉庫 |
|
||||
|
||||
個人倉庫和組織倉庫的權限之間存在一些差異。
|
||||
|
||||
## 個人倉庫
|
||||
|
||||
對於個人倉庫，創建者是倉庫的唯一所有者，對更改或刪除此倉庫沒有任何限制。倉庫所有者可以添加合作者來幫助維護倉庫。合作者可以具有 `讀取`、`寫入` 和 `管理` 權限。
|
||||
|
||||
對於私有倉庫，體驗類似於訪問匿名公共倉庫。您可以訪問倉庫中的所有可用內容，包括克隆代碼、創建問題、回應問題評論、提交拉取請求等。如果您具有“寫入”權限，則可以推送代碼到倉庫的特定分支，前提是分支保護規則允許。此外，您可以更改維基頁面。具有“管理”權限，您可以修改倉庫的設置。
|
||||
|
||||
但如果您不是該倉庫的所有者，則無法刪除或轉移此倉庫。
|
||||
|
||||
## 組織倉庫
|
||||
|
||||
對於個人倉庫，所有者是創建它的用戶。對於組織倉庫，所有者是該組織所有者團隊的成員。所有權限取決於團隊權限設置。
|
||||
|
||||
### 所有者團隊
|
||||
|
||||
創建組織時將創建所有者團隊，創建者將成為所有者團隊的第一個成員。所有者團隊不能被刪除，並且至少有一名成員。
|
||||
|
||||
### 管理員團隊
|
||||
|
||||
創建團隊時，有兩種類型的團隊。一個是管理員團隊，另一個是普通團隊。可以創建管理員團隊來管理一些倉庫，其成員可以對這些倉庫執行任何操作。只有所有者或管理員團隊的成員可以創建新團隊。
|
||||
|
||||
### 普通團隊
|
||||
|
||||
組織中的普通團隊具有單元權限設置。它可以有成員和倉庫範圍。
|
||||
|
||||
- 團隊可以訪問此組織中的所有倉庫或特殊倉庫。
|
||||
- 團隊還可以被允許創建新倉庫或不允許。
|
||||
|
||||
普通團隊可以創建以執行其權限允許的操作。一個成員可以加入多個團隊。
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
date: "2023-03-02T21:00:00+05:00"
|
||||
slug: "profile-readme"
|
||||
sidebar_position: 12
|
||||
---
|
||||
|
||||
# 個人資料 README
|
||||
|
||||
要在您的 Gitea 用戶或組織個人資料頁面中顯示 Markdown 文件，請創建一個名為 `.profile` 的倉庫，並添加一個名為 `README.md` 的新文件。
|
||||
Gitea 將自動在您的個人資料中顯示該文件的內容，在您的倉庫上方的新“概覽”中。
|
||||
|
||||
將 `.profile` 倉庫設為私有將隱藏個人資料 README。
|
||||
|
||||
具有 `.profile/README.md` 的用戶示例：
|
||||
|
||||
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
date: "2021-05-14T00:00:00-00:00"
|
||||
slug: "protected-tags"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-tw/protected-tags
|
||||
---
|
||||
|
||||
# 受保護標籤
|
||||
|
||||
受保護標籤允許控制誰有權創建或更新 Git 標籤。每個規則允許您匹配單個標籤名稱，或使用適當的模式來控制多個標籤。
|
||||
|
||||
## 設置受保護標籤
|
||||
|
||||
要保護標籤，您需要按照以下步驟操作：
|
||||
|
||||
1. 轉到倉庫的 **設置** > **標籤** 頁面。
|
||||
1. 輸入要匹配的名稱模式。您可以使用單個名稱、[glob 模式](https://pkg.go.dev/github.com/gobwas/glob#Compile) 或正則表達式。
|
||||
1. 選擇允許的用戶和/或團隊。如果您將這些字段留空，則沒有人可以創建或修改此標籤。
|
||||
1. 選擇 **保存** 以保存配置。
|
||||
|
||||
## 模式受保護標籤
|
||||
|
||||
該模式使用 [glob](https://pkg.go.dev/github.com/gobwas/glob#Compile) 或正則表達式來匹配標籤名稱。對於正則表達式，您需要將模式括在斜杠中。
|
||||
|
||||
示例：
|
||||
|
||||
| 類型 | 模式受保護標籤 | 可能匹配的標籤 |
|
||||
| ----- | ------------------------ | --------------------------------------- |
|
||||
| Glob | `v*` | `v`、`v-1`、`version2` |
|
||||
| Glob | `v[0-9]` | `v0`、`v1` 到 `v9` |
|
||||
| Glob | `*-release` | `2.1-release`、`final-release` |
|
||||
| Glob | `gitea` | 只有 `gitea` |
|
||||
| Glob | `*gitea*` | `gitea`、`2.1-gitea`、`1_gitea-release` |
|
||||
| Glob | `{v,rel}-*` | `v-`、`v-1`、`v-final`、`rel-`、`rel-x` |
|
||||
| Glob | `*` | 匹配所有可能的標籤名稱 |
|
||||
| Regex | `/\Av/` | `v`、`v-1`、`version2` |
|
||||
| Regex | `/\Av[0-9]\z/` | `v0`、`v1` 到 `v9` |
|
||||
| Regex | `/\Av\d+\.\d+\.\d+\z/` | `v1.0.17`、`v2.1.0` |
|
||||
| Regex | `/\Av\d+(\.\d+){0,2}\z/` | `v1`、`v2.1`、`v1.2.34` |
|
||||
| Regex | `/-release\z/` | `2.1-release`、`final-release` |
|
||||
| Regex | `/gitea/` | `gitea`、`2.1-gitea`、`1_gitea-release` |
|
||||
| Regex | `/\Agitea\z/` | 只有 `gitea` |
|
||||
| Regex | `/^gitea$/` | 只有 `gitea` |
|
||||
| Regex | `/\A(v\|rel)-/` | `v-`、`v-1`、`v-final`、`rel-`、`rel-x` |
|
||||
| Regex | `/.+/` | 匹配所有可能的標籤名稱 |
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
date: "2018-06-01T19:00:00+02:00"
|
||||
slug: "pull-request"
|
||||
sidebar_position: 13
|
||||
aliases:
|
||||
- /zh-tw/pull-request
|
||||
---
|
||||
|
||||
# 拉取請求
|
||||
|
||||
拉取請求（PR）是一種提議對倉庫進行更改的方法。
|
||||
它是一個請求，要求將一個分支合併到另一個分支，並附有對所做更改的描述。
|
||||
拉取請求通常用於貢獻者提議更改，並由維護者審查和合併這些更改。
|
||||
|
||||
## 創建拉取請求
|
||||
|
||||
要創建 PR，您需要按照以下步驟操作：
|
||||
|
||||
1. **分叉倉庫** - 如果您沒有直接更改倉庫的權限，您需要將倉庫分叉到自己的帳戶。
|
||||
這會創建一個您可以進行更改的倉庫副本。
|
||||
|
||||
2. **創建分支（可選）** - 在您的分叉倉庫中創建一個包含您要提議的更改的新分支。
|
||||
給分支起一個描述性名稱，表明更改的用途。
|
||||
|
||||
3. **進行更改** - 進行您想要的更改，提交並推送到您的分叉倉庫。
|
||||
|
||||
4. **創建 PR** - 轉到原始倉庫並轉到“拉取請求”選項卡。點擊“新建拉取請求”按鈕，選擇您的新分支作為源分支。
|
||||
為您的拉取請求輸入描述性標題和描述，然後點擊“創建拉取請求”。
|
||||
|
||||
## 審查拉取請求
|
||||
|
||||
創建 PR 後，會觸發審查過程。倉庫的維護者會收到 PR 的通知，並可以審查所做的更改。
|
||||
他們可以留下評論、請求更改或批准更改。
|
||||
|
||||
如果維護者請求更改，您需要在您的分支中進行這些更改，並將更改推送到您的分叉倉庫。
|
||||
PR 將自動更新為新更改。
|
||||
|
||||
如果維護者批准更改，他們可以將 PR 合併到倉庫中。
|
||||
|
||||
## 關閉拉取請求
|
||||
|
||||
如果您決定不再想合併 PR，您可以關閉它。
|
||||
要關閉 PR，請轉到打開的 PR，然後點擊“關閉拉取請求”按鈕。這將關閉 PR 而不合併它。
|
||||
|
||||
## “進行中”拉取請求
|
||||
|
||||
將拉取請求標記為進行中將防止該拉取請求被意外合併。
|
||||
要將拉取請求標記為進行中，您必須在其標題前加上 `WIP:` 或 `[WIP]`（不區分大小寫）。
|
||||
這些值可以在您的 `app.ini` 文件中配置：
|
||||
|
||||
```ini
|
||||
[repository.pull-request]
|
||||
WORK_IN_PROGRESS_PREFIXES=WIP:,[WIP]
|
||||
```
|
||||
|
||||
列表中的第一個值將用於幫助程序。
|
||||
|
||||
## 拉取請求模板
|
||||
|
||||
您可以在 [問題和拉取請求模板](usage/issue-pull-request-templates.md) 頁面找到有關拉取請求模板的更多信息。
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
date: "2020-07-06T16:00:00+02:00"
|
||||
slug: "push"
|
||||
sidebar_position: 15
|
||||
aliases:
|
||||
- /zh-tw/push-to-create
|
||||
- /zh-tw/push-options
|
||||
---
|
||||
|
||||
# 推送
|
||||
|
||||
將提交推送到 Gitea 服務器時，有一些附加功能。
|
||||
|
||||
## 通過推送打開 PR
|
||||
|
||||
當您第一次將提交推送到非默認分支時，
|
||||
您將收到一個鏈接，您可以點擊該鏈接訪問您的分支與主分支的比較頁面。
|
||||
從那裡，即使您想針對另一個分支，也可以輕鬆創建拉取請求。
|
||||
|
||||
|
||||
|
||||
## 推送選項
|
||||
|
||||
在 Gitea `1.13` 中，添加了對一些 [推送選項](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt) 的支持。
|
||||
|
||||
### 支持的選項
|
||||
|
||||
- `repo.private` (true|false) - 更改倉庫的可見性。
|
||||
|
||||
這在與推送創建結合使用時特別有用。
|
||||
|
||||
- `repo.template` (true|false) - 更改倉庫是否為模板。
|
||||
|
||||
將倉庫的可見性更改為公共的示例：
|
||||
|
||||
```shell
|
||||
git push -o repo.private=false -u origin main
|
||||
```
|
||||
|
||||
## 推送創建
|
||||
|
||||
推送創建是一個允許您推送到 Gitea 中尚不存在的倉庫的功能。這對於自動化和允許用戶創建倉庫而無需通過 Web 界面非常有用。此功能默認禁用。
|
||||
|
||||
### 啟用推送創建
|
||||
|
||||
在 `app.ini` 文件中，將 `ENABLE_PUSH_CREATE_USER` 設置為 `true`，如果您希望允許用戶在其自己的用戶帳戶中創建倉庫，並在他們是成員的組織中創建倉庫，則將 `ENABLE_PUSH_CREATE_ORG` 設置為 `true`。重新啟動 Gitea 以使更改生效。您可以在 [配置備忘單](../administration/config-cheat-sheet.md#repository-repository) 中閱讀有關這兩個選項的更多信息。
|
||||
|
||||
### 使用推送創建
|
||||
|
||||
假設您在當前目錄中有一個 git 倉庫，您可以通過運行以下命令推送到 Gitea 中尚不存在的倉庫：
|
||||
|
||||
```shell
|
||||
# 添加您要推送的遠程
|
||||
git remote add origin git@{domain}:{username}/{repo name that does not exist yet}.git
|
||||
|
||||
# 推送到遠程
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
這假設您使用的是 SSH 遠程，但您也可以使用 HTTPS 遠程。
|
||||
|
||||
推送創建將默認為 `app.ini` 中定義的 `DEFAULT_PUSH_CREATE_PRIVATE` 的可見性。
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user