docs: add zh-tw folder (#195)

Signed-off-by: appleboy <[email protected]>
Reviewed-on: https://gitea.com/gitea/docs/pulls/195
Reviewed-by: Lunny Xiao <[email protected]>
Co-authored-by: appleboy <[email protected]>
Co-committed-by: appleboy <[email protected]>
This commit is contained in:
appleboy
2025-04-04 23:28:16 +00:00
committed by Lunny Xiao
parent 3275094871
commit dbfa0ba454
835 changed files with 72590 additions and 5155 deletions
@@ -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 是個壞主意。
![network](/images/usage/actions/network.png)
圖片中標記了四個網絡連接,箭頭的方向表示建立連接的方向。
### 連接 1act runner 到 Gitea 實例
act runner 必須能夠連接到 Gitea 以接收任務並發送回執行結果。
### 連接 2,作業容器到 Gitea 實例
作業容器與 runner 有不同的網絡命名空間,即使它們在同一台機器上。
如果工作流程中有 `actions/checkout@v4`,它們需要連接到 Gitea 以獲取代碼。
運行某些作業並不總是需要獲取代碼,但在大多數情況下是必需的。
如果您使用回環地址註冊 runner,當它在同一台機器上時,runner 可以連接到 Gitea。
但是,如果作業容器嘗試從 localhost 獲取代碼,則會失敗,因為 Gitea 不在同一容器中。
### 連接 3act 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 的代理標籤和自定義標籤有什麼區別?
![labels](/images/usage/actions/labels.png)
代理標籤是在註冊期間由 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`.
![register runner](/images/usage/actions/register-runner.png)
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:
![view runner](/images/usage/actions/view-runner.png)
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`.
![enable actions](/images/usage/actions/enable-actions.png)
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.
![view job](/images/usage/actions/view-job.png)
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. 要導航到較舊的提交,點擊 ![versions](/octicon-versions.svg) 圖標。
## 在 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` 上運行的其他服務的潛在安全問題。
@@ -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 protected]
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
在具有不同類型問題(外部與內部)的倉庫之間的自動引用尚未完全支援,可能會渲染無效鏈接。
:::
@@ -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 <[email protected]>`
## 重新基準
在沒有合併提交的情況下重新基準,`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 APIGitea 需要訪問密鑰 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 憑據。
@@ -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:[email protected]/...`)。
## 發布套件
要發布套件,請執行 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:[email protected]/...`)。
## 發布套件
要發布 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/[email protected]
```
## 安裝套件
要從套件註冊表中安裝套件,請執行以下命令:
```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 [email protected] 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:[email protected]/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` 的用戶示例:
![個人資料 README 截圖](/images/usage/profile-readme.png)
@@ -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 推送提示](/gitea-push-hint.png)
## 推送選項
在 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` 的可見性。
@@ -0,0 +1,98 @@
---
date: "2021-05-13T00:00:00-00:00"
slug: "repo-mirror"
sidebar_position: 45
aliases:
- /zh-tw/repo-mirror
---
# 倉庫鏡像
倉庫鏡像允許將倉庫與外部來源進行鏡像。您可以使用它在倉庫之間鏡像分支、標籤和提交。
## 用例
以下是倉庫鏡像的一些可能用例:
- 您已遷移到 Gitea,但仍需要將項目保留在另一個來源中。在這種情況下,您可以簡單地設置為鏡像到 Gitea(拉取),所有提交、標籤和分支的歷史記錄都將在您的 Gitea 實例中可用。
- 您在另一個來源中有舊項目,您不再積極使用它們,但不想刪除以進行存檔。在這種情況下,您可以創建一個推送鏡像,以便您的活動 Gitea 倉庫可以將其更改推送到舊位置。
## 從遠程倉庫拉取
對於現有的遠程倉庫,您可以按以下步驟設置拉取鏡像:
1. 在右上角的 **創建...** 菜單中選擇 **新建遷移**
2. 選擇遠程倉庫服務。
3. 輸入倉庫 URL。
4. 如果倉庫需要身份驗證,請填寫您的身份驗證信息。
5. 勾選 **此倉庫將成為鏡像**
6. 選擇 **遷移倉庫** 以保存配置。
現在,倉庫將定期從遠程倉庫鏡像。您可以在倉庫設置中選擇 **立即同步** 來強制同步。
:::warning
:exclamation::exclamation: 您只能為尚不存在於您的實例中的倉庫設置拉取鏡像。一旦倉庫創建,您將無法將其轉換為拉取鏡像。 :exclamation::exclamation:
:::
## 推送到遠程倉庫
對於現有倉庫,您可以按以下步驟設置推送鏡像:
1. 在您的倉庫中,轉到 **設置** > **倉庫**,然後轉到 **鏡像設置** 部分。
2. 輸入倉庫 URL。
3. 如果倉庫需要身份驗證,請展開 **授權** 部分並填寫您的身份驗證信息。請注意,請求的 **密碼** 也可以是您的訪問令牌。
4. 選擇 **添加推送鏡像** 以保存配置。
現在,倉庫將定期鏡像到遠程倉庫。您可以選擇 **立即同步** 來強制同步。如果出現錯誤,將顯示一條消息以幫助您解決問題。
:::warning
:exclamation::exclamation: 這將強制推送到遠程倉庫。這將覆蓋遠程倉庫中的任何更改! :exclamation::exclamation:
:::
### 從 Gitea 到 GitHub 設置推送鏡像
要從 Gitea 設置到 GitHub 的鏡像,您需要按照以下步驟操作:
1. 創建一個 [GitHub 個人訪問令牌](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token),並勾選 _public_repo_ 框。如果您的倉庫使用 GitHub Actions 進行持續集成,還請勾選 **workflow** 框。
2. 在 GitHub 上創建一個具有該名稱的倉庫。與 Gitea 不同,GitHub 不支持通過推送創建倉庫。如果它具有與您的 Gitea 倉庫相同的提交歷史記錄,您也可以使用現有的遠程倉庫。
3. 在您的 Gitea 倉庫設置中,填寫 **Git 遠程倉庫 URL**`https://github.com/<your_github_group>/<your_github_project>.git`
4. 使用您的 GitHub 用戶名和個人訪問令牌作為 **密碼** 填寫 **授權** 字段。
5. (可選,適用於 Gitea 1.18+)選擇 `推送新提交時同步`,以便鏡像在有更改時也會更新。您也可以禁用定期同步。
6. 選擇 **添加推送鏡像** 以保存配置。
倉庫隨後會很快推送。要強制推送,選擇 **立即同步** 按鈕。
### 從 Gitea 到 GitLab 設置推送鏡像
要從 Gitea 設置到 GitLab 的鏡像,您需要按照以下步驟操作:
1. 創建一個 [GitLab 個人訪問令牌](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html),並勾選 _write_repository_ 範圍。
2. 填寫 **Git 遠程倉庫 URL**`https://<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`
3. 使用 `oauth2` 作為 **用戶名** 和您的 GitLab 個人訪問令牌作為 **密碼** 填寫 **授權** 字段。
4. 選擇 **添加推送鏡像** 以保存配置。
倉庫隨後會很快推送。要強制推送,選擇 **立即同步** 按鈕。
### 從 Gitea 到 Bitbucket 設置推送鏡像
要從 Gitea 設置到 Bitbucket 的鏡像,您需要按照以下步驟操作:
1. 創建一個 [Bitbucket 應用密碼](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/),並勾選 _Repository Write_ 框。
2. 填寫 **Git 遠程倉庫 URL**`https://bitbucket.org/<your_bitbucket_group_or_name>/<your_bitbucket_project>.git`
3. 使用您的 Bitbucket 用戶名和應用密碼作為 **密碼** 填寫 **授權** 字段。
4. 選擇 **添加推送鏡像** 以保存配置。
倉庫隨後會很快推送。要強制推送,選擇 **立即同步** 按鈕。
### 鏡像現有的 ssh 倉庫
目前 Gitea 不支持 ssh 推送鏡像。您可以通過向您的 Gitea 倉庫添加一個 `post-receive` 鉤子來手動推送來解決此問題。
1. 確保運行 Gitea 的用戶可以從 shell 訪問您嘗試鏡像到的 git 倉庫。
2. 在 Web 界面的倉庫設置 > git 鉤子中,為鏡像添加一個 post-receive 鉤子。例如:
```
#!/usr/bin/env bash
git push --mirror --quiet [email protected]:username/repository.git &>/dev/null &
echo "GitHub 鏡像已啟動 .."
```
@@ -0,0 +1,86 @@
---
date: "2019-11-28:00:00+02:00"
slug: "template-repositories"
sidebar_position: 14
aliases:
- /zh-tw/template-repositories
---
# 模板倉庫
自 Gitea `1.11` 起,您可以創建模板倉庫。
創建基於模板的倉庫時,您可以複製其大部分內容,甚至自動注入變量。
默認情況下,不會在任何文件中展開變量。
只有包含在 `.gitea/template` 文件中的模式內的文件才會被檢查是否包含變量。
創建模板時,除 `.gitea/template` 文件外,所有文件都包含在內。
Gitea 使用 [gobwas/glob](https://github.com/gobwas/glob) 進行其 glob 語法。
它與傳統的 `.gitignore` 非常相似,但可能存在細微差異。
## 示例 `.gitea/template` 文件
所有路徑均相對於倉庫的基礎
```gitignore
# 展開倉庫中任何位置的所有 .go 文件
**.go
# 文本目錄中的所有文本文件
text/*.txt
# 特定文件
a/b/c/d.json
# 大小寫均可匹配的批處理文件
**.[bB][aA][tT]
```
## 變量展開
在上述 glob 匹配的任何文件中,以下變量將被展開。
匹配的文件名和路徑也可以展開,並且經過保守的清理以支持跨平台文件系統。
您可以通過在變量前加上 `$` 或將其括在 `${}` 中來使用變量,因此 `$VAR``${VAR}` 都會在此位置插入 `VAR` 的值。
要轉義展開,請使用 `$$`,例如 `$$VAR``$${VAR}`
這些是 Gitea 目前識別的變量:
| 變量 | 展開為 | 可轉換 |
| -------------------- | -------------------------------- | ------ |
| YEAR | 生成倉庫的年份(即 `2024` | ✘ |
| MONTH | 生成倉庫的月份(即 `03` | ✘ |
| MONTH_ENGLISH | 月份,但用英文表示(即 `March` | ✓ |
| DAY | 生成倉庫的日期(即 `02` | ✘ |
| REPO_NAME | 生成倉庫的名稱 | ✓ |
| TEMPLATE_NAME | 模板倉庫的名稱 | ✓ |
| REPO_DESCRIPTION | 生成倉庫的描述 | ✘ |
| TEMPLATE_DESCRIPTION | 模板倉庫的描述 | ✘ |
| REPO_OWNER | 生成倉庫的所有者 | ✓ |
| TEMPLATE_OWNER | 模板倉庫的所有者 | ✓ |
| REPO_LINK | 生成倉庫的 URL | ✘ |
| TEMPLATE_LINK | 模板倉庫的 URL | ✘ |
| REPO_HTTPS_URL | 生成倉庫的 HTTP(S) 克隆鏈接 | ✘ |
| TEMPLATE_HTTPS_URL | 模板倉庫的 HTTP(S) 克隆鏈接 | ✘ |
| REPO_SSH_URL | 生成倉庫的 SSH 克隆鏈接 | ✘ |
| TEMPLATE_SSH_URL | 模板倉庫的 SSH 克隆鏈接 | ✘ |
## 轉換器 :robot:
自 Gitea `1.12.0` 起,表中標記為可轉換的變量還具有應用了給定轉換器的替代版本。
可以通過將轉換器名稱附加到變量名稱來調用轉換後的變量。
例如,要獲取 `PASCAL` 大小寫的 `REPO_NAME`,您應該使用變量 `${REPO_NAME_PASCAL}`
以下是可用的轉換器(假設輸入為 `go-sdk`):
| 轉換器 | 效果 |
| ------ | ------ |
| SNAKE | go_sdk |
| KEBAB | go-sdk |
| CAMEL | goSdk |
| PASCAL | GoSdk |
| LOWER | go-sdk |
| UPPER | GO-SDK |
| TITLE | Go-Sdk |
@@ -0,0 +1,187 @@
---
date: "2016-12-01T16:00:00+02:00"
slug: "webhooks"
sidebar_position: 30
aliases:
- /zh-tw/webhooks
---
# Webhooks
Gitea 支援倉庫事件的 webhooks。這可以由倉庫管理員在設置頁面 `/:username/:reponame/settings/hooks` 中配置。webhooks 也可以在每個組織和整個系統範圍內配置。
所有事件推送都是 POST 請求。目前支持的方法有:
- Gitea(也可以是 GET 請求)
- Gogs
- Slack
- Discord
- Dingtalk
- Telegram
- Microsoft Teams
- Feishu
- Wechatwork
- Packagist
### 事件信息
:::warning
自 Gitea 1.13.0 起,payload 中的 `secret` 字段已棄用,並將在 1.14.0 中刪除:https://github.com/go-gitea/gitea/issues/11755
:::
以下是 Gitea 將發送到 Payload URL 的事件信息示例:
```http
X-GitHub-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
X-GitHub-Event: push
X-Gogs-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
X-Gogs-Event: push
X-Gitea-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
X-Gitea-Event: push
```
```json
{
"secret": "3gEsCfjlV2ugRwgpU#w1*WaW*wa4NXgGmpCfkbG3",
"ref": "refs/heads/develop",
"before": "28e1879d029cb852e4844d9c718537df08844e03",
"after": "bffeb74224043ba2feb48d137756c8a9331c449a",
"compare_url": "http://localhost:3000/gitea/webhooks/compare/28e1879d029cb852e4844d9c718537df08844e03...bffeb74224043ba2feb48d137756c8a9331c449a",
"commits": [
{
"id": "bffeb74224043ba2feb48d137756c8a9331c449a",
"message": "Webhooks Yay!",
"url": "http://localhost:3000/gitea/webhooks/commit/bffeb74224043ba2feb48d137756c8a9331c449a",
"author": {
"name": "Gitea",
"email": "[email protected]",
"username": "gitea"
},
"committer": {
"name": "Gitea",
"email": "[email protected]",
"username": "gitea"
},
"timestamp": "2017-03-13T13:52:11-04:00"
}
],
"repository": {
"id": 140,
"owner": {
"id": 1,
"login": "gitea",
"full_name": "Gitea",
"email": "[email protected]",
"avatar_url": "https://localhost:3000/avatars/1",
"username": "gitea"
},
"name": "webhooks",
"full_name": "gitea/webhooks",
"description": "",
"private": false,
"fork": false,
"html_url": "http://localhost:3000/gitea/webhooks",
"ssh_url": "ssh://gitea@localhost:2222/gitea/webhooks.git",
"clone_url": "http://localhost:3000/gitea/webhooks.git",
"website": "",
"stars_count": 0,
"forks_count": 1,
"watchers_count": 1,
"open_issues_count": 7,
"default_branch": "master",
"created_at": "2017-02-26T04:29:06-05:00",
"updated_at": "2017-03-13T13:51:58-04:00"
},
"pusher": {
"id": 1,
"login": "gitea",
"full_name": "Gitea",
"email": "[email protected]",
"avatar_url": "https://localhost:3000/avatars/1",
"username": "gitea"
},
"sender": {
"id": 1,
"login": "gitea",
"full_name": "Gitea",
"email": "[email protected]",
"avatar_url": "https://localhost:3000/avatars/1",
"username": "gitea"
}
}
```
### 示例
這是一個如何使用 webhooks 在推送請求到倉庫時運行 php 腳本的示例。
在您的倉庫設置中,webhooks 下,設置一個 Gitea webhook,如下所示:
- 目標 URL: http://mydomain.com/webhook.php
- HTTP 方法: POST
- POST 內容類型: application/json
- Secret: 123
- 觸發事件: 推送事件
- 活躍: 已勾選
現在在您的服務器上創建 php 文件 webhook.php
```php
<?php
$secret_key = '123';
// 檢查是否為 POST 請求
if ($_SERVER['REQUEST_METHOD'] != 'POST') {
error_log('FAILED - not POST - '. $_SERVER['REQUEST_METHOD']);
exit();
}
// 獲取內容類型
$content_type = isset($_SERVER['CONTENT_TYPE']) ? strtolower(trim($_SERVER['CONTENT_TYPE'])) : '';
if ($content_type != 'application/json') {
error_log('FAILED - not application/json - '. $content_type);
exit();
}
// 獲取 payload
$payload = trim(file_get_contents("php://input"));
if (empty($payload)) {
error_log('FAILED - no payload');
exit();
}
// 獲取標頭簽名
$header_signature = isset($_SERVER['HTTP_X_GITEA_SIGNATURE']) ? $_SERVER['HTTP_X_GITEA_SIGNATURE'] : '';
if (empty($header_signature)) {
error_log('FAILED - header signature missing');
exit();
}
// 計算 payload 簽名
$payload_signature = hash_hmac('sha256', $payload, $secret_key, false);
// 檢查 payload 簽名與標頭簽名是否匹配
if ($header_signature !== $payload_signature) {
error_log('FAILED - payload signature');
exit();
}
// 將 json 轉換為數組
$decoded = json_decode($payload, true);
// 檢查 json 解碼錯誤
if (json_last_error() !== JSON_ERROR_NONE) {
error_log('FAILED - json decode - '. json_last_error());
exit();
}
// 成功,執行操作
```
webhook 設置中有一個測試傳遞按鈕,允許測試配置以及最近傳遞的列表。
### 授權標頭
**從 1.19 開始**Gitea hooks 可以配置為向 webhook 目標發送 [授權標頭](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization)。