mirror of
https://gitea.com/gitea/docs.git
synced 2026-06-11 12:41:27 +00:00
Remove outdated versions and keep the latest 5 versions(include the current developing version and latest 4 stable versions (#304)
Resolve #302 Reviewed-on: https://gitea.com/gitea/docs/pulls/304 Reviewed-by: delvh <dev.lh@web.de>
This commit is contained in:
Lunny Xiao
@@ -21,7 +21,7 @@ jobs:
|
||||
pip install awscli
|
||||
- name: prepare awesome list
|
||||
run: |
|
||||
make prepare-awesome-latest prepare-awesome\#23 prepare-awesome\#22 prepare-awesome\#21 prepare-awesome\#20 prepare-awesome\#19
|
||||
make prepare-awesome-latest prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22
|
||||
- name: Cache ~/.npm for npm ci
|
||||
uses: actions/cache@v4
|
||||
with:
|
||||
|
||||
@@ -14,7 +14,7 @@ jobs:
|
||||
cache: npm
|
||||
- name: prepare awesome list
|
||||
run: |
|
||||
make prepare-awesome-latest prepare-awesome\#23 prepare-awesome\#22 prepare-awesome\#21 prepare-awesome\#20 prepare-awesome\#19
|
||||
make prepare-awesome-latest prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22
|
||||
- name: Cache ~/.npm for npm ci
|
||||
uses: actions/cache@v4
|
||||
with:
|
||||
|
||||
@@ -16,13 +16,10 @@ jobs:
|
||||
sed -i "$@" 's\"basePath": "{{AppSubUrl | JSEscape}}/api/v1"\"basePath": "https://gitea.com/api/v1"\' v1_json.tmpl
|
||||
mv v1_json.tmpl static/swagger-latest.json
|
||||
|
||||
for ver in '1.24.7' '1.23.8' '1.22.6' '1.21.11' '1.20.6' '1.19.4'; do
|
||||
for ver in '1.25.1' '1.24.7' '1.23.8' '1.22.6'; do
|
||||
wget https://raw.githubusercontent.com/go-gitea/gitea/refs/tags/v${ver}/templates/swagger/v1_json.tmpl
|
||||
sed -i "$@" "s|\"version\": \"{{AppVer \| JSEscape}}\"|\"version\": \"${ver}\"|" v1_json.tmpl
|
||||
sed -i "$@" 's\"basePath": "{{AppSubUrl | JSEscape}}/api/v1"\"basePath": "https://gitea.com/api/v1"\' v1_json.tmpl
|
||||
# for version < 1.21.11
|
||||
sed -i "$@" "s|\"version\": \"{{AppVer \| JSEscape \| Safe}}\"|\"version\": \"${ver}\"|" v1_json.tmpl
|
||||
sed -i "$@" 's\"basePath": "{{AppSubUrl | JSEscape | Safe}}/api/v1"\"basePath": "https://gitea.com/api/v1"\' v1_json.tmpl
|
||||
minor=$(echo "$ver" | cut -d '.' -f 2)
|
||||
mv v1_json.tmpl static/swagger-$minor.json
|
||||
done
|
||||
|
||||
@@ -47,18 +47,6 @@ const apiConfig = [
|
||||
route: "/api/1.22/",
|
||||
spec: "static/swagger-22.json",
|
||||
},
|
||||
{
|
||||
route: "/api/1.21/",
|
||||
spec: "static/swagger-21.json",
|
||||
},
|
||||
{
|
||||
route: "/api/1.20/",
|
||||
spec: "static/swagger-20.json",
|
||||
},
|
||||
{
|
||||
route: "/api/1.19/",
|
||||
spec: "static/swagger-19.json",
|
||||
},
|
||||
]
|
||||
: [],
|
||||
// Theme Options for modifying how redoc renders them
|
||||
@@ -126,36 +114,6 @@ const globalVariables = {
|
||||
dockerVersion: "1.22.6",
|
||||
displayVersion: "1.22.6",
|
||||
},
|
||||
"1.21": {
|
||||
goVersion: "1.21",
|
||||
minGoVersion: "1.21",
|
||||
minNodeVersion: "18",
|
||||
version: "1.21.11",
|
||||
sourceVersion: "v1.21.11",
|
||||
sourceBranch: "release/v1.21",
|
||||
dockerVersion: "1.21.11",
|
||||
displayVersion: "1.21.11",
|
||||
},
|
||||
"1.20": {
|
||||
goVersion: "1.20",
|
||||
minGoVersion: "1.20",
|
||||
minNodeVersion: "16",
|
||||
version: "1.20.6",
|
||||
sourceVersion: "v1.20.6",
|
||||
sourceBranch: "release/v1.20",
|
||||
dockerVersion: "1.20.6",
|
||||
displayVersion: "1.20.6",
|
||||
},
|
||||
"1.19": {
|
||||
goVersion: "1.20",
|
||||
minGoVersion: "1.19",
|
||||
minNodeVersion: "14",
|
||||
version: "1.19.4",
|
||||
sourceVersion: "v1.19.4",
|
||||
sourceBranch: "release/v1.19",
|
||||
dockerVersion: "1.19.4",
|
||||
displayVersion: "1.19.4",
|
||||
},
|
||||
};
|
||||
|
||||
const versions = {
|
||||
@@ -175,15 +133,6 @@ const versions = {
|
||||
"1.22": {
|
||||
label: globalVariables["1.22"].displayVersion,
|
||||
},
|
||||
"1.21": {
|
||||
label: globalVariables["1.21"].displayVersion,
|
||||
},
|
||||
"1.20": {
|
||||
label: globalVariables["1.20"].displayVersion,
|
||||
},
|
||||
"1.19": {
|
||||
label: globalVariables["1.19"].displayVersion,
|
||||
},
|
||||
};
|
||||
|
||||
/** @type {import('@docusaurus/types').Config} */
|
||||
@@ -413,7 +362,7 @@ const config = {
|
||||
to: "/api/1.25/",
|
||||
label: "API",
|
||||
position: "left",
|
||||
activeBaseRegex: "api/(1.19|1.20|1.21|1.22|1.23|1.24|1.25|next)/",
|
||||
activeBaseRegex: "api/(1.22|1.23|1.24|1.25|next)/",
|
||||
},
|
||||
{
|
||||
to: "/runner/0.2.11/",
|
||||
@@ -446,13 +395,11 @@ const config = {
|
||||
label: "API Version",
|
||||
position: "right",
|
||||
items: [
|
||||
{ to: "/api/next/", label: "1.25-dev" },
|
||||
{ to: "/api/next/", label: "1.26-dev" },
|
||||
{ to: "/api/1.25/", label: "1.25.1" },
|
||||
{ to: "/api/1.24/", label: "1.24.7" },
|
||||
{ to: "/api/1.23/", label: "1.23.8" },
|
||||
{ to: "/api/1.22/", label: "1.22.6" },
|
||||
{ to: "/api/1.21/", label: "1.21.11" },
|
||||
{ to: "/api/1.20/", label: "1.20.6" },
|
||||
{ to: "/api/1.19/", label: "1.19.4" },
|
||||
],
|
||||
routerRgx: "/api/",
|
||||
classNames: "api-dropdown",
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
title: "运维"
|
||||
slug: "administration"
|
||||
sidebar_position: 30
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "运维"
|
||||
sidebar_position: 20
|
||||
identifier: "administration"
|
||||
---
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: adding-legal-pages
|
||||
sidebar_position: 110
|
||||
aliases:
|
||||
- /zh-cn/adding-legal-pages
|
||||
---
|
||||
|
||||
# 添加法律页面
|
||||
|
||||
一些法域（例如欧盟）要求在网站上添加特定的法律页面（例如隐私政策）。按照以下步骤将它们添加到你的 Gitea 实例中。
|
||||
|
||||
## 获取页面
|
||||
|
||||
Gitea 源代码附带了示例页面，位于 `contrib/legal` 目录中。将它们复制到 `custom/public/` 目录下。例如，如果要添加隐私政策：
|
||||
|
||||
```
|
||||
wget -O /path/to/custom/public/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/legal/privacy.html.sample
|
||||
```
|
||||
|
||||
现在，你需要编辑该页面以满足你的需求。特别是，你必须更改电子邮件地址、网址以及与 "Your Gitea Instance" 相关的引用，以匹配你的情况。
|
||||
|
||||
请务必不要放置会暗示 Gitea 项目对你的服务器负责的一般服务条款或隐私声明。
|
||||
|
||||
## 使其可见
|
||||
|
||||
创建或追加到 `/path/to/custom/templates/custom/extra_links_footer.tmpl` 文件中：
|
||||
|
||||
```go
|
||||
<a class="item" href="{{AppSubUrl}}/assets/privacy.html">隐私政策</a>
|
||||
```
|
||||
|
||||
重启 Gitea 以查看更改。
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "authentication"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# 认证
|
||||
|
||||
## 反向代理认证
|
||||
|
||||
Gitea 支持通过读取反向代理传递的 HTTP 头中的登录名或者 email 地址来支持反向代理来认证。默认是不启用的，你可以用以下配置启用。
|
||||
|
||||
```ini
|
||||
[service]
|
||||
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
|
||||
```
|
||||
|
||||
默认的登录用户名的 HTTP 头是 `X-WEBAUTH-USER`，你可以通过修改 `REVERSE_PROXY_AUTHENTICATION_USER` 来变更它。如果用户不存在，可以自动创建用户，当然你需要修改 `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true` 来启用它。
|
||||
|
||||
默认的登录用户 Email 的 HTTP 头是 `X-WEBAUTH-EMAIL`，你可以通过修改 `REVERSE_PROXY_AUTHENTICATION_EMAIL` 来变更它。如果用户不存在，可以自动创建用户，当然你需要修改 `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true` 来启用它。你也可以通过修改 `ENABLE_REVERSE_PROXY_EMAIL` 来启用或停用这个 HTTP 头。
|
||||
|
||||
如果设置了 `ENABLE_REVERSE_PROXY_FULL_NAME=true`，则用户的全名会从 `X-WEBAUTH-FULLNAME` 读取，这样在自动创建用户时将使用这个字段作为用户全名，你也可以通过修改 `REVERSE_PROXY_AUTHENTICATION_FULL_NAME` 来变更 HTTP 头。
|
||||
|
||||
你也可以通过修改 `REVERSE_PROXY_TRUSTED_PROXIES` 来设置反向代理的IP地址范围，加强安全性，默认值是 `127.0.0.0/8,::1/128`。 通过 `REVERSE_PROXY_LIMIT`， 可以设置最多信任几级反向代理。
|
||||
|
||||
注意：反向代理认证不支持认证 API，API 仍旧需要用 access token 来进行认证。
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
date: "2018-06-06T09:33:00+08:00"
|
||||
slug: "backup-and-restore"
|
||||
sidebar_position: 11
|
||||
---
|
||||
|
||||
# 备份与恢复
|
||||
|
||||
Gitea 已经实现了 `dump` 命令可以用来备份所有需要的文件到一个zip压缩文件。该压缩文件可以被用来进行数据恢复。
|
||||
|
||||
## 备份命令 (`dump`)
|
||||
|
||||
先转到git用户的权限: `su git`. 再Gitea目录运行 `./gitea dump`。一般会显示类似如下的输出：
|
||||
|
||||
```
|
||||
2016/12/27 22:32:09 Creating tmp work dir: /tmp/gitea-dump-417443001
|
||||
2016/12/27 22:32:09 Dumping local repositories.../home/git/gitea-repositories
|
||||
2016/12/27 22:32:22 Dumping database...
|
||||
2016/12/27 22:32:22 Packing dump files...
|
||||
2016/12/27 22:32:34 Removing tmp work dir: /tmp/gitea-dump-417443001
|
||||
2016/12/27 22:32:34 Finish dumping in file gitea-dump-1482906742.zip
|
||||
```
|
||||
|
||||
最后生成的 `gitea-dump-1482906742.zip` 文件将会包含如下内容：
|
||||
|
||||
* `custom` - 所有保存在 `custom/` 目录下的配置和自定义的文件。
|
||||
* `data` - 数据目录下的所有内容不包含使用文件session的文件。该目录包含 `attachments`, `avatars`, `lfs`, `indexers`, 如果使用sqlite 还会包含 sqlite 数据库文件。
|
||||
* `gitea-db.sql` - 数据库dump出来的 SQL。
|
||||
* `gitea-repo.zip` - Git仓库压缩文件。
|
||||
* `log/` - Logs文件，如果用作迁移不是必须的。
|
||||
|
||||
中间备份文件将会在临时目录进行创建，如果您要重新指定临时目录，可以用 `--tempdir` 参数，或者用 `TMPDIR` 环境变量。
|
||||
|
||||
## Restore Command (`restore`)
|
||||
|
||||
当前还没有恢复命令，恢复需要人工进行。主要是把文件和数据库进行恢复。
|
||||
|
||||
例如：
|
||||
|
||||
```sh
|
||||
unzip gitea-dump-1610949662.zip
|
||||
cd gitea-dump-1610949662
|
||||
mv data/conf/app.ini /etc/gitea/conf/app.ini
|
||||
mv data/* /var/lib/gitea/data/
|
||||
mv log/* /var/lib/gitea/log/
|
||||
mv repos/* /var/lib/gitea/repositories/
|
||||
chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea
|
||||
|
||||
# mysql
|
||||
mysql --default-character-set=utf8mb4 -u$USER -p$PASS $DATABASE <gitea-db.sql
|
||||
# sqlite3
|
||||
sqlite3 $DATABASE_PATH <gitea-db.sql
|
||||
# postgres
|
||||
psql -U $USER -d $DATABASE < gitea-db.sql
|
||||
|
||||
service gitea restart
|
||||
```
|
||||
@@ -1,92 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "cmd-embedded"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-cn/cmd-embedded
|
||||
---
|
||||
|
||||
# 嵌入资源提取工具
|
||||
|
||||
Gitea 的可执行文件包含了运行所需的所有资源：模板、图片、样式表和翻译文件。你可以通过在 `custom` 目录下的相应路径中放置替换文件来覆盖其中的任何资源（详见 [自定义 Gitea 配置](../administration/customizing-gitea.md)）。
|
||||
|
||||
要获取嵌入资源的副本以进行编辑，可以使用 CLI 中的 `embedded` 命令，通过操作系统的 shell 执行。
|
||||
|
||||
**注意：** 嵌入资源提取工具包含在 Gitea 1.12 及以上版本中。
|
||||
|
||||
## 资源列表
|
||||
|
||||
要列出嵌入在 Gitea 可执行文件中的资源，请使用以下语法：
|
||||
|
||||
```sh
|
||||
gitea embedded list [--include-vendored] [patterns...]
|
||||
```
|
||||
|
||||
`--include-vendored` 标志使命令包括被供应的文件，这些文件通常被排除在外；即来自外部库的文件，这些文件是 Gitea 所需的（例如 [octicons](https://octicons.github.com/) 等）。
|
||||
|
||||
可以提供一系列文件搜索模式。Gitea 使用 [gobwas/glob](https://github.com/gobwas/glob) 作为其 glob 语法。以下是一些示例：
|
||||
|
||||
- 列出所有模板文件，无论在哪个虚拟目录下：`**.tmpl`
|
||||
- 列出所有邮件模板文件：`templates/mail/**.tmpl`
|
||||
- 列出 `public/img` 目录下的所有文件：`public/img/**`
|
||||
|
||||
不要忘记为模式使用引号，因为空格、`*` 和其他字符可能对命令行解释器有特殊含义。
|
||||
|
||||
如果未提供模式，则列出所有文件。
|
||||
|
||||
### 示例
|
||||
|
||||
列出所有路径中包含 `openid` 的嵌入文件：
|
||||
|
||||
```sh
|
||||
$ gitea embedded list '**openid**'
|
||||
public/img/auth/openid_connect.svg
|
||||
public/img/openid-16x16.png
|
||||
templates/user/auth/finalize_openid.tmpl
|
||||
templates/user/auth/signin_openid.tmpl
|
||||
templates/user/auth/signup_openid_connect.tmpl
|
||||
templates/user/auth/signup_openid_navbar.tmpl
|
||||
templates/user/auth/signup_openid_register.tmpl
|
||||
templates/user/settings/security_openid.tmpl
|
||||
```
|
||||
|
||||
## 提取资源
|
||||
|
||||
要提取嵌入在 Gitea 可执行文件中的资源，请使用以下语法：
|
||||
|
||||
```sh
|
||||
gitea [--config {file}] embedded extract [--destination {dir}|--custom] [--overwrite|--rename] [--include-vendored] {patterns...}
|
||||
```
|
||||
|
||||
`--config` 选项用于告知 Gitea `app.ini` 配置文件的位置（如果不在默认位置）。此选项仅在使用 `--custom` 标志时使用。
|
||||
|
||||
`--destination` 选项用于指定提取文件的目标目录。默认为当前目录。
|
||||
|
||||
`--custom` 标志告知 Gitea 直接将文件提取到 `custom` 目录中。为使其正常工作，该命令需要知道 `app.ini` 配置文件的位置（通过 `--config` 指定），并且根据配置的不同，需要从 Gitea 通常启动的目录运行。有关详细信息，请参阅 [自定义 Gitea 配置](../administration/customizing-gitea.md)。
|
||||
|
||||
`--overwrite` 标志允许覆盖目标目录中的任何现有文件。
|
||||
|
||||
`--rename` 标志告知 Gitea 将目标目录中的任何现有文件重命名为 `filename.bak`。之前的 `.bak` 文件将被覆盖。
|
||||
|
||||
至少需要提供一个文件搜索模式；有关模式的语法和示例，请参阅上述 `list` 子命令。
|
||||
|
||||
### 重要提示
|
||||
|
||||
请确保**只提取需要自定义的文件**。位于 `custom` 目录中的文件不会受到 Gitea 的升级过程的影响。当 Gitea 升级到新版本（通过替换可执行文件）时，许多嵌入文件将发生变化。Gitea 将尊重并使用在 `custom` 目录中找到的任何文件，即使这些文件是旧的和不兼容的。
|
||||
|
||||
### 示例
|
||||
|
||||
将邮件模板提取到临时目录：
|
||||
|
||||
```sh
|
||||
$ mkdir tempdir
|
||||
$ gitea embedded extract --destination tempdir 'templates/mail/**.tmpl'
|
||||
Extracting to tempdir:
|
||||
tempdir/templates/mail/auth/activate.tmpl
|
||||
tempdir/templates/mail/auth/activate_email.tmpl
|
||||
tempdir/templates/mail/auth/register_notify.tmpl
|
||||
tempdir/templates/mail/auth/reset_passwd.tmpl
|
||||
tempdir/templates/mail/issue/assigned.tmpl
|
||||
tempdir/templates/mail/issue/default.tmpl
|
||||
tempdir/templates/mail/notify/collaborator.tmpl
|
||||
```
|
||||
@@ -1,543 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "command-line"
|
||||
sidebar_position: 1
|
||||
aliases:
|
||||
- /zh-cn/command-line
|
||||
---
|
||||
|
||||
# 命令行
|
||||
|
||||
## 用法
|
||||
|
||||
`gitea [全局选项] 命令 [命令或全局选项] [参数...]`
|
||||
|
||||
## 全局选项
|
||||
|
||||
所有全局选项均可被放置在命令级别。
|
||||
|
||||
- `--help`，`-h`：显示帮助文本并退出。可选。
|
||||
- `--version`，`-v`：显示版本信息并退出。可选。 (示例：`Gitea version 1.1.0+218-g7b907ed built with: bindata, sqlite`)。
|
||||
- `--custom-path path`，`-C path`：Gitea 自定义文件夹的路径。可选。 (默认值：`AppWorkPath`/custom 或 `$GITEA_CUSTOM`)。
|
||||
- `--config path`，`-c path`：Gitea 配置文件的路径。可选。 (默认值：`custom`/conf/app.ini)。
|
||||
- `--work-path path`，`-w path`：Gitea 的 `AppWorkPath`。可选。 (默认值：LOCATION_OF_GITEA_BINARY 或 `$GITEA_WORK_DIR`)
|
||||
|
||||
注意：默认的 custom-path、config 和 work-path 也可以在构建时更改（如果需要）。
|
||||
|
||||
## 命令
|
||||
|
||||
### web
|
||||
|
||||
启动服务器：
|
||||
|
||||
- 选项：
|
||||
- `--port number`，`-p number`：端口号。可选。 (默认值：3000)。覆盖配置文件中的设置。
|
||||
- `--install-port number`：运行安装页面的端口号。可选。 (默认值：3000)。覆盖配置文件中的设置。
|
||||
- `--pid path`，`-P path`：Pid 文件的路径。可选。
|
||||
- `--quiet`，`-q`：只在控制台上输出 Fatal 日志，用于在设置日志之前发出的日志。
|
||||
- `--verbose`：在控制台上输出跟踪日志，用于在设置日志之前发出的日志。
|
||||
- 示例：
|
||||
- `gitea web`
|
||||
- `gitea web --port 80`
|
||||
- `gitea web --config /etc/gitea.ini --pid /some/custom/gitea.pid`
|
||||
- 注意：
|
||||
- Gitea 不应以 root 用户身份运行。要绑定到低于 1024 的端口，您可以在 Linux 上使用 setcap 命令：`sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`。每次更新 Gitea 都需要重新执行此操作。
|
||||
|
||||
### admin
|
||||
|
||||
管理员操作：
|
||||
|
||||
- 命令：
|
||||
- `user`：
|
||||
- `list`：
|
||||
- 选项：
|
||||
- `--admin`：仅列出管理员用户。可选。
|
||||
- 描述：列出所有现有用户。
|
||||
- 示例：
|
||||
- `gitea admin user list`
|
||||
- `delete`：
|
||||
- 选项：
|
||||
- `--email`：要删除的用户的电子邮件。
|
||||
- `--username`：要删除的用户的用户名。
|
||||
- `--id`：要删除的用户的 ID。
|
||||
- 必须提供 `--id`、`--username` 或 `--email` 中的一个。如果提供多个，则所有条件必须匹配。
|
||||
- 示例：
|
||||
- `gitea admin user delete --id 1`
|
||||
- `create`：
|
||||
- 选项：
|
||||
- `--name value`：用户名。必填。自 Gitea 1.9.0 版本起，请改用 `--username` 标志。
|
||||
- `--username value`：用户名。必填。Gitea 1.9.0 新增。
|
||||
- `--password value`：密码。必填。
|
||||
- `--email value`：邮箱。必填。
|
||||
- `--admin`：如果提供此选项，将创建一个管理员用户。可选。
|
||||
- `--access-token`：如果提供，将为用户创建访问令牌。可选。（默认值：false）。
|
||||
- `--must-change-password`：如果提供，创建的用户将在初始登录后需要选择一个新密码。可选。（默认值：true）。
|
||||
- `--random-password`：如果提供，将使用随机生成的密码作为创建用户的密码。`--password` 的值将被忽略。可选。
|
||||
- `--random-password-length`：如果提供，将用于配置随机生成密码的长度。可选。（默认值：12）
|
||||
- 示例：
|
||||
- `gitea admin user create --username myname --password asecurepassword --email me@example.com`
|
||||
- `change-password`：
|
||||
- 选项：
|
||||
- `--username value`，`-u value`：用户名。必填。
|
||||
- `--password value`，`-p value`：新密码。必填。
|
||||
- 示例：
|
||||
- `gitea admin user change-password --username myname --password asecurepassword`
|
||||
- `must-change-password`：
|
||||
- 参数：
|
||||
- `[username...]`：需要更改密码的用户
|
||||
- 选项：
|
||||
- `--all`，`-A`：强制所有用户更改密码
|
||||
- `--exclude username`，`-e username`：排除给定的用户。可以多次设置。
|
||||
- `--unset`：撤销对给定用户的强制密码更改
|
||||
- `regenerate`：
|
||||
- 选项：
|
||||
- `hooks`：重新生成所有仓库的 Git Hooks。
|
||||
- `keys`：重新生成 authorized_keys 文件。
|
||||
- 示例：
|
||||
- `gitea admin regenerate hooks`
|
||||
- `gitea admin regenerate keys`
|
||||
- `auth`：
|
||||
- `list`：
|
||||
- 描述：列出所有存在的外部认证源。
|
||||
- 示例：
|
||||
- `gitea admin auth list`
|
||||
- `delete`：
|
||||
- 选项：
|
||||
- `--id`：要删除的源的 ID。必填。
|
||||
- 示例：
|
||||
- `gitea admin auth delete --id 1`
|
||||
- `add-oauth`：
|
||||
- 选项：
|
||||
- `--name`：应用程序名称。
|
||||
- `--provider`：OAuth2 提供者。
|
||||
- `--key`：客户端 ID（Key）。
|
||||
- `--secret`：客户端密钥。
|
||||
- `--auto-discover-url`：OpenID Connect 自动发现 URL（仅在使用 OpenID Connect 作为提供程序时需要）。
|
||||
- `--use-custom-urls`：在 GitLab/GitHub OAuth 端点上使用自定义 URL。
|
||||
- `--custom-tenant-id`：在 OAuth 端点上使用自定义租户 ID。
|
||||
- `--custom-auth-url`：使用自定义授权 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-token-url`：使用自定义令牌 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-profile-url`：使用自定义配置文件 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-email-url`：使用自定义电子邮件 URL（GitHub 的选项）。
|
||||
- `--icon-url`：OAuth2 登录源的自定义图标 URL。
|
||||
- `--skip-local-2fa`：允许源覆盖本地 2FA。（可选）
|
||||
- `--scopes`：请求此 OAuth2 源的附加范围。（可选）
|
||||
- `--required-claim-name`：必须设置的声明名称，以允许用户使用此源登录。（可选）
|
||||
- `--required-claim-value`：必须设置的声明值，以允许用户使用此源登录。（可选）
|
||||
- `--group-claim-name`：提供此源的组名的声明名称。（可选）
|
||||
- `--admin-group`：管理员用户的组声明值。（可选）
|
||||
- `--restricted-group`：受限用户的组声明值。（可选）
|
||||
- `--group-team-map`：组与组织团队之间的 JSON 映射。（可选）
|
||||
- `--group-team-map-removal`：根据组自动激活团队成员资格的删除。（可选）
|
||||
- 示例：
|
||||
- `gitea admin auth add-oauth --name external-github --provider github --key OBTAIN_FROM_SOURCE --secret OBTAIN_FROM_SOURCE`
|
||||
- `update-oauth`：
|
||||
- 选项：
|
||||
- `--id`：要更新的源的 ID。必填。
|
||||
- `--name`：应用程序名称。
|
||||
- `--provider`：OAuth2 提供者。
|
||||
- `--key`：客户端 ID（Key）。
|
||||
- `--secret`：客户端密钥。
|
||||
- `--auto-discover-url`：OpenID Connect 自动发现 URL（仅在使用 OpenID Connect 作为提供程序时需要）。
|
||||
- `--use-custom-urls`：在 GitLab/GitHub OAuth 端点上使用自定义 URL。
|
||||
- `--custom-tenant-id`：在 OAuth 端点上使用自定义租户 ID。
|
||||
- `--custom-auth-url`：使用自定义授权 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-token-url`：使用自定义令牌 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-profile-url`：使用自定义配置文件 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-email-url`：使用自定义电子邮件 URL（GitHub 的选项）。
|
||||
- `--icon-url`：OAuth2 登录源的自定义图标 URL。
|
||||
- `--skip-local-2fa`：允许源覆盖本地 2FA。（可选）
|
||||
- `--scopes`：请求此 OAuth2 源的附加范围。
|
||||
- `--required-claim-name`：必须设置的声明名称，以允许用户使用此源登录。（可选）
|
||||
- `--required-claim-value`：必须设置的声明值，以允许用户使用此源登录。（可选）
|
||||
- `--group-claim-name`：提供此源的组名的声明名称。（可选）
|
||||
- `--admin-group`：管理员用户的组声明值。（可选）
|
||||
- `--restricted-group`：受限用户的组声明值。（可选）
|
||||
- 示例：
|
||||
- `gitea admin auth update-oauth --id 1 --name external-github-updated`
|
||||
- `add-smtp`：
|
||||
- 选项：
|
||||
- `--name`：应用程序名称。必填。
|
||||
- `--auth-type`：SMTP 认证类型（PLAIN/LOGIN/CRAM-MD5）。默认为 PLAIN。
|
||||
- `--host`：SMTP 主机。必填。
|
||||
- `--port`：SMTP 端口。必填。
|
||||
- `--force-smtps`：SMTPS 始终在端口 465 上使用。设置此选项以强制在其他端口上使用 SMTPS。
|
||||
- `--skip-verify`：跳过 TLS 验证。
|
||||
- `--helo-hostname`：发送 HELO 时使用的主机名。留空以发送当前主机名。
|
||||
- `--disable-helo`：禁用 SMTP helo。
|
||||
- `--allowed-domains`：留空以允许所有域。使用逗号（','）分隔多个域。
|
||||
- `--skip-local-2fa`：跳过 2FA 登录。
|
||||
- `--active`：启用此认证源。
|
||||
备注：
|
||||
`--force-smtps`、`--skip-verify`、`--disable-helo`、`--skip-local-2fs` 和 `--active` 选项可以采用以下形式使用：
|
||||
- `--option`、`--option=true` 以启用选项
|
||||
- `--option=false` 以禁用选项
|
||||
如果未指定这些选项，则在 `update-smtp` 中不会更改值，或者在 `add-smtp` 中将使用默认的 `false` 值。
|
||||
- 示例：
|
||||
- `gitea admin auth add-smtp --name ldap --host smtp.mydomain.org --port 587 --skip-verify --active`
|
||||
- `update-smtp`：
|
||||
- 选项：
|
||||
- `--id`：要更新的源的 ID。必填。
|
||||
- 其他选项与 `add-smtp` 共享
|
||||
- 示例：
|
||||
- `gitea admin auth update-smtp --id 1 --host smtp.mydomain.org --port 587 --skip-verify=false`
|
||||
- `gitea admin auth update-smtp --id 1 --active=false`
|
||||
- `add-ldap`：添加新的 LDAP（通过 Bind DN）认证源
|
||||
- 选项：
|
||||
- `--name value`：认证名称。必填。
|
||||
- `--not-active`：停用认证源。
|
||||
- `--security-protocol value`：安全协议名称。必填。
|
||||
- `--skip-tls-verify`：禁用 TLS 验证。
|
||||
- `--host value`：LDAP 服务器的地址。必填。
|
||||
- `--port value`：连接到 LDAP 服务器时使用的端口。必填。
|
||||
- `--user-search-base value`：用户帐户将在其中搜索的 LDAP 基础路径。必填。
|
||||
- `--user-filter value`：声明如何查找试图进行身份验证的用户记录的 LDAP 过滤器。必填。
|
||||
- `--admin-filter value`：指定是否应授予用户管理员特权的 LDAP 过滤器。
|
||||
- `--restricted-filter value`：指定是否应将用户设置为受限状态的 LDAP 过滤器。
|
||||
- `--username-attribute value`：用户 LDAP 记录中包含用户名的属性。
|
||||
- `--firstname-attribute value`：用户 LDAP 记录中包含用户名字的属性。
|
||||
- `--surname-attribute value`：用户 LDAP 记录中包含用户姓氏的属性。
|
||||
- `--email-attribute value`：用户 LDAP 记录中包含用户电子邮件地址的属性。必填。
|
||||
- `--public-ssh-key-attribute value`：用户 LDAP 记录中包含用户公共 SSH 密钥的属性。
|
||||
- `--avatar-attribute value`：用户 LDAP 记录中包含用户头像的属性。
|
||||
- `--bind-dn value`：在搜索用户时绑定到 LDAP 服务器的 DN。
|
||||
- `--bind-password value`：绑定 DN 的密码（如果有）。
|
||||
- `--attributes-in-bind`：在绑定 DN 上下文中获取属性。
|
||||
- `--synchronize-users`：启用用户同步。
|
||||
- `--page-size value`：搜索页面大小。
|
||||
- 示例：
|
||||
- `gitea admin auth add-ldap --name ldap --security-protocol unencrypted --host mydomain.org --port 389 --user-search-base "ou=Users,dc=mydomain,dc=org" --user-filter "(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))" --email-attribute mail`
|
||||
- `update-ldap`：更新现有的 LDAP（通过 Bind DN）认证源
|
||||
- 选项：
|
||||
- `--id value`：认证源的 ID。必填。
|
||||
- `--name value`：认证名称。
|
||||
- `--not-active`：停用认证源。
|
||||
- `--security-protocol value`：安全协议名称。
|
||||
- `--skip-tls-verify`：禁用 TLS 验证。
|
||||
- `--host value`：LDAP 服务器的地址。
|
||||
- `--port value`：连接到 LDAP 服务器时使用的端口。
|
||||
- `--user-search-base value`：用户帐户将在其中搜索的 LDAP 基础路径。
|
||||
- `--user-filter value`：声明如何查找试图进行身份验证的用户记录的 LDAP 过滤器。
|
||||
- `--admin-filter value`：指定是否应授予用户管理员特权的 LDAP 过滤器。
|
||||
- `--restricted-filter value`：指定是否应将用户设置为受限状态的 LDAP 过滤器。
|
||||
- `--username-attribute value`：用户 LDAP 记录中包含用户名的属性。
|
||||
- `--firstname-attribute value`：用户 LDAP 记录中包含用户名字的属性。
|
||||
- `--surname-attribute value`：用户 LDAP 记录中包含用户姓氏的属性。
|
||||
- `--email-attribute value`：用户 LDAP 记录中包含用户电子邮件地址的属性。
|
||||
- `--public-ssh-key-attribute value`：用户 LDAP 记录中包含用户公共 SSH 密钥的属性。
|
||||
- `--avatar-attribute value`：用户 LDAP 记录中包含用户头像的属性。
|
||||
- `--bind-dn value`：在搜索用户时绑定到 LDAP 服务器的 DN。
|
||||
- `--bind-password value`：绑定 DN 的密码（如果有）。
|
||||
- `--attributes-in-bind`：在绑定 DN 上下文中获取属性。
|
||||
- `--synchronize-users`：启用用户同步。
|
||||
- `--page-size value`：搜索页面大小。
|
||||
- 示例：
|
||||
- `gitea admin auth update-ldap --id 1 --name "my ldap auth source"`
|
||||
- `gitea admin auth update-ldap --id 1 --username-attribute uid --firstname-attribute givenName --surname-attribute sn`
|
||||
- `add-ldap-simple`：添加新的 LDAP（简单身份验证）认证源
|
||||
- 选项：
|
||||
- `--name value`：认证名称。必填。
|
||||
- `--not-active`：停用认证源。
|
||||
- `--security-protocol value`：安全协议名称。必填。
|
||||
- `--skip-tls-verify`：禁用 TLS 验证。
|
||||
- `--host value`：LDAP 服务器的地址。必填。
|
||||
- `--port value`：连接到 LDAP 服务器时使用的端口。必填。
|
||||
- `--user-search-base value`：用户帐户将在其中搜索的 LDAP 基础路径。
|
||||
- `--user-filter value`：声明如何查找试图进行身份验证的用户记录的 LDAP 过滤器。必填。
|
||||
- `--admin-filter value`：指定是否应授予用户管理员特权的 LDAP 过滤器。
|
||||
- `--restricted-filter value`：指定是否应将用户设置为受限状态的 LDAP 过滤器。
|
||||
- `--username-attribute value`：用户 LDAP 记录中包含用户名的属性。
|
||||
- `--firstname-attribute value`：用户 LDAP 记录中包含用户名字的属性。
|
||||
- `--surname-attribute value`：用户 LDAP 记录中包含用户姓氏的属性。
|
||||
- `--email-attribute value`：用户 LDAP 记录中包含用户电子邮件地址的属性。必填。
|
||||
- `--public-ssh-key-attribute value`：用户 LDAP 记录中包含用户公共 SSH 密钥的属性。
|
||||
- `--avatar-attribute value`：用户 LDAP 记录中包含用户头像的属性。
|
||||
- `--user-dn value`：用户的 DN。必填。
|
||||
- 示例：
|
||||
- `gitea admin auth add-ldap-simple --name ldap --security-protocol unencrypted --host mydomain.org --port 389 --user-dn "cn=%s,ou=Users,dc=mydomain,dc=org" --user-filter "(&(objectClass=posixAccount)(cn=%s))" --email-attribute mail`
|
||||
- `update-ldap-simple`：更新现有的 LDAP（简单身份验证）认证源
|
||||
- 选项：
|
||||
- `--id value`：认证源的 ID。必填。
|
||||
- `--name value`：认证名称。
|
||||
- `--not-active`：停用认证源。
|
||||
- `--security-protocol value`：安全协议名称。
|
||||
- `--skip-tls-verify`：禁用 TLS 验证。
|
||||
- `--host value`：LDAP 服务器的地址。
|
||||
- `--port value`：连接到 LDAP 服务器时使用的端口。
|
||||
- `--user-search-base value`：用户帐户将在其中搜索的 LDAP 基础路径。
|
||||
- `--user-filter value`：声明如何查找试图进行身份验证的用户记录的 LDAP 过滤器。
|
||||
- `--admin-filter value`：指定是否应授予用户管理员特权的 LDAP 过滤器。
|
||||
- `--restricted-filter value`：指定是否应将用户设置为受限状态的 LDAP 过滤器。
|
||||
- `--username-attribute value`：用户 LDAP 记录中包含用户名的属性。
|
||||
- `--firstname-attribute value`：用户 LDAP 记录中包含用户名字的属性。
|
||||
- `--surname-attribute value`：用户 LDAP 记录中包含用户姓氏的属性。
|
||||
- `--email-attribute value`：用户 LDAP 记录中包含用户电子邮件地址的属性。
|
||||
- `--public-ssh-key-attribute value`：用户 LDAP 记录中包含用户公共 SSH 密钥的属性。
|
||||
- `--avatar-attribute value`：用户 LDAP 记录中包含用户头像的属性。
|
||||
- `--user-dn value`：用户的 DN。
|
||||
- 示例：
|
||||
- `gitea admin auth update-ldap-simple --id 1 --name "my ldap auth source"`
|
||||
- `gitea admin auth update-ldap-simple --id 1 --username-attribute uid --firstname-attribute givenName --surname-attribute sn`
|
||||
|
||||
### cert
|
||||
|
||||
生成自签名的 SSL 证书。将输出到当前目录下的`cert.pem`和`key.pem`文件中，并且会覆盖任何现有文件。
|
||||
|
||||
- 选项：
|
||||
- `--host value`：逗号分隔的主机名和 IP 地址列表，此证书适用于这些主机。支持使用通配符。必填。
|
||||
- `--ecdsa-curve value`：用于生成密钥的 ECDSA 曲线。可选。有效选项为 P224、P256、P384、P521。
|
||||
- `--rsa-bits value`：要生成的 RSA 密钥的大小。可选。如果设置了--ecdsa-curve，则忽略此选项。（默认值：2048）。
|
||||
- `--start-date value`：证书的创建日期。可选。（格式：`Jan 1 15:04:05 2011`）。
|
||||
- `--duration value`：证书有效期。可选。（默认值：8760h0m0s）
|
||||
- `--ca`：如果提供此选项，则证书将生成自己的证书颁发机构。可选。
|
||||
- 示例：
|
||||
- `gitea cert --host git.example.com,example.com,www.example.com --ca`
|
||||
|
||||
### dump
|
||||
|
||||
将所有文件和数据库导出到一个 zip 文件中。输出文件将保存在当前目录下，类似于`gitea-dump-1482906742.zip`。
|
||||
|
||||
- 选项：
|
||||
- `--file name`，`-f name`：指定要创建的导出文件的名称。可选。（默认值：gitea-dump-[timestamp].zip）。
|
||||
- `--tempdir path`，`-t path`：指定临时目录的路径。可选。（默认值：/tmp）。
|
||||
- `--skip-repository`，`-R`：跳过仓库的导出。可选。
|
||||
- `--skip-custom-dir`：跳过自定义目录的导出。可选。
|
||||
- `--skip-lfs-data`：跳过 LFS 数据的导出。可选。
|
||||
- `--skip-attachment-data`：跳过附件数据的导出。可选。
|
||||
- `--skip-package-data`：跳过包数据的导出。可选。
|
||||
- `--skip-log`：跳过日志数据的导出。可选。
|
||||
- `--database`，`-d`：指定数据库的 SQL 语法。可选。
|
||||
- `--verbose`，`-V`：如果提供此选项，显示附加详细信息。可选。
|
||||
- `--type`：设置导出的格式。可选。（默认值：zip）
|
||||
- 示例：
|
||||
- `gitea dump`
|
||||
- `gitea dump --verbose`
|
||||
|
||||
### generate
|
||||
|
||||
用于在配置文件中生成随机值和令牌。对于自动部署时生成值非常有用。
|
||||
|
||||
- 命令:
|
||||
- `secret`:
|
||||
- 选项:
|
||||
- `INTERNAL_TOKEN`: 用于内部 API 调用身份验证的令牌。
|
||||
- `JWT_SECRET`: 用于 LFS 和 OAUTH2 JWT 身份验证的密钥（LFS_JWT_SECRET 是此选项的别名，用于向后兼容）。
|
||||
- `SECRET_KEY`: 全局密钥。
|
||||
- 示例:
|
||||
- `gitea generate secret INTERNAL_TOKEN`
|
||||
- `gitea generate secret JWT_SECRET`
|
||||
- `gitea generate secret SECRET_KEY`
|
||||
|
||||
### keys
|
||||
|
||||
提供一个 SSHD AuthorizedKeysCommand。需要在 sshd 配置文件中进行配置:
|
||||
|
||||
```ini
|
||||
...
|
||||
# -e 的值和 AuthorizedKeysCommandUser 应与运行 Gitea 的用户名匹配
|
||||
AuthorizedKeysCommandUser git
|
||||
AuthorizedKeysCommand /path/to/gitea keys -e git -u %u -t %t -k %k
|
||||
```
|
||||
|
||||
该命令将返回适用于提供的密钥的合适 authorized_keys 行。您还应在 `app.ini` 的 `[server]` 部分设置值 `SSH_CREATE_AUTHORIZED_KEYS_FILE=false`。
|
||||
|
||||
注意: opensshd 要求 Gitea 程序由 root 拥有，并且不可由组或其他人写入。程序必须使用绝对路径指定。
|
||||
注意: Gitea 必须在运行此命令时处于运行状态才能成功。
|
||||
|
||||
### migrate
|
||||
|
||||
迁移数据库。该命令可用于在首次启动服务器之前运行其他命令。此命令是幂等的。
|
||||
|
||||
### convert
|
||||
|
||||
将现有的 MySQL 数据库从 utf8 转换为 utf8mb4。
|
||||
|
||||
### doctor
|
||||
|
||||
根据给定的配置诊断当前 Gitea 实例的问题。目前有以下检查清单:
|
||||
|
||||
- 检查 OpenSSH 的 authorized_keys 文件是否正确
|
||||
当您的 Gitea 实例支持 OpenSSH 时，当您的 Gitea 实例添加或更改任何公钥时，Gitea 实例的二进制路径将被写入 `authorized_keys` 文件。
|
||||
有时，如果您在升级时移动或重命名了 Gitea 二进制文件，并且您没有在管理面板上运行“使用 Gitea 的 SSH 密钥更新「.ssh/authorized_keys」文件”操作。那么通过 SSH 的所有拉取/推送操作将无法正常工作。
|
||||
此检查将帮助您检查它是否正常工作。
|
||||
|
||||
对于贡献者，如果您想添加更多的检查项，您可以编写一个新的函数，如 `func(ctx *cli.Context) ([]string, error)`，并将其追加到 `doctor.go` 文件中。
|
||||
|
||||
```go
|
||||
var checklist = []check{
|
||||
{
|
||||
title: "Check if OpenSSH authorized_keys file id correct",
|
||||
f: runDoctorLocationMoved,
|
||||
},
|
||||
// more checks please append here
|
||||
}
|
||||
```
|
||||
|
||||
此函数将接收一个命令行上下文，并返回有关问题或错误的详细信息列表。
|
||||
|
||||
#### doctor recreate-table
|
||||
|
||||
有时，在迁移时，旧的列和默认值可能会在数据库模式中保持不变。这可能会导致警告，如下所示:
|
||||
|
||||
```
|
||||
2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync2() [W] Table user Column keep_activity_private db default is , struct default is 0
|
||||
```
|
||||
|
||||
您可以通过以下方式让 Gitea 重新创建这些表，并将旧数据复制到新表中，并适当设置默认值：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table user
|
||||
```
|
||||
|
||||
您可以使用以下方式让 Gitea 重新创建多个表：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table table1 table2 ...
|
||||
```
|
||||
|
||||
如果您希望 Gitea 重新创建所有表，请直接调用：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table
|
||||
```
|
||||
|
||||
强烈建议在运行这些命令之前备份您的数据库。
|
||||
|
||||
### manager
|
||||
|
||||
管理运行中的服务器操作：
|
||||
|
||||
- 命令:
|
||||
- `shutdown`: 优雅地关闭运行中的进程
|
||||
- `restart`: 优雅地重新启动运行中的进程（对于 Windows 服务器尚未实现）
|
||||
- `flush-queues`: 刷新运行中的进程中的队列
|
||||
- 选项:
|
||||
- `--timeout value`: 刷新过程的超时时间（默认值: 1m0s）
|
||||
- `--non-blocking`: 设置为 true，以在返回之前不等待刷新完成
|
||||
- `logging`: 调整日志命令
|
||||
- 命令:
|
||||
- `pause`: 暂停日志记录
|
||||
- 注意:
|
||||
- 如果日志级别低于此级别，日志级别将被临时提升为 INFO。
|
||||
- Gitea 将在一定程度上缓冲日志，并在超过该点后丢弃日志。
|
||||
- `resume`: 恢复日志记录
|
||||
- `release-and-reopen`: 使 Gitea 释放和重新打开用于日志记录的文件和连接（相当于向 Gitea 发送 SIGUSR1 信号）。
|
||||
- `remove name`: 删除指定的日志记录器
|
||||
- 选项:
|
||||
- `--group group`, `-g group`: 从中删除子记录器的组（默认为`default`）
|
||||
- `add`: 添加日志记录器
|
||||
- 命令:
|
||||
- `console`: 添加控制台日志记录器
|
||||
- 选项:
|
||||
- `--group value`, `-g value`: 要添加日志记录器的组 - 默认为"default"
|
||||
- `--name value`, `-n value`: 新日志记录器的名称 - 默认为模式
|
||||
- `--level value`, `-l value`: 新日志记录器的日志级别
|
||||
- `--stacktrace-level value`, `-L value`: 堆栈跟踪日志级别
|
||||
- `--flags value`, `-F value`: 日志记录器的标志
|
||||
- `--expression value`, `-e value`: 日志记录器的匹配表达式
|
||||
- `--prefix value`, `-p value`: 日志记录器的前缀
|
||||
- `--color`: 在日志中使用颜色
|
||||
- `--stderr`: 将控制台日志输出到 stderr - 仅适用于控制台
|
||||
- `file`: 添加文件日志记录器
|
||||
- 选项:
|
||||
- `--group value`, `-g value`: 要添加日志记录器的组 - 默认为"default"
|
||||
- `--name value`, `-n value`: 新日志记录器的名称 - 默认为模式
|
||||
- `--level value`, `-l value`: 新日志记录器的日志级别
|
||||
- `--stacktrace-level value`, `-L value`: 堆栈跟踪日志级别
|
||||
- `--flags value`, `-F value`: 日志记录器的标志
|
||||
- `--expression value`, `-e value`: 日志记录器的匹配表达式
|
||||
- `--prefix value`, `-p value`: 日志记录器的前缀
|
||||
- `--color`: 在日志中使用颜色
|
||||
- `--filename value`, `-f value`: 日志记录器的文件名
|
||||
- `--rotate`, `-r`: 轮转日志
|
||||
- `--max-size value`, `-s value`: 在轮转之前的最大大小（以字节为单位）
|
||||
- `--daily`, `-d`: 每天轮转日志
|
||||
- `--max-days value`, `-D value`: 保留的每日日志的最大数量
|
||||
- `--compress`, `-z`: 压缩轮转的日志
|
||||
- `--compression-level value`, `-Z value`: 使用的压缩级别
|
||||
- `conn`: 添加网络连接日志记录器
|
||||
- 选项:
|
||||
- `--group value`, `-g value`: 要添加日志记录器的组 - 默认为"default"
|
||||
- `--name value`, `-n value`: 新日志记录器的名称 - 默认为模式
|
||||
- `--level value`, `-l value`: 新日志记录器的日志级别
|
||||
- `--stacktrace-level value`, `-L value`: 堆栈跟踪日志级别
|
||||
- `--flags value`, `-F value`: 日志记录器的标志
|
||||
- `--expression value`, `-e value`: 日志记录器的匹配表达式
|
||||
- `--prefix value`, `-p value`: 日志记录器的前缀
|
||||
- `--color`: 在日志中使用颜色
|
||||
- `--reconnect-on-message`, `-R`: 对于每个消息重新连接主机
|
||||
- `--reconnect`, `-r`: 连接中断时重新连接主机
|
||||
- `--protocol value`, `-P value`: 设置要使用的协议：tcp、unix 或 udp（默认为 tcp）
|
||||
- `--address value`, `-a value`: 要连接到的主机地址和端口（默认为:7020）
|
||||
- `smtp`: 添加 SMTP 日志记录器
|
||||
- 选项:
|
||||
- `--group value`, `-g value`: 要添加日志记录器的组 - 默认为"default"
|
||||
- `--name value`, `-n value`: 新日志记录器的名称 - 默认为模式
|
||||
- `--level value`, `-l value`: 新日志记录器的日志级别
|
||||
- `--stacktrace-level value`, `-L value`: 堆栈跟踪日志级别
|
||||
- `--flags value`, `-F value`: 日志记录器的标志
|
||||
- `--expression value`, `-e value`: 日志记录器的匹配表达式
|
||||
- `--prefix value`, `-p value`: 日志记录器的前缀
|
||||
- `--color`: 在日志中使用颜色
|
||||
- `--username value`, `-u value`: 邮件服务器用户名
|
||||
- `--password value`, `-P value`: 邮件服务器密码
|
||||
- `--host value`, `-H value`: 邮件服务器主机（默认为: 127.0.0.1:25）
|
||||
- `--send-to value`, `-s value`: 要发送到的电子邮件地址
|
||||
- `--subject value`, `-S value`: 发送电子邮件的主题标题
|
||||
- `processes`: 显示 Gitea 进程和 Goroutine 信息
|
||||
- 选项:
|
||||
- `--flat`: 以平面表格形式显示进程，而不是树形结构
|
||||
- `--no-system`: 不显示系统进程
|
||||
- `--stacktraces`: 显示与进程关联的 Goroutine 的堆栈跟踪
|
||||
- `--json`: 输出为 JSON 格式
|
||||
- `--cancel PID`: 向具有 PID 的进程发送取消命令（仅适用于非系统进程）
|
||||
|
||||
### dump-repo
|
||||
|
||||
`dump-repo` 从 Git/GitHub/Gitea/GitLab 中转储存储库数据：
|
||||
|
||||
- 选项：
|
||||
- `--git_service service`：Git 服务，可以是 `git`、`github`、`gitea`、`gitlab`。如果 `clone_addr` 可以被识别，则可以忽略此选项。
|
||||
- `--repo_dir dir`，`-r dir`：存储数据的存储库目录路径。
|
||||
- `--clone_addr addr`：将被克隆的 URL，目前可以是 git/github/gitea/gitlab 的 http/https URL。例如：https://github.com/lunny/tango.git
|
||||
- `--auth_username lunny`：访问 `clone_addr` 的用户名。
|
||||
- `--auth_password <password>`：访问 `clone_addr` 的密码。
|
||||
- `--auth_token <token>`：访问 `clone_addr` 的个人令牌。
|
||||
- `--owner_name lunny`：如果非空，数据将存储在具有所有者名称的目录中。
|
||||
- `--repo_name tango`：如果非空，数据将存储在具有存储库名称的目录中。
|
||||
- `--units <units>`：要迁移的项目，一个或多个项目应以逗号分隔。允许的项目有 wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments。如果为空，则表示所有项目。
|
||||
|
||||
### restore-repo
|
||||
|
||||
`restore-repo` 从磁盘目录中还原存储库数据：
|
||||
|
||||
- 选项：
|
||||
- `--repo_dir dir`，`-r dir`：还原数据的存储库目录路径。
|
||||
- `--owner_name lunny`：还原目标所有者名称。
|
||||
- `--repo_name tango`：还原目标存储库名称。
|
||||
- `--units <units>`：要还原的项目，一个或多个项目应以逗号分隔。允许的项目有 wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments。如果为空，则表示所有项目。
|
||||
|
||||
### actions generate-runner-token
|
||||
|
||||
生成一个供 Runner 使用的新令牌，用于向服务器注册。
|
||||
|
||||
- 选项：
|
||||
- `--scope {owner}[/{repo}]`，`-s {owner}[/{repo}]`：限制 Runner 的范围，没有范围表示该 Runner 可用于所有仓库，但你也可以将其限制为特定的仓库或所有者。
|
||||
|
||||
要注册全局 Runner：
|
||||
|
||||
```
|
||||
gitea actions generate-runner-token
|
||||
```
|
||||
|
||||
要注册特定组织的 Runner，例如 `org`：
|
||||
|
||||
```
|
||||
gitea actions generate-runner-token -s org
|
||||
```
|
||||
|
||||
要注册特定仓库的 Runner，例如 `username/test-repo`：
|
||||
|
||||
```
|
||||
gitea actions generate-runner-token -s username/test-repo
|
||||
```
|
||||
@@ -1,461 +0,0 @@
|
||||
---
|
||||
date: "2016-12-26T16:00:00+02:00"
|
||||
slug: "config-cheat-sheet"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
# 配置说明
|
||||
|
||||
这是针对Gitea配置文件的说明，你可以了解Gitea的强大配置。需要说明的是，你的所有改变请修改 `custom/conf/app.ini` 文件而不是源文件。
|
||||
所有默认值可以通过 [app.example.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) 查看到。
|
||||
如果你发现 `%(X)s` 这样的内容，请查看 [ini](https://github.com/go-ini/ini/#recursive-values) 这里的说明。
|
||||
标注了 :exclamation: 的配置项表明除非你真的理解这个配置项的意义，否则最好使用默认值。
|
||||
|
||||
## ⚠️时效性警告⚠️
|
||||
|
||||
此文档的内容可能过于陈旧或者错误，请参考英文文档。
|
||||
|
||||
## Overall (`DEFAULT`)
|
||||
|
||||
- `APP_NAME`: 应用名称，改成你希望的名字。
|
||||
- `RUN_USER`: 运行Gitea的用户，推荐使用 `git`；如果在你自己的个人电脑使用改成你自己的用户名。如果设置不正确，Gitea可能崩溃。
|
||||
- `RUN_MODE`: 从性能考虑，如果在产品级的服务上改成 `prod`。如果您使用安装向导安装的那么会自动设置为 `prod`。
|
||||
|
||||
## Repository (`repository`)
|
||||
|
||||
- `ROOT`: 存放git工程的根目录。这里必须填绝对路径，默认值是 `~/<username>/gitea-repositories`。
|
||||
- `SCRIPT_TYPE`: 服务器支持的Shell类型，通常是 `bash`，但有些服务器也有可能是 `sh`。
|
||||
- `ANSI_CHARSET`: 默认字符编码。
|
||||
- `FORCE_PRIVATE`: 强制所有git工程必须私有。
|
||||
- `DEFAULT_PRIVATE`: 默认创建的git工程为私有。 可以是`last`, `private` 或 `public`。默认值是 `last`表示用户最后创建的Repo的选择。
|
||||
- `DEFAULT_PUSH_CREATE_PRIVATE`: **true**: 通过 ``push-to-create`` 方式创建的仓库是否默认为私有仓库.
|
||||
- `MAX_CREATION_LIMIT`: 全局最大每个用户创建的git工程数目， `-1` 表示没限制。
|
||||
- `PULL_REQUEST_QUEUE_LENGTH`: 小心：合并请求测试队列的长度，尽量放大。
|
||||
|
||||
### Repository - Release (`repository.release`)
|
||||
|
||||
- `ALLOWED_TYPES`: **_empty_**: 允许扩展名的列表，用逗号分隔 (`.zip`), mime 类型 (`text/plain`) 或者匹配符号 (`image/*`, `audio/*`, `video/*`). 空值或者 `*/*` 允许所有类型。
|
||||
- `DEFAULT_PAGING_NUM`: **10**: 默认的发布版本页面分页。
|
||||
|
||||
## UI (`ui`)
|
||||
|
||||
- `EXPLORE_PAGING_NUM`: 探索页面每页显示的仓库数量。
|
||||
- `ISSUE_PAGING_NUM`: 工单页面每页显示的工单数量。
|
||||
- `MEMBERS_PAGING_NUM`: **20**: 组织成员页面每页显示的成员数量。
|
||||
- `FEED_MAX_COMMIT_NUM`: 活动流页面显示的最大提交数量。
|
||||
|
||||
### UI - Admin (`ui.admin`)
|
||||
|
||||
- `USER_PAGING_NUM`: 用户管理页面每页显示的用户数量。
|
||||
- `REPO_PAGING_NUM`: 仓库管理页面每页显示的仓库数量。
|
||||
- `NOTICE_PAGING_NUM`: 系统提示页面每页显示的提示数量。
|
||||
- `ORG_PAGING_NUM`: 组织管理页面每页显示的组织数量。
|
||||
|
||||
## Markdown (`markdown`)
|
||||
|
||||
- `ENABLE_HARD_LINE_BREAK`: 是否启用硬换行扩展。
|
||||
|
||||
## Server (`server`)
|
||||
|
||||
- `PROTOCOL`: 可选 `http` 或 `https`。
|
||||
- `DOMAIN`: 服务器域名。
|
||||
- `ROOT_URL`: Gitea服务器的对外 URL。
|
||||
- `HTTP_ADDR`: HTTP 监听地址。
|
||||
- `HTTP_PORT`: HTTP 监听端口。
|
||||
- `DISABLE_SSH`: 是否禁用SSH。
|
||||
- `START_SSH_SERVER`: 是否启用内部SSH服务器。
|
||||
- `SSH_PORT`: SSH端口，默认为 `22`。
|
||||
- `OFFLINE_MODE`: 针对静态和头像文件禁用 CDN。
|
||||
- `DISABLE_ROUTER_LOG`: 关闭日志中的路由日志。
|
||||
- `CERT_FILE`: 启用HTTPS的证书文件。
|
||||
- `KEY_FILE`: 启用HTTPS的密钥文件。
|
||||
- `STATIC_ROOT_PATH`: 存放模板和静态文件的根目录，默认是 Gitea 的根目录。
|
||||
- `STATIC_CACHE_TIME`: **6h**: 静态资源文件，包括 `custom/`, `public/` 和所有上传的头像的浏览器缓存时间。
|
||||
- `ENABLE_GZIP`: 启用实时生成的数据启用 GZIP 压缩，不包括静态资源。
|
||||
- `LANDING_PAGE`: 未登录用户的默认页面，可选 `home` 或 `explore`。
|
||||
|
||||
- `LFS_START_SERVER`: 是否启用 git-lfs 支持. 可以为 `true` 或 `false`， 默认是 `false`。
|
||||
- `LFS_JWT_SECRET`: LFS 认证密钥，改成自己的。
|
||||
- `LFS_CONTENT_PATH`: **已废弃**, 存放 lfs 命令上传的文件的地方，默认是 `data/lfs`。**废弃** 请使用 `[lfs]` 的设置。
|
||||
|
||||
## Database (`database`)
|
||||
|
||||
- `DB_TYPE`: 数据库类型，可选 `mysql`, `postgres`, `mssql` 或 `sqlite3`。
|
||||
- `HOST`: 数据库服务器地址和端口。
|
||||
- `NAME`: 数据库名称。
|
||||
- `USER`: 数据库用户名。
|
||||
- `PASSWD`: 数据库用户密码。
|
||||
- `SSL_MODE`: MySQL 或 PostgreSQL数据库是否启用SSL模式。
|
||||
- `CHARSET`: **utf8mb4**: 仅当数据库为 MySQL 时有效, 可以为 "utf8" 或 "utf8mb4"。注意：如果使用 "utf8mb4"，你的 MySQL InnoDB 版本必须在 5.6 以上。
|
||||
- `PATH`: SQLite3 数据文件存放路径。
|
||||
- `LOG_SQL`: **true**: 显示生成的SQL，默认为真。
|
||||
- `MAX_IDLE_CONNS` **0**: 最大空闲数据库连接
|
||||
- `CONN_MAX_LIFETIME` **3s**: 数据库连接最大存活时间
|
||||
|
||||
## Indexer (`indexer`)
|
||||
|
||||
- `ISSUE_INDEXER_TYPE`: **bleve**: 工单索引类型，当前支持 `bleve`, `db` 和 `elasticsearch`，当为 `db` 时其它工单索引项可不用设置。
|
||||
- `ISSUE_INDEXER_CONN_STR`: ****: 工单索引连接字符串，仅当 ISSUE_INDEXER_TYPE 为 `elasticsearch` 时有效。例如: http://elastic:changeme@localhost:9200
|
||||
- `ISSUE_INDEXER_NAME`: **gitea_issues**: 工单索引名称，仅当 ISSUE_INDEXER_TYPE 为 `elasticsearch` 时有效。
|
||||
- `ISSUE_INDEXER_PATH`: **indexers/issues.bleve**: 工单索引文件存放路径，当索引类型为 `bleve` 时有效。
|
||||
- `ISSUE_INDEXER_QUEUE_TYPE`: **levelqueue**: 工单索引队列类型，当前支持 `channel`， `levelqueue` 或 `redis`。
|
||||
- `ISSUE_INDEXER_QUEUE_DIR`: **indexers/issues.queue**: 当 `ISSUE_INDEXER_QUEUE_TYPE` 为 `levelqueue` 时，保存索引队列的磁盘路径。
|
||||
- `ISSUE_INDEXER_QUEUE_CONN_STR`: **addrs=127.0.0.1:6379 db=0**: 当 `ISSUE_INDEXER_QUEUE_TYPE` 为 `redis` 时，保存Redis队列的连接字符串。
|
||||
- `ISSUE_INDEXER_QUEUE_BATCH_NUMBER`: **20**: 队列处理中批量提交数量。
|
||||
|
||||
- `REPO_INDEXER_ENABLED`: **false**: 是否启用代码搜索（启用后会占用比较大的磁盘空间，如果是bleve可能需要占用约6倍存储空间）。
|
||||
- `REPO_INDEXER_TYPE`: **bleve**: 代码搜索引擎类型，可以为 `bleve` 或者 `elasticsearch`。
|
||||
- `REPO_INDEXER_PATH`: **indexers/repos.bleve**: 用于代码搜索的索引文件路径。
|
||||
- `REPO_INDEXER_CONN_STR`: ****: 代码搜索引擎连接字符串，当 `REPO_INDEXER_TYPE` 为 `elasticsearch` 时有效。例如： http://elastic:changeme@localhost:9200
|
||||
- `REPO_INDEXER_NAME`: **gitea_codes**: 代码搜索引擎的名字，当 `REPO_INDEXER_TYPE` 为 `elasticsearch` 时有效。
|
||||
|
||||
- `UPDATE_BUFFER_LEN`: **20**: 代码索引请求的缓冲区长度。
|
||||
- `MAX_FILE_SIZE`: **1048576**: 进行解析的源代码文件的最大长度，小于该值时才会索引。
|
||||
|
||||
## Security (`security`)
|
||||
|
||||
- `INSTALL_LOCK`: 是否允许运行安装向导，(跟管理员账号有关，十分重要)。
|
||||
- `SECRET_KEY`: 全局服务器安全密钥 **最好改成你自己的** (当你运行安装向导的时候会被设置为一个随机值)。
|
||||
- `LOGIN_REMEMBER_DAYS`: Cookie 保存时间，单位天。
|
||||
- `COOKIE_USERNAME`: 保存用户名的 cookie 名称。
|
||||
- `COOKIE_REMEMBER_NAME`: 保存自动登录信息的 cookie 名称。
|
||||
- `REVERSE_PROXY_AUTHENTICATION_USER`: 反向代理认证的 HTTP 头名称。
|
||||
|
||||
## Service (`service`)
|
||||
|
||||
- `ACTIVE_CODE_LIVE_MINUTES`: 登录验证码失效时间，单位分钟。
|
||||
- `RESET_PASSWD_CODE_LIVE_MINUTES`: 重置密码失效时间，单位分钟。
|
||||
- `REGISTER_EMAIL_CONFIRM`: 启用注册邮件激活，前提是 `Mailer` 已经启用。
|
||||
- `REGISTER_MANUAL_CONFIRM`: **false**: 新注册用户必须由管理员手动激活,启用此选项需取消`REGISTER_EMAIL_CONFIRM`.
|
||||
- `DISABLE_REGISTRATION`: 禁用注册，启用后只能用管理员添加用户。
|
||||
- `SHOW_REGISTRATION_BUTTON`: 是否显示注册按钮。
|
||||
- `REQUIRE_SIGNIN_VIEW`: 是否所有页面都必须登录后才可访问。
|
||||
- `ENABLE_CACHE_AVATAR`: 是否缓存来自 Gravatar 的头像。
|
||||
- `ENABLE_NOTIFY_MAIL`: 是否发送工单创建等提醒邮件，需要 `Mailer` 被激活。
|
||||
- `ENABLE_REVERSE_PROXY_AUTHENTICATION`: 允许反向代理认证，更多细节见：https://github.com/gogits/gogs/issues/165
|
||||
- `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION`: 允许通过反向认证做自动注册。
|
||||
- `ENABLE_CAPTCHA`: **false**: 注册时使用图片验证码。
|
||||
- `REQUIRE_CAPTCHA_FOR_LOGIN`: **false**: 登录时需要图片验证码。需要同时开启 `ENABLE_CAPTCHA`。
|
||||
- `CAPTCHA_TYPE`: **image**: \[image, recaptcha, hcaptcha, mcaptcha, cfturnstile\]，人机验证类型，分别表示图片认证、 recaptcha 、 hcaptcha 、mcaptcha 、和 cloudlfare 的 turnstile。
|
||||
- `RECAPTCHA_SECRET`: **""**: recaptcha 服务的密钥，可在 https://www.google.com/recaptcha/admin 获取。
|
||||
- `RECAPTCHA_SITEKEY`: **""**: recaptcha 服务的网站密钥 ，可在 https://www.google.com/recaptcha/admin 获取。
|
||||
- `RECAPTCHA_URL`: **https://www.google.com/recaptcha/**: 设置 recaptcha 的 url 。
|
||||
- `HCAPTCHA_SECRET`: **""**: hcaptcha 服务的密钥，可在 https://www.hcaptcha.com/ 获取。
|
||||
- `HCAPTCHA_SITEKEY`: **""**: hcaptcha 服务的网站密钥，可在 https://www.hcaptcha.com/ 获取。
|
||||
- `MCAPTCHA_SECRET`: **""**: mCaptcha 服务的密钥。
|
||||
- `MCAPTCHA_SITEKEY`: **""**: mCaptcha 服务的网站密钥。
|
||||
- `MCAPTCHA_URL` **https://demo.mcaptcha.org/**: 设置 remCaptchacaptcha 的 url 。
|
||||
- `CF_TURNSTILE_SECRET` **""**: cloudlfare turnstile 服务的密钥，可在 https://dash.cloudflare.com/?to=/:account/turnstile 获取。
|
||||
- `CF_TURNSTILE_SITEKEY` **""**: cloudlfare turnstile 服务的网站密钥 ，可在 https://www.google.com/recaptcha/admin 获取。
|
||||
|
||||
### Service - Expore (`service.explore`)
|
||||
|
||||
- `REQUIRE_SIGNIN_VIEW`: **false**: 仅允许已登录的用户查看探索页面。
|
||||
- `DISABLE_USERS_PAGE`: **false**: 不显示用户探索页面。
|
||||
|
||||
## Webhook (`webhook`)
|
||||
|
||||
- `QUEUE_LENGTH`: 说明: Hook 任务队列长度。
|
||||
- `DELIVER_TIMEOUT`: 请求webhooks的超时时间，单位秒。
|
||||
- `SKIP_TLS_VERIFY`: 是否允许不安全的证书。
|
||||
- `PAGING_NUM`: 每页显示的Webhook 历史数量。
|
||||
- `PROXY_URL`: ****: 代理服务器网址，支持 http://, https//, socks://, 为空将使用环境变量中的 http_proxy/https_proxy 设置。
|
||||
- `PROXY_HOSTS`: ****: 逗号分隔的需要代理的域名或IP地址。支持 * 号匹配符，使用 ** 匹配所有域名和IP地址。
|
||||
|
||||
## Mailer (`mailer`)
|
||||
|
||||
- `ENABLED`: 是否启用邮件服务。
|
||||
- `DISABLE_HELO`: 禁用 HELO 命令。
|
||||
- `HELO_HOSTNAME`: 自定义主机名来回应 HELO 命令。
|
||||
- `HOST`: SMTP 主机地址和端口 (例如：smtp.gitea.io:587)。
|
||||
- `FROM`: 邮件发送地址，RFC 5322. 这里可以填一个邮件地址或者 "Name" \<email@example.com\> 格式。
|
||||
- `USER`: 用户名(通常就是邮件地址)。
|
||||
- `PASSWD`: 密码。
|
||||
- `SKIP_VERIFY`: 忽略证书验证。
|
||||
|
||||
说明：实际上 Gitea 仅仅支持基于 STARTTLS 的 SMTP。
|
||||
|
||||
## Cache (`cache`)
|
||||
|
||||
- `ENABLED`: **true**: 是否启用。
|
||||
- `ADAPTER`: **memory**: 缓存引擎，可以为 `memory`, `redis` 或 `memcache`。
|
||||
- `INTERVAL`: **60**: 只对内存缓存有效，GC间隔，单位秒。
|
||||
- `HOST`: **_empty_**: 针对redis和memcache有效，主机地址和端口。
|
||||
- Redis: `network=tcp,addr=127.0.0.1:6379,password=macaron,db=0,pool_size=100,idle_timeout=180`
|
||||
- Memache: `127.0.0.1:9090;127.0.0.1:9091`
|
||||
- `ITEM_TTL`: **16h**: 缓存项目失效时间，设置为 -1 则禁用缓存。
|
||||
|
||||
## Cache - LastCommitCache settings (`cache.last_commit`)
|
||||
|
||||
- `ENABLED`: **true**: 是否启用。
|
||||
- `ITEM_TTL`: **8760h**: 缓存项目失效时间，设置为 -1 则禁用缓存。
|
||||
- `COMMITS_COUNT`: **1000**: 仅当仓库的提交数大于时才启用缓存。
|
||||
|
||||
## Session (`session`)
|
||||
|
||||
- `PROVIDER`: Session 内容存储方式，可选 `memory`, `file`, `redis` 或 `mysql`。
|
||||
- `PROVIDER_CONFIG`: 如果是文件，那么这里填根目录；其他的要填主机地址和端口。
|
||||
- `COOKIE_SECURE`: 强制使用 HTTPS 作为session访问。
|
||||
- `GC_INTERVAL_TIME`: Session失效时间。
|
||||
|
||||
## Picture (`picture`)
|
||||
|
||||
- `GRAVATAR_SOURCE`: 头像来源，可以是 `gravatar`, `duoshuo` 或者类似 `http://cn.gravatar.com/avatar/` 的来源
|
||||
- `DISABLE_GRAVATAR`: 开启则只使用内部头像。
|
||||
- `ENABLE_FEDERATED_AVATAR`: 启用头像联盟支持 (参见 http://www.libravatar.org)
|
||||
|
||||
- `AVATAR_STORAGE_TYPE`: **local**: 头像存储类型，可以为 `local` 或 `minio`，分别支持本地文件系统和 minio 兼容的API。
|
||||
- `AVATAR_UPLOAD_PATH`: **data/avatars**: 存储头像的文件系统路径。
|
||||
- `AVATAR_MAX_WIDTH`: **4096**: 头像最大宽度，单位像素。
|
||||
- `AVATAR_MAX_HEIGHT`: **3072**: 头像最大高度，单位像素。
|
||||
- `AVATAR_MAX_FILE_SIZE`: **1048576** (1Mb): 头像最大大小。
|
||||
|
||||
- `REPOSITORY_AVATAR_STORAGE_TYPE`: **local**: 仓库头像存储类型，可以为 `local` 或 `minio`，分别支持本地文件系统和 minio 兼容的API。
|
||||
- `REPOSITORY_AVATAR_UPLOAD_PATH`: **data/repo-avatars**: 存储仓库头像的路径。
|
||||
- `REPOSITORY_AVATAR_FALLBACK`: **none**: 当头像丢失时的处理方式
|
||||
- none = 不显示头像
|
||||
- random = 显示随机生成的头像
|
||||
- image = 显示默认头像，通过 `REPOSITORY_AVATAR_FALLBACK_IMAGE` 设置
|
||||
- `REPOSITORY_AVATAR_FALLBACK_IMAGE`: **/img/repo_default.png**: 默认仓库头像
|
||||
|
||||
## Attachment (`attachment`)
|
||||
|
||||
- `ENABLED`: 是否允许用户上传附件。
|
||||
- `ALLOWED_TYPES`: 允许上传的附件类型。比如：`image/jpeg|image/png`，用 `*/*` 表示允许任何类型。
|
||||
- `MAX_SIZE`: 附件最大限制，单位 MB，比如： `4`。
|
||||
- `MAX_FILES`: 一次最多上传的附件数量，比如： `5`。
|
||||
- `STORAGE_TYPE`: **local**: 附件存储类型，`local` 将存储到本地文件夹， `minio` 将存储到 s3 兼容的对象存储服务中。
|
||||
- `PATH`: **data/attachments**: 附件存储路径，仅当 `STORAGE_TYPE` 为 `local` 时有效。
|
||||
- `MINIO_ENDPOINT`: **localhost:9000**: Minio 终端，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID ，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_BUCKET`: **gitea**: Minio bucket to store the attachments，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_LOCATION`: **us-east-1**: Minio location to create bucket，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_BASE_PATH`: **attachments/**: Minio base path on the bucket，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_USE_SSL`: **false**: Minio enabled ssl，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
|
||||
关于 `ALLOWED_TYPES`， 在 (*)unix 系统中可以使用`file -I <filename>` 来快速获得对应的 `MIME type`。
|
||||
|
||||
```shell
|
||||
$ file -I test00.tar.xz
|
||||
test00.tar.xz: application/x-xz; charset=binary
|
||||
|
||||
$ file --mime test00.xlsx
|
||||
test00.xlsx: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; charset=binary
|
||||
|
||||
file -I test01.xls
|
||||
test01.xls: application/vnd.ms-excel; charset=binary
|
||||
```
|
||||
|
||||
## Log (`log`)
|
||||
|
||||
- `ROOT_PATH`: 日志文件根目录。
|
||||
- `MODE`: 日志记录模式，默认是为 `console`。如果要写到多个通道，用逗号分隔
|
||||
- `LEVEL`: 日志级别，默认为`Trace`。
|
||||
|
||||
## Cron (`cron`)
|
||||
|
||||
- `ENABLED`: 是否在后台运行定期任务。
|
||||
- `RUN_AT_START`: 是否启动时自动运行。
|
||||
- `SCHEDULE` 所接受的格式
|
||||
- 完整 crontab 控制, 例如 `* * * * * ?`
|
||||
- 描述符, 例如 `@midnight`, `@every 1h30m` ...
|
||||
- 更多细节参见 [cron api文档](https://pkg.go.dev/github.com/gogs/cron@v0.0.0-20171120032916-9f6c956d3e14)
|
||||
|
||||
### Cron - Update Mirrors (`cron.update_mirrors`)
|
||||
|
||||
- `SCHEDULE`: 自动同步镜像仓库的Cron语法，比如：`@every 1h`。
|
||||
|
||||
### Cron - Repository Health Check (`cron.repo_health_check`)
|
||||
|
||||
- `SCHEDULE`: 仓库健康监测的Cron语法，比如：`@midnight`。
|
||||
- `TIMEOUT`: 仓库健康监测的超时时间，比如：`60s`.
|
||||
- `ARGS`: 执行 `git fsck` 命令的参数，比如：`--unreachable --tags`。
|
||||
|
||||
### Cron - Repository Statistics Check (`cron.check_repo_stats`)
|
||||
|
||||
- `RUN_AT_START`: 是否启动时自动运行仓库统计。
|
||||
- `SCHEDULE`: 仓库统计时的Cron 语法，比如：`@midnight`.
|
||||
|
||||
### Cron - Update Migration Poster ID (`cron.update_migration_poster_id`)
|
||||
|
||||
- `SCHEDULE`: **@midnight** : 每次同步的间隔时间。此任务总是在启动时自动进行。
|
||||
|
||||
## Git (`git`)
|
||||
|
||||
- `MAX_GIT_DIFF_LINES`: 比较视图中，一个文件最多显示行数。
|
||||
- `MAX_GIT_DIFF_LINE_CHARACTERS`: 比较视图中一行最大字符数。
|
||||
- `MAX_GIT_DIFF_FILES`: 比较视图中的最大现实文件数目。
|
||||
- `GC_ARGS`: 执行 `git gc` 命令的参数, 比如： `--aggressive --auto`。
|
||||
|
||||
## Git - 超时设置 (`git.timeout`)
|
||||
|
||||
- `DEFAUlT`: **360**: Git操作默认超时时间，单位秒
|
||||
- `MIGRATE`: **600**: 迁移外部仓库时的超时时间，单位秒
|
||||
- `MIRROR`: **300**: 镜像外部仓库的超时时间，单位秒
|
||||
- `CLONE`: **300**: 内部仓库间克隆的超时时间，单位秒
|
||||
- `PULL`: **300**: 内部仓库间拉取的超时时间，单位秒
|
||||
- `GC`: **60**: git仓库GC的超时时间，单位秒
|
||||
- `ENABLE_AUTO_GIT_WIRE_PROTOCOL`: **true**: 是否根据 Git Wire Protocol协议支持情况自动切换版本，当 git 版本在 2.18 及以上时会自动切换到版本2。为 `false` 则不切换。
|
||||
|
||||
## API (`api`)
|
||||
|
||||
- `ENABLE_SWAGGER`: **true**: 是否启用swagger路由 /api/swagger, /api/v1/swagger etc. endpoints. True 或 false.
|
||||
- `MAX_RESPONSE_ITEMS`: **50**: 一个页面最大的项目数。
|
||||
- `DEFAULT_PAGING_NUM`: **30**: API中默认分页条数。
|
||||
- `DEFAULT_GIT_TREES_PER_PAGE`: **1000**: GIT TREES API每页的默认最大项数.
|
||||
- `DEFAULT_MAX_BLOB_SIZE`: **10485760**: BLOBS API默认最大大小.
|
||||
|
||||
## Markup (`markup`)
|
||||
|
||||
外部渲染工具支持，你可以用你熟悉的文档渲染工具. 比如一下将新增一个名字为 `asciidoc` 的渲染工具which is followed `markup.` ini section. And there are some config items below.
|
||||
|
||||
```ini
|
||||
[markup.asciidoc]
|
||||
ENABLED = false
|
||||
NEED_POSTPROCESS = true
|
||||
FILE_EXTENSIONS = .adoc,.asciidoc
|
||||
RENDER_COMMAND = "asciidoc --out-file=- -"
|
||||
IS_INPUT_FILE = false
|
||||
```
|
||||
|
||||
- ENABLED: 是否启用，默认为false。
|
||||
- NEED\_POSTPROCESS: **true** 设置为 true 则会替换渲染文件中的内部链接和Commit ID 等。
|
||||
- FILE_EXTENSIONS: 关联的文档的扩展名，多个扩展名用都好分隔。
|
||||
- RENDER_COMMAND: 工具的命令行命令及参数。
|
||||
- IS_INPUT_FILE: 输入方式是最后一个参数为文件路径还是从标准输入读取。
|
||||
- RENDER_CONTENT_MODE: **sanitized** 内容如何被渲染。
|
||||
- sanitized: 对内容进行净化并渲染到当前页面中，仅有一部分 HTML 标签和属性是被允许的。
|
||||
- no-sanitizer: 禁用净化器，把内容渲染到当前页面中。此模式是**不安全**的，如果内容中含有恶意代码，可能会导致 XSS 攻击。
|
||||
- iframe: 把内容渲染在一个独立的页面中并使用 iframe 嵌入到当前页面中。使用的 iframe 工作在沙箱模式并禁用了同源请求，JS 代码被安全的从父页面中隔离出去。
|
||||
|
||||
以下两个环境变量将会被传递给渲染命令：
|
||||
|
||||
- `GITEA_PREFIX_SRC`：包含当前的`src`路径的URL前缀，可以被用于链接的前缀。
|
||||
- `GITEA_PREFIX_RAW`：包含当前的`raw`路径的URL前缀，可以被用于图片的前缀。
|
||||
|
||||
如果 `RENDER_CONTENT_MODE` 为 `sanitized`，则 Gitea 支持自定义渲染 HTML 的净化策略。以下例子将用 pandoc 支持 KaTeX 输出。
|
||||
|
||||
```ini
|
||||
[markup.sanitizer.TeX]
|
||||
; Pandoc renders TeX segments as <span>s with the "math" class, optionally
|
||||
; with "inline" or "display" classes depending on context.
|
||||
ELEMENT = span
|
||||
ALLOW_ATTR = class
|
||||
REGEXP = ^\s*((math(\s+|$)|inline(\s+|$)|display(\s+|$)))+
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
- `ELEMENT`: 将要被应用到该策略的 HTML 元素，不能为空。
|
||||
- `ALLOW_ATTR`: 将要被应用到该策略的属性，不能为空。
|
||||
- `REGEXP`: 正则表达式，用来匹配属性的内容。如果为空，则跟属性内容无关。
|
||||
- `ALLOW_DATA_URI_IMAGES`: **false** 允许 data uri 图片 (`<img src="data:image/png;base64,..."/>`)。
|
||||
|
||||
多个净化规则可以被同时定义，只要section名称最后一位不重复即可。如： `[markup.sanitizer.TeX-2]`。
|
||||
为了针对一种渲染类型进行一个特殊的净化策略，必须使用形如 `[markup.sanitizer.asciidoc.rule-1]` 的方式来命名 section。
|
||||
如果此规则没有匹配到任何渲染类型，它将会被应用到所有的渲染类型。
|
||||
|
||||
## Time (`time`)
|
||||
|
||||
- `FORMAT`: 显示在界面上的时间格式。比如： RFC1123 或者 2006-01-02 15:04:05
|
||||
- `DEFAULT_UI_LOCATION`: 默认显示在界面上的时区，默认为本地时区。比如： Asia/Shanghai
|
||||
|
||||
## Task (`task`)
|
||||
|
||||
- `QUEUE_TYPE`: **channel**: 任务队列类型，可以为 `channel` 或 `redis`。
|
||||
- `QUEUE_LENGTH`: **1000**: 任务队列长度，当 `QUEUE_TYPE` 为 `channel` 时有效。
|
||||
- `QUEUE_CONN_STR`: **addrs=127.0.0.1:6379 db=0**: 任务队列连接字符串，当 `QUEUE_TYPE` 为 `redis` 时有效。如果redis有密码，则可以 `addrs=127.0.0.1:6379 password=123 db=0`。
|
||||
|
||||
## Migrations (`migrations`)
|
||||
|
||||
- `MAX_ATTEMPTS`: **3**: 在迁移过程中的 http/https 请求重试次数。
|
||||
- `RETRY_BACKOFF`: **3**: 等待下一次重试的时间，单位秒。
|
||||
- `ALLOWED_DOMAINS`: **_empty_**: 迁移仓库的域名白名单，默认为空，表示允许从任意域名迁移仓库，多个域名用逗号分隔。
|
||||
- `BLOCKED_DOMAINS`: **_empty_**: 迁移仓库的域名黑名单，默认为空，多个域名用逗号分隔。如果 `ALLOWED_DOMAINS` 不为空，此选项有更高的优先级拒绝这里的域名。
|
||||
- `ALLOW_LOCALNETWORKS`: **false**: Allow private addresses defined by RFC 1918
|
||||
- `SKIP_TLS_VERIFY`: **false**: 允许忽略 TLS 认证
|
||||
|
||||
## LFS (`lfs`)
|
||||
|
||||
LFS 的存储配置。 如果 `STORAGE_TYPE` 为空，则此配置将从 `[storage]` 继承。如果不为 `local` 或者 `minio` 而为 `xxx`， 则从 `[storage.xxx]` 继承。当继承时， `PATH` 默认为 `data/lfs`，`MINIO_BASE_PATH` 默认为 `lfs/`。
|
||||
|
||||
- `STORAGE_TYPE`: **local**: LFS 的存储类型，`local` 将存储到磁盘，`minio` 将存储到 s3 兼容的对象服务。
|
||||
- `SERVE_DIRECT`: **false**: 允许直接重定向到存储系统。当前，仅 Minio/S3 是支持的。
|
||||
- `PATH`: 存放 lfs 命令上传的文件的地方，默认是 `data/lfs`。
|
||||
- `MINIO_ENDPOINT`: **localhost:9000**: Minio 地址，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_BUCKET`: **gitea**: Minio bucket，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_LOCATION`: **us-east-1**: Minio location ，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_BASE_PATH`: **lfs/**: Minio base path ，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_USE_SSL`: **false**: Minio 是否启用 ssl ，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
|
||||
## Storage (`storage`)
|
||||
|
||||
Attachments, lfs, avatars and etc 的默认存储配置。
|
||||
|
||||
- `STORAGE_TYPE`: **local**: 附件存储类型，`local` 将存储到本地文件夹， `minio` 将存储到 s3 兼容的对象存储服务中。
|
||||
- `SERVE_DIRECT`: **false**: 允许直接重定向到存储系统。当前，仅 Minio/S3 是支持的。
|
||||
- `MINIO_ENDPOINT`: **localhost:9000**: Minio 终端，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID ，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_BUCKET`: **gitea**: Minio bucket to store the attachments，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_LOCATION`: **us-east-1**: Minio location to create bucket，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_USE_SSL`: **false**: Minio enabled ssl，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
|
||||
你也可以自定义一个存储的名字如下：
|
||||
|
||||
```ini
|
||||
[storage.my_minio]
|
||||
STORAGE_TYPE = minio
|
||||
; Minio endpoint to connect only available when STORAGE_TYPE is `minio`
|
||||
MINIO_ENDPOINT = localhost:9000
|
||||
; Minio accessKeyID to connect only available when STORAGE_TYPE is `minio`
|
||||
MINIO_ACCESS_KEY_ID =
|
||||
; Minio secretAccessKey to connect only available when STORAGE_TYPE is `minio`
|
||||
MINIO_SECRET_ACCESS_KEY =
|
||||
; Minio bucket to store the attachments only available when STORAGE_TYPE is `minio`
|
||||
MINIO_BUCKET = gitea
|
||||
; Minio location to create bucket only available when STORAGE_TYPE is `minio`
|
||||
MINIO_LOCATION = us-east-1
|
||||
; Minio enabled ssl only available when STORAGE_TYPE is `minio`
|
||||
MINIO_USE_SSL = false
|
||||
; Minio skip SSL verification available when STORAGE_TYPE is `minio`
|
||||
MINIO_INSECURE_SKIP_VERIFY = false
|
||||
```
|
||||
|
||||
然后你在 `[attachment]`, `[lfs]` 等中可以把这个名字用作 `STORAGE_TYPE` 的值。
|
||||
|
||||
## Repository Archive Storage (`storage.repo-archive`)
|
||||
|
||||
Repository archive 的存储配置。 如果 `STORAGE_TYPE` 为空，则此配置将从 `[storage]` 继承。如果不为 `local` 或者 `minio` 而为 `xxx`， 则从 `[storage.xxx]` 继承。当继承时， `PATH` 默认为 `data/repo-archive`，`MINIO_BASE_PATH` 默认为 `repo-archive/`。
|
||||
|
||||
- `STORAGE_TYPE`: **local**: Repository archive 的存储类型，`local` 将存储到磁盘，`minio` 将存储到 s3 兼容的对象服务。
|
||||
- `SERVE_DIRECT`: **false**: 允许直接重定向到存储系统。当前，仅 Minio/S3 是支持的。
|
||||
- `PATH`: 存放 Repository archive 上传的文件的地方，默认是 `data/repo-archive`。
|
||||
- `MINIO_ENDPOINT`: **localhost:9000**: Minio 地址，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_BUCKET`: **gitea**: Minio bucket，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_LOCATION`: **us-east-1**: Minio location ，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_BASE_PATH`: **repo-archive/**: Minio base path ，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_USE_SSL`: **false**: Minio 是否启用 ssl ，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
|
||||
## Proxy (`proxy`)
|
||||
|
||||
- `PROXY_ENABLED`: **false**: 是否启用全局代理。如果为否，则不使用代理，环境变量中的代理也不使用
|
||||
- `PROXY_URL`: **_empty_**: 代理服务器地址，支持 http://, https//, socks://，为空则不启用代理而使用环境变量中的 http_proxy/https_proxy
|
||||
- `PROXY_HOSTS`: **_empty_**: 逗号分隔的多个需要代理的网址，支持 * 号匹配符号， ** 表示匹配所有网站
|
||||
|
||||
i.e.
|
||||
|
||||
```ini
|
||||
PROXY_ENABLED = true
|
||||
PROXY_URL = socks://127.0.0.1:1080
|
||||
PROXY_HOSTS = *.github.com
|
||||
```
|
||||
|
||||
## Other (`other`)
|
||||
|
||||
- `SHOW_FOOTER_BRANDING`: 为真则在页面底部显示Gitea的字样。
|
||||
- `SHOW_FOOTER_VERSION`: 为真则在页面底部显示Gitea的版本。
|
||||
@@ -1,79 +0,0 @@
|
||||
---
|
||||
date: "2017-04-15T14:56:00+02:00"
|
||||
slug: "customizing-gitea"
|
||||
sidebar_position: 100
|
||||
---
|
||||
|
||||
# 自定义 Gitea 配置
|
||||
|
||||
Gitea 引用 `custom` 目录中的自定义配置文件来覆盖配置、模板等默认配置。
|
||||
|
||||
如果从二进制部署 Gitea ，则所有默认路径都将相对于该 gitea 二进制文件；如果从发行版安装，则可能会将这些路径修改为Linux文件系统标准。Gitea
|
||||
将会自动创建包括 `custom/` 在内的必要应用目录，应用本身的配置存放在
|
||||
`custom/conf/app.ini` 当中。在发行版中可能会以 `/etc/gitea/` 的形式为 `custom` 设置一个符号链接，查看配置详情请移步：
|
||||
|
||||
- [快速备忘单](https://docs.gitea.io/en-us/config-cheat-sheet/)
|
||||
- [完整配置清单](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
|
||||
|
||||
如果您在 binary 同目录下无法找到 `custom` 文件夹，请检查您的 `GITEA_CUSTOM`
|
||||
环境变量配置， 因为它可能被配置到了其他地方（可能被一些启动脚本设置指定了目录）。
|
||||
|
||||
- [环境变量清单](https://docs.gitea.io/en-us/specific-variables/)
|
||||
|
||||
**注：** 必须完全重启 Gitea 以使配置生效。
|
||||
|
||||
## 使用自定义 /robots.txt
|
||||
|
||||
将 [想要展示的内容](http://www.robotstxt.org/) 存放在 `custom` 目录中的
|
||||
`robots.txt` 文件来让 Gitea 使用自定义的`/robots.txt` （默认：空 404）。
|
||||
|
||||
## 使用自定义的公共文件
|
||||
|
||||
将自定义的公共文件（比如页面和图片）作为 webroot 放在 `custom/public/` 中来让 Gitea 提供这些自定义内容（符号链接将被追踪）。
|
||||
|
||||
举例说明：`image.png` 存放在 `custom/public/`中，那么它可以通过链接 http://gitea.domain.tld/assets/image.png 访问。
|
||||
|
||||
## 修改默认头像
|
||||
|
||||
替换以下目录中的 png 图片： `custom/public/img/avatar\_default.png`
|
||||
|
||||
## 自定义 Gitea 页面
|
||||
|
||||
您可以改变 Gitea `custom/templates` 的每个单页面。您可以在 Gitea 源码的 `templates` 目录中找到用于覆盖的模板文件，应用将根据
|
||||
`custom/templates` 目录下的路径结构进行匹配和覆盖。
|
||||
|
||||
包含在 `{{` 和 `}}` 中的任何语句都是 Gitea 的模板语法，如果您不完全理解这些组件，不建议您对它们进行修改。
|
||||
|
||||
### 添加链接和页签
|
||||
|
||||
如果您只是想添加额外的链接到顶部导航栏或额外的选项卡到存储库视图，您可以将它们放在您 `custom/templates/custom/` 目录下的 `extra_links.tmpl` 和 `extra_tabs.tmpl` 文件中。
|
||||
|
||||
举例说明：假设您需要在网站放置一个静态的“关于”页面，您只需将该页面放在您的
|
||||
"custom/public/"目录下（比如 `custom/public/impressum.html`）并且将它与 `custom/templates/custom/extra_links.tmpl` 链接起来即可。
|
||||
|
||||
这个链接应当使用一个名为“item”的 class 来匹配当前样式，您可以使用 `{{AppSubUrl}}` 来获取 base URL:
|
||||
`<a class="item" href="{{AppSubUrl}}/assets/impressum.html">Impressum</a>`
|
||||
|
||||
同理，您可以将页签添加到 `extra_tabs.tmpl` 中，使用同样的方式来添加页签。它的具体样式需要与
|
||||
`templates/repo/header.tmpl` 中已有的其他选项卡的样式匹配
|
||||
([source in GitHub](https://github.com/go-gitea/gitea/blob/main/templates/repo/header.tmpl))
|
||||
|
||||
### 页面的其他新增内容
|
||||
|
||||
除了 `extra_links.tmpl` 和 `extra_tabs.tmpl`，您可以在您的 `custom/templates/custom/` 目录中存放一些其他有用的模板，例如：
|
||||
|
||||
- `header.tmpl`，在 `<head>` 标记结束之前的模板，例如添加自定义CSS文件
|
||||
- `body_outer_pre.tmpl`，在 `<body>` 标记开始处的模板
|
||||
- `body_inner_pre.tmpl`，在顶部导航栏之前，但在主 container 内部的模板，例如添加一个 `<div class="full height">`
|
||||
- `body_inner_post.tmpl`，在主 container 结束处的模板
|
||||
- `body_outer_post.tmpl`，在底部 `<footer>` 元素之前.
|
||||
- `footer.tmpl`，在 `<body>` 标签结束处的模板，可以在这里填写一些附加的 Javascript 脚本。
|
||||
|
||||
## 自定义 gitignores，labels， licenses， locales 以及 readmes
|
||||
|
||||
将自定义文件放在 `custom/options` 下相应子的文件夹中即可
|
||||
|
||||
## 更改 Gitea 外观
|
||||
|
||||
Gitea 目前由两种内置主题，分别为默认 `gitea` 主题和深色主题 `arc-green`，您可以通过修改
|
||||
`app.ini` [ui](https://docs.gitea.io/en-us/config-cheat-sheet/#界面) 部分的 `DEFAULT_THEME` 的值来变更至一个可用的 Gitea 外观。
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "email-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-cn/email-setup
|
||||
---
|
||||
|
||||
# Email 设置
|
||||
|
||||
Gitea 具有邮件功能，用于发送事务性邮件（例如注册确认邮件）。它可以配置为使用 Sendmail（或兼容的 MTA，例如 Postfix 和 msmtp）或直接使用 SMTP 服务器。
|
||||
|
||||
## 使用 Sendmail
|
||||
|
||||
使用 `sendmail` 命令作为邮件传输代理（mailer）。
|
||||
|
||||
注意：对于在官方 Gitea Docker 镜像中使用，请使用 SMTP 版本进行配置（请参考下一节）。
|
||||
|
||||
注意：对于面向互联网的网站，请查阅您的 MTA 文档以了解通过 TLS 发送邮件的说明。同时设置 SPF、DMARC 和 DKIM DNS 记录，以使发送的邮件被各个电子邮件提供商接受为合法邮件。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = gitea@mydomain.com
|
||||
MAILER_TYPE = sendmail
|
||||
SENDMAIL_PATH = /usr/sbin/sendmail
|
||||
SENDMAIL_ARGS = "--" ; 大多数 "sendmail" 程序都接受选项，使用 "--" 将防止电子邮件地址被解释为选项。
|
||||
```
|
||||
|
||||
## 使用 SMTP
|
||||
|
||||
直接使用 SMTP 服务器作为中继。如果您不想在实例上设置 MTA，但在电子邮件提供商那里有一个帐户，这个选项非常有用。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = gitea@mydomain.com
|
||||
MAILER_TYPE = smtp
|
||||
SMTP_ADDR = mail.mydomain.com
|
||||
SMTP_PORT = 587
|
||||
IS_TLS_ENABLED = true
|
||||
USER = gitea@mydomain.com
|
||||
PASSWD = `password`
|
||||
```
|
||||
|
||||
重启 Gitea 以使配置更改生效。
|
||||
|
||||
要发送测试邮件以验证设置，请转到 Gitea > 站点管理 > 配置 > SMTP 邮件配置。
|
||||
|
||||
有关所有选项的完整列表，请查看[配置速查表](../administration/config-cheat-sheet.md)。
|
||||
|
||||
请注意：只有在使用 TLS 或 `HOST=localhost` 加密 SMTP 服务器通信时才支持身份验证。TLS 加密可以通过以下方式进行：
|
||||
|
||||
- 通过端口 587 的 STARTTLS（也称为 Opportunistic TLS）。初始连接是明文的，但如果服务器支持，则可以升级为 TLS。
|
||||
- 通过默认端口 465 的 SMTPS 连接。连接到服务器从一开始就使用 TLS。
|
||||
- 使用 `IS_TLS_ENABLED=true` 进行强制的 SMTPS 连接。（这两种方式都被称为 Implicit TLS）
|
||||
这是由于 Go 内部库对 STRIPTLS 攻击的保护机制。
|
||||
|
||||
请注意，自 2018 年起，[RFC8314](https://tools.ietf.org/html/rfc8314#section-3) 推荐使用 Implicit TLS。
|
||||
|
||||
### Gmail
|
||||
|
||||
以下配置应该适用于 Gmail 的 SMTP 服务器：
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
HOST = smtp.gmail.com:465 ; 对于 Gitea >= 1.18.0，删除此行
|
||||
SMTP_ADDR = smtp.gmail.com
|
||||
SMTP_PORT = 465
|
||||
FROM = example.user@gmail.com
|
||||
USER = example.user
|
||||
PASSWD = `***`
|
||||
MAILER_TYPE = smtp
|
||||
IS_TLS_ENABLED = true
|
||||
```
|
||||
|
||||
请注意，您需要创建并使用一个 [应用密码](https://support.google.com/accounts/answer/185833?hl=en) 并在您的 Google 帐户上启用 2FA。您将无法直接使用您的 Google 帐户密码。
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
date: "2017-04-08T11:34:00+02:00"
|
||||
slug: "environment-variables"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# 环境变量清单
|
||||
|
||||
这里是用来控制 Gitea 行为表现的的环境变量清单，您需要在执行如下 Gitea 启动命令前设置它们来确保配置生效：
|
||||
|
||||
```
|
||||
GITEA_CUSTOM=/home/gitea/custom ./gitea web
|
||||
```
|
||||
|
||||
## Go 的配置
|
||||
|
||||
因为 Gitea 使用 Go 语言编写，因此它使用了一些相关的 Go 的配置参数：
|
||||
|
||||
* `GOOS`
|
||||
* `GOARCH`
|
||||
* [`GOPATH`](https://golang.org/cmd/go/#hdr-GOPATH_environment_variable)
|
||||
|
||||
您可以在[官方文档](https://golang.org/cmd/go/#hdr-Environment_variables)中查阅这些配置参数的详细信息。
|
||||
|
||||
## Gitea 的文件目录
|
||||
|
||||
* `GITEA_WORK_DIR`：工作目录的绝对路径
|
||||
* `GITEA_CUSTOM`：默认情况下 Gitea 使用默认目录 `GITEA_WORK_DIR`/custom，您可以使用这个参数来配置 *custom* 目录
|
||||
* `GOGS_WORK_DIR`： 已废弃，请使用 `GITEA_WORK_DIR` 替代
|
||||
* `GOGS_CUSTOM`： 已废弃，请使用 `GITEA_CUSTOM` 替代
|
||||
|
||||
## 操作系统配置
|
||||
|
||||
* `USER`：Gitea 运行时使用的系统用户，它将作为一些 repository 的访问地址的一部分
|
||||
* `USERNAME`： 如果没有配置 `USER`， Gitea 将使用 `USERNAME`
|
||||
* `HOME`： 用户的 home 目录，在 Windows 中会使用 `USERPROFILE` 环境变量
|
||||
|
||||
### 仅限于 Windows 的配置
|
||||
|
||||
* `USERPROFILE`： 用户的主目录，如果未配置则会使用 `HOMEDRIVE` + `HOMEPATH`
|
||||
* `HOMEDRIVE`: 用于访问 home 目录的主驱动器路径（C盘）
|
||||
* `HOMEPATH`：在指定主驱动器下的 home 目录相对路径
|
||||
|
||||
## Miscellaneous
|
||||
|
||||
* `SKIP_MINWINSVC`：如果设置为 1，在 Windows 上不会以 service 的形式运行。
|
||||
@@ -1,195 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "external-renderers"
|
||||
sidebar_position: 60
|
||||
aliases:
|
||||
- /zh-cn/external-renderers
|
||||
---
|
||||
|
||||
# 外部渲染器
|
||||
|
||||
Gitea 通过外部二进制文件支持自定义文件渲染（例如 Jupyter notebooks、asciidoc 等），只需要进行以下步骤：
|
||||
|
||||
- 安装外部二进制文件
|
||||
- 在您的 `app.ini` 文件中添加一些配置
|
||||
- 重新启动 Gitea 实例
|
||||
|
||||
此功能支持整个文件的渲染。如果您想要在 Markdown 中渲染代码块，您需要使用 JavaScript 进行一些操作。请参阅 [自定义 Gitea 配置](../administration/customizing-gitea.md) 页面上的一些示例。
|
||||
|
||||
## 安装外部二进制文件
|
||||
|
||||
为了通过外部二进制文件进行文件渲染，必须安装它们的关联软件包。
|
||||
如果您正在使用 Docker 镜像，则您的 `Dockerfile` 应该包含以下内容：
|
||||
|
||||
```docker
|
||||
FROM docker.gitea.com/gitea:@dockerVersion@
|
||||
[...]
|
||||
|
||||
COPY custom/app.ini /data/gitea/conf/app.ini
|
||||
[...]
|
||||
|
||||
RUN apk --no-cache add asciidoctor freetype freetype-dev gcc g++ libpng libffi-dev py-pip python3-dev py3-pip py3-pyzmq
|
||||
# 安装其他您需要的外部渲染器的软件包
|
||||
|
||||
RUN pip3 install --upgrade pip
|
||||
RUN pip3 install -U setuptools
|
||||
RUN pip3 install jupyter docutils
|
||||
# 在上面添加您需要安装的任何其他 Python 软件包
|
||||
```
|
||||
|
||||
## `app.ini` 文件配置
|
||||
|
||||
在您的自定义 `app.ini` 文件中为每个外部渲染器添加一个 `[markup.XXXXX]` 部分：
|
||||
|
||||
```ini
|
||||
[markup.asciidoc]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .adoc,.asciidoc
|
||||
RENDER_COMMAND = "asciidoctor -s -a showtitle --out-file=- -"
|
||||
; 输入不是标准输入而是文件
|
||||
IS_INPUT_FILE = false
|
||||
|
||||
[markup.jupyter]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .ipynb
|
||||
RENDER_COMMAND = "jupyter nbconvert --stdin --stdout --to html --template basic"
|
||||
IS_INPUT_FILE = false
|
||||
|
||||
[markup.restructuredtext]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .rst
|
||||
RENDER_COMMAND = "timeout 30s pandoc +RTS -M512M -RTS -f rst"
|
||||
IS_INPUT_FILE = false
|
||||
```
|
||||
|
||||
如果您的外部标记语言依赖于在生成的 HTML 元素上的额外类和属性，您可能需要启用自定义的清理策略。Gitea 使用 [`bluemonday`](https://godoc.org/github.com/microcosm-cc/bluemonday) 包作为我们的 HTML 清理器。下面的示例可以用于支持从 [`pandoc`](https://pandoc.org/) 输出的服务器端 [KaTeX](https://katex.org/) 渲染结果。
|
||||
|
||||
```ini
|
||||
[markup.sanitizer.TeX]
|
||||
; Pandoc 渲染 TeX 段落为带有 "math" 类的 <span> 元素，根据上下文可能还带有 "inline" 或 "display" 类。
|
||||
; - 请注意，这与我们的 Markdown 解析器中内置的数学支持不同，后者使用 <code> 元素。
|
||||
ELEMENT = span
|
||||
ALLOW_ATTR = class
|
||||
REGEXP = ^\s*((math(\s+|$)|inline(\s+|$)|display(\s+|$)))+
|
||||
|
||||
[markup.markdown]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .md,.markdown
|
||||
RENDER_COMMAND = pandoc -f markdown -t html --katex
|
||||
```
|
||||
|
||||
您必须在每个部分中定义 `ELEMENT` 和 `ALLOW_ATTR`。
|
||||
|
||||
要定义多个条目，请添加唯一的字母数字后缀（例如，`[markup.sanitizer.1]` 和 `[markup.sanitizer.something]`）。
|
||||
|
||||
要仅为特定的外部渲染器应用清理规则，它们必须使用渲染器名称，例如 `[markup.sanitizer.asciidoc.rule-1]`、`[markup.sanitizer.<renderer>.rule-1]`。
|
||||
|
||||
**注意**：如果规则在渲染器 ini 部分之前定义，或者名称与渲染器不匹配，它将应用于所有渲染器。
|
||||
|
||||
完成配置更改后，请重新启动 Gitea 以使更改生效。
|
||||
|
||||
**注意**：在 Gitea 1.12 之前，存在一个名为 `markup.sanitiser` 的单个部分，其中的键被重新定义为多个规则，但是，这种配置方法存在重大问题，需要通过多个部分进行配置。
|
||||
|
||||
### 示例：HTML
|
||||
|
||||
直接渲染 HTML 文件：
|
||||
|
||||
```ini
|
||||
[markup.html]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .html,.htm
|
||||
RENDER_COMMAND = cat
|
||||
; 输入不是标准输入，而是文件
|
||||
IS_INPUT_FILE = true
|
||||
|
||||
[markup.sanitizer.html.1]
|
||||
ELEMENT = div
|
||||
ALLOW_ATTR = class
|
||||
|
||||
[markup.sanitizer.html.2]
|
||||
ELEMENT = a
|
||||
ALLOW_ATTR = class
|
||||
```
|
||||
|
||||
请注意：此示例中的配置将允许渲染 HTML 文件，并使用 `cat` 命令将文件内容输出为 HTML。此外，配置中的两个清理规则将允许 `<div>` 和 `<a>` 元素使用 `class` 属性。
|
||||
|
||||
在进行配置更改后，请重新启动 Gitea 以使更改生效。
|
||||
|
||||
### 示例：Office DOCX
|
||||
|
||||
使用 [`pandoc`](https://pandoc.org/) 显示 Office DOCX 文件：
|
||||
|
||||
```ini
|
||||
[markup.docx]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .docx
|
||||
RENDER_COMMAND = "pandoc --from docx --to html --self-contained --template /path/to/basic.html"
|
||||
|
||||
[markup.sanitizer.docx.img]
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
在此示例中，配置将允许显示 Office DOCX 文件，并使用 `pandoc` 命令将文件转换为 HTML 格式。同时，清理规则中的 `ALLOW_DATA_URI_IMAGES` 设置为 `true`，允许使用 Data URI 格式的图片。
|
||||
|
||||
模板文件的内容如下：
|
||||
|
||||
```
|
||||
$body$
|
||||
```
|
||||
|
||||
### 示例：Jupyter Notebook
|
||||
|
||||
使用 [`nbconvert`](https://github.com/jupyter/nbconvert) 显示 Jupyter Notebook 文件：
|
||||
|
||||
```ini
|
||||
[markup.jupyter]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .ipynb
|
||||
RENDER_COMMAND = "jupyter-nbconvert --stdin --stdout --to html --template basic"
|
||||
|
||||
[markup.sanitizer.jupyter.img]
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
在此示例中，配置将允许显示 Jupyter Notebook 文件，并使用 `nbconvert` 命令将文件转换为 HTML 格式。同样，清理规则中的 `ALLOW_DATA_URI_IMAGES` 设置为 `true`，允许使用 Data URI 格式的图片。
|
||||
|
||||
在进行配置更改后，请重新启动 Gitea 以使更改生效。
|
||||
|
||||
## 自定义 CSS
|
||||
|
||||
在 `.ini` 文件中，可以使用 `[markup.XXXXX]` 的格式指定外部渲染器，并且由外部渲染器生成的 HTML 将被包装在一个带有 `markup` 和 `XXXXX` 类的 `<div>` 中。`markup` 类提供了预定义的样式（如果 `XXXXX` 是 `markdown`，则使用 `markdown` 类）。否则，您可以使用这些类来针对渲染的 HTML 内容进行定制样式。
|
||||
|
||||
因此，您可以编写一些 CSS 样式：
|
||||
|
||||
```css
|
||||
.markup.XXXXX html {
|
||||
font-size: 100%;
|
||||
overflow-y: scroll;
|
||||
-webkit-text-size-adjust: 100%;
|
||||
-ms-text-size-adjust: 100%;
|
||||
}
|
||||
|
||||
.markup.XXXXX body {
|
||||
color: #444;
|
||||
font-family: Georgia, Palatino, "Palatino Linotype", Times, "Times New Roman",
|
||||
serif;
|
||||
font-size: 12px;
|
||||
line-height: 1.7;
|
||||
padding: 1em;
|
||||
margin: auto;
|
||||
max-width: 42em;
|
||||
background: #fefefe;
|
||||
}
|
||||
|
||||
.markup.XXXXX p {
|
||||
color: orangered;
|
||||
}
|
||||
```
|
||||
|
||||
将您的样式表添加到自定义目录中，例如 `custom/public/css/my-style-XXXXX.css`，并使用自定义的头文件 `custom/templates/custom/header.tmpl` 进行导入：
|
||||
|
||||
```html
|
||||
<link rel="stylesheet" href="{{AppSubUrl}}/assets/css/my-style-XXXXX.css" />
|
||||
```
|
||||
|
||||
通过以上步骤，您可以将自定义的 CSS 样式应用到特定的外部渲染器，使其具有所需的样式效果。
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
date: "2022-08-01T00:00:00+00:00"
|
||||
slug: "fail2ban-setup"
|
||||
sidebar_position: 16
|
||||
---
|
||||
|
||||
# 设置 Fail2ban
|
||||
|
||||
**Fail2ban 检查客户端登录日志，将多次登录失败的客户端识别为攻击者并在一段时间内阻止其访问服务。如果你的实例是公开的，这一点尤其重要。请管理员仔细设置 fail2ban，错误的配置将导致防火墙阻止你访问自己的服务器。**
|
||||
|
||||
Gitea 会在日志文件 `log/gitea.log` 中记录登录失败的 CLI、SSH 或 HTTP 客户端 IP 地址，而你需要将 Gitea 的日志输出模式从默认的 `console` 更改为 `file`。这表示将日志输出到文件，使得 fail2ban 可以定期扫描日志内容。
|
||||
|
||||
当用户的身份验证失败时，日志中会记录此类信息：
|
||||
|
||||
```log
|
||||
2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
```log
|
||||
2020/10/15 16:08:44 [E] invalid credentials from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
## Fail2ban 规则
|
||||
|
||||
添加日志过滤器规则到配置文件 `/etc/fail2ban/filter.d/gitea.conf`:
|
||||
|
||||
```ini
|
||||
[Definition]
|
||||
failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST>
|
||||
ignoreregex =
|
||||
```
|
||||
|
||||
添加监狱规则到配置文件 `/etc/fail2ban/jail.d/gitea.conf`:
|
||||
|
||||
```ini
|
||||
[gitea]
|
||||
enabled = true
|
||||
filter = gitea
|
||||
logpath = /var/lib/gitea/log/gitea.log
|
||||
maxretry = 10
|
||||
findtime = 3600
|
||||
bantime = 900
|
||||
action = iptables-allports
|
||||
```
|
||||
|
||||
如果你的 Gitea 实例运行在 Docker 容器中，并且直接将容器端口暴露到外部网络，
|
||||
你还需要添加 `chain="FORWARD"` 到监狱规则配置文件 `/etc/fail2ban/jail.d/gitea-docker.conf`
|
||||
以适应 Docker 的网络转发规则。但如果你在容器的宿主机上使用 Nginx 反向代理连接到 Gitea 则无需这样配置。
|
||||
|
||||
```ini
|
||||
[gitea-docker]
|
||||
enabled = true
|
||||
filter = gitea
|
||||
logpath = /var/lib/gitea/log/gitea.log
|
||||
maxretry = 10
|
||||
findtime = 3600
|
||||
bantime = 900
|
||||
action = iptables-allports[chain="FORWARD"]
|
||||
```
|
||||
|
||||
最后，运行 `systemctl restart fail2ban` 即可应用更改。现在，你可以使用 `systemctl status fail2ban` 检查 fail2ban 运行状态。
|
||||
|
||||
上述规则规定客户端在 1 小时内，如果登录失败的次数达到 10 次，则通过 iptables 锁定该客户端 IP 地址 15 分钟。
|
||||
|
||||
## 设置反向代理
|
||||
|
||||
如果你使用 Nginx 反向代理到 Gitea 实例，你还需要设置 Nginx 的 HTTP 头部值 `X-Real-IP` 将真实的客户端 IP 地址传递给 Gitea。否则 Gitea 程序会将客户端地址错误解析为反向代理服务器的地址，例如回环地址 `127.0.0.1`。
|
||||
|
||||
```
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
```
|
||||
|
||||
额外注意，在 Gitea 的配置文件 `app.ini` 中存在下列默认值：
|
||||
|
||||
```
|
||||
REVERSE_PROXY_LIMIT = 1
|
||||
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.0/8,::1/128
|
||||
```
|
||||
|
||||
`REVERSE_PROXY_LIMIT` 限制反向代理服务器的层数，设置为 `0` 表示不使用这些标头。
|
||||
`REVERSE_PROXY_TRUSTED_PROXIES` 表示受信任的反向代理服务器网络地址，
|
||||
经过该网络地址转发来的流量会经过解析 `X-Real-IP` 头部得到真实客户端地址。
|
||||
（参考 [configuration cheat sheet](https://docs.gitea.io/en-us/config-cheat-sheet/#安全性)）
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "git-lfs-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-cn/git-lfs-setup
|
||||
---
|
||||
|
||||
# Git LFS 设置
|
||||
|
||||
要使用 Gitea 内置的 LFS 支持，您需要更新 `app.ini` 文件：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
; 启用 git-lfs 支持。true 或 false，默认为 false。
|
||||
LFS_START_SERVER = true
|
||||
|
||||
[lfs]
|
||||
; 存放 LFS 文件的路径，默认为 data/lfs。
|
||||
PATH = /home/gitea/data/lfs
|
||||
```
|
||||
|
||||
**注意**：LFS 服务器支持需要服务器上安装 Git v2.1.2 以上版本。
|
||||
@@ -1,259 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "logging-config"
|
||||
sidebar_position: 40
|
||||
aliases:
|
||||
- /zh-cn/logging-configuration
|
||||
---
|
||||
|
||||
# 日志配置
|
||||
|
||||
Gitea 的日志配置主要由以下三种类型的组件组成：
|
||||
|
||||
- `[log]` 部分用于一般配置
|
||||
- `[log.<mode-name>]` 部分用于配置不同的日志输出方式，也称为 "writer mode"，模式名称同时也作为 "writer name"
|
||||
- `[log]` 部分还可以包含遵循 `logger.<logger-name>.<CONFIG-KEY>` 模式的子日志记录器的配置
|
||||
|
||||
默认情况下，已经有一个完全功能的日志输出，因此不需要重新定义。
|
||||
|
||||
## `[log]` 部分
|
||||
|
||||
在 Gitea 中，日志设施的配置在 `[log]` 部分及其子部分。
|
||||
|
||||
在顶层的 `[log]` 部分，可以放置以下配置项：
|
||||
|
||||
- `ROOT_PATH`：（默认值：**%(GITEA_WORK_DIR)/log**）：日志文件的基本路径。
|
||||
- `MODE`：（默认值：**console**）：要用于默认日志记录器的日志输出列表。
|
||||
- `LEVEL`：（默认值：**Info**）：要持久化的最严重的日志事件，不区分大小写。可能的值为：`Trace`、`Debug`、`Info`、`Warn`、`Error`、`Fatal`。
|
||||
- `STACKTRACE_LEVEL`：（默认值：**None**）：对于此类及更严重的事件，将在记录时打印堆栈跟踪。
|
||||
|
||||
它还可以包含以下子日志记录器：
|
||||
|
||||
- `logger.router.MODE`：（默认值：**,**）：用于路由器日志记录器的日志输出列表。
|
||||
- `logger.access.MODE`：（默认值：**_empty_**）：用于访问日志记录器的日志输出列表。默认情况下，访问日志记录器被禁用。
|
||||
- `logger.xorm.MODE`：（默认值：**,**）：用于 XORM 日志记录器的日志输出列表。
|
||||
|
||||
将子日志记录器的模式设置为逗号（`,`）表示使用默认的全局 `MODE`。
|
||||
|
||||
## 快速示例
|
||||
|
||||
### 默认（空）配置
|
||||
|
||||
空配置等同于默认配置：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
ROOT_PATH = %(GITEA_WORK_DIR)/log
|
||||
MODE = console
|
||||
LEVEL = Info
|
||||
STACKTRACE_LEVEL = None
|
||||
logger.router.MODE = ,
|
||||
logger.xorm.MODE = ,
|
||||
logger.access.MODE =
|
||||
|
||||
; 这是“控制台”模式的配置选项（由上面的 MODE=console 使用）
|
||||
[log.console]
|
||||
MODE = console
|
||||
FLAGS = stdflags
|
||||
PREFIX =
|
||||
COLORIZE = true
|
||||
```
|
||||
|
||||
这等同于将所有日志发送到控制台，并将默认的 Golang 日志也发送到控制台日志中。
|
||||
|
||||
这只是一个示例，默认情况下不需要将其写入配置文件中。
|
||||
|
||||
### 禁用路由日志并将一些访问日志记录到文件中
|
||||
|
||||
禁用路由日志，将访问日志（>=Warn）记录到 `access.log` 中：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
logger.router.MODE =
|
||||
logger.access.MODE = access-file
|
||||
|
||||
[log.access-file]
|
||||
MODE = file
|
||||
LEVEL = Warn
|
||||
FILE_NAME = access.log
|
||||
```
|
||||
|
||||
### 为不同的模式设置不同的日志级别
|
||||
|
||||
将默认日志（>=Warn）记录到 `gitea.log` 中，将错误日志记录到 `file-error.log` 中：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
LEVEL = Warn
|
||||
MODE = file, file-error
|
||||
|
||||
; 默认情况下，"file" 模式会将日志记录到 %(log.ROOT_PATH)/gitea.log，因此我们不需要设置它
|
||||
; [log.file]
|
||||
|
||||
[log.file-error]
|
||||
LEVEL = Error
|
||||
FILE_NAME = file-error.log
|
||||
```
|
||||
|
||||
## 日志输出（模式和写入器）
|
||||
|
||||
Gitea 提供以下日志写入器：
|
||||
|
||||
- `console` - 输出日志到 `stdout`（或 `stderr`，如果已在配置中设置）
|
||||
- `file` - 输出日志到文件
|
||||
- `conn` - 输出日志到套接字（网络或 Unix 套接字）
|
||||
|
||||
### 公共配置
|
||||
|
||||
某些配置适用于所有日志输出模式：
|
||||
|
||||
- `MODE` 是日志输出写入器的模式。它将默认为 ini 部分的模式名称。因此，`[log.console]` 将默认为 `MODE = console`。
|
||||
- `LEVEL` 是此输出将记录的最低日志级别。
|
||||
- `STACKTRACE_LEVEL` 是此输出将打印堆栈跟踪的最低日志级别。
|
||||
- `COLORIZE` 对于 `console`，默认为 `true`，否则默认为 `false`。
|
||||
|
||||
#### `EXPRESSION`
|
||||
|
||||
`EXPRESSION` 表示日志事件必须匹配才能被输出写入器记录的正则表达式。
|
||||
日志消息（去除颜色）或 `longfilename:linenumber:functionname` 必须匹配其中之一。
|
||||
注意：整个消息或字符串不需要完全匹配。
|
||||
|
||||
请注意，此表达式将在写入器的 goroutine 中运行，而不是在日志事件的 goroutine 中运行。
|
||||
|
||||
#### `FLAGS`
|
||||
|
||||
`FLAGS` 表示在每条消息之前打印的前置日志上下文信息。
|
||||
它是一个逗号分隔的字符串集。值的顺序无关紧要。
|
||||
|
||||
默认值为 `stdflags`（= `date,time,medfile,shortfuncname,levelinitial`）。
|
||||
|
||||
可能的值为：
|
||||
|
||||
- `none` 或 `,` - 无标志。
|
||||
- `date` - 当地时区的日期：`2009/01/23`。
|
||||
- `time` - 当地时区的时间：`01:23:23`。
|
||||
- `microseconds` - 微秒精度：`01:23:23.123123`。假定有时间。
|
||||
- `longfile` - 完整的文件名和行号：`/a/b/c/d.go:23`。
|
||||
- `shortfile` - 文件名的最后一个部分和行号：`d.go:23`。
|
||||
- `funcname` - 调用者的函数名：`runtime.Caller()`。
|
||||
- `shortfuncname` - 函数名的最后一部分。覆盖 `funcname`。
|
||||
- `utc` - 如果设置了日期或时间，则使用 UTC 而不是本地时区。
|
||||
- `levelinitial` - 提供的级别的初始字符，放在方括号内，例如 `[I]` 表示 info。
|
||||
- `level` - 在方括号内的级别，例如 `[INFO]`。
|
||||
- `gopid` - 上下文的 Goroutine-PID。
|
||||
- `medfile` - 文件名的最后 20 个字符 - 相当于 `shortfile,longfile`。
|
||||
- `stdflags` - 相当于 `date,time,medfile,shortfuncname,levelinitial`。
|
||||
|
||||
### Console 模式
|
||||
|
||||
在此模式下，日志记录器将将日志消息转发到 Gitea 进程附加的 stdout 和 stderr 流。
|
||||
|
||||
对于 console 模式的日志记录器，如果不在 Windows 上，或者 Windows 终端可以设置为 ANSI 模式，或者是 cygwin 或 Msys 管道，则 `COLORIZE` 默认为 `true`。
|
||||
|
||||
设置：
|
||||
|
||||
- `STDERR`：**false**：日志记录器是否应将日志打印到 `stderr` 而不是 `stdout`。
|
||||
|
||||
### File 模式
|
||||
|
||||
在此模式下，日志记录器将将日志消息保存到文件中。
|
||||
|
||||
设置：
|
||||
|
||||
- `FILE_NAME`：要将日志事件写入的文件，相对于 `ROOT_PATH`，默认为 `%(ROOT_PATH)/gitea.log`。异常情况：访问日志默认为 `%(ROOT_PATH)/access.log`。
|
||||
- `MAX_SIZE_SHIFT`：**28**：单个文件的最大大小位移。28 表示 256Mb。详细信息见下文。
|
||||
- `LOG_ROTATE` **true**：是否轮转日志文件。
|
||||
- `DAILY_ROTATE`：**true**：是否每天旋转日志。
|
||||
- `MAX_DAYS`：**7**：在此天数之后删除旋转的日志文件。
|
||||
- `COMPRESS`：**true**：默认情况下是否使用 gzip 压缩旧的日志文件。
|
||||
- `COMPRESSION_LEVEL`：**-1**：压缩级别。详细信息见下文。
|
||||
|
||||
`MAX_SIZE_SHIFT` 通过将给定次数左移 1 (`1 << x`) 来定义文件的最大大小。
|
||||
在 v1.17.3 版本时的确切行为可以在[这里](https://github.com/go-gitea/gitea/blob/v1.17.3/modules/setting/log.go#L185)中查看。
|
||||
|
||||
`COMPRESSION_LEVEL` 的有用值范围从 1 到（包括）9，其中较高的数字表示更好的压缩。
|
||||
请注意，更好的压缩可能会带来更高的资源使用。
|
||||
必须在前面加上 `-` 符号。
|
||||
|
||||
### Conn 模式
|
||||
|
||||
在此模式下，日志记录器将通过网络套接字发送日志消息。
|
||||
|
||||
设置：
|
||||
|
||||
- `ADDR`：**:7020**：设置要连接的地址。
|
||||
- `PROTOCOL`：**tcp**：设置协议，可以是 "tcp"、"unix" 或 "udp"。
|
||||
- `RECONNECT`：**false**：在连接丢失时尝试重新连接。
|
||||
- `RECONNECT_ON_MSG`：**false**：为每条消息重新连接主机。
|
||||
|
||||
### "Router" 日志记录器
|
||||
|
||||
当 Gitea 的路由处理程序工作时，Router 日志记录器记录以下消息类型：
|
||||
|
||||
- `started` 消息将以 TRACE 级别记录
|
||||
- `polling`/`completed` 路由将以 INFO 级别记录。异常情况："/assets" 静态资源请求也会以 TRACE 级别记录。
|
||||
- `slow` 路由将以 WARN 级别记录
|
||||
- `failed` 路由将以 WARN 级别记录
|
||||
|
||||
### "XORM" 日志记录器
|
||||
|
||||
为了使 XORM 输出 SQL 日志，还应将 `[database]` 部分中的 `LOG_SQL` 设置为 `true`。
|
||||
|
||||
### "Access" 日志记录器
|
||||
|
||||
"Access" 日志记录器是自 Gitea 1.9 版本以来的新日志记录器。它提供了符合 NCSA Common Log 标准的日志格式。虽然它具有高度可配置性，但在更改其模板时应谨慎。此日志记录器的主要好处是，Gitea 现在可以使用标准日志格式记录访问日志，因此可以使用标准工具进行分析。
|
||||
|
||||
您可以通过使用 `logger.access.MODE = ...` 来启用此日志记录器。
|
||||
|
||||
如果需要，可以通过更改 `ACCESS_LOG_TEMPLATE` 的值来更改 "Access" 日志记录器的格式。
|
||||
|
||||
请注意，访问日志记录器将以 `INFO` 级别记录，将此日志记录器的 `LEVEL` 设置为 `WARN` 或更高级别将导致不记录访问日志。
|
||||
|
||||
#### ACCESS_LOG_TEMPLATE
|
||||
|
||||
此值表示一个 Go 模板。其默认值为
|
||||
|
||||
```tmpl
|
||||
{{.Ctx.RemoteHost}} - {{.Identity}} {{.Start.Format "[02/Jan/2006:15:04:05 -0700]" }} "{{.Ctx.Req.Method}} {{.Ctx.Req.URL.RequestURI}} {{.Ctx.Req.Proto}}" {{.ResponseWriter.Status}} {{.ResponseWriter.Size}} "{{.Ctx.Req.Referer}}" "{{.Ctx.Req.UserAgent}}"`
|
||||
```
|
||||
|
||||
模板接收以下选项：
|
||||
|
||||
- `Ctx` 是 `context.Context`
|
||||
- `Identity` 是 `SignedUserName`，如果用户未登录，则为 "-"
|
||||
- `Start` 是请求的开始时间
|
||||
- `ResponseWriter` 是 `http.ResponseWriter`
|
||||
|
||||
更改此模板时必须小心，因为它在标准的 panic 恢复陷阱之外运行。此模板应该尽可能简单，因为它会为每个请求运行一次。
|
||||
|
||||
## 释放和重新打开、暂停和恢复日志记录
|
||||
|
||||
如果您在 Unix 上运行，您可能希望释放和重新打开日志以使用 `logrotate` 或其他工具。
|
||||
可以通过向运行中的进程发送 `SIGUSR1` 信号或运行 `gitea manager logging release-and-reopen` 命令来强制 Gitea 释放并重新打开其日志文件和连接。
|
||||
|
||||
或者，您可能希望暂停和恢复日志记录 - 可以通过使用 `gitea manager logging pause` 和 `gitea manager logging resume` 命令来实现。请注意，当日志记录暂停时，低于 INFO 级别的日志事件将不会存储，并且只会存储有限数量的事件。在暂停时，日志记录可能会阻塞，尽管是暂时性的，但会大大减慢 Gitea 的运行速度，因此建议仅暂停很短的时间。
|
||||
|
||||
### 在 Gitea 运行时添加和删除日志记录
|
||||
|
||||
可以使用 `gitea manager logging add` 和 `remove` 子命令在 Gitea 运行时添加和删除日志记录。
|
||||
此功能只能调整正在运行的日志系统，不能用于启动未初始化的访问或路由日志记录器。如果您希望启动这些系统，建议调整 app.ini 并（优雅地）重新启动 Gitea 服务。
|
||||
|
||||
这些命令的主要目的是在运行中的系统上轻松添加临时日志记录器，以便调查问题，因为重新启动可能会导致问题消失。
|
||||
|
||||
## 使用 `logrotate` 而不是内置的日志轮转
|
||||
|
||||
Gitea 包含内置的日志轮转功能，对于大多数部署来说应该已经足够了。但是，如果您想使用 `logrotate` 工具：
|
||||
|
||||
- 在 `app.ini` 中将 `LOG_ROTATE` 设置为 `false`，禁用内置的日志轮转。
|
||||
- 安装 `logrotate`。
|
||||
- 根据部署要求配置 `logrotate`，有关配置语法细节，请参阅 `man 8 logrotate`。
|
||||
在 `postrotate/endscript` 块中通过 `kill -USR1` 或 `kill -10` 向 `gitea` 进程本身发送 `USR1` 信号，
|
||||
或者运行 `gitea manager logging release-and-reopen`（使用适当的环境设置）。
|
||||
确保配置适用于由 Gitea 日志记录器生成的所有文件，如上述部分所述。
|
||||
- 始终使用 `logrotate /etc/logrotate.conf --debug` 来测试您的配置。
|
||||
- 如果您正在使用 Docker 并从容器外部运行，您可以使用
|
||||
`docker exec -u $OS_USER $CONTAINER_NAME sh -c 'gitea manager logging release-and-reopen'`
|
||||
或 `docker exec $CONTAINER_NAME sh -c '/bin/s6-svc -1 /etc/s6/gitea/'`，或直接向 Gitea 进程本身发送 `USR1` 信号。
|
||||
|
||||
下一个 `logrotate` 作业将包括您的配置，因此不需要重新启动。
|
||||
您还可以立即使用 `logrotate /etc/logrotate.conf --force` 重新加载 `logrotate`。
|
||||
@@ -1,254 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "mail-templates"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-cn/mail-templates
|
||||
---
|
||||
|
||||
# 邮件模板
|
||||
|
||||
为了定制特定操作的电子邮件主题和内容，可以使用模板来自定义 Gitea。这些功能的模板位于 [`custom` 目录](https://docs.gitea.io/en-us/customizing-gitea/) 下。
|
||||
如果没有自定义的替代方案，Gitea 将使用内部模板作为默认模板。
|
||||
|
||||
自定义模板在 Gitea 启动时加载。对它们的更改在 Gitea 重新启动之前不会被识别。
|
||||
|
||||
## 支持模板的邮件通知
|
||||
|
||||
目前，以下通知事件使用模板：
|
||||
|
||||
| 操作名称 | 用途 |
|
||||
| ---------- | ---------------------------------------------------------------------- |
|
||||
| `new` | 创建了新的工单或合并请求。 |
|
||||
| `comment` | 在现有工单或合并请求中创建了新的评论。 |
|
||||
| `close` | 关闭了工单或合并请求。 |
|
||||
| `reopen` | 重新打开了工单或合并请求。 |
|
||||
| `review` | 在合并请求中进行审查的首要评论。 |
|
||||
| `approve` | 对合并请求进行批准的首要评论。 |
|
||||
| `reject` | 对合并请求提出更改请求的审查的首要评论。 |
|
||||
| `code` | 关于合并请求的代码的单个评论。 |
|
||||
| `assigned` | 用户被分配到工单或合并请求。 |
|
||||
| `default` | 未包括在上述类别中的任何操作，或者当对应类别的模板不存在时使用的模板。 |
|
||||
|
||||
特定消息类型的模板路径为：
|
||||
|
||||
```sh
|
||||
custom/templates/mail/{操作类型}/{操作名称}.tmpl
|
||||
```
|
||||
|
||||
其中 `{操作类型}` 是 `issue` 或 `pull`（针对合并请求），`{操作名称}` 是上述列出的操作名称之一。
|
||||
|
||||
例如，有关合并请求中的评论的电子邮件的特定模板是：
|
||||
|
||||
```sh
|
||||
custom/templates/mail/pull/comment.tmpl
|
||||
```
|
||||
|
||||
然而，并不需要为每个操作类型/名称组合创建模板。
|
||||
使用回退系统来选择适当的模板。在此列表中，将使用 _第一个存在的_ 模板：
|
||||
|
||||
- 所需**操作类型**和**操作名称**的特定模板。
|
||||
- 操作类型为 `issue` 和所需**操作名称**的模板。
|
||||
- 所需**操作类型**和操作名称为 `default` 的模板。
|
||||
- 操作类型为` issue` 和操作名称为 `default` 的模板。
|
||||
|
||||
唯一必需的模板是操作类型为 `issue` 操作名称为 `default` 的模板，除非用户在 `custom` 目录中覆盖了它。
|
||||
|
||||
## 模板语法
|
||||
|
||||
邮件模板是 UTF-8 编码的文本文件，需要遵循以下格式之一：
|
||||
|
||||
```
|
||||
用于主题行的文本和宏
|
||||
------------
|
||||
用于邮件正文的文本和宏
|
||||
```
|
||||
|
||||
或者
|
||||
|
||||
```
|
||||
用于邮件正文的文本和宏
|
||||
```
|
||||
|
||||
指定 _主题_ 部分是可选的（因此也是虚线分隔符）。在使用时，_主题_ 和 _邮件正文_ 模板之间的分隔符需要至少三个虚线；分隔符行中不允许使用其他字符。
|
||||
|
||||
_主题_ 和 _邮件正文_ 由 [Golang 的模板引擎](https://golang.org/pkg/text/template/) 解析，并提供了为每个通知组装的 _元数据上下文_。上下文包含以下元素：
|
||||
|
||||
| 名称 | 类型 | 可用性 | 用途 |
|
||||
| ------------------ | ---------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `.FallbackSubject` | string | 始终可用 | 默认主题行。参见下文。 |
|
||||
| `.Subject` | string | 仅在正文中可用 | 解析后的 _主题_。 |
|
||||
| `.Body` | string | 始终可用 | 工单、合并请求或评论的消息，从 Markdown 解析为 HTML 并进行了清理。请勿与 _邮件正文_ 混淆。 |
|
||||
| `.Link` | string | 始终可用 | 源工单、合并请求或评论的地址。 |
|
||||
| `.Issue` | models.Issue | 始终可用 | 产生通知的工单（或合并请求）。要获取特定于合并请求的数据（例如 `HasMerged`），可以使用 `.Issue.PullRequest`，但需要注意，如果工单 _不是_ 合并请求，则该字段将为 `nil`。 |
|
||||
| `.Comment` | models.Comment | 如果适用 | 如果通知是针对添加到工单或合并请求的评论，则其中包含有关评论的信息。 |
|
||||
| `.IsPull` | bool | 始终可用 | 如果邮件通知与合并请求关联（即 `.Issue.PullRequest` 不为 `nil` ），则为 `true`。 |
|
||||
| `.Repo` | string | 始终可用 | 仓库的名称，包括所有者名称（例如 `mike/stuff`） |
|
||||
| `.User` | models.User | 始终可用 | 事件来源仓库的所有者。要获取用户名（例如 `mike`），可以使用 `.User.Name`。 |
|
||||
| `.Doer` | models.User | 始终可用 | 执行触发通知事件的操作的用户。要获取用户名（例如 `rhonda`），可以使用 `.Doer.Name`。 |
|
||||
| `.IsMention` | bool | 始终可用 | 如果此通知仅是因为在评论中提到了用户而生成的，并且收件人未订阅源，则为 `true`。如果收件人已订阅工单或仓库，则为 `false`。 |
|
||||
| `.SubjectPrefix` | string | 始终可用 | 如果通知是关于除工单或合并请求创建之外的其他内容，则为 `Re：`；否则为空字符串。 |
|
||||
| `.ActionType` | string | 始终可用 | `"issue"` 或 `"pull"`。它将与实际的 _操作类型_ 对应，与选择的模板无关。 |
|
||||
| `.ActionName` | string | 始终可用 | 它将是上述操作类型之一（`new` ，`comment` 等），并与选择的模板对应。 |
|
||||
| `.ReviewComments` | []models.Comment | 始终可用 | 审查中的代码评论列表。评论文本将在 `.RenderedContent` 中，引用的代码将在 `.Patch` 中。 |
|
||||
|
||||
所有名称区分大小写。
|
||||
|
||||
### 模板中的主题部分
|
||||
|
||||
用于邮件主题的模板引擎是 Golang 的 [`text/template`](https://golang.org/pkg/text/template/)。
|
||||
有关语法的详细信息，请参阅链接的文档。
|
||||
|
||||
主题构建的步骤如下：
|
||||
|
||||
- 根据通知类型和可用的模板选择一个模板。
|
||||
- 解析并解析模板（例如，将 `{{.Issue.Index}}` 转换为工单或合并请求的编号）。
|
||||
- 将所有空格字符（例如 `TAB`，`LF` 等）转换为普通空格。
|
||||
- 删除所有前导、尾随和多余的空格。
|
||||
- 将字符串截断为前 256 个字母（字符）。
|
||||
|
||||
如果最终结果为空字符串，**或者**没有可用的主题模板（即所选模板不包含主题部分），将使用 Gitea 的**内部默认值**。
|
||||
|
||||
内部默认（回退）主题相当于：
|
||||
|
||||
```
|
||||
{{.SubjectPrefix}}[{{.Repo}}] {{.Issue.Title}} (#{{.Issue.Index}})
|
||||
```
|
||||
|
||||
例如：`Re: [mike/stuff] New color palette (#38)`
|
||||
|
||||
即使存在有效的主题模板，Gitea 的默认主题也可以在模板的元数据中作为 `.FallbackSubject` 找到。
|
||||
|
||||
### 模板中的邮件正文部分
|
||||
|
||||
用于邮件正文的模板引擎是 Golang 的 [`html/template`](https://golang.org/pkg/html/template/)。
|
||||
有关语法的详细信息，请参阅链接的文档。
|
||||
|
||||
邮件正文在邮件主题之后进行解析，因此还有一个额外的 _元数据_ 字段，即在考虑所有情况之后实际呈现的主题。
|
||||
|
||||
期望的结果是 HTML（包括结构元素，如`<html>`，`<body>`等）。可以通过 `<style>` 块、`class` 和 `style` 属性进行样式设置。但是，`html/template` 会进行一些 [自动转义](https://golang.org/pkg/html/template/#hdr-Contexts)，需要考虑这一点。
|
||||
|
||||
不支持附件（例如图像或外部样式表）。但是，也可以引用其他模板，例如以集中方式提供 `<style>` 元素的内容。外部模板必须放置在 `custom/mail` 下，并相对于该目录引用。例如，可以使用 `{{template styles/base}}` 包含 `custom/mail/styles/base.tmpl`。
|
||||
|
||||
邮件以 `Content-Type: multipart/alternative` 发送，因此正文以 HTML 和文本格式发送。通过剥离 HTML 标记来获取文本版本。
|
||||
|
||||
## 故障排除
|
||||
|
||||
邮件的呈现方式直接取决于邮件应用程序的功能。许多邮件客户端甚至不支持 HTML，因此显示生成邮件中包含的文本版本。
|
||||
|
||||
如果模板无法呈现，则只有在发送邮件时才会注意到。
|
||||
如果主题模板失败，将使用默认主题，如果从 _邮件正文_ 中成功呈现了任何内容，则将使用该内容，忽略其他内容。
|
||||
|
||||
如果遇到问题，请检查 [Gitea 的日志](https://docs.gitea.io/en-us/logging-configuration/) 以获取错误消息。
|
||||
|
||||
## 示例
|
||||
|
||||
`custom/templates/mail/issue/default.tmpl`:
|
||||
|
||||
```html
|
||||
[{{.Repo}}] @{{.Doer.Name}}
|
||||
{{if eq .ActionName "new"}}
|
||||
创建了
|
||||
{{else if eq .ActionName "comment"}}
|
||||
评论了
|
||||
{{else if eq .ActionName "close"}}
|
||||
关闭了
|
||||
{{else if eq .ActionName "reopen"}}
|
||||
重新打开了
|
||||
{{else}}
|
||||
更新了
|
||||
{{end}}
|
||||
{{if eq .ActionType "issue"}}
|
||||
工单
|
||||
{{else}}
|
||||
合并请求
|
||||
{{end}}
|
||||
#{{.Issue.Index}}: {{.Issue.Title}}
|
||||
------------
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<title>{{.Subject}}</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
{{if .IsMention}}
|
||||
<p>
|
||||
您收到此邮件是因为 @{{.Doer.Name}} 提到了您。
|
||||
</p>
|
||||
{{end}}
|
||||
<p>
|
||||
<p>
|
||||
<a href="{{AppUrl}}/{{.Doer.LowerName}}">@{{.Doer.Name}}</a>
|
||||
{{if not (eq .Doer.FullName "")}}
|
||||
({{.Doer.FullName}})
|
||||
{{end}}
|
||||
{{if eq .ActionName "new"}}
|
||||
创建了
|
||||
{{else if eq .ActionName "close"}}
|
||||
关闭了
|
||||
{{else if eq .ActionName "reopen"}}
|
||||
重新打开了
|
||||
{{else}}
|
||||
更新了
|
||||
{{end}}
|
||||
<a href="{{.Link}}">{{.Repo}}#{{.Issue.Index}}</a>。
|
||||
</p>
|
||||
{{if not (eq .Body "")}}
|
||||
<h3>消息内容：</h3>
|
||||
<hr>
|
||||
{{.Body | Str2html}}
|
||||
{{end}}
|
||||
</p>
|
||||
<hr>
|
||||
<p>
|
||||
<a href="{{.Link}}">在 Gitea 上查看</a>。
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
该模板将生成以下内容：
|
||||
|
||||
### 主题
|
||||
|
||||
> [mike/stuff] @rhonda 在合并请求 #38 上进行了评论：New color palette
|
||||
|
||||
### 邮件正文
|
||||
|
||||
> [@rhonda](#)（Rhonda Myers）更新了 [mike/stuff#38](#)。
|
||||
>
|
||||
> #### 消息内容：
|
||||
>
|
||||
> \_******\*\*******\*\*\*\*******\*\*******\_******\*\*******\*\*\*\*******\*\*******
|
||||
>
|
||||
> Mike, I think we should tone down the blues a little.
|
||||
>
|
||||
> \_******\*\*******\*\*\*\*******\*\*******\_******\*\*******\*\*\*\*******\*\*******
|
||||
>
|
||||
> [在 Gitea 上查看](#)。
|
||||
|
||||
## 高级用法
|
||||
|
||||
模板系统包含一些函数，可用于进一步处理和格式化消息。以下是其中一些函数的列表：
|
||||
|
||||
| 函数名 | 参数 | 可用于 | 用法 |
|
||||
| ---------------- | ----------- | ---------- | --------------------------------------------------------------------- |
|
||||
| `AppUrl` | - | 任何地方 | Gitea 的 URL |
|
||||
| `AppName` | - | 任何地方 | 从 `app.ini` 中设置，通常为 "Gitea" |
|
||||
| `AppDomain` | - | 任何地方 | Gitea 的主机名 |
|
||||
| `EllipsisString` | string, int | 任何地方 | 将字符串截断为指定长度；根据需要添加省略号 |
|
||||
| `Str2html` | string | 仅正文部分 | 通过删除其中的 HTML 标签对文本进行清理 |
|
||||
| `Safe` | string | 仅正文部分 | 将输入作为 HTML 处理；可用于 `.ReviewComments.RenderedContent` 等字段 |
|
||||
|
||||
这些都是 _函数_，而不是元数据，因此必须按以下方式使用：
|
||||
|
||||
```html
|
||||
像这样使用： {{Str2html "Escape<my
|
||||
>text"}} 或者这样使用： {{"Escape<my
|
||||
>text" | Str2html}} 或者这样使用： {{AppUrl}} 但不要像这样使用：
|
||||
{{.AppUrl}}</my
|
||||
></my
|
||||
>
|
||||
```
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "repo-indexer"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-cn/repo-indexer
|
||||
---
|
||||
|
||||
# 仓库索引器
|
||||
|
||||
## 设置仓库索引器
|
||||
|
||||
通过在您的 [`app.ini`](https://docs.gitea.io/en-us/config-cheat-sheet/) 中启用此功能，Gitea 可以通过仓库的文件进行搜索：
|
||||
|
||||
```ini
|
||||
[indexer]
|
||||
; ...
|
||||
REPO_INDEXER_ENABLED = true
|
||||
REPO_INDEXER_PATH = indexers/repos.bleve
|
||||
MAX_FILE_SIZE = 1048576
|
||||
REPO_INDEXER_INCLUDE =
|
||||
REPO_INDEXER_EXCLUDE = resources/bin/**
|
||||
```
|
||||
|
||||
请记住，索引内容可能会消耗大量系统资源，特别是在首次创建索引或全局更新索引时（例如升级 Gitea 之后）。
|
||||
|
||||
### 按大小选择要索引的文件
|
||||
|
||||
`MAX_FILE_SIZE` 选项将使索引器跳过所有大于指定值的文件。
|
||||
|
||||
### 按路径选择要索引的文件
|
||||
|
||||
Gitea 使用 [`gobwas/glob` 库](https://github.com/gobwas/glob) 中的 glob 模式匹配来选择要包含在索引中的文件。
|
||||
|
||||
限制文件列表可以防止索引被派生或无关的文件（例如 lss、sym、map 等）污染，从而使搜索结果更相关。这还有助于减小索引的大小。
|
||||
|
||||
`REPO_INDEXER_EXCLUDE_VENDORED`（默认值为 true）将排除供应商文件不包含在索引中。
|
||||
|
||||
`REPO_INDEXER_INCLUDE`（默认值为空）是一个逗号分隔的 glob 模式列表，用于在索引中**包含**的文件。空列表表示“_包含所有文件_”。
|
||||
`REPO_INDEXER_EXCLUDE`（默认值为空）是一个逗号分隔的 glob 模式列表，用于从索引中**排除**的文件。与该列表匹配的文件将不会被索引。`REPO_INDEXER_EXCLUDE` 优先于 `REPO_INDEXER_INCLUDE`。
|
||||
|
||||
模式匹配工作方式如下：
|
||||
|
||||
- 要匹配所有带有 `.txt` 扩展名的文件，无论在哪个目录中，请使用 `**.txt`。
|
||||
- 要匹配仅在仓库的根级别中具有 `.txt` 扩展名的所有文件，请使用 `*.txt`。
|
||||
- 要匹配 `resources/bin` 目录及其子目录中的所有文件，请使用 `resources/bin/**`。
|
||||
- 要匹配位于 `resources/bin` 目录下的所有文件，请使用 `resources/bin/*`。
|
||||
- 要匹配所有名为 `Makefile` 的文件，请使用 `**Makefile`。
|
||||
- 匹配目录没有效果；模式 `resources/bin` 不会包含/排除该目录中的文件；`resources/bin/**` 会。
|
||||
- 所有文件和模式都规范化为小写，因此 `**Makefile`、`**makefile` 和 `**MAKEFILE` 是等效的。
|
||||
@@ -1,125 +0,0 @@
|
||||
---
|
||||
date: "2018-05-22T11:00:00+00:00"
|
||||
slug: "reverse-proxies"
|
||||
sidebar_position: 16
|
||||
---
|
||||
|
||||
# 反向代理
|
||||
|
||||
## 使用 Nginx 作为反向代理服务
|
||||
|
||||
如果您想使用 Nginx 作为 Gitea 的反向代理服务，您可以参照以下 `nginx.conf` 配置中 `server` 的 `http` 部分：
|
||||
|
||||
```
|
||||
server {
|
||||
listen 80;
|
||||
server_name git.example.com;
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:3000;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 使用 Nginx 作为反向代理服务并将 Gitea 路由至一个子路径
|
||||
|
||||
如果您已经有一个域名并且想与 Gitea 共享该域名，您可以增加以下 `nginx.conf` 配置中 `server` 的 `http` 部分，为 Gitea 添加路由规则：
|
||||
|
||||
```
|
||||
server {
|
||||
listen 80;
|
||||
server_name git.example.com;
|
||||
|
||||
# 注意: /git/ 最后需要有一个路径符号
|
||||
location /git/ {
|
||||
# 注意: 反向代理后端 URL 的最后需要有一个路径符号
|
||||
proxy_pass http://localhost:3000/;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
然后您**必须**在 Gitea 的配置文件中正确的添加类似 `[server] ROOT_URL = http://git.example.com/git/` 的配置项。
|
||||
|
||||
## 使用 Apache HTTPD 作为反向代理服务
|
||||
|
||||
如果您想使用 Apache HTTPD 作为 Gitea 的反向代理服务，您可以为您的 Apache HTTPD 作如下配置（在 Ubuntu 中，配置文件通常在 `/etc/apache2/httpd.conf` 目录下）：
|
||||
|
||||
```
|
||||
<VirtualHost *:80>
|
||||
...
|
||||
ProxyPreserveHost On
|
||||
ProxyRequests off
|
||||
AllowEncodedSlashes NoDecode
|
||||
ProxyPass / http://localhost:3000/ nocanon
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
注：必须启用以下 Apache HTTPD 组件：`proxy`， `proxy_http`
|
||||
|
||||
## 使用 Apache HTTPD 作为反向代理服务并将 Gitea 路由至一个子路径
|
||||
|
||||
如果您已经有一个域名并且想与 Gitea 共享该域名，您可以增加以下配置为 Gitea 添加路由规则（在 Ubuntu 中，配置文件通常在 `/etc/apache2/httpd.conf` 目录下）：
|
||||
|
||||
```
|
||||
<VirtualHost *:80>
|
||||
...
|
||||
<Proxy *>
|
||||
Order allow,deny
|
||||
Allow from all
|
||||
</Proxy>
|
||||
AllowEncodedSlashes NoDecode
|
||||
# 注意: 路径和 URL 后面都不要写路径符号 '/'
|
||||
ProxyPass /git http://localhost:3000 nocanon
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
然后您**必须**在 Gitea 的配置文件中正确的添加类似 `[server] ROOT_URL = http://git.example.com/git/` 的配置项。
|
||||
|
||||
注：必须启用以下 Apache HTTPD 组件：`proxy`， `proxy_http`
|
||||
|
||||
## 使用 Caddy 作为反向代理服务
|
||||
|
||||
如果您想使用 Caddy 作为 Gitea 的反向代理服务，您可以在 `Caddyfile` 中添加如下配置：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
proxy / http://localhost:3000
|
||||
}
|
||||
```
|
||||
|
||||
## 使用 Caddy 作为反向代理服务并将 Gitea 路由至一个子路径
|
||||
|
||||
如果您已经有一个域名并且想与 Gitea 共享该域名，您可以在您的 `Caddyfile` 文件中增加以下配置，为 Gitea 添加路由规则：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
# 注意: 路径 /git/ 最后需要有路径符号
|
||||
proxy /git/ http://localhost:3000
|
||||
}
|
||||
```
|
||||
|
||||
然后您**必须**在 Gitea 的配置文件中正确的添加类似 `[server] ROOT_URL = http://git.example.com/git/` 的配置项。
|
||||
|
||||
## 使用 Traefik 作为反向代理服务
|
||||
|
||||
如果您想使用 traefik 作为 Gitea 的反向代理服务，您可以在 `docker-compose.yaml` 中添加 label 部分（假设使用 docker 作为 traefik 的 provider）：
|
||||
|
||||
```yaml
|
||||
gitea:
|
||||
image: docker.io/gitea/gitea
|
||||
...
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.gitea.rule=Host(`example.com`)"
|
||||
- "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000"
|
||||
```
|
||||
|
||||
这份配置假设您使用 traefik 来处理 HTTPS 服务，并在其和 Gitea 之间使用 HTTP 进行通信。
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "search-engines-indexation"
|
||||
sidebar_position: 60
|
||||
aliases:
|
||||
- /zh-cn/search-engines-indexation
|
||||
---
|
||||
|
||||
# 搜索引擎索引
|
||||
|
||||
默认情况下，您的 Gitea 安装将被搜索引擎索引。
|
||||
如果您不希望您的仓库对搜索引擎可见，请进一步阅读。
|
||||
|
||||
## 使用 robots.txt 阻止搜索引擎索引
|
||||
|
||||
为了使 Gitea 为顶级安装提供自定义的`robots.txt`（默认为空的 404），请在[`custom`文件夹或`CustomPath`]（administration/customizing-gitea.md）中创建一个名为 `robots.txt` 的文件。
|
||||
|
||||
有关如何配置 `robots.txt` 的示例，请参考 [https://moz.com/learn/seo/robotstxt](https://moz.com/learn/seo/robotstxt)。
|
||||
|
||||
```txt
|
||||
User-agent: *
|
||||
Disallow: /
|
||||
```
|
||||
|
||||
如果您将 Gitea 安装在子目录中，则需要在顶级目录中创建或编辑 `robots.txt`。
|
||||
|
||||
```txt
|
||||
User-agent: *
|
||||
Disallow: /gitea/
|
||||
```
|
||||
@@ -1,137 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "signing"
|
||||
sidebar_position: 50
|
||||
aliases:
|
||||
- /zh-cn/signing
|
||||
---
|
||||
|
||||
# GPG 提交签名
|
||||
|
||||
Gitea 将通过检查提交是否由 Gitea 数据库中的密钥签名，或者提交是否与 Git 的默认密钥匹配，来验证提供的树中的 GPG 提交签名。
|
||||
|
||||
密钥不会被检查以确定它们是否已过期或撤销。密钥也不会与密钥服务器进行检查。
|
||||
|
||||
如果找不到用于验证提交的密钥，提交将被标记为灰色的未锁定图标。如果提交被标记为红色的未锁定图标，则表示它使用带有 ID 的密钥签名。
|
||||
|
||||
请注意：提交的签署者不必是提交的作者或提交者。
|
||||
|
||||
此功能要求 Git >= 1.7.9，但要实现全部功能，需要 Git >= 2.0.0。
|
||||
|
||||
## 自动签名
|
||||
|
||||
有许多地方 Gitea 会生成提交：
|
||||
|
||||
- 仓库初始化
|
||||
- Wiki 更改
|
||||
- 使用编辑器或 API 进行的 CRUD 操作
|
||||
- 从合并请求进行合并
|
||||
|
||||
根据配置和服务器信任，您可能希望 Gitea 对这些提交进行签名。
|
||||
|
||||
## 安装和生成 Gitea 的 GPG 密钥
|
||||
|
||||
如何安装签名密钥由服务器管理员决定。Gitea 目前使用服务器的 `git` 命令生成所有提交，因此将使用服务器的 `gpg` 进行签名（如果配置了）。管理员应该审查 GPG 的最佳实践 - 特别是可能建议仅安装签名的子密钥，而不是主签名和认证的密钥。
|
||||
|
||||
## 通用配置
|
||||
|
||||
Gitea 的签名配置可以在 `app.ini` 的 `[repository.signing]` 部分找到：
|
||||
|
||||
```ini
|
||||
...
|
||||
[repository.signing]
|
||||
SIGNING_KEY = default
|
||||
SIGNING_NAME =
|
||||
SIGNING_EMAIL =
|
||||
INITIAL_COMMIT = always
|
||||
CRUD_ACTIONS = pubkey, twofa, parentsigned
|
||||
WIKI = never
|
||||
MERGES = pubkey, twofa, basesigned, commitssigned
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
### `SIGNING_KEY`
|
||||
|
||||
首先讨论的选项是 `SIGNING_KEY`。有三个主要选项：
|
||||
|
||||
- `none` - 这将阻止 Gitea 对任何提交进行签名
|
||||
- `default` - Gitea 将使用 `git config` 中配置的默认密钥
|
||||
- `KEYID` - Gitea 将使用具有 ID `KEYID` 的 GPG 密钥对提交进行签名。在这种情况下，您应该提供 `SIGNING_NAME` 和 `SIGNING_EMAIL`，以便显示此密钥的信息。
|
||||
|
||||
`default` 选项将读取 `git config` 中的 `commit.gpgsign` 选项 - 如果设置了该选项，它将使用 `user.signingkey`、`user.name` 和 `user.email` 的结果。
|
||||
|
||||
通过在 Gitea 的仓库中调整 Git 的 `config` 文件，可以使用 `SIGNING_KEY=default` 为每个仓库提供不同的签名密钥。然而，这显然不是一个理想的用户界面，因此可能会发生更改。
|
||||
|
||||
:::warning
|
||||
**自 1.17 起**，Gitea 在自己的主目录 `[git].HOME_PATH`（默认为 `%(APP_DATA_PATH)/home`）中运行 git，并使用自己的配置文件 `{[git].HOME_PATH}/.gitconfig`。
|
||||
|
||||
如果您有自己定制的 Gitea git 配置，您应该将这些配置设置在系统 git 配置文件中（例如 `/etc/gitconfig`）或者 Gitea 的内部 git 配置文件 `{[git].HOME_PATH}/.gitconfig` 中。
|
||||
|
||||
与 git 命令相关的主目录文件（如 `.gnupg`）也应该放在 Gitea 的 git 主目录 `[git].HOME_PATH` 中。
|
||||
如果您希望将 `.gnupg` 目录放在 `{[git].HOME_PATH}/` 之外的位置，请考虑设置 `$GNUPGHOME` 环境变量为您首选的位置。，否则 Gitea 将会从 `{[git].HOME_PATH}/.gnupg` 查找私钥。
|
||||
:::
|
||||
|
||||
### `INITIAL_COMMIT`
|
||||
|
||||
此选项确定在创建仓库时，Gitea 是否应该对初始提交进行签名。可能的取值有：
|
||||
|
||||
- `never`：从不签名
|
||||
- `pubkey`：仅在用户拥有公钥时进行签名
|
||||
- `twofa`：仅在用户使用 2FA 登录时进行签名
|
||||
- `always`：始终签名
|
||||
|
||||
除了 `never` 和 `always` 之外的选项可以组合为逗号分隔的列表。如果所有选择的选项都为 true，则提交将被签名。
|
||||
|
||||
### `WIKI`
|
||||
|
||||
此选项确定 Gitea 是否应该对 Wiki 的提交进行签名。可能的取值有：
|
||||
|
||||
- `never`：从不签名
|
||||
- `pubkey`：仅在用户拥有公钥时进行签名
|
||||
- `twofa`：仅在用户使用 2FA 登录时进行签名
|
||||
- `parentsigned`：仅在父提交已签名时进行签名。
|
||||
- `always`：始终签名
|
||||
|
||||
除了 `never` 和 `always` 之外的选项可以组合为逗号分隔的列表。如果所有选择的选项都为 true，则提交将被签名。
|
||||
|
||||
### `CRUD_ACTIONS`
|
||||
|
||||
此选项确定 Gitea 是否应该对 Web 编辑器或 API CRUD 操作的提交进行签名。可能的取值有：
|
||||
|
||||
- `never`：从不签名
|
||||
- `pubkey`：仅在用户拥有公钥时进行签名
|
||||
- `twofa`：仅在用户使用 2FA 登录时进行签名
|
||||
- `parentsigned`：仅在父提交已签名时进行签名。
|
||||
- `always`：始终签名
|
||||
|
||||
除了 `never` 和 `always` 之外的选项可以组合为逗号分隔的列表。如果所有选择的选项都为 true，则更改将被签名。
|
||||
|
||||
### `MERGES`
|
||||
|
||||
此选项确定 Gitea 是否应该对 PR 的合并提交进行签名。可能的选项有：
|
||||
|
||||
- `never`：从不签名
|
||||
- `pubkey`：仅在用户拥有公钥时进行签名
|
||||
- `twofa`：仅在用户使用 2FA 登录时进行签名
|
||||
- `basesigned`：仅在基础仓库中的父提交已签名时进行签名。
|
||||
- `headsigned`：仅在头分支中的头提交已签名时进行签名。
|
||||
- `commitssigned`：仅在头分支中的所有提交到合并点的提交都已签名时进行签名。
|
||||
- `approved`：仅对已批准的合并到受保护分支的提交进行签名。
|
||||
- `always`：始终签名
|
||||
|
||||
除了 `never` 和 `always` 之外的选项可以组合为逗号分隔的列表。如果所有选择的选项都为 true，则合并将被签名。
|
||||
|
||||
## 获取签名密钥的公钥
|
||||
|
||||
用于签署 Gitea 提交的公钥可以通过 API 获取：
|
||||
|
||||
```sh
|
||||
/api/v1/signing-key.gpg
|
||||
```
|
||||
|
||||
在存在特定于仓库的密钥的情况下，可以通过以下方式获取：
|
||||
|
||||
```sh
|
||||
/api/v1/repos/:username/:reponame/signing-key.gpg
|
||||
```
|
||||
@@ -1,110 +0,0 @@
|
||||
---
|
||||
date: "2023-05-25T23:41:00+08:00"
|
||||
slug: "guidelines-backend"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-cn/guidelines-backend
|
||||
---
|
||||
|
||||
# 后端开发指南
|
||||
|
||||
## 背景
|
||||
|
||||
Gitea 使用 Golang 作为后端编程语言。它使用了许多第三方包，并且自己也编写了一些包。
|
||||
例如，Gitea 使用[Chi](https://github.com/go-chi/chi)作为基本的 Web 框架。[Xorm](https://xorm.io)是一个用于与数据库交互的 ORM 框架。
|
||||
因此，管理这些包非常重要。在开始编写后端代码之前，请参考以下准则。
|
||||
|
||||
## 包设计准则
|
||||
|
||||
### 包列表
|
||||
|
||||
为了保持易于理解的代码并避免循环依赖，拥有良好的代码结构是很重要的。Gitea 后端分为以下几个部分：
|
||||
|
||||
- `build`：帮助构建 Gitea 的脚本。
|
||||
- `cmd`：包含所有 Gitea 的实际子命令，包括 web、doctor、serv、hooks、admin 等。`web`将启动 Web 服务。`serv`和`hooks`将被 Git 或 OpenSSH 调用。其他子命令可以帮助维护 Gitea。
|
||||
- `tests`：常用的测试函数
|
||||
- `tests/integration`：集成测试，用于测试后端回归。
|
||||
- `tests/e2e`：端到端测试，用于测试前端和后端的兼容性和视觉回归。
|
||||
- `models`：包含由 xorm 用于构建数据库表的数据结构。它还包含查询和更新数据库的函数。应避免与其他 Gitea 代码的依赖关系。在某些情况下，比如日志记录时可以例外。
|
||||
- `models/db`：基本的数据库操作。所有其他`models/xxx`包都应依赖于此包。`GetEngine`函数只能从 models/中调用。
|
||||
- `models/fixtures`：单元测试和集成测试中使用的示例数据。一个`yml`文件表示一个将在测试开始时加载到数据库中的表。
|
||||
- `models/migrations`：存储不同版本之间的数据库迁移。修改数据库结构的 PR**必须**包含一个迁移步骤。
|
||||
- `modules`：在 Gitea 中处理特定功能的不同模块。工作正在进行中：其中一些模块应该移到`services`中，特别是那些依赖于 models 的模块，因为它们依赖于数据库。
|
||||
- `modules/setting`：存储从 ini 文件中读取的所有系统配置，并在各处引用。但是在可能的情况下，应将其作为函数参数使用。
|
||||
- `modules/git`：用于与`Git`命令行或 Gogit 包交互的包。
|
||||
- `public`：编译后的前端文件（JavaScript、图像、CSS 等）
|
||||
- `routers`：处理服务器请求。由于它使用其他 Gitea 包来处理请求，因此其他包（models、modules 或 services）不能依赖于 routers。
|
||||
- `routers/api`：包含`/api/v1`相关路由，用于处理 RESTful API 请求。
|
||||
- `routers/install`：只能在系统处于安装模式（INSTALL_LOCK=false）时响应。
|
||||
- `routers/private`：仅由内部子命令调用，特别是`serv`和`hooks`。
|
||||
- `routers/web`：处理来自 Web 浏览器或 Git SMART HTTP 协议的 HTTP 请求。
|
||||
- `services`：用于常见路由操作或命令执行的支持函数。使用`models`和`modules`来处理请求。
|
||||
- `templates`：用于生成 HTML 输出的 Golang 模板。
|
||||
|
||||
### 包依赖关系
|
||||
|
||||
由于 Golang 不支持导入循环，我们必须仔细决定包之间的依赖关系。这些包之间有一些级别。以下是理想的包依赖关系方向。
|
||||
|
||||
`cmd` -> `routers` -> `services` -> `models` -> `modules`
|
||||
|
||||
从左到右，左侧的包可以依赖于右侧的包，但右侧的包不能依赖于左侧的包。在同一级别的子包中，可以根据该级别的规则进行依赖。
|
||||
|
||||
**注意事项**
|
||||
|
||||
为什么我们需要在`models`之外使用数据库事务？以及如何使用？
|
||||
某些操作在数据库记录插入/更新/删除失败时应该允许回滚。
|
||||
因此，服务必须能够创建数据库事务。以下是一些示例：
|
||||
|
||||
```go
|
||||
// services/repository/repository.go
|
||||
func CreateXXXX() error {
|
||||
return db.WithTx(func(ctx context.Context) error {
|
||||
// do something, if err is returned, it will rollback automatically
|
||||
if err := issues.UpdateIssue(ctx, repoID); err != nil {
|
||||
// ...
|
||||
return err
|
||||
}
|
||||
// ...
|
||||
return nil
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
在`services`中**不应该**直接使用`db.GetEngine(ctx)`，而是应该在`models/`下编写一个函数。
|
||||
如果该函数将在事务中使用，请将`context.Context`作为函数的第一个参数。
|
||||
|
||||
```go
|
||||
// models/issues/issue.go
|
||||
func UpdateIssue(ctx context.Context, repoID int64) error {
|
||||
e := db.GetEngine(ctx)
|
||||
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
### 包名称
|
||||
|
||||
对于顶层包，请使用复数作为包名，例如`services`、`models`，对于子包，请使用单数，例如`services/user`、`models/repository`。
|
||||
|
||||
### 导入别名
|
||||
|
||||
由于有一些使用相同包名的包，例如`modules/user`、`models/user`和`services/user`，当这些包在一个 Go 文件中被导入时，很难知道我们使用的是哪个包以及它是变量名还是导入名。因此，我们始终建议使用导入别名。为了与常见的驼峰命名法的包变量区分开，建议使用**snake_case**作为导入别名的命名规则。
|
||||
例如：`import user_service "code.gitea.io/gitea/services/user"`
|
||||
|
||||
### 重要注意事项
|
||||
|
||||
- 永远不要写成`x.Update(exemplar)`，而没有明确的`WHERE`子句：
|
||||
- 这将导致表中的所有行都被使用 exemplar 的非零值进行更新，包括 ID。
|
||||
- 通常应该写成`x.ID(id).Update(exemplar)`。
|
||||
- 如果在迁移过程中使用`x.Insert(exemplar)`向表中插入记录，而 ID 是预设的：
|
||||
- 对于 MSSQL 变体，你将需要执行`` SET IDENTITY_INSERT `table` ON ``（否则迁移将失败）
|
||||
- 对于 PostgreSQL，你还需要更新 ID 序列，否则迁移将悄无声息地通过，但后续的插入将失败：
|
||||
`` SELECT setval('table_name_id_seq', COALESCE((SELECT MAX(id)+1 FROM `table_name`), 1), false) ``
|
||||
|
||||
### 未来的任务
|
||||
|
||||
目前，我们正在进行一些重构，以完成以下任务：
|
||||
|
||||
- 纠正不符合规则的代码。
|
||||
- `models`中的文件太多了，所以我们正在将其中的一些移动到子包`models/xxx`中。
|
||||
- 由于它们依赖于`models`，因此应将某些`modules`子包移动到`services`中。
|
||||
@@ -1,135 +0,0 @@
|
||||
---
|
||||
date: "2023-05-25T16:00:00+02:00"
|
||||
slug: "guidelines-frontend"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-cn/guidelines-frontend
|
||||
---
|
||||
|
||||
# 前端开发指南
|
||||
|
||||
## 背景
|
||||
|
||||
Gitea 在其前端中使用[Fomantic-UI](https://fomantic-ui.com/introduction/getting-started.html)（基于[jQuery](https://api.jquery.com)）和 [Vue3](https://vuejs.org/)。
|
||||
|
||||
HTML 页面由[Go HTML Template](https://pkg.go.dev/html/template)渲染。
|
||||
|
||||
源文件可以在以下目录中找到：
|
||||
|
||||
- **CSS 样式**： `web_src/css/`
|
||||
- **JavaScript 文件**： `web_src/js/`
|
||||
- **Vue 组件**： `web_src/js/components/`
|
||||
- **Go HTML 模板**： `templates/`
|
||||
|
||||
## 通用准则
|
||||
|
||||
我们推荐使用[Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html)和[Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)。
|
||||
|
||||
## Gitea 特定准则：
|
||||
|
||||
1. 每个功能（Fomantic-UI/jQuery 模块）应放在单独的文件/目录中。
|
||||
2. HTML 的 id 和 class 应使用 kebab-case，最好包含 2-3 个与功能相关的关键词。
|
||||
3. 在 JavaScript 中使用的 HTML 的 id 和 class 应在整个项目中是唯一的，并且应包含 2-3 个与功能相关的关键词。建议在仅在 JavaScript 中使用的 class 中使用 `js-` 前缀。
|
||||
4. 不应覆盖框架提供的 class 的 CSS 样式。始终使用具有 2-3 个与功能相关的关键词的新 class 名称来覆盖框架样式。Gitea 中的帮助 CSS 类在 `helpers.less` 中。
|
||||
5. 后端可以通过使用`ctx.PageData["myModuleData"] = map[]{}`将复杂数据传递给前端，但不要将整个模型暴露给前端，以避免泄露敏感数据。
|
||||
6. 简单页面和与 SEO 相关的页面使用 Go HTML 模板渲染生成静态的 Fomantic-UI HTML 输出。复杂页面可以使用 Vue3。
|
||||
7. 明确变量类型，优先使用`elem.disabled = true`而不是`elem.setAttribute('disabled', 'anything')`，优先使用`$el.prop('checked', var === 'yes')`而不是`$el.prop('checked', var)`。
|
||||
8. 使用语义化元素，优先使用`<button class="ui button">`而不是`<div class="ui button">`。
|
||||
9. 避免在 CSS 中使用不必要的`!important`，如果无法避免，添加注释解释为什么需要它。
|
||||
10. 避免在一个事件监听器中混合不同的事件，优先为每个事件使用独立的事件监听器。
|
||||
11. 推荐使用自定义事件名称前缀`ce-`。
|
||||
12. Gitea 的 tailwind-style CSS 类使用`gt-`前缀（`gt-relative`），而 Gitea 自身的私有框架级 CSS 类使用`g-`前缀（`g-modal-confirm`）。
|
||||
|
||||
### 可访问性 / ARIA
|
||||
|
||||
在历史上，Gitea 大量使用了可访问性不友好的框架 Fomantic UI。
|
||||
Gitea 使用一些补丁使 Fomantic UI 更具可访问性（参见`aria.js`和`aria.md`），
|
||||
但仍然存在许多问题需要大量的工作和时间来修复。
|
||||
|
||||
### 框架使用
|
||||
|
||||
不建议混合使用不同的框架，这会使代码难以维护。
|
||||
一个 JavaScript 模块应遵循一个主要框架，并遵循该框架的最佳实践。
|
||||
|
||||
推荐的实现方式：
|
||||
|
||||
- Vue + Vanilla JS
|
||||
- Fomantic-UI（jQuery）
|
||||
- Vanilla JS
|
||||
|
||||
不推荐的实现方式：
|
||||
|
||||
- Vue + Fomantic-UI（jQuery）
|
||||
- jQuery + Vanilla JS
|
||||
|
||||
为了保持界面一致，Vue 组件可以使用 Fomantic-UI 的 CSS 类。
|
||||
尽管不建议混合使用不同的框架，
|
||||
但如果混合使用是必要的，并且代码设计良好且易于维护，也可以工作。
|
||||
|
||||
### async 函数
|
||||
|
||||
只有当函数内部存在`await`调用或返回`Promise`时，才将函数标记为`async`。
|
||||
|
||||
不建议使用`async`事件监听器，这可能会导致问题。
|
||||
原因是`await`后的代码在事件分发之外执行。
|
||||
参考：https://github.com/github/eslint-plugin-github/blob/main/docs/rules/async-preventdefault.md
|
||||
|
||||
如果一个事件监听器必须是`async`，应在任何`await`之前使用`e.preventDefault()`，
|
||||
建议将其放在函数的开头。
|
||||
|
||||
如果我们想在非异步上下文中调用`async`函数，
|
||||
建议使用`const _promise = asyncFoo()`来告诉读者
|
||||
这是有意为之的，我们想调用异步函数并忽略 Promise。
|
||||
一些 lint 规则和 IDE 也会在未处理返回的 Promise 时发出警告。
|
||||
|
||||
### HTML 属性和 dataset
|
||||
|
||||
禁止使用`dataset`，它的驼峰命名行为使得搜索属性变得困难。
|
||||
然而，仍然存在一些特殊情况，因此当前的准则是：
|
||||
|
||||
- 对于旧代码：
|
||||
|
||||
- 应将`$.data()`重构为`$.attr()`。
|
||||
- 在极少数情况下，可以使用`$.data()`将一些非字符串数据绑定到元素上，但强烈不推荐使用。
|
||||
|
||||
- 对于新代码：
|
||||
- 不应使用`node.dataset`，而应使用`node.getAttribute`。
|
||||
- 不要将任何用户数据绑定到 DOM 节点上，使用合适的设计模式描述节点和数据之间的关系。
|
||||
|
||||
### 显示/隐藏元素
|
||||
|
||||
- 推荐在 Vue 组件中使用`v-if`和`v-show`来显示/隐藏元素。
|
||||
- Go 模板代码应使用 Gitea 的 `.gt-hidden` 和 `showElem()/hideElem()/toggleElem()` 来显示/隐藏元素，请参阅`.gt-hidden`的注释以获取更多详细信息。
|
||||
|
||||
### Go HTML 模板中的样式和属性
|
||||
|
||||
建议使用以下方式：
|
||||
|
||||
```html
|
||||
<div
|
||||
class="gt-name1 gt-name2 {{if .IsFoo}}gt-foo{{end}}"
|
||||
{{if
|
||||
.IsFoo}}data-foo{{end}}
|
||||
></div>
|
||||
```
|
||||
|
||||
而不是：
|
||||
|
||||
```html
|
||||
<div
|
||||
class="gt-name1 gt-name2{{if .IsFoo}} gt-foo{{end}}"
|
||||
{{if
|
||||
.IsFoo}}
|
||||
data-foo{{end}}
|
||||
></div>
|
||||
```
|
||||
|
||||
以使代码更易读。
|
||||
|
||||
### 旧代码
|
||||
|
||||
许多旧代码已经存在于本文撰写之前。建议重构旧代码以遵循指南。
|
||||
|
||||
### Vue3 和 JSX
|
||||
|
||||
Gitea 现在正在使用 Vue3。我们决定不引入 JSX，以保持 HTML 代码和 JavaScript 代码分离。
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
date: "2023-05-25T00:00:00+00:00"
|
||||
slug: "guidelines-refactoring"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-cn/guidelines-refactoring
|
||||
---
|
||||
|
||||
# 重构指南
|
||||
|
||||
## 背景
|
||||
|
||||
自 2014 年 2 月 12 日编写了第一行代码以来，Gitea 已经发展成为一个庞大的项目。
|
||||
因此，代码库变得越来越大。代码库越大，维护就越困难。
|
||||
存在许多过时的机制，许多框架混合在一起，一些遗留代码可能会导致错误并阻碍新功能的开发。
|
||||
为了使代码库更易于维护，使 Gitea 变得更好，开发人员应牢记使用现代机制来重构旧代码。
|
||||
|
||||
本文档是关于重构代码库的指南集合。
|
||||
|
||||
## 重构建议
|
||||
|
||||
- 设计更多关于未来的内容，而不仅仅解决当前问题。
|
||||
- 减少模糊性，减少冲突，提高可维护性。
|
||||
- 描述重构，例如：
|
||||
- 为什么需要重构。
|
||||
- 如何解决旧问题。
|
||||
- 重构的优点/缺点是什么。
|
||||
- 只做必要的更改，尽量保留旧逻辑。
|
||||
- 引入一些中间步骤，使重构更容易审查，完整的重构计划可以在几个 PR 中完成。
|
||||
- 如果存在分歧，应该请 TOC（技术监督委员会）参与决策。
|
||||
- 添加必要的测试以确保重构的正确性。
|
||||
- 非错误重构优先在里程碑的开始时进行，这样可以更容易地在发布之前发现问题。
|
||||
|
||||
## 审查和合并建议
|
||||
|
||||
- 重构的 PR 不应该长时间保持打开状态（通常为 7 天），应尽快进行审查。
|
||||
- 重构的 PR 应尽快合并，不应被其他 PR 阻塞。
|
||||
- 如果 TOC 没有异议，重构的 PR 可以在 7 天后由一名核心成员（非作者）批准后合并。
|
||||
- 如果最终结果良好，容忍一些不完美/临时的步骤。
|
||||
- 如果重构是必要的，容忍一些回归错误，并尽快修复错误。
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "localization"
|
||||
sidebar_position: 70
|
||||
aliases:
|
||||
- /zh-cn/localization
|
||||
---
|
||||
|
||||
# 本地化
|
||||
|
||||
Gitea 的本地化是通过我们的[Crowdin 项目](https://crowdin.com/project/gitea)进行的。
|
||||
|
||||
对于对**英语翻译**的更改，可以发出 pull-request，来更改[英语语言环境](https://github.com/go-gitea/gitea/blob/main/options/locale/locale_en-US.ini)中合适的关键字。
|
||||
|
||||
有关对**非英语**翻译的更改，请参阅上面的 Crowdin 项目。
|
||||
|
||||
## 支持的语言
|
||||
|
||||
上述 Crowdin 项目中列出的任何语言一旦翻译了 25% 或更多都将得到支持。
|
||||
|
||||
翻译被接受后，它将在下一次 Crowdin 同步后反映在主存储库中，这通常是在任何 PR 合并之后。
|
||||
|
||||
在撰写本文时，这意味着更改后的翻译可能要到 Gitea 的下一个版本才会出现。
|
||||
|
||||
如果使用开发版本，则在同步更改内容后，它应该会在更新后立即显示。
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
title: "开发"
|
||||
slug: "development"
|
||||
sidebar_position: 40
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "开发"
|
||||
sidebar_position: 40
|
||||
identifier: "development"
|
||||
---
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
date: "2018-06-24:00:00+02:00"
|
||||
slug: "api-usage"
|
||||
sidebar_position: 40
|
||||
---
|
||||
|
||||
# API 使用指南
|
||||
|
||||
## 开启/配置 API 访问
|
||||
|
||||
通常情况下， `ENABLE_SWAGGER` 默认开启并且参数 `MAX_RESPONSE_ITEMS` 默认为 50。您可以从 [Config Cheat
|
||||
Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/) 中获取更多配置相关信息。
|
||||
|
||||
## 通过 API 认证
|
||||
|
||||
Gitea 支持以下几种 API 认证方式：
|
||||
|
||||
- HTTP basic authentication 方式
|
||||
- 通过指定 `token=...` URL 查询参数方式
|
||||
- 通过指定 `access_token=...` URL 查询参数方式
|
||||
- 通过指定 `Authorization: token ...` HTTP header 方式
|
||||
|
||||
以上提及的认证方法接受相同的 apiKey token 类型，您可以在编码时通过查阅代码更好地理解这一点。
|
||||
Gitea 调用解析查询参数以及头部信息来获取 token 的代码可以在 [modules/auth/auth.go](https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47) 中找到。
|
||||
|
||||
您可以通过您的 gitea web 界面来创建 apiKey token：
|
||||
`Settings | Applications | Generate New Token`.
|
||||
|
||||
### 关于 `Authorization:` header
|
||||
|
||||
由于一些历史原因，Gitea 需要在 header 的 apiKey token 里引入前缀 `token`，类似于如下形式：
|
||||
|
||||
```
|
||||
Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675
|
||||
```
|
||||
|
||||
以 `curl` 命令为例，它会以如下形式携带在请求中：
|
||||
|
||||
```
|
||||
curl "http://localhost:4000/api/v1/repos/test1/test1/issues" \
|
||||
-H "accept: application/json" \
|
||||
-H "Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675" \
|
||||
-H "Content-Type: application/json" -d "{ \"body\": \"testing\", \"title\": \"test 20\"}" -i
|
||||
```
|
||||
|
||||
正如上例所示，您也可以在 GET 请求中使用同一个 token 并以 `token=` 的查询参数形式携带 token 来进行认证。
|
||||
|
||||
## 通过 API 列出您发布的令牌
|
||||
|
||||
`/users/:name/tokens` 是一个特殊的接口，需要您使用 basic authentication 进行认证，具体原因在 issue 中
|
||||
[#3842](https://github.com/go-gitea/gitea/issues/3842#issuecomment-397743346) 有所提及，使用方法如下所示：
|
||||
|
||||
### 使用 Basic authentication 认证：
|
||||
|
||||
```
|
||||
$ curl --url https://yourusername:yourpassword@gitea.your.host/api/v1/users/yourusername/tokens
|
||||
[{"name":"test","sha1":"..."},{"name":"dev","sha1":"..."}]
|
||||
```
|
||||
|
||||
## 使用 Sudo 方式请求 API
|
||||
|
||||
此 API 允许管理员借用其他用户身份进行 API 请求。只需在请求中指定查询参数 `sudo=` 或是指定 header 中的 `Sudo:` 为需要使用的用户 username 即可。
|
||||
@@ -1,336 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "hacking-on-gitea"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# 玩转 Gitea
|
||||
|
||||
## 快速入门
|
||||
|
||||
要获得快速工作的开发环境，您可以使用 Gitpod。
|
||||
|
||||
[](https://gitpod.io/#https://github.com/go-gitea/gitea)
|
||||
|
||||
## 安装 Golang
|
||||
|
||||
您需要 [安装 go]( https://golang.org/doc/install ) 并设置您的 go 环境。
|
||||
|
||||
接下来，[使用 npm 安装 Node.js](https://nodejs.org/en/download/) ，这是构建
|
||||
JavaScript 和 CSS 文件的必要工具。最低支持的 Node.js 版本是 @minNodeVersion@
|
||||
并且推荐使用最新的 LTS 版本。
|
||||
|
||||
**注意** ：当执行需要外部工具的 make 任务时，比如
|
||||
`make watch-backend`，Gitea 会自动下载并构建这些必要的组件。为了能够使用这些，你必须
|
||||
将 `"$GOPATH"/bin` 目录加入到可执行路径上。如果你不把go bin目录添加到可执行路径你必须手动
|
||||
指定可执行程序路径。
|
||||
|
||||
**注意2** ：Go版本 @minGoVersion@ 或更高版本是必须的。Gitea 使用 `gofmt` 来
|
||||
格式化源代码。然而，`gofmt` 的结果可能因 `go` 的版本而有差异。因此推荐安装我们持续集成使用
|
||||
的 Go版本。截至上次更新，Go 版本应该是 @goVersion@。
|
||||
|
||||
## 安装 Make
|
||||
|
||||
Gitea 大量使用 `Make` 来自动化任务和改进开发。本指南涵盖了如何安装 Make。
|
||||
|
||||
### 在 Linux 上
|
||||
|
||||
使用包管理器安装。
|
||||
|
||||
在 Ubuntu/Debian 上：
|
||||
|
||||
```bash
|
||||
sudo apt-get install make
|
||||
```
|
||||
|
||||
在 Fedora/RHEL/CentOS 上：
|
||||
|
||||
```bash
|
||||
sudo yum install make
|
||||
```
|
||||
|
||||
### 在 Windows 上
|
||||
|
||||
Make 的这三个发行版都可以在 Windows 上运行：
|
||||
|
||||
- [单个二进制构建]( http://www.equation.com/servlet/equation.cmd?fa=make )。复制到某处并添加到 `PATH`。
|
||||
- [32 位版本](http://www.equation.com/ftpdir/make/32/make.exe)
|
||||
- [64 位版本](http://www.equation.com/ftpdir/make/64/make.exe)
|
||||
- [MinGW-w64](https://www.mingw-w64.org) / [MSYS2](https://www.msys2.org/)。
|
||||
- MSYS2 是一个工具和库的集合，为您提供一个易于使用的环境来构建、安装和运行本机 Windows 软件，它包括 MinGW-w64。
|
||||
- 在 MingGW-w64 中，二进制文件称为 `mingw32-make.exe` 而不是 `make.exe`。将 `bin` 文件夹添加到 `PATH`。
|
||||
- 在 MSYS2 中，您可以直接使用 `make`。请参阅 [MSYS2 移植](https://www.msys2.org/wiki/Porting/)。
|
||||
- 要使用 CGO_ENABLED（例如：SQLite3）编译 Gitea，您可能需要使用 [tdm-gcc](https://jmeubank.github.io/tdm-gcc/) 而不是 MSYS2 gcc，因为 MSYS2 gcc 标头缺少一些 Windows -只有 CRT 函数像 _beginthread 一样。
|
||||
- [Chocolatey包管理器]( https://chocolatey.org/packages/make )。运行`choco install make`
|
||||
|
||||
**注意** ：如果您尝试在 Windows 命令提示符下使用 make 进行构建，您可能会遇到问题。建议使用上述提示（Git bash 或 MinGW），但是如果您只有命令提示符（或可能是 PowerShell），则可以使用 [set](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/set_1) 命令，例如 `set TAGS=bindata`。
|
||||
|
||||
## 下载并克隆 Gitea 源代码
|
||||
|
||||
获取源代码的推荐方法是使用 `git clone`。
|
||||
|
||||
```bash
|
||||
git clone https://github.com/go-gitea/gitea
|
||||
```
|
||||
|
||||
（自从go modules出现后，不再需要构建 go 项目从 `$GOPATH` 中获取，因此不再推荐使用 `go get` 方法。）
|
||||
|
||||
## 派生 Gitea
|
||||
|
||||
如上所述下载主要的 Gitea 源代码。然后，派生 [Gitea 仓库](https://github.com/go-gitea/gitea)，
|
||||
并为您的本地仓库切换 git 远程源，或添加另一个远程源：
|
||||
|
||||
```bash
|
||||
# 将原来的 Gitea origin 重命名为 upstream
|
||||
git remote rename origin upstream
|
||||
git remote add origin "git@github.com:$GITHUB_USERNAME/gitea.git"
|
||||
git fetch --all --prune
|
||||
```
|
||||
|
||||
或者：
|
||||
|
||||
```bash
|
||||
# 为我们的 fork 添加新的远程
|
||||
git remote add "$FORK_NAME" "git@github.com:$GITHUB_USERNAME/gitea.git"
|
||||
git fetch --all --prune
|
||||
```
|
||||
|
||||
为了能够创建合并请求，应将分叉存储库添加为 Gitea 本地仓库的远程，否则无法推送更改。
|
||||
|
||||
## 构建 Gitea（基本）
|
||||
|
||||
看看我们的
|
||||
[说明](installation/from-source.md)
|
||||
关于如何[从源代码构建](installation/from-source.md) 。
|
||||
|
||||
从源代码构建的最简单推荐方法是：
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
```
|
||||
|
||||
`build` 目标将同时执行 `frontend` 和 `backend` 子目标。如果存在 `bindata` 标签，资源文件将被编译成二进制文件。建议在进行前端开发时省略 `bindata` 标签，以便实时反映更改。
|
||||
|
||||
有关所有可用的 `make` 目标，请参阅 `make help`。另请参阅 [`.drone.yml`](https://github.com/go-gitea/gitea/blob/main/.drone.yml) 以了解我们的持续集成是如何工作的。
|
||||
|
||||
## 持续构建
|
||||
|
||||
要在源文件更改时运行并持续构建：
|
||||
|
||||
```bash
|
||||
# 对于前端和后端
|
||||
make watch
|
||||
|
||||
# 或者：只看前端文件（html/js/css）
|
||||
make watch-frontend
|
||||
|
||||
# 或者：只看后端文件 (go)
|
||||
make watch-backend
|
||||
```
|
||||
|
||||
在 macOS 上，监视所有后端源文件可能会达到默认的打开文件限制，这可以通过当前 shell 的 `ulimit -n 12288` 或所有未来 shell 的 shell 启动文件来增加。
|
||||
|
||||
### 格式化、代码分析和拼写检查
|
||||
|
||||
我们的持续集成将拒绝未通过代码检查（包括格式检查、代码分析和拼写检查）的 PR。
|
||||
|
||||
你应该格式化你的代码：
|
||||
|
||||
```bash
|
||||
make fmt
|
||||
```
|
||||
|
||||
并检查源代码：
|
||||
|
||||
```bash
|
||||
# lint 前端和后端代码
|
||||
make lint
|
||||
# 仅 lint 后端代码
|
||||
make lint-backend
|
||||
```
|
||||
|
||||
**注意** ：`gofmt` 的结果取决于 `go` 的版本。您应该运行与持续集成相同的 go 版本。
|
||||
|
||||
### 处理 JS 和 CSS
|
||||
|
||||
前端开发应遵循 [Guidelines for Frontend Development](contributing/guidelines-frontend.md)。
|
||||
|
||||
要使用前端资源构建，请使用上面提到的“watch-frontend”目标或只构建一次：
|
||||
|
||||
```bash
|
||||
make build && ./gitea
|
||||
```
|
||||
|
||||
在提交之前，确保 linters 通过：
|
||||
|
||||
```bash
|
||||
make lint-frontend
|
||||
```
|
||||
|
||||
### 配置本地 ElasticSearch 实例
|
||||
|
||||
使用 docker 启动本地 ElasticSearch 实例：
|
||||
|
||||
```sh
|
||||
mkdir -p $(pwd) /data/elasticsearch
|
||||
sudo chown -R 1000:1000 $(pwd) /data/elasticsearch
|
||||
docker run --rm --memory= "4g" -p 127.0.0.1:9200:9200 -p 127.0.0.1:9300:9300 -e "discovery.type=single-node" -v "$(pwd)/data /elasticsearch:/usr/share/elasticsearch/data" docker.elastic.co/elasticsearch/elasticsearch:7.16.3
|
||||
```
|
||||
|
||||
配置`app.ini`：
|
||||
|
||||
```ini
|
||||
[indexer]
|
||||
ISSUE_INDEXER_TYPE = elasticsearch
|
||||
ISSUE_INDEXER_CONN_STR = http://elastic:changeme@localhost:9200
|
||||
REPO_INDEXER_ENABLED = true
|
||||
REPO_INDEXER_TYPE = elasticsearch
|
||||
REPO_INDEXER_CONN_STR = http://elastic:changeme@localhost:9200
|
||||
```
|
||||
|
||||
### 构建和添加 SVGs
|
||||
|
||||
SVG 图标是使用 `make svg` 目标构建的，该目标将 `build/generate-svg.js` 中定义的图标源编译到输出目录 `public/img/svg` 中。可以在 `web_src/svg` 目录中添加自定义图标。
|
||||
|
||||
### 构建 Logo
|
||||
|
||||
Gitea Logo的 PNG 和 SVG 版本是使用 `TAGS="gitea" make generate-images` 目标从单个 SVG 源文件 assets/logo.svg 构建的。要运行它，Node.js 和 npm 必须可用。
|
||||
|
||||
通过更新 `assets/logo.svg` 并运行 `make generate-images`，同样的过程也可用于从 SVG 源文件生成自定义 Logo PNG。忽略 gitea 编译选项将仅更新用户指定的 LOGO 文件。
|
||||
|
||||
### 更新 API
|
||||
|
||||
创建新的 API 路由或修改现有的 API 路由时，您**必须**
|
||||
更新和/或创建 [Swagger](https://swagger.io/docs/specification/2-0/what-is-swagger/)
|
||||
这些使用 [go-swagger](https://goswagger.io/) 评论的文档。
|
||||
[规范]( https://goswagger.io/use/spec.html#annotation-syntax )中描述了这些注释的结构。
|
||||
如果您想了解更多有关 Swagger 结构的信息，可以查看
|
||||
[Swagger 2.0 文档](https://swagger.io/docs/specification/2-0/basic-structure/)
|
||||
或与添加新 API 端点的先前 PR 进行比较，例如 [PR #5483](https://github.com/go-gitea/gitea/pull/5843/files#diff-2e0a7b644cf31e1c8ef7d76b444fe3aaR20)
|
||||
|
||||
您应该注意不要破坏下游用户依赖的 API。在稳定的 API 上，一般来说添加是可以接受的，但删除
|
||||
或对 API 进行根本性更改将会被拒绝。
|
||||
|
||||
创建或更改 API 端点后，请用以下命令重新生成 Swagger 文档：
|
||||
|
||||
```bash
|
||||
make generate-swagger
|
||||
```
|
||||
|
||||
您应该验证生成的 Swagger 文件并使用以下命令对其进行拼写检查：
|
||||
|
||||
```bash
|
||||
make swagger-validate misspell-check
|
||||
```
|
||||
|
||||
您应该提交更改后的 swagger JSON 文件。持续集成服务器将使用以下方法检查是否已完成：
|
||||
|
||||
```bash
|
||||
make swagger-check
|
||||
```
|
||||
|
||||
**注意** ：请注意，您应该使用 Swagger 2.0 文档，而不是 OpenAPI 3 文档。
|
||||
|
||||
### 创建新的配置选项
|
||||
|
||||
创建新的配置选项时，将它们添加到 `modules/setting` 的对应文件。您应该将信息添加到 `custom/conf/app.ini`
|
||||
并到[配置备忘单](../administration/config-cheat-sheet.md)
|
||||
在 `docs/content/doc/advanced/config-cheat-sheet.en-us.md` 中找到
|
||||
|
||||
### 更改Logo
|
||||
|
||||
更改 Gitea Logo SVG 时，您将需要运行并提交结果的：
|
||||
|
||||
```bash
|
||||
make generate-images
|
||||
```
|
||||
|
||||
这将创建必要的 Gitea 图标和其他图标。
|
||||
|
||||
### 数据库迁移
|
||||
|
||||
如果您对数据库中的任何数据库持久结构进行重大更改
|
||||
`models/` 目录，您将需要进行新的迁移。可以找到这些
|
||||
在 `models/migrations/` 中。您可以确保您的迁移适用于主要
|
||||
数据库类型使用：
|
||||
|
||||
```bash
|
||||
make test-sqlite-migration # 将 SQLite 切换为适当的数据库
|
||||
```
|
||||
|
||||
## 测试
|
||||
|
||||
Gitea 运行两种类型的测试：单元测试和集成测试。
|
||||
|
||||
### 单元测试
|
||||
|
||||
`go test` 系统中的`*_test.go` 涵盖了单元测试。
|
||||
您可以设置环境变量 `GITEA_UNIT_TESTS_LOG_SQL=1` 以在详细模式下运行测试时显示所有 SQL 语句（即设置`GOTESTFLAGS=-v` 时）。
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make test # Runs the unit tests
|
||||
```
|
||||
|
||||
### 集成测试
|
||||
|
||||
单元测试不会也不能完全单独测试 Gitea。因此，我们编写了集成测试；但是，这些依赖于数据库。
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build test-sqlite
|
||||
```
|
||||
|
||||
将在 SQLite 环境中运行集成测试。集成测试需要安装 `git lfs`。其他数据库测试可用，但
|
||||
可能需要适应当地环境。
|
||||
|
||||
看看 [`tests/integration/README.md`](https://github.com/go-gitea/gitea/blob/main/tests/integration/README.md) 有关更多信息以及如何运行单个测试。
|
||||
|
||||
### 测试 PR
|
||||
|
||||
我们的持续集成将测试代码是否通过了单元测试，并且所有支持的数据库都将在 Docker 环境中通过集成测试。
|
||||
还将测试从几个最新版本的 Gitea 迁移。
|
||||
|
||||
请在PR中附带提交适当的单元测试和集成测试。
|
||||
|
||||
## 网站文档
|
||||
|
||||
该网站的文档位于 `docs/` 中。如果你改变了文档内容，你可以使用以下测试方法进行持续集成：
|
||||
|
||||
```bash
|
||||
# 来自 Gitea 中的 docs 目录
|
||||
make trans-copy clean build
|
||||
```
|
||||
|
||||
运行此任务依赖于 [Hugo](https://gohugo.io/)。请注意：这可能会生成一些未跟踪的 Git 对象，
|
||||
需要被清理干净。
|
||||
|
||||
## Visual Studio Code
|
||||
|
||||
`contrib/ide/vscode` 中为 Visual Studio Code 提供了 `launch.json` 和 `tasks.json`。查看
|
||||
[`contrib/ide/README.md`](https://github.com/go-gitea/gitea/blob/main/contrib/ide/README.md) 了解更多信息。
|
||||
|
||||
## Goland
|
||||
|
||||
单击 `/main.go` 中函数 `func main()` 上的 `Run Application` 箭头
|
||||
可以快速启动一个可调试的 Gitea 实例。
|
||||
|
||||
`Run/Debug Configuration` 中的 `Output Directory` 必须设置为
|
||||
gitea 项目目录（包含 `main.go` 和 `go.mod`），
|
||||
否则，启动实例的工作目录是 GoLand 的临时目录
|
||||
并防止 Gitea 在开发环境中加载动态资源（例如：模板）。
|
||||
|
||||
要在 GoLand 中使用 SQLite 运行单元测试，请设置 `-tags sqlite,sqlite_unlock_notify`
|
||||
在 `运行/调试配置` 的 `Go 工具参数` 中。
|
||||
|
||||
## 提交 PR
|
||||
|
||||
对更改感到满意后，将它们推送并打开拉取请求。它建议您允许 Gitea Managers 和 Owners 修改您的 PR
|
||||
分支，因为我们需要在合并之前将其更新为 main 和/或可能是能够直接帮助解决问题。
|
||||
|
||||
任何 PR 都需要 Gitea 维护者的两次批准，并且需要通过持续集成。看看我们的
|
||||
[CONTRIBUTING.md](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md)
|
||||
文档。
|
||||
|
||||
如果您需要更多帮助，请访问 [Discord](https://discord.gg/gitea) #Develop 频道
|
||||
并在那里聊天。
|
||||
|
||||
现在，您已准备好 Hacking Gitea。
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
date: "2023-05-25T17:29:00+08:00"
|
||||
slug: "integrations"
|
||||
sidebar_position: 65
|
||||
aliases:
|
||||
- /zh-cn/integrations
|
||||
---
|
||||
|
||||
# 集成
|
||||
|
||||
Gitea 拥有一个出色的第三方集成社区，以及在其他各种项目中的一流支持。
|
||||
|
||||
我们正在[awesome-gitea](https://gitea.com/gitea/awesome-gitea)上整理一个列表来跟踪这些集成！
|
||||
|
||||
如果你正在寻找[CI/CD](https://gitea.com/gitea/awesome-gitea#user-content-devops)，
|
||||
一个[SDK](https://gitea.com/gitea/awesome-gitea#user-content-sdk)，
|
||||
甚至一些额外的[主题](https://gitea.com/gitea/awesome-gitea#user-content-themes)，
|
||||
你可以在[awesome-gitea](https://gitea.com/gitea/awesome-gitea)中找到它们的列表！
|
||||
|
||||
## 预填新文件名和内容
|
||||
|
||||
如果你想打开一个具有给定名称和内容的新文件，
|
||||
你可以使用查询参数来实现：
|
||||
|
||||
```txt
|
||||
GET /{{org}}/{{repo}}/_new/{{filepath}}
|
||||
?filename={{filename}}
|
||||
&value={{content}}
|
||||
```
|
||||
|
||||
例如：
|
||||
|
||||
```txt
|
||||
GET https://git.example.com/johndoe/bliss/_new/articles/
|
||||
?filename=hello-world.md
|
||||
&value=Hello%2C%20World!
|
||||
```
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
date: "2023-05-25T17:29:00+08:00"
|
||||
slug: "migrations-interfaces"
|
||||
sidebar_position: 55
|
||||
aliases:
|
||||
- /zh-cn/migrations-interfaces
|
||||
---
|
||||
|
||||
# 迁移接口
|
||||
|
||||
完整迁移功能在 Gitea 1.9.0 版本中引入。它定义了两个接口，用于支持从其他 Git 托管平台迁移存储库数据到 Gitea，或者在将来将 Gitea 数据迁移到其他 Git 托管平台。
|
||||
|
||||
目前已实现了从 GitHub、GitLab 和其他 Gitea 实例的迁移。
|
||||
|
||||
首先，Gitea 在包[modules/migration](https://github.com/go-gitea/gitea/tree/main/modules/migration)中定义了一些标准对象。它们是`Repository`、`Milestone`、`Release`、`ReleaseAsset`、`Label`、`Issue`、`Comment`、`PullRequest`、`Reaction`、`Review`、`ReviewComment`。
|
||||
|
||||
## 下载器接口
|
||||
|
||||
要从新的 Git 托管平台迁移，需要进行两个步骤的更新。
|
||||
|
||||
- 您应该实现一个`Downloader`，用于获取存储库信息。
|
||||
- 您应该实现一个`DownloaderFactory`，用于检测 URL 是否匹配，并创建上述的`Downloader`。
|
||||
- 您需要在`init()`中通过`RegisterDownloaderFactory`注册`DownloaderFactory`。
|
||||
|
||||
您可以在[downloader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/downloader.go)中找到这些接口。
|
||||
|
||||
## 上传器接口
|
||||
|
||||
目前，只实现了`GiteaLocalUploader`，因此我们只能通过此 Uploader 将下载的数据保存到本地的 Gitea 实例。目前不支持其他上传器。
|
||||
|
||||
您可以在[uploader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/uploader.go)中找到这些接口。
|
||||
@@ -1,128 +0,0 @@
|
||||
---
|
||||
date: "2019-04-19:44:00+01:00"
|
||||
slug: "oauth2-provider"
|
||||
sidebar_position: 41
|
||||
aliases:
|
||||
- /zh-cn/oauth2-provider
|
||||
---
|
||||
|
||||
# OAuth2 提供者
|
||||
|
||||
Gitea 支持作为 OAuth2 提供者，允许第三方应用程序在用户同意的情况下访问其资源。此功能自 1.8.0 版起可用。
|
||||
|
||||
## 端点
|
||||
|
||||
| 端点 | URL |
|
||||
| ------------------------ | ----------------------------------- |
|
||||
| OpenID Connect Discovery | `/.well-known/openid-configuration` |
|
||||
| Authorization Endpoint | `/login/oauth/authorize` |
|
||||
| Access Token Endpoint | `/login/oauth/access_token` |
|
||||
| OpenID Connect UserInfo | `/login/oauth/userinfo` |
|
||||
| JSON Web Key Set | `/login/oauth/keys` |
|
||||
|
||||
## 支持的 OAuth2 授权
|
||||
|
||||
目前 Gitea 仅支持 [**Authorization Code Grant**](https://tools.ietf.org/html/rfc6749#section-1.3.1) 标准，并额外支持以下扩展：
|
||||
|
||||
- [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636)
|
||||
- [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth)
|
||||
|
||||
要将 Authorization Code Grant 作为第三方应用程序，您需要通过在设置中添加一个新的 "应用程序" (`/user/settings/applications`)。
|
||||
|
||||
## 范围
|
||||
|
||||
Gitea 支持以下令牌范围:
|
||||
|
||||
| 名称 | 介绍 |
|
||||
| ---------------------------------------- | --------------------------------------------------------------- |
|
||||
| **(no scope)** | 授予对公共用户配置文件和公共存储库的只读访问权限 |
|
||||
| **repo** | 完全控制所有存储库 |
|
||||
| **repo:status** | 授予对所有存储库中提交状态的读/写访问权限 |
|
||||
| **public_repo** | 仅授予对公共存储库的读/写访问权限 |
|
||||
| **admin:repo_hook** | 授予对所有存储库的 Hooks 访问权限，该权限已包含在 `repo` 范围中 |
|
||||
| **write:repo_hook** | 授予对存储库 Hooks 的读/写访问权限 |
|
||||
| **read:repo_hook** | 授予对存储库 Hooks 的只读访问权限 |
|
||||
| **admin:org** | 授予对组织设置的完全访问权限 |
|
||||
| **write:org** | 授予对组织设置的读/写访问权限 |
|
||||
| **read:org** | 授予对组织设置的只读访问权限 |
|
||||
| **admin:public_key** | 授予公钥管理的完全访问权限 |
|
||||
| **write:public_key** | 授予对公钥的读/写访问权限 |
|
||||
| **read:public_key** | 授予对公钥的只读访问权限 |
|
||||
| **admin:org_hook** | 授予对组织级别 Hooks 的完全访问权限 |
|
||||
| **admin:user_hook** | 授予对用户级别 Hooks 的完全访问权限 |
|
||||
| **notification** | 授予对通知的完全访问权限 |
|
||||
| **user** | 授予对用户个人资料信息的完全访问权限 |
|
||||
| **read:user** | 授予对用户个人资料的读取权限 |
|
||||
| **user:email** | 授予对用户电子邮件地址的读取权限 |
|
||||
| **user:follow** | 授予访问权限以关注/取消关注用户 |
|
||||
| **delete_repo** | 授予删除存储库的权限 |
|
||||
| **package** | 授予对托管包的完全访问权限 |
|
||||
| **write:package** | 授予对包的读/写访问权限 |
|
||||
| **read:package** | 授予对包的读取权限 |
|
||||
| **delete:package** | 授予对包的删除权限 |
|
||||
| **admin:gpg_key** | 授予 GPG 密钥管理的完全访问权限 |
|
||||
| **write:gpg_key** | 授予对 GPG 密钥的读/写访问权限 |
|
||||
| **read:gpg_key** | 授予对 GPG 密钥的只读访问权限 |
|
||||
| **admin:application** | 授予应用程序管理的完全访问权限 |
|
||||
| **write:application** | 授予应用程序管理的读/写访问权限 |
|
||||
| **read:application** | 授予应用程序管理的读取权限 |
|
||||
| **sudo** | 允许以站点管理员身份执行操作 |
|
||||
|
||||
## 客户端类型
|
||||
|
||||
Gitea 支持私密和公共客户端类型，[参见 RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1).
|
||||
|
||||
对于公共客户端, 允许在本地回环地址的重定向 URI 中使用任意端口，例如 `http://127.0.0.1/`。根据 [RFC 8252 的建议](https://datatracker.ietf.org/doc/html/rfc8252#section-8.3)，请避免使用 `localhost`。
|
||||
|
||||
## 示例
|
||||
|
||||
**注意：** 该示例中尚未使用 PKCE。
|
||||
|
||||
1. 将用户重定向到授权端点，以获得他们的访问资源授权:
|
||||
|
||||
```curl
|
||||
https://[YOUR-GITEA-URL]/login/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI& response_type=code&state=STATE
|
||||
```
|
||||
|
||||
在设置中注册应用程序以获得 `CLIENT_ID`。`STATE` 是一个随机字符串，它将在获得用户授权后发送回您的应用程序。`state` 参数是可选的，但您应该使用它来防止 CSRF 攻击。
|
||||
|
||||
|
||||
|
||||
用户将会被询问是否授权给您的应用程序。如果他们同意了授权，用户将会被重定向到 `REDIRECT_URL`，例如：
|
||||
|
||||
```curl
|
||||
https://[REDIRECT_URI]?code=RETURNED_CODE&state=STATE
|
||||
```
|
||||
|
||||
2. 使用重定向提供的 `code`，您可以请求一个新的应用程序和 Refresh Token。Access Token Endpoint 接受 `application/json` 或 `application/x-www-form-urlencoded` 类型的 POST 请求，例如：
|
||||
|
||||
```curl
|
||||
POST https://[YOUR-GITEA-URL]/login/oauth/access_token
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"client_id": "YOUR_CLIENT_ID",
|
||||
"client_secret": "YOUR_CLIENT_SECRET",
|
||||
"code": "RETURNED_CODE",
|
||||
"grant_type": "authorization_code",
|
||||
"redirect_uri": "REDIRECT_URI"
|
||||
}
|
||||
```
|
||||
|
||||
返回：
|
||||
|
||||
```json
|
||||
{
|
||||
"access_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjowLCJleHAiOjE1NTUxNzk5MTIsImlhdCI6MTU1NTE3NjMxMn0.0-iFsAwBtxuckA0sNZ6QpBQmywVPz129u75vOM7wPJecw5wqGyBkmstfJHAjEOqrAf_V5Z-1QYeCh_Cz4RiKug",
|
||||
"token_type": "bearer",
|
||||
"expires_in": 3600,
|
||||
"refresh_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjoxLCJjbnQiOjEsImV4cCI6MTU1NzgwNDMxMiwiaWF0IjoxNTU1MTc2MzEyfQ.S_HZQBy4q9r5SEzNGNIoFClT43HPNDbUdHH-GYNYYdkRfft6XptJBkUQscZsGxOW975Yk6RbgtGvq1nkEcklOw"
|
||||
}
|
||||
```
|
||||
|
||||
`CLIENT_SECRET` 是生成给应用程序的唯一密钥。请注意，该密钥只会在您使用 Gitea 创建/注册应用程序后出现一次。如果您丢失了密钥，您必须在应用程序设置中重新生成密钥。
|
||||
|
||||
`access_token` 请求中的 `REDIRECT_URI` 必须与 `authorize` 请求中的 `REDIRECT_URI` 相符。
|
||||
|
||||
3. 使用 `access_token` 来构造 [API 请求](https://docs.gitea.io/en-us/api-usage#oauth2) 以读写用户的资源。
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
date: "2017-01-20T15:00:00+08:00"
|
||||
title: "帮助"
|
||||
slug: "help"
|
||||
sidebar_position: 5
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "帮助"
|
||||
sidebar_position: 100
|
||||
identifier: "help"
|
||||
---
|
||||
@@ -1,463 +0,0 @@
|
||||
---
|
||||
date: "2023-05-25T16:00:00+02:00"
|
||||
slug: "faq"
|
||||
sidebar_position: 5
|
||||
aliases:
|
||||
- /zh-cn/faq
|
||||
---
|
||||
|
||||
# 常见问题
|
||||
|
||||
本页面包含一些常见问题和答案。
|
||||
|
||||
有关更多帮助资源，请查看所有[支持选项](seek-help.md)。
|
||||
|
||||
## 1.x 和 1.x.x 下载之间的区别
|
||||
|
||||
以 1.7.x 版本为例。
|
||||
|
||||
**注意：**此示例也适用于 Docker 镜像！
|
||||
|
||||
在我们的[下载页面](https://dl.gitea.io/gitea/)上，您会看到一个 1.7 目录，以及 1.7.0、1.7.1、1.7.2、1.7.3、1.7.4、1.7.5 和 1.7.6 的目录。
|
||||
|
||||
1.7 目录和 1.7.0 目录是**不同**的。1.7 目录是在每个合并到[`release/v1.7`](https://github.com/go-gitea/gitea/tree/release/v1.7)分支的提交上构建的。
|
||||
|
||||
然而，1.7.0 目录是在创建[`v1.7.0`](https://github.com/go-gitea/gitea/releases/tag/v1.7.0)标签时创建的构建。
|
||||
|
||||
这意味着 1.x 的下载会随着提交合并到各自的分支而改变（将其视为每个版本的单独的“main”分支）。
|
||||
|
||||
另一方面，1.x.x 的下载应该永远不会改变。
|
||||
|
||||
## 如何从 Gogs/GitHub 等迁移到 Gitea
|
||||
|
||||
要从 Gogs 迁移到 Gitea：
|
||||
|
||||
- [Gogs 版本 0.9.146 或更低](installation/upgrade-from-gogs.md)
|
||||
- [Gogs 版本 0.11.46.0418](https://github.com/go-gitea/gitea/issues/4286)
|
||||
|
||||
要从 GitHub 迁移到 Gitea，您可以使用 Gitea 内置的迁移表单。
|
||||
|
||||
为了迁移诸如问题、拉取请求等项目，您需要至少输入您的用户名。
|
||||
|
||||
[Example (requires login)](https://try.gitea.io/repo/migrate)
|
||||
|
||||
要从 GitLab 迁移到 Gitea，您可以使用这个非关联的工具：
|
||||
|
||||
https://github.com/loganinak/MigrateGitlabToGogs
|
||||
|
||||
## Gitea 存储文件的位置
|
||||
|
||||
- _`AppWorkPath`_
|
||||
- `--work-path`标志
|
||||
- 或者环境变量`GITEA_WORK_DIR`
|
||||
- 或者在构建时设置的内置值
|
||||
- 或者包含 Gitea 二进制文件的目录
|
||||
- `%(APP_DATA_PATH)`（数据库、索引器等的默认路径）
|
||||
- `app.ini`中的`APP_DATA_PATH`
|
||||
- 或者*`AppWorkPath`*`/data`
|
||||
- _`CustomPath`_（自定义模板）
|
||||
- `--custom-path`标志
|
||||
- 或者环境变量`GITEA_CUSTOM`
|
||||
- 或者在构建时设置的内置值
|
||||
- 或者*`AppWorkPath`*`/custom`
|
||||
- HomeDir
|
||||
- Unix：环境变量`HOME`
|
||||
- Windows：环境变量`USERPROFILE`，或者环境变量`HOMEDRIVE`+`HOMEPATH`
|
||||
- RepoRootPath
|
||||
- `app.ini`中\[repository]部分的`ROOT`（如果是绝对路径）
|
||||
- 否则*`AppWorkPath`*`/ROOT`(如果`app.ini`中\[repository]部分的`ROOT`是相对路径）
|
||||
- 默认值为`%(APP_DATA_PATH)/gitea-repositories`
|
||||
- INI（配置文件）
|
||||
- `--config`标志
|
||||
- 或者在构建时设置的可能内置值
|
||||
- 或者 _`CustomPath`_`/conf/app.ini`
|
||||
- SQLite 数据库
|
||||
- app.ini 中 database 部分的 PATH
|
||||
- 或者`%(APP_DATA_PATH)/gitea.db`
|
||||
|
||||
## 看不到克隆 URL 或克隆 URL 不正确
|
||||
|
||||
有几个地方可能会导致显示不正确。
|
||||
|
||||
1. 如果使用反向代理，请确保按照[反向代理指南](../administration/reverse-proxies.md)中的正确说明进行设置。
|
||||
2. 确保在`app.ini`的`server`部分中正确设置了`ROOT_URL`。
|
||||
|
||||
如果某些克隆选项未显示（HTTP/S 或 SSH），可以在`app.ini中`
|
||||
|
||||
- `DISABLE_HTTP_GIT`: 如果设为 true, 将会没有 HTTP/HTTPS 链接
|
||||
- `DISABLE_SSH`: 如果设为 true, 将会没有 SSH 链接
|
||||
- `SSH_EXPOSE_ANONYMOUS`: 如果设为 false, SSH 链接将会对匿名用户隐藏
|
||||
|
||||
## 文件上传失败：413 Request Entity Too Large
|
||||
|
||||
当反向代理限制文件上传大小时，会出现此错误。
|
||||
|
||||
有关使用 nginx 解决此问题，请参阅[反向代理指南](../administration/reverse-proxies.md)。
|
||||
|
||||
## 自定义模板无法加载或运行错误
|
||||
|
||||
Gitea 的自定义模板必须将其添加到正确的位置，否则 Gitea 将无法找到并使用自定义模板。
|
||||
|
||||
模板的正确路径应该相对于`CustomPath`。
|
||||
|
||||
1. 要找到`CustomPath`，请在站点管理 -> 配置 中查找自定义文件根路径。
|
||||
|
||||
如果找不到，请尝试`echo $GITEA_CUSTOM`。
|
||||
|
||||
2. 如果仍然找不到，默认值可以被[计算](faq.md#Gitea存储文件的位置)
|
||||
3. 如果仍然找不到路径，则可以参考[自定义 Gitea](../administration/customizing-gitea.md)页面，将模板添加到正确的位置。
|
||||
|
||||
## Gitea 是否有"GitHub/GitLab Pages"功能？
|
||||
|
||||
Gitea 不提供内置的 Pages 服务器。您需要一个专用的域名来提供静态页面，以避免 CSRF 安全风险。
|
||||
|
||||
对于简单的用法，您可以使用反向代理来重写和提供 Gitea 的原始文件 URL 中的静态内容。
|
||||
|
||||
还有一些已经可用的第三方服务，比如独立[pages server](https://codeberg.org/Codeberg/pages-server)的或[caddy plugin](https://github.com/42wim/caddy-gitea)，可以提供所需的功能。
|
||||
|
||||
## 活跃用户与禁止登录用户
|
||||
|
||||
在 Gitea 中，"活跃用户"是指通过电子邮件激活其帐户的用户。
|
||||
|
||||
"禁止登录用户"是指不允许再登录到 Gitea 的用户。
|
||||
|
||||
## 设置日志记录
|
||||
|
||||
- [官方文档](../administration/logging-documentation.md)
|
||||
|
||||
## 什么是 Swagger？
|
||||
|
||||
[Swagger](https://swagger.io/) 是 Gitea 用于其 API 文档的工具。
|
||||
|
||||
所有 Gitea 实例都有内置的 API，无法完全禁用它。
|
||||
但是，您可以在 app.ini 的 api 部分将 ENABLE_SWAGGER 设置为 false，以禁用其文档显示。
|
||||
有关更多信息，请参阅 Gitea 的[API 文档](development/api-usage.md)。
|
||||
|
||||
您可以在上查看最新的 API（例如）https://try.gitea.io/api/swagger
|
||||
|
||||
您还可以在上查看`swagger.json`文件的示例 https://try.gitea.io/swagger.v1.json
|
||||
|
||||
## 调整服务器用于公共/私有使用
|
||||
|
||||
### 防止垃圾邮件发送者
|
||||
|
||||
有多种方法可以组合使用来防止垃圾邮件发送者：
|
||||
|
||||
1. 通过设置电子邮件域名的白名单或黑名单。
|
||||
2. 通过设置一些域名或者 OpenID 白名单（见下文）。
|
||||
3. 在您的`app.ini`中将`ENABLE_CAPTCHA`设置为`true`，并正确配置`RECAPTCHA_SECRET`和 `RECAPTCHA_SITEKEY`。
|
||||
4. 将`DISABLE_REGISTRATION`设置为`true`，并通过 [CLI](../administration/command-line.md)、[API](../development/api-usage.md) 或 Gitea 的管理界面创建新用户。
|
||||
|
||||
### 仅允许/阻止特定的电子邮件域名
|
||||
|
||||
您可以在`app.ini`中的`[service]`下的配置`EMAIL_DOMAIN_WHITELIST` 或 `EMAIL_DOMAIN_BLOCKLIST`。
|
||||
|
||||
### 仅允许/阻止特定的 OpenID 提供商
|
||||
|
||||
您可以在`app.ini`的`[openid]`下配置`WHITELISTED_URI`或`BLACKLISTED_URIS`。
|
||||
|
||||
**注意**： 白名单优先，如果白名单非空，则忽略黑名单。
|
||||
|
||||
### 仅允许发布问题的用户
|
||||
|
||||
目前实现这一点的方法是创建/修改一个具有最大仓库创建限制为 0 的用户。
|
||||
|
||||
### 受限制的用户
|
||||
|
||||
受限制的用户仅能访问其组织/团队成员和协作所在的内容的子集，而忽略组织/仓库等的公共标志。
|
||||
|
||||
示例用例：一个公司运行一个需要登录的 Gitea 实例。大多数仓库是公开的（所有同事都可以访问/浏览）。
|
||||
|
||||
在某些情况下，某个客户或第三方需要访问特定的仓库，并且只能访问该仓库。通过将此类客户帐户设置为受限制帐户，并使用团队成员身份和/或协作来授予所需的任何访问权限，可以简单地实现这一点，而无需使所有内容都变为私有。
|
||||
|
||||
### 启用 Fail2ban
|
||||
|
||||
使用 [Fail2Ban](../administration/fail2ban-setup.md) 监视并阻止基于日志模式的自动登录尝试或其他恶意行为。
|
||||
|
||||
## 如何添加/使用自定义主题
|
||||
|
||||
Gitea 目前支持三个官方主题，分别是 `gitea`（亮色）、`arc-green`（暗色）和 `auto`（根据操作系统设置自动切换前两个主题）。
|
||||
要添加自己的主题，目前唯一的方法是提供一个完整的主题（不仅仅是颜色覆盖）。
|
||||
|
||||
假设我们的主题是 `arc-blue`（这是一个真实的主题，可以在[此问题](https://github.com/go-gitea/gitea/issues/6011)中找到）
|
||||
|
||||
将`.css`文件命名为`theme-arc-blue.css`并将其添加到`custom/public/css`文件夹中
|
||||
|
||||
通过将`arc-blue`添加到`app.ini`中的`THEMES`列表中，允许用户使用该主题
|
||||
|
||||
## SSHD vs 内建 SSH
|
||||
|
||||
SSHD 是大多数 Unix 系统上内建的 SSH 服务器。
|
||||
|
||||
Gitea 还提供了自己的 SSH 服务器，用于在 SSHD 不可用时使用。
|
||||
|
||||
## Gitea 运行缓慢
|
||||
|
||||
导致此问题的最常见原因是加载联合头像。
|
||||
|
||||
您可以通过在`app.ini`中将`ENABLE_FEDERATED_AVATAR`设置为`false`来关闭此功能。
|
||||
|
||||
还有一个可能需要更改的选项是在`app.ini`中将`DISABLE_GRAVATAR`设置为`true`。
|
||||
|
||||
## 无法创建仓库/文件
|
||||
|
||||
请确保 Gitea 具有足够的权限来写入其主目录和数据目录。
|
||||
|
||||
参见[AppDataPath 和 RepoRootPath](faq.md#Gitea存储文件的位置)
|
||||
|
||||
**适用于 Arch 用户的注意事项：**在撰写本文时，Arch 软件包的 systemd 文件包含了以下行：
|
||||
|
||||
`ReadWritePaths=/etc/gitea/app.ini`
|
||||
|
||||
这将使得 Gitea 无法写入其他路径。
|
||||
|
||||
## 翻译不正确/如何添加更多翻译
|
||||
|
||||
我们当前的翻译是在我们的[Crowdin 项目](https://crowdin.com/project/gitea)上众包进行的
|
||||
|
||||
无论您想要更改翻译还是添加新的翻译，都需要在 Crowdin 集成中进行，因为所有翻译都会被 CI 覆盖。
|
||||
|
||||
## 推送钩子/ Webhook 未运行
|
||||
|
||||
如果您可以推送但无法在主页仪表板上看到推送活动，或者推送不触发 Webhook，有几种可能性：
|
||||
|
||||
1. Git 钩子不同步：在站点管理面板上运行“重新同步所有仓库的 pre-receive、update 和 post-receive 钩子”
|
||||
2. Git 仓库（和钩子）存储在一些不支持脚本执行的文件系统上（例如由 NAS 挂载），请确保文件系统支持`chmod a+x any-script`
|
||||
3. 如果您使用的是 Docker，请确保 Docker Server（而不是客户端）的版本 >= 20.10.6
|
||||
|
||||
## SSH 问题
|
||||
|
||||
如果无法通过`ssh`访问仓库，但`https`正常工作，请考虑以下情况。
|
||||
|
||||
首先，请确保您可以通过 SSH 访问 Gitea。
|
||||
|
||||
`ssh git@myremote.example`
|
||||
|
||||
如果连接成功，您应该会收到以下错误消息：
|
||||
|
||||
```bash
|
||||
Hi there, You've successfully authenticated, but Gitea does not provide shell access.
|
||||
If this is unexpected, please log in with password and setup Gitea under another user.
|
||||
```
|
||||
|
||||
如果您收到以上消息但仍然连接成功，这意味着您的 SSH 密钥**没有**由 Gitea 管理。这意味着钩子不会运行，在其他一些潜在问题中也包括在内。
|
||||
|
||||
如果您无法连接，可能是因为您的 SSH 密钥在本地配置不正确。
|
||||
这是针对 SSH 而不是 Gitea 的问题，因此在此不涉及。
|
||||
|
||||
### SSH 常见错误
|
||||
|
||||
```bash
|
||||
Permission denied (publickey).
|
||||
fatal: Could not read from remote repository.
|
||||
```
|
||||
|
||||
此错误表示服务器拒绝登录尝试，
|
||||
请检查以下事项：
|
||||
|
||||
- 在客户端：
|
||||
- 确保公钥和私钥已添加到正确的 Gitea 用户。
|
||||
- 确保远程 URL 中没有任何问题。特别是，请确保 ∂
|
||||
Git 用户（@ 之前的部分）的名称拼写正确。
|
||||
- 确保客户端机器上的公钥和私钥正确无误。
|
||||
- 在服务器上：
|
||||
|
||||
- 确保存储库存在并且命名正确。
|
||||
- 检查系统用户主目录中的 `.ssh` 目录的权限。
|
||||
- 验证正确的公钥是否已添加到 `.ssh/authorized_keys` 中。
|
||||
|
||||
尝试在 Gitea 管理面板上运行
|
||||
`Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys)`。
|
||||
|
||||
- 查看 Gitea 日志。
|
||||
- 查看 /var/log/auth（或类似的文件）。
|
||||
- 检查存储库的权限。
|
||||
|
||||
以下是一个示例，其中缺少公共 SSH 密钥，
|
||||
认证成功，但是其他设置导致 SSH 无法访问正确的
|
||||
存储库。
|
||||
|
||||
```bash
|
||||
fatal: Could not read from remote repository.
|
||||
|
||||
Please make sure you have the correct access rights
|
||||
and the repository exists.
|
||||
```
|
||||
|
||||
在这种情况下，请检查以下设置：
|
||||
|
||||
- 在服务器上：
|
||||
- 确保`git`系统用户设置了可用的 shell
|
||||
- 使用`getent passwd git | cut -d: -f7`进行验证
|
||||
- 可以使用`usermod`或`chsh`进行修改。
|
||||
- 确保`.ssh/authorized_keys`中的`gitea serv`命令使用
|
||||
正确的配置文件。
|
||||
|
||||
## 迁移带有标签的存储库后缺失发布版本
|
||||
|
||||
要迁移带有所有标签的存储库，您需要执行两个操作：
|
||||
|
||||
- 推送标签到存储库：
|
||||
|
||||
```bash
|
||||
git push --tags
|
||||
```
|
||||
|
||||
- 在 Gitea 中重新同步所有存储库的标签：
|
||||
|
||||
```bash
|
||||
gitea admin repo-sync-releases
|
||||
```
|
||||
|
||||
## LFS 问题
|
||||
|
||||
针对涉及 LFS 数据上传的问题
|
||||
|
||||
```bash
|
||||
batch response: Authentication required: Authorization error: <GITEA_LFS_URL>/info/lfs/objects/batch
|
||||
Check that you have proper access to the repository
|
||||
error: failed to push some refs to '<GIT_REPO_URL>'
|
||||
```
|
||||
|
||||
检查`app.ini`文件中的`LFS_HTTP_AUTH_EXPIRY`值。
|
||||
|
||||
默认情况下，LFS 令牌在 20 分钟后过期。如果您的连接速度较慢或文件较大（或两者都是），可能无法在时间限制内完成上传。
|
||||
|
||||
您可以将此值设置为`60m`或`120m`。
|
||||
|
||||
## 如何在启动 Gitea 之前创建用户
|
||||
|
||||
Gitea 提供了一个子命令`gitea migrate`来初始化数据库，然后您可以使用[管理 CLI 命令](../administration/command-line.md#admin)像正常情况下添加用户。
|
||||
|
||||
## 如何启用密码重置
|
||||
|
||||
没有密码重置的设置。当配置了[邮件服务](../administration/email-setup.md)时，密码重置将自动启用；否则将被禁用。
|
||||
|
||||
## 如何更改用户的密码
|
||||
|
||||
- 作为管理员，您可以更改任何用户的密码（并可选择强制其在下次登录时更改密码）...
|
||||
- 转到您的`站点管理 -> 用户账户`页面并编辑用户。
|
||||
- 使用[管理 CLI 命令](../administration/command-line.md#admin)。
|
||||
|
||||
请注意，大多数命令还需要一个[全局标志](../administration/command-line.md#全局选项)来指向正确的配置。
|
||||
|
||||
- 作为**用户**，您可以更改密码...
|
||||
|
||||
- 在您的账户的`设置 -> 账户`页面（此方法**需要**您知道当前密码）。
|
||||
- 使用`忘记密码`链接。
|
||||
|
||||
如果`忘记密码/账户恢复`页面被禁用，请联系管理员配置[邮件服务](../administration/email-setup.md)。
|
||||
|
||||
## 为什么我的 Markdown 显示错误
|
||||
|
||||
在 Gitea 版本 `1.11` 中，我们转换为使用[goldmark](https://github.com/yuin/goldmark)进行 Markdown 渲染，它符合[CommonMark](https://commonmark.org/)标准。
|
||||
|
||||
如果您在版本`1.11`之前的 Markdown 正常工作，但在升级后无法正常工作，请仔细阅读 CommonMark 规范，看看问题是由错误还是非兼容的语法引起的。
|
||||
|
||||
如果是后者，通常规范中会列出一种符合标准的替代方法。
|
||||
|
||||
## 使用 MySQL 进行升级时出现的错误
|
||||
|
||||
如果在使用 MySQL 升级 Gitea 时收到以下错误：
|
||||
|
||||
> `ORM engine initialization failed: migrate: do migrate: Error: 1118: Row size too large...`
|
||||
|
||||
请运行 `gitea convert` 或对数据库中的每个表运行 `ALTER TABLE table_name ROW_FORMAT=dynamic;`。
|
||||
|
||||
潜在问题是默认行格式分配给每个表的索引空间
|
||||
太小。Gitea 要求其表的 `ROWFORMAT` 为 `DYNAMIC`。
|
||||
|
||||
如果收到包含 `Error 1071: Specified key was too long; max key length is 1000 bytes...`
|
||||
的错误行，则表示您正在尝试在使用 ISAM 引擎的表上运行 Gitea。尽管在先前版本的 Gitea 中可能是凑巧能够工作的，但它从未得到官方支持，
|
||||
您必须使用 InnoDB。您应该对数据库中的每个表运行`ALTER TABLE table_name ENGINE=InnoDB;`。
|
||||
|
||||
如果您使用的是 MySQL 5，另一个可能的修复方法是：
|
||||
|
||||
```SQL
|
||||
SET GLOBAL innodb_file_format=Barracuda;
|
||||
SET GLOBAL innodb_file_per_table=1;
|
||||
SET GLOBAL innodb_large_prefix=1;
|
||||
```
|
||||
|
||||
## 为什么 MySQL 上的 Emoji 显示错误
|
||||
|
||||
不幸的是，MySQL 的`utf8`字符集不完全允许所有可能的 UTF-8 字符，特别是 Emoji。
|
||||
他们创建了一个名为 `utf8mb4`的字符集和校对规则，允许存储 Emoji，但使用
|
||||
utf8 字符集的表和连接将不会使用它。
|
||||
|
||||
请运行 `gitea convert` 或对数据库运行 `ALTER DATABASE database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;`
|
||||
并对每个表运行
|
||||
`ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;`。
|
||||
|
||||
您还需要将`app.ini`文件中的数据库字符集设置为`CHARSET=utf8mb4`。
|
||||
|
||||
## 为什么 Emoji 只显示占位符或单色图像
|
||||
|
||||
Gitea 需要系统或浏览器安装其中一个受支持的 Emoji 字体，例如 `Apple Color Emoji`、`Segoe UI Emoji`、`Segoe UI Symbol`、`Noto Color Emoji` 和 `Twemoji Mozilla`。通常，操作系统应该已经提供了其中一个字体，但特别是在 Linux 上，可能需要手动安装它们。
|
||||
|
||||
## SystemD 和 Docker 上的标准输出日志
|
||||
|
||||
SystemD 上的标准输出默认会写入日志记录中。您可以尝试使用 `journalctl`、`journalctl -u gitea` 或 `journalctl <path-to-gitea-binary>`来查看。
|
||||
|
||||
类似地，Docker 上的标准输出可以使用`docker logs <container>`来查看。
|
||||
|
||||
要收集日志以进行帮助和问题报告，请参阅[支持选项](seek-help.md)。
|
||||
|
||||
## 初始日志记录
|
||||
|
||||
在 Gitea 读取配置文件并设置其日志记录之前，它会将一些内容记录到标准输出，以帮助调试日志记录无法工作的情况。
|
||||
|
||||
您可以通过设置`--quiet`或`-q`选项来停止此日志记录。请注意，这只会在 Gitea 设置自己的日志记录之前停止日志记录。
|
||||
|
||||
如果您报告了错误或问题，必须提供这些信息以恢复初始日志记录。
|
||||
|
||||
只有在完全配置了所有内容之后，您才应该设置此选项。
|
||||
|
||||
## 在数据库启动期间出现有关结构默认值的警告
|
||||
|
||||
有时，在迁移过程中，旧列和默认值可能在数据库架构中保持不变。
|
||||
这可能会导致警告，例如：
|
||||
|
||||
```bash
|
||||
2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync2() [W] Table user Column keep_activity_private db default is , struct default is 0
|
||||
```
|
||||
|
||||
可以安全地忽略这些警告，但您可以通过让 Gitea 重新创建这些表来停止这些警告，使用以下命令：
|
||||
|
||||
```bash
|
||||
gitea doctor recreate-table user
|
||||
```
|
||||
|
||||
这将导致 Gitea 重新创建用户表并将旧数据复制到新表中，
|
||||
并正确设置默认值。
|
||||
|
||||
您可以使用以下命令要求 Gitea 重新创建多个表：
|
||||
|
||||
```bash
|
||||
gitea doctor recreate-table table1 table2 ...
|
||||
```
|
||||
|
||||
如果您希望 Gitea 重新创建所有表，请使用以下命令：
|
||||
|
||||
```bash
|
||||
gitea doctor recreate-table
|
||||
```
|
||||
|
||||
在运行这些命令之前，强烈建议您备份数据库。
|
||||
|
||||
## 为什么查看文件时制表符/缩进显示错误
|
||||
|
||||
如果您正在使用 Cloudflare，请在仪表板中关闭自动缩小选项。
|
||||
|
||||
`Speed` -> `Optimization` -> 在 `Auto-Minify` 设置中取消选中 `HTML`。
|
||||
|
||||
## 如何从磁盘采用存储库
|
||||
|
||||
- 将您的（裸）存储库添加到正确的位置，即您的配置所在的地方（`repository.ROOT`），确保它们位于正确的布局`<REPO_ROOT>/[user]/[repo].git`。
|
||||
- **注意：**目录名必须为小写。
|
||||
- 您还可以在`<ROOT_URL>/admin/config`中检查存储库根路径。
|
||||
- 确保存在要采用存储库的用户/组织。
|
||||
- 作为管理员，转到`<ROOT_URL>/admin/repos/unadopted`并搜索。
|
||||
- 用户也可以通过配置[`ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`](../administration/config-cheat-sheet.md#仓库) 获得类似的权限。
|
||||
- 如果上述步骤都正确执行，您应该能够选择要采用的存储库。
|
||||
- 如果没有找到存储库，请启用[调试日志记录](../administration/config-cheat-sheet.md#仓库)以检查是否有特定错误。
|
||||
@@ -1,21 +0,0 @@
|
||||
---
|
||||
date: "2017-01-20T15:00:00+08:00"
|
||||
slug: "seek-help"
|
||||
sidebar_position: 20
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "help"
|
||||
name: "需要帮助"
|
||||
sidebar_position: 20
|
||||
identifier: "seek-help"
|
||||
---
|
||||
|
||||
# 需要帮助？
|
||||
|
||||
如果您在使用或者开发过程中遇到问题，请到以下渠道咨询：
|
||||
|
||||
- 到 [GitHub Issue](https://github.com/go-gitea/gitea/issues) 提问(因为项目维护人员来自世界各地，为保证沟通顺畅，请使用英文提问)
|
||||
- 中文问题到 [Gitea 论坛](https://discourse.gitea.io/c/5-category/5) 提问
|
||||
- 访问 [Discord Gitea 聊天室 - 英文](https://discord.gg/Gitea)
|
||||
- 加入 QQ群 328432459 获得进一步的支持
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
date: "2016-11-08T16:00:00+02:00"
|
||||
|
||||
slug: /
|
||||
sidebar_position: 10
|
||||
|
||||
---
|
||||
|
||||
# 关于Gitea
|
||||
|
||||
Gitea 是一个自己托管的Git服务程序。他和GitHub, Bitbucket or Gitlab等比较类似。他是从 [Gogs](http://gogs.io) 发展而来，不过我们已经Fork并且命名为Gitea。对于我们Fork的原因可以看 [这里](https://blog.gitea.io/2016/12/welcome-to-gitea/)。
|
||||
|
||||
## 目标
|
||||
|
||||
Gitea的首要目标是创建一个极易安装，运行非常快速，安装和使用体验良好的自建 Git 服务。我们采用Go作为后端语言，这使我们只要生成一个可执行程序即可。并且他还支持跨平台，支持 Linux, macOS 和 Windows 以及各种架构，除了x86，amd64，还包括 ARM 和 PowerPC。
|
||||
|
||||
## 功能特性
|
||||
|
||||
- 支持活动时间线
|
||||
- 支持 SSH 以及 HTTP/HTTPS 协议
|
||||
- 支持 SMTP、LDAP 和反向代理的用户认证
|
||||
- 支持反向代理子路径
|
||||
- 支持用户、组织和仓库管理系统
|
||||
- 支持添加和删除仓库协作者
|
||||
- 支持仓库和组织级别 Web 钩子（包括 Slack 集成）
|
||||
- 支持仓库 Git 钩子和部署密钥
|
||||
- 支持仓库工单（Issue）、合并请求（Pull Request）以及 Wiki
|
||||
- 支持迁移和镜像仓库以及它的 Wiki
|
||||
- 支持在线编辑仓库文件和 Wiki
|
||||
- 支持自定义源的 Gravatar 和 Federated Avatar
|
||||
- 支持邮件服务
|
||||
- 支持后台管理面板
|
||||
- 支持 MySQL、PostgreSQL、SQLite3、MSSQL 和 TiDB(MySQL) 数据库
|
||||
- 支持多语言本地化（21 种语言）
|
||||
- 支持软件包注册中心（Composer/Conan/Container/Generic/Helm/Maven/NPM/Nuget/PyPI/RubyGems）
|
||||
|
||||
## 系统要求
|
||||
|
||||
- 最低的系统硬件要求为一个廉价的树莓派
|
||||
- 如果用于团队项目，建议使用 2 核 CPU 及 1GB 内存
|
||||
|
||||
## 浏览器支持
|
||||
|
||||
- Chrome, Firefox, Safari, Edge
|
||||
|
||||
## 组件
|
||||
|
||||
- Web框架： [Chi](http://github.com/go-chi/chi)
|
||||
- ORM: [XORM](https://xorm.io)
|
||||
- UI 框架：
|
||||
- [jQuery](https://jquery.com)
|
||||
- [Fomantic UI](https://fomantic-ui.com)
|
||||
- [Vue3](https://vuejs.org)
|
||||
- 更多组件参见 package.json
|
||||
- 编辑器：
|
||||
- [CodeMirror](https://codemirror.net)
|
||||
- [EasyMDE](https://github.com/Ionaru/easy-markdown-editor)
|
||||
- [Monaco Editor](https://microsoft.github.io/monaco-editor)
|
||||
- 数据库驱动：
|
||||
- [github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)
|
||||
- [github.com/lib/pq](https://github.com/lib/pq)
|
||||
- [github.com/mattn/go-sqlite3](https://github.com/mattn/go-sqlite3)
|
||||
- [github.com/denisenkom/go-mssqldb](https://github.com/denisenkom/go-mssqldb)
|
||||
|
||||
## 集成支持
|
||||
|
||||
请访问 [Awesome Gitea](https://gitea.com/gitea/awesome-gitea/) 获得更多的第三方集成支持
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
title: "安装"
|
||||
slug: "installation"
|
||||
sidebar_position: 10
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "安装"
|
||||
sidebar_position: 10
|
||||
identifier: "installation"
|
||||
---
|
||||
@@ -1,127 +0,0 @@
|
||||
---
|
||||
date: "2019-02-14T11:51:04+08:00"
|
||||
slug: "comparison"
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# 横向对比 Gitea 与其它 Git 托管工具
|
||||
|
||||
这里列出了 Gitea 与其它一些 Git 托管工具之间的异同，以便确认 Gitea 是否能够满足您的需求。
|
||||
|
||||
请注意，此列表中的某些表项可能已经过时，因为我们并没有定期检查其它产品的功能是否有所更改。你可以前往 [Github issue](https://github.com/go-gitea/gitea/issues) 来帮助我们更新过时的内容，感谢！
|
||||
|
||||
_表格中的符号含义:_
|
||||
|
||||
* _✓ - 支持_
|
||||
|
||||
* _⁄ - 部分支持_
|
||||
|
||||
* _✘ - 不支持_
|
||||
|
||||
* _? - 不确定_
|
||||
|
||||
* _⚙️ - 由第三方服务或插件支持_
|
||||
|
||||
#### 主要特性
|
||||
|
||||
| 特性 | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE |
|
||||
| --------------------- | -------------------------------------------------- | ---- | --------- | --------- | --------- | -------------- | ------------ |
|
||||
| 开源免费 | ✓ | ✓ | ✘ | ✓ | ✘ | ✘ | ✓ |
|
||||
| 低资源开销 (RAM/CPU) | ✓ | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ |
|
||||
| 支持多种数据库 | ✓ | ✓ | ✘ | ⁄ | ⁄ | ✓ | ✓ |
|
||||
| 支持多种操作系统 | ✓ | ✓ | ✘ | ✘ | ✘ | ✘ | ✓ |
|
||||
| 升级简便 | ✓ | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ |
|
||||
| 支持 Markdown | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 支持 Orgmode | ✓ | ✘ | ✓ | ✘ | ✘ | ✘ | ? |
|
||||
| 支持 CSV | ✓ | ✘ | ✓ | ✘ | ✘ | ✓ | ? |
|
||||
| 支持第三方渲染工具 | ✓ | ✘ | ✘ | ✘ | ✘ | ✓ | ? |
|
||||
| Git 驱动的静态 pages | [⚙️][gitea-pages-server], [⚙️][gitea-caddy-plugin] | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| Git 驱动的集成化 wiki | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ (cloud only) | ✘ |
|
||||
| 部署令牌 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 仓库写权限令牌 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 内置容器 Registry | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 外部 Git 镜像 | ✓ | ✓ | ✘ | ✘ | ✓ | ✓ | ✓ |
|
||||
| WebAuthn (2FA) | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ? |
|
||||
| 内置 CI/CD | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 子组织：组织内的组织 | [✘](https://github.com/go-gitea/gitea/issues/1872) | ✘ | ✘ | ✓ | ✓ | ✘ | ✓ |
|
||||
|
||||
#### 代码管理
|
||||
|
||||
| 特性 | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE |
|
||||
| ---------------------------------------- | ------------------------------------------------ | ---- | --------- | --------- | --------- | --------- | ------------ |
|
||||
| 仓库主题描述 | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 仓库内代码搜索 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 全局代码搜索 | ✓ | ✘ | ✓ | ✘ | ✓ | ✓ | ✓ |
|
||||
| Git LFS 2.0 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 组织里程碑 | ✘ | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 细粒度用户角色 (例如 Code, Issues, Wiki) | ✓ | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 提交人的身份验证 | ⁄ | ✘ | ? | ✓ | ✓ | ✓ | ✘ |
|
||||
| GPG 签名的提交 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| SSH 签名的提交 | ✓ | ✘ | ✘ | ✘ | ✘ | ? | ? |
|
||||
| 拒绝未用通过验证的提交 | [✓](https://github.com/go-gitea/gitea/pull/9708) | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 仓库活跃度页面 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 分支管理 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 建立新分支 | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 在线代码编辑 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 提交的统计图表 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 模板仓库 | [✓](https://github.com/go-gitea/gitea/pull/8768) | ✘ | ✓ | ✘ | ✓ | ✓ | ✘ |
|
||||
|
||||
#### 工单管理
|
||||
|
||||
| 特性 | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE |
|
||||
| ------------------- | -------------------------------------------------- | --------------------------------------------- | --------- | ----------------------------------------------------------------------- | --------- | -------------- | ------------ |
|
||||
| 工单跟踪 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ (cloud only) | ✘ |
|
||||
| 工单模板 | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 标签 | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 时间跟踪 | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 支持多个负责人 | ✓ | ✘ | ✓ | ✘ | ✓ | ✘ | ✘ |
|
||||
| 关联的工单 | ✘ | ✘ | ⁄ | [✓](https://docs.gitlab.com/ce/user/project/issues/related_issues.html) | ✓ | ✘ | ✘ |
|
||||
| 私密工单 | [✘](https://github.com/go-gitea/gitea/issues/3217) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 评论反馈 | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 锁定讨论 | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 工单批处理 | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 工单看板 | [✓](https://github.com/go-gitea/gitea/pull/8346) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 从工单创建分支 | ✘ | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 工单搜索 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ |
|
||||
| 工单全局搜索 | [✘](https://github.com/go-gitea/gitea/issues/2434) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ |
|
||||
| 工单依赖关系 | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ |
|
||||
| 通过 Email 创建工单 | [✘](https://github.com/go-gitea/gitea/issues/6226) | [✘](https://github.com/gogs/gogs/issues/2602) | ✘ | ✓ | ✓ | ✓ | ✘ |
|
||||
| 服务台 | [✘](https://github.com/go-gitea/gitea/issues/6219) | ✘ | ✘ | [✓](https://gitlab.com/groups/gitlab-org/-/epics/3103) | ✓ | ✘ | ✘ |
|
||||
|
||||
#### Pull/Merge requests
|
||||
|
||||
| 特性 | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE |
|
||||
| ------------------------------------ | -------------------------------------------------- | ---- | --------- | --------------------------------------------------------------------------------- | --------- | ------------------------------------------------------------------------ | ------------ |
|
||||
| Pull/Merge requests | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Squash merging | ✓ | ✘ | ✓ | [✓](https://docs.gitlab.com/ce/user/project/merge_requests/squash_and_merge.html) | ✓ | ✓ | ✓ |
|
||||
| Rebase merging | ✓ | ✓ | ✓ | ✘ | ⁄ | ✘ | ✓ |
|
||||
| 评论 Pull/Merge request 中的某行代码 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 指定 Pull/Merge request 的审核人 | ✓ | ✘ | ⁄ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 解决 Merge 冲突 | [✘](https://github.com/go-gitea/gitea/issues/5158) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ |
|
||||
| 限制某些用户的 push 和 merge 权限 | ✓ | ✘ | ✓ | ⁄ | ✓ | ✓ | ✓ |
|
||||
| 回退某些 commits 或 merge request | [✓](https://github.com/go-gitea/gitea/issues/5158) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ |
|
||||
| Pull/Merge requests 模板 | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 查看 Cherry-picking 的更改 | [✓](https://github.com/go-gitea/gitea/issues/5158) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 下载 Patch | ✓ | ✘ | ✓ | ✓ | ✓ | [/](https://jira.atlassian.com/plugins/servlet/mobile#issue/BCLOUD-8323) | ✘ |
|
||||
|
||||
#### 第三方集成
|
||||
|
||||
| 特性 | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE |
|
||||
| -------------------------- | -------------------------------------------------- | --------------------------------------------- | --------- | --------- | --------- | --------- | ------------ |
|
||||
| 支持 Webhook | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 自定义 Git 钩子 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 集成 AD / LDAP | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| 支持多个 LDAP / AD 服务 | ✓ | ✓ | ✘ | ✘ | ✓ | ✓ | ✓ |
|
||||
| LDAP 用户同步 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| SAML 2.0 service provider | [✘](https://github.com/go-gitea/gitea/issues/5512) | [✘](https://github.com/gogs/gogs/issues/1221) | ✓ | ✓ | ✓ | ✓ | ✘ |
|
||||
| 支持 OpenId 连接 | ✓ | ✘ | ✓ | ✓ | ✓ | ? | ✘ |
|
||||
| 集成 OAuth 2.0（外部授权） | ✓ | ✘ | ⁄ | ✓ | ✓ | ? | ✓ |
|
||||
| 作为 OAuth 2.0 provider | [✓](https://github.com/go-gitea/gitea/pull/5378) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ |
|
||||
| 二次验证 (2FA) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ |
|
||||
| 集成 Mattermost/Slack | ✓ | ✓ | ⁄ | ✓ | ✓ | ⁄ | ✓ |
|
||||
| 集成 Discord | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
|
||||
| 集成 Microsoft Teams | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ |
|
||||
| 显示外部 CI/CD 的状态 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
|
||||
[gitea-caddy-plugin]: https://github.com/42wim/caddy-gitea
|
||||
[gitea-pages-server]: https://codeberg.org/Codeberg/pages-server
|
||||
@@ -1,294 +0,0 @@
|
||||
---
|
||||
date: "2020-01-16"
|
||||
slug: "database-prep"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
- /zh-cn/database-prep
|
||||
---
|
||||
|
||||
# 数据库准备
|
||||
|
||||
在使用 Gitea 前，您需要准备一个数据库。Gitea 支持 PostgreSQL（>=10）、MySQL（>=5.7）、SQLite 和 MSSQL（>=2008R2 SP3）这几种数据库。本页将指导您准备数据库。由于 PostgreSQL 和 MySQL 在生产环境中被广泛使用，因此本文档将仅涵盖这两种数据库。如果您计划使用 SQLite，则可以忽略本章内容。
|
||||
|
||||
数据库实例可以与 Gitea 实例在相同机器上（本地数据库），也可以与 Gitea 实例在不同机器上（远程数据库）。
|
||||
|
||||
注意：以下所有步骤要求您的选择的数据库引擎已安装在您的系统上。对于远程数据库设置，请在数据库实例上安装服务器应用程序，在 Gitea 服务器上安装客户端程序。客户端程序用于测试 Gitea 服务器与数据库之间的连接，而 Gitea 本身使用 Go 提供的数据库驱动程序完成相同的任务。此外，请确保服务器和客户端使用相同的引擎版本，以使某些引擎功能正常工作。出于安全原因，请使用安全密码保护 `root`（MySQL）或 `postgres`（PostgreSQL）数据库超级用户。以下步骤假设您在数据库和 Gitea 服务器上都使用 Linux。
|
||||
|
||||
## MySQL
|
||||
|
||||
1. 对于远程数据库设置，您需要让 MySQL 监听您的 IP 地址。编辑数据库实例上的 `/etc/mysql/my.cnf` 文件中的 `bind-address` 选项为：
|
||||
|
||||
```ini
|
||||
bind-address = 203.0.113.3
|
||||
```
|
||||
|
||||
2. 在数据库实例上，使用 `root` 用户登录到数据库控制台：
|
||||
|
||||
```
|
||||
mysql -u root -p
|
||||
```
|
||||
|
||||
按提示输入密码。
|
||||
|
||||
3. 创建一个将被 Gitea 使用的数据库用户，并使用密码进行身份验证。以下示例中使用了 `'gitea'` 作为密码。请为您的实例使用一个安全密码。
|
||||
|
||||
对于本地数据库：
|
||||
|
||||
```sql
|
||||
SET old_passwords=0;
|
||||
CREATE USER 'gitea' IDENTIFIED BY 'gitea';
|
||||
```
|
||||
|
||||
对于远程数据库：
|
||||
|
||||
```sql
|
||||
SET old_passwords=0;
|
||||
CREATE USER 'gitea'@'192.0.2.10' IDENTIFIED BY 'gitea';
|
||||
```
|
||||
|
||||
其中 `192.0.2.10` 是您的 Gitea 实例的 IP 地址。
|
||||
|
||||
根据需要替换上述用户名和密码。
|
||||
|
||||
4. 使用 UTF-8 字符集和排序规则创建数据库。确保使用 `**utf8mb4**` 字符集，而不是 `utf8`，因为前者支持 _Basic Multilingual Plane_ 之外的所有 Unicode 字符（包括表情符号）。排序规则根据您预期的内容选择。如果不确定，可以使用 `unicode_ci` 或 `general_ci`。
|
||||
|
||||
```sql
|
||||
CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';
|
||||
```
|
||||
|
||||
根据需要替换数据库名称。
|
||||
|
||||
5. 将数据库上的所有权限授予上述创建的数据库用户。
|
||||
|
||||
对于本地数据库：
|
||||
|
||||
```sql
|
||||
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea';
|
||||
FLUSH PRIVILEGES;
|
||||
```
|
||||
|
||||
对于远程数据库：
|
||||
|
||||
```sql
|
||||
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'192.0.2.10';
|
||||
FLUSH PRIVILEGES;
|
||||
```
|
||||
|
||||
6. 通过 exit 退出数据库控制台。
|
||||
|
||||
7. 在您的 Gitea 服务器上，测试与数据库的连接：
|
||||
|
||||
```
|
||||
mysql -u gitea -h 203.0.113.3 -p giteadb
|
||||
```
|
||||
|
||||
其中 `gitea` 是数据库用户名，`giteadb` 是数据库名称，`203.0.113.3` 是数据库实例的 IP 地址。对于本地数据库，省略 -h 选项。
|
||||
|
||||
到此您应该能够连接到数据库了。
|
||||
|
||||
## PostgreSQL
|
||||
|
||||
1. 对于远程数据库设置，通过编辑数据库实例上的 postgresql.conf 文件中的 listen_addresses 将 PostgreSQL 配置为监听您的 IP 地址：
|
||||
|
||||
```ini
|
||||
listen_addresses = 'localhost, 203.0.113.3'
|
||||
```
|
||||
|
||||
2. PostgreSQL 默认使用 `md5` 质询-响应加密方案进行密码身份验证。现在这个方案不再被认为是安全的。改用 SCRAM-SHA-256 方案，通过编辑数据库服务器上的` postgresql.conf` 配置文件：
|
||||
|
||||
```ini
|
||||
password_encryption = scram-sha-256
|
||||
```
|
||||
|
||||
重启 PostgreSQL 以应用该设置。
|
||||
|
||||
3. 在数据库服务器上，以超级用户身份登录到数据库控制台：
|
||||
|
||||
```
|
||||
su -c "psql" - postgres
|
||||
```
|
||||
|
||||
4. 创建具有登录权限和密码的数据库用户（在 PostgreSQL 术语中称为角色）。请使用安全的、强密码，而不是下面的 `'gitea'`：
|
||||
|
||||
```sql
|
||||
CREATE ROLE gitea WITH LOGIN PASSWORD 'gitea';
|
||||
```
|
||||
|
||||
根据需要替换用户名和密码。
|
||||
|
||||
5. 使用 UTF-8 字符集创建数据库，并由之前创建的数据库用户拥有。可以根据预期内容使用任何 `libc` 排序规则，使用 `LC_COLLATE` 和 `LC_CTYPE` 参数指定：
|
||||
|
||||
```sql
|
||||
CREATE DATABASE giteadb WITH OWNER gitea TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
|
||||
```
|
||||
|
||||
根据需要替换数据库名称。
|
||||
|
||||
6. 通过将以下身份验证规则添加到 `pg_hba.conf`，允许数据库用户访问上面创建的数据库。
|
||||
|
||||
对于本地数据库：
|
||||
|
||||
```ini
|
||||
local giteadb gitea scram-sha-256
|
||||
```
|
||||
|
||||
对于远程数据库：
|
||||
|
||||
```ini
|
||||
host giteadb gitea 192.0.2.10/32 scram-sha-256
|
||||
```
|
||||
|
||||
根据您自己的数据库名称、用户和 Gitea 实例的 IP 地址进行替换。
|
||||
|
||||
注意：`pg_hba.conf` 上的规则按顺序评估，也就是第一个匹配的规则将用于身份验证。您的 PostgreSQL 安装可能附带了适用于所有用户和数据库的通用身份验证规则。如果是这种情况，您可能需要将此处提供的规则放置在此类通用规则之上。
|
||||
|
||||
重启 PostgreSQL 以应用新的身份验证规则。
|
||||
|
||||
7. 在您的 Gitea 服务器上，测试与数据库的连接。
|
||||
|
||||
对于本地数据库：
|
||||
|
||||
```
|
||||
psql -U gitea -d giteadb
|
||||
```
|
||||
|
||||
对于远程数据库：
|
||||
|
||||
```
|
||||
psql "postgres://gitea@203.0.113.3/giteadb"
|
||||
```
|
||||
|
||||
其中 `gitea` 是数据库用户，`giteadb` 是数据库名称，`203.0.113.3` 是您的数据库实例的 IP 地址。
|
||||
|
||||
您应该会被提示输入数据库用户的密码，并连接到数据库。
|
||||
|
||||
## 使用 TLS 进行数据库连接
|
||||
|
||||
如果 Gitea 和您的数据库实例之间的通信是通过私有网络进行的，或者如果 Gitea 和数据库运行在同一台服务器上，那么可以省略本节，因为 Gitea 和数据库实例之间的安全性不会受到严重威胁。但是，如果数据库实例位于公共网络上，请使用 TLS 对数据库连接进行加密，以防止第三方拦截流量数据。
|
||||
|
||||
### 先决条件
|
||||
|
||||
- 您需要两个有效的 TLS 证书，一个用于数据库实例（数据库服务器），一个用于 Gitea 实例（数据库客户端）。两个证书都必须由受信任的 CA 签名。
|
||||
- 数据库证书必须在 `X509v3 Extended Key Usage` 扩展属性中包含 `TLS Web Server Authentication`，而客户端证书则需要在相应的属性中包含 `TLS Web Client Authentication`。
|
||||
- 在数据库服务器证书中，`Subject Alternative Name` 或 `Common Name` 条目之一必须是数据库实例的完全限定域名（FQDN）（例如 `db.example.com`）。在数据库客户端证书中，上述提到的条目之一必须包含 Gitea 将用于连接的数据库用户名。
|
||||
- 您需要将 Gitea 和数据库服务器的域名映射到它们各自的 IP 地址。可以为它们设置 DNS 记录，也可以在每个系统上的 `/etc/hosts`（Windows 中的 `%WINDIR%\System32\drivers\etc\hosts`）中添加本地映射。这样可以通过域名而不是 IP 地址进行数据库连接。有关详细信息，请参阅您系统的文档。
|
||||
|
||||
### PostgreSQL
|
||||
|
||||
Gitea 使用的 PostgreSQL 驱动程序支持双向 TLS。在双向 TLS 中，数据库客户端和服务器通过将各自的证书发送给对方进行验证来相互认证。换句话说，服务器验证客户端证书，客户端验证服务器证书。
|
||||
|
||||
1. 在数据库实例所在的服务器上，放置以下凭据：
|
||||
|
||||
- `/path/to/postgresql.crt`: 数据库实例证书
|
||||
- `/path/to/postgresql.key`: 数据库实例私钥
|
||||
- `/path/to/root.crt`: 用于验证客户端证书的 CA 证书链
|
||||
|
||||
2. 在 `postgresql.conf` 中添加以下选项：
|
||||
|
||||
```ini
|
||||
ssl = on
|
||||
ssl_ca_file = '/path/to/root.crt'
|
||||
ssl_cert_file = '/path/to/postgresql.crt'
|
||||
ssl_key_file = '/path/to/postgresql.key'
|
||||
ssl_min_protocol_version = 'TLSv1.2'
|
||||
```
|
||||
|
||||
3. 根据 PostgreSQL 的要求，调整凭据的所有权和权限：
|
||||
|
||||
```
|
||||
chown postgres:postgres /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
|
||||
chmod 0600 /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
|
||||
```
|
||||
|
||||
4. 编辑 `pg_hba.conf` 规则，仅允许 Gitea 数据库用户通过 SSL 连接，并要求客户端证书验证。
|
||||
|
||||
对于 PostgreSQL 12：
|
||||
|
||||
```ini
|
||||
hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=verify-full
|
||||
```
|
||||
|
||||
对于 PostgreSQL 11 及更早版本：
|
||||
|
||||
```ini
|
||||
hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=1
|
||||
```
|
||||
|
||||
根据需要替换数据库名称、用户和 Gitea 实例的 IP 地址。
|
||||
|
||||
5. 重新启动 PostgreSQL 以应用上述配置。
|
||||
|
||||
6. 在运行 Gitea 实例的服务器上，将以下凭据放置在运行 Gitea 的用户的主目录下（例如 `git`）：
|
||||
|
||||
- `~/.postgresql/postgresql.crt`: 数据库客户端证书
|
||||
- `~/.postgresql/postgresql.key`: 数据库客户端私钥
|
||||
- `~/.postgresql/root.crt`: 用于验证服务器证书的 CA 证书链
|
||||
|
||||
注意：上述文件名在 PostgreSQL 中是硬编码的，无法更改。
|
||||
|
||||
7. 根据需要调整凭据、所有权和权限：
|
||||
|
||||
```
|
||||
chown git:git ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
|
||||
chown 0600 ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
|
||||
```
|
||||
|
||||
8. 测试与数据库的连接：
|
||||
|
||||
```
|
||||
psql "postgres://gitea@example.db/giteadb?sslmode=verify-full"
|
||||
```
|
||||
|
||||
您将被提示输入数据库用户的密码，然后连接到数据库。
|
||||
|
||||
### MySQL
|
||||
|
||||
虽然 Gitea 使用的 MySQL 驱动程序也支持双向 TLS，但目前 Gitea 仅支持单向 TLS。有关详细信息，请参见工单＃10828。
|
||||
|
||||
在单向 TLS 中，数据库客户端在连接握手期间验证服务器发送的证书，而服务器则假定连接的客户端是合法的，因为不进行客户端证书验证。
|
||||
|
||||
1. 在数据库实例上放置以下凭据：
|
||||
|
||||
- `/path/to/mysql.crt`: 数据库实例证书
|
||||
- `/path/to/mysql.key`: 数据库实例密钥
|
||||
- `/path/to/ca.crt`: CA 证书链。在单向 TLS 中不使用此文件，但用于验证双向 TLS 中的客户端证书。
|
||||
|
||||
2. 将以下选项添加到 `my.cnf`：
|
||||
|
||||
```ini
|
||||
[mysqld]
|
||||
ssl-ca = /path/to/ca.crt
|
||||
ssl-cert = /path/to/mysql.crt
|
||||
ssl-key = /path/to/mysql.key
|
||||
tls-version = TLSv1.2,TLSv1.3
|
||||
```
|
||||
|
||||
3. 调整凭据的所有权和权限：
|
||||
|
||||
```
|
||||
chown mysql:mysql /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
|
||||
chmod 0600 /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
|
||||
```
|
||||
|
||||
4. 重新启动 MySQL 以应用设置。
|
||||
|
||||
5. Gitea 的数据库用户可能已经创建过，但只会对运行 Gitea 的服务器的 IP 地址进行身份验证。要对其域名进行身份验证，请重新创建用户，并设置其需要通过 TLS 连接到数据库：
|
||||
|
||||
```sql
|
||||
DROP USER 'gitea'@'192.0.2.10';
|
||||
CREATE USER 'gitea'@'example.gitea' IDENTIFIED BY 'gitea' REQUIRE SSL;
|
||||
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'example.gitea';
|
||||
FLUSH PRIVILEGES;
|
||||
```
|
||||
|
||||
根据需要替换数据库用户名、密码和 Gitea 实例域名。
|
||||
|
||||
6. 确保用于验证数据库服务器证书的 CA 证书链位于数据库和 Gitea 服务器的系统证书存储中。请参考系统文档中有关将 CA 证书添加到证书存储的说明。
|
||||
|
||||
7. 在运行 Gitea 的服务器上，测试与数据库的连接：
|
||||
|
||||
```
|
||||
mysql -u gitea -h example.db -p --ssl
|
||||
```
|
||||
|
||||
至此应该成功连接到数据库了。
|
||||
@@ -1,151 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "install-from-binary"
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
# 使用二进制文件安装
|
||||
|
||||
所有打包的二进制程序均包含 SQLite，MySQL 和 PostgreSQL 的数据库连接支持，同时网站的静态资源均已嵌入到可执行程序中，这一点和曾经的 Gogs 有所不同。
|
||||
|
||||
## 下载
|
||||
|
||||
你可以从 [下载页面](https://dl.gitea.com/gitea/) 选择对应平台的二进制文件。
|
||||
|
||||
### 选择架构
|
||||
|
||||
- **对于 Linux**，`linux-amd64` 适用于 64-bit 的 Intel/AMD 平台。更多架构包含 `arm64` (Raspberry PI 4)，`386` (32-bit)，`arm-5` 以及 `arm-6`。
|
||||
|
||||
- **对于 Windows**，`windows-4.0-amd64` 适用于 64-bit 的 Intel/AMD 平台，`386` 适用于 32-bit 的 Intel/AMD 平台。（提示：`gogit-windows` 版本内建了 gogit 可能缓解在旧的 Windows 平台上 Go 程序调用 git 子程序时面临的 [性能问题](https://github.com/go-gitea/gitea/pull/15482)）
|
||||
|
||||
- **对于 macOS**，`darwin-arm64` 适用于 Apple Silicon 架构，`darwin-amd64` 适用于 Intel 架构.
|
||||
|
||||
- **对于 FreeBSD**，`freebsd12-amd64` 适用于 64-bit 的 Intel/AMD 平台。
|
||||
|
||||
### 使用 wget 下载
|
||||
|
||||
使用以下命令下载适用于 64-bit Linux 平台的二进制文件。
|
||||
|
||||
```sh
|
||||
wget -O gitea https://dl.gitea.com/gitea/@version@/gitea-@version@-linux-amd64
|
||||
chmod +x gitea
|
||||
```
|
||||
|
||||
## 验证 GPG 签名
|
||||
|
||||
Gitea 对打包的二进制文件使用 [GPG密钥](https://keys.openpgp.org/search?q=teabot%40gitea.io) 签名以防止篡改。
|
||||
请根据对应文件名 `.asc` 中包含的校验码检验文件的一致性。
|
||||
|
||||
```sh
|
||||
gpg --keyserver hkps://keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
|
||||
gpg --verify gitea-@version@-linux-amd64.asc gitea-@version@-linux-amd64
|
||||
```
|
||||
|
||||
校验正确时的信息为 `Good signature from "Teabot <teabot@gitea.io>"`。
|
||||
校验错误时的信息为 `This key is not certified with a trusted signature!`。
|
||||
|
||||
## 服务器设置
|
||||
|
||||
**提示：** `GITEA_WORK_DIR` 表示 Gitea 工作的路径。以下路径可以通过 [环境变量](../administration/environment-variables.md) 初始化。
|
||||
|
||||
### 准备环境
|
||||
|
||||
检查是否安装 Git。要求 Git 版本 >= 2.0。
|
||||
|
||||
```sh
|
||||
git --version
|
||||
```
|
||||
|
||||
创建用户（推荐使用名称 `git`）
|
||||
|
||||
```sh
|
||||
adduser \
|
||||
--system \
|
||||
--shell /bin/bash \
|
||||
--gecos 'Git Version Control' \
|
||||
--group \
|
||||
--disabled-password \
|
||||
--home /home/git \
|
||||
git
|
||||
```
|
||||
|
||||
### 创建工作路径
|
||||
|
||||
```sh
|
||||
mkdir -p /var/lib/gitea/{custom,data,log}
|
||||
chown -R git:git /var/lib/gitea/
|
||||
chmod -R 750 /var/lib/gitea/
|
||||
mkdir /etc/gitea
|
||||
chown root:git /etc/gitea
|
||||
chmod 770 /etc/gitea
|
||||
```
|
||||
|
||||
> **注意：** 为了让 Web 安装程序可以写入配置文件，我们临时为 `/etc/gitea` 路径授予了组外用户 `git` 写入权限。建议在安装结束后将配置文件的权限设置为只读。
|
||||
>
|
||||
> ```sh
|
||||
> chmod 750 /etc/gitea
|
||||
> chmod 640 /etc/gitea/app.ini
|
||||
> ```
|
||||
|
||||
如果您不希望通过 Web 安装程序创建配置文件，可以将配置文件设置为仅供 Gitea 用户只读（owner/group `root:git`, mode `0640`）并手工创建配置文件：
|
||||
|
||||
- 设置 `INSTALL_LOCK=true` 关闭安装界面
|
||||
- 手动配置数据库连接参数
|
||||
- 使用 `gitea generate secret` 创建 `SECRET_KEY` 和 `INTERNAL_TOKEN`
|
||||
- 提供所有必要的密钥
|
||||
|
||||
详情参考 [命令行文档](../administration/command-line.md) 中有关 `gitea generate secret` 的内容。
|
||||
|
||||
### 配置 Gitea 工作路径
|
||||
|
||||
**提示：** 如果使用 Systemd 管理 Gitea 的 Linux 服务，你可以采用 `WorkingDirectory` 参数来配置工作路径。 否则，使用环境变量 `GITEA_WORK_DIR` 来明确指出程序工作和数据存放路径。
|
||||
|
||||
```sh
|
||||
export GITEA_WORK_DIR=/var/lib/gitea/
|
||||
```
|
||||
|
||||
### 复制二进制文件到全局位置
|
||||
|
||||
```sh
|
||||
cp gitea /usr/local/bin/gitea
|
||||
```
|
||||
|
||||
## 运行 Gitea
|
||||
|
||||
完成以上步骤后，可以通过两种方式运行 Gitea：
|
||||
|
||||
### 1. 创建服务自动启动 Gitea（推荐）
|
||||
|
||||
学习创建 [Linux 服务](installation/run-as-service-in-ubuntu.md)
|
||||
|
||||
### 2. 通过命令行终端运行
|
||||
|
||||
```sh
|
||||
GITEA_WORK_DIR=/var/lib/gitea/ /usr/local/bin/gitea web -c /etc/gitea/app.ini
|
||||
```
|
||||
|
||||
## 升级到最新版本
|
||||
|
||||
您可以通过停止程序，替换 `/usr/local/bin/gitea` 并重启来更新到新版本。直接替换可执行程序时不要更改或使用新的文件名称，以避免数据出错。
|
||||
|
||||
建议您在更新之前进行[备份](../administration/backup-and-restore.md)。
|
||||
|
||||
### 1. 使用 systemd 重新启动 Gitea（推荐）
|
||||
|
||||
我们建议使用 systemd 作为服务管理器，使用 `systemctl restart gitea` 安全地重启程序。
|
||||
|
||||
### 2. 非 systemd 重启方法
|
||||
|
||||
使用 SIGHUP 信号关闭程序：查询到 Gitea 程序的 PID，使用 `kill -1 $GITEA_PID`，或者 `killall -1 gitea`。
|
||||
|
||||
更优雅的停止指令可能包括 `kill $GITEA_PID` 或者 `killall gitea`。
|
||||
|
||||
**提示：** 我们不建议使用 SIGKILL 信号（`-9`），这会强制停止 Gitea 程序，但不会正确关闭队列、索引器等任务。
|
||||
|
||||
请参阅下面的疑难解答说明，以在Gitea版本更新后修复损坏的仓库。
|
||||
|
||||
## 排查故障
|
||||
|
||||
> 更多经验总结，请参考英文版 [Troubleshooting](/en-us/install-from-binary.md#troubleshooting)
|
||||
|
||||
如果从本页中没有找到你需要的内容，请访问 [帮助页面](help/seek-help.md)
|
||||
@@ -1,91 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "install-from-package"
|
||||
sidebar_position: 20
|
||||
---
|
||||
|
||||
# 使用包管理器安装
|
||||
|
||||
## Alpine Linux
|
||||
|
||||
Gitea 已经包含在 Alpine Linux 的[社区存储库](https://pkgs.alpinelinux.org/packages?name=gitea&branch=edge)中，版本与 Gitea 官方保持同步。
|
||||
|
||||
```sh
|
||||
apk add gitea
|
||||
```
|
||||
|
||||
## Arch Linux
|
||||
|
||||
Gitea 已经在滚动发布发行版的官方[社区存储库](https://www.archlinux.org/packages/community/x86_64/gitea/)中，版本与 Gitea 官方保持同步。
|
||||
|
||||
```sh
|
||||
pacman -S gitea
|
||||
```
|
||||
|
||||
## Arch Linux ARM
|
||||
|
||||
官方支持 [aarch64](https://archlinuxarm.org/packages/aarch64/gitea)， [armv7h](https://archlinuxarm.org/packages/armv7h/gitea) 和 [armv6h](https://archlinuxarm.org/packages/armv6h/gitea) 架构。
|
||||
|
||||
```sh
|
||||
pacman -S gitea
|
||||
```
|
||||
|
||||
## Canonical Snap
|
||||
|
||||
目前 Gitea 已在 Snap Store 中发布，名称为 [gitea](https://snapcraft.io/gitea)。
|
||||
|
||||
```sh
|
||||
snap install gitea
|
||||
```
|
||||
|
||||
## SUSE/openSUSE
|
||||
|
||||
OpenSUSE 构建服务为 [openSUSE 和 SLE](https://software.opensuse.org/download/package?package=gitea&project=devel%3Atools%3Ascm)
|
||||
提供包，你可以在开发软件配置管理存储库中找到它们。
|
||||
|
||||
## Windows
|
||||
|
||||
目前你可以通过 [Chocolatey](https://chocolatey.org/) 来安装 [Gitea](https://chocolatey.org/packages/gitea)。
|
||||
|
||||
```sh
|
||||
choco install gitea
|
||||
```
|
||||
|
||||
你也可以 [从二进制安装](installation/from-binary.md) 。
|
||||
|
||||
## macOS
|
||||
|
||||
macOS 平台下当前我们仅支持通过 `brew` 来安装。如果你没有安装 [Homebrew](http://brew.sh/)，你也可以查看 [从二进制安装](installation/from-binary.md)。在你安装了 `brew` 之后， 你可以执行以下命令：
|
||||
|
||||
```
|
||||
brew tap gitea/tap https://gitea.com/gitea/homebrew-gitea
|
||||
brew install gitea
|
||||
```
|
||||
|
||||
## FreeBSD
|
||||
|
||||
可以使用 Gitea 的 FreeBSD port `www/gitea`。 请安装预构建的二进制包：
|
||||
|
||||
```
|
||||
pkg install gitea
|
||||
```
|
||||
|
||||
对于最新版本，或使用自定义选项构建 port，请
|
||||
[从 port 安装](https://www.freebsd.org/doc/handbook/ports-using.html)：
|
||||
|
||||
```
|
||||
su -
|
||||
cd /usr/ports/www/gitea
|
||||
make install clean
|
||||
```
|
||||
|
||||
该 port 使用标准的 FreeBSD 文件系统布局：配置文件在 `/usr/local/etc/gitea` 目录中，
|
||||
模板、选项、插件和主题在 `/usr/local/share/gitea` 目录中，启动脚本在 `/usr/local/etc/rc.d/gitea` 目录中。
|
||||
|
||||
要使 Gitea 作为服务运行，请运行 `sysrc gitea_enable=YES` 并使用 `service gitea start` 命令启动它。
|
||||
|
||||
## 第三方
|
||||
|
||||
如果这里没有找到你喜欢的包管理器，可以使用 Gitea 第三方软件包。这里有一个完整的列表： [awesome-gitea](https://gitea.com/gitea/awesome-gitea/src/branch/master/README.md#user-content-packages)。
|
||||
|
||||
如果你知道其他 Gitea 第三方软件包，请发送 PR 来添加它。
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "install-from-source"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
# 使用源代码安装
|
||||
|
||||
首先你需要安装 Golang，关于 Golang 的安装，参见[官方文档](https://golang.google.cn/doc/install)。
|
||||
|
||||
其次你需要[安装 Node.js](https://nodejs.org/zh-cn/download/)，Node.js 和 npm 将用于构建 Gitea 前端。
|
||||
|
||||
## 下载
|
||||
|
||||
你需要获取 Gitea 的源码，最方便的方式是使用 `git` 命令。执行以下命令：
|
||||
|
||||
```
|
||||
git clone https://github.com/go-gitea/gitea
|
||||
cd gitea
|
||||
```
|
||||
|
||||
然后你可以选择编译和安装的版本，当前你有多个选择。如果你想编译 `main` 版本，你可以直接跳到 [编译](#编译) 部分，这是我们的开发分支，虽然也很稳定但不建议您在正式产品中使用。
|
||||
|
||||
如果你想编译最新稳定分支，你可以执行以下命令签出源码：
|
||||
|
||||
```bash
|
||||
git branch -a
|
||||
git checkout @sourceBranch@
|
||||
```
|
||||
|
||||
最后，你也可以直接使用标签版本如 `@sourceVersion@`。你可以执行以下命令列出可用的版本并选择某个版本签出：
|
||||
|
||||
```bash
|
||||
git tag -l
|
||||
git checkout @sourceVersion@
|
||||
```
|
||||
|
||||
## 编译
|
||||
|
||||
要从源代码进行编译，以下依赖程序必须事先安装好：
|
||||
|
||||
- `go` @minGoVersion@ 或以上版本, 详见[这里](https://golang.google.cn/doc/install)
|
||||
- `node` @minNodeVersion@ 或以上版本，并且安装 `npm`, 详见[这里](https://nodejs.org/zh-cn/download/)
|
||||
- `make`, 详见[这里](development/hacking-on-gitea.md)
|
||||
|
||||
各种可用的 [make 任务](https://github.com/go-gitea/gitea/blob/main/Makefile)
|
||||
可以用来使编译过程更方便。
|
||||
|
||||
按照您的编译需求，以下 tags 可以使用：
|
||||
|
||||
- `bindata`: 这个编译选项将会把运行 Gitea 所需的所有外部资源都打包到可执行文件中，这样部署将非常简单因为除了可执行程序将不再需要任何其他文件。
|
||||
- `sqlite sqlite_unlock_notify`: 这个编译选项将启用 SQLite3 数据库的支持，建议只在少数人使用时使用这个模式。
|
||||
- `pam`: 这个编译选项将会启用 PAM (Linux Pluggable Authentication Modules) 认证，如果你使用这一认证模式的话需要开启这个选项。
|
||||
|
||||
使用 bindata 可以打包资源文件到二进制可以使开发和测试更容易，你可以根据自己的需求决定是否打包资源文件。
|
||||
要包含资源文件，请使用 `bindata` tag：
|
||||
|
||||
```bash
|
||||
TAGS="bindata" make build
|
||||
```
|
||||
|
||||
默认的发布版本中的编译选项是： `TAGS="bindata sqlite sqlite_unlock_notify"`。以下为推荐的编译方式：
|
||||
|
||||
```bash
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
```
|
||||
|
||||
## 测试
|
||||
|
||||
在执行了以上步骤之后，你将会获得 `gitea` 的二进制文件，在你复制到部署的机器之前可以先测试一下。在命令行执行完后，你可以 `Ctrl + C` 关掉程序。
|
||||
|
||||
```bash
|
||||
./gitea web
|
||||
```
|
||||
|
||||
## 交叉编译
|
||||
|
||||
Go 编译器支持交叉编译到不同的目标架构。有关 Go 支持的目标架构列表，请参见 [Optional environment variables](https://go.dev/doc/install/source#environment)。
|
||||
|
||||
交叉构建适用于 Linux ARM64 的 Gitea：
|
||||
|
||||
```bash
|
||||
GOOS=linux GOARCH=arm64 make build
|
||||
```
|
||||
|
||||
交叉构建适用于 Linux ARM64 的 Gitea，并且带上 Gitea 发行版采用的编译选项：
|
||||
|
||||
```bash
|
||||
CC=aarch64-unknown-linux-gnu-gcc GOOS=linux GOARCH=arm64 TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
```
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "install-on-cloud-provider"
|
||||
sidebar_position: 90
|
||||
aliases:
|
||||
- /zh-cn/install-on-cloud-provider
|
||||
---
|
||||
|
||||
# 在云服务器上安装 Gitea
|
||||
|
||||
## Cloudron
|
||||
|
||||
Gitea 可以在 [Cloudron](https://cloudron.io) 上进行一键安装。
|
||||
Cloudron 使得在您的服务器上运行 Gitea，并保持其更新和安全变得简单。
|
||||
|
||||
[](https://cloudron.io/button.html?app=io.gitea.cloudronapp)
|
||||
|
||||
Gitea 软件包的维护地址在[这里](https://git.cloudron.io/cloudron/gitea-app).
|
||||
|
||||
这里有一个[demo 实例](https://my.demo.cloudron.io) (用户名: cloudron 密码: cloudron) 您可以在其中尝试运行 Gitea。
|
||||
|
||||
## Linode
|
||||
|
||||
[Linode](https://www.linode.com/) 将 Gitea 作为其市场中的一个应用程序.
|
||||
|
||||
要将 Gitea 部署到 Linode, 请参考 [Linode Marketplace](https://www.linode.com/marketplace/apps/linode/gitea/).
|
||||
|
||||
## alwaysdata
|
||||
|
||||
[alwaysdata](https://www.alwaysdata.com/) 将 Gitea 作为其市场中的一个 droplet.
|
||||
|
||||
要将 Gitea 部署到 alwaysdata, 请参考 [alwaysdata Marketplace](https://www.alwaysdata.com/en/marketplace/gitea/).
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
date: "2020-03-19T19:27:00+02:00"
|
||||
slug: "install-on-kubernetes"
|
||||
sidebar_position: 80
|
||||
---
|
||||
|
||||
# 在 Kubernetes 中安装 Gitea
|
||||
|
||||
Gitea 已经提供了便于在 Kubernetes 云原生环境中安装所需的 Helm Chart
|
||||
|
||||
默认安装指令为：
|
||||
|
||||
```bash
|
||||
helm repo add gitea https://dl.gitea.io/charts
|
||||
helm repo update
|
||||
helm install gitea gitea/gitea
|
||||
```
|
||||
|
||||
如果采用默认安装指令，Helm 会部署单实例的 Gitea, PostgreSQL, Memcached。若您想实现自定义安装（包括配置 Gitea 集群、NGINX Ingress、MySQL、MariaDB、持久存储等），请前往阅读：[Gitea Helm Chart](https://gitea.com/gitea/helm-chart/)
|
||||
|
||||
您也可以通过 `helm show` 命令导出 `README.md` 和配置文件 `values.yaml` 进行学习和编辑，例如：
|
||||
|
||||
```bash
|
||||
helm show values gitea/gitea > values.yaml
|
||||
helm show readme gitea/gitea > README.md
|
||||
|
||||
# 使用自定义的配置文件 values.yaml
|
||||
helm install gitea -f values.yaml gitea/gitea
|
||||
```
|
||||
|
||||
## 运行状况检查接口
|
||||
|
||||
Gitea 附带了一个运行状况检查接口 `/api/healthz`，你可以像这样在 Kubernetes 中配置它：
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /api/healthz
|
||||
port: http
|
||||
initialDelaySeconds: 200
|
||||
timeoutSeconds: 5
|
||||
periodSeconds: 10
|
||||
successThreshold: 1
|
||||
failureThreshold: 10
|
||||
```
|
||||
|
||||
成功的运行状况检查响应代码为 HTTP `200`，下面是示例：
|
||||
|
||||
```json
|
||||
HTTP/1.1 200 OK
|
||||
|
||||
{
|
||||
"status": "pass",
|
||||
"description": "Gitea: Git with a cup of tea",
|
||||
"checks": {
|
||||
"cache:ping": [
|
||||
{
|
||||
"status": "pass",
|
||||
"time": "2022-02-19T09:16:08Z"
|
||||
}
|
||||
],
|
||||
"database:ping": [
|
||||
{
|
||||
"status": "pass",
|
||||
"time": "2022-02-19T09:16:08Z"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
有关更多信息，请参考 Kubernetes 文档 [配置存活、就绪和启动探测器](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
date: "2017-07-21T12:00:00+02:00"
|
||||
slug: "linux-service"
|
||||
sidebar_position: 40
|
||||
---
|
||||
|
||||
# 在 Linux 中以 service 方式运行
|
||||
|
||||
## 在 Ubuntu 16.04 LTS 中以 service 方式运行
|
||||
|
||||
### systemd 方式
|
||||
|
||||
在 terminal 中执行以下命令：
|
||||
|
||||
```
|
||||
sudo vim /etc/systemd/system/gitea.service
|
||||
```
|
||||
|
||||
接着拷贝示例代码 [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) 并取消对任何需要运行在主机上的服务部分的注释，譬如 MySQL。
|
||||
|
||||
修改 user，home 目录以及其他必须的初始化参数，如果使用自定义端口，则需修改 PORT 参数，反之如果使用默认端口则需删除 -p 标记。
|
||||
|
||||
激活 gitea 并将它作为系统自启动服务：
|
||||
|
||||
```
|
||||
sudo systemctl enable gitea
|
||||
sudo systemctl start gitea
|
||||
```
|
||||
|
||||
### 使用 supervisor
|
||||
|
||||
在 terminal 中执行以下命令安装 supervisor：
|
||||
|
||||
```
|
||||
sudo apt install supervisor
|
||||
```
|
||||
|
||||
为 supervisor 配置日志路径：
|
||||
|
||||
```
|
||||
# assuming gitea is installed in /home/git/gitea/
|
||||
mkdir /home/git/gitea/log/supervisor
|
||||
```
|
||||
|
||||
在文件编辑器中打开 supervisor 的配置文件：
|
||||
|
||||
```
|
||||
sudo vim /etc/supervisor/supervisord.conf
|
||||
```
|
||||
|
||||
增加如下示例配置
|
||||
[supervisord config](https://github.com/go-gitea/gitea/blob/main/contrib/supervisor/gitea)。
|
||||
|
||||
将 user(git) 和 home(/home/git) 设置为与上文部署中匹配的值。如果使用自定义端口，则需修改 PORT 参数，反之如果使用默认端口则需删除 -p 标记。
|
||||
|
||||
最后激活 supervisor 并将它作为系统自启动服务：
|
||||
|
||||
```
|
||||
sudo systemctl enable supervisor
|
||||
sudo systemctl start supervisor
|
||||
```
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
date: "2021-09-02T16:00:00+08:00"
|
||||
slug: "upgrade-from-gitea"
|
||||
sidebar_position: 100
|
||||
---
|
||||
|
||||
# 从旧版 Gitea 升级
|
||||
|
||||
想要升级 Gitea，只需要下载新版，停止运行旧版，进行数据备份，然后运行新版就好。
|
||||
每次 Gitea 实例启动时，它都会检查是否要进行数据库迁移。
|
||||
如果需要进行数据库迁移，Gitea 会花一些时间完成升级然后继续服务。
|
||||
|
||||
## 为重大变更检查更新日志
|
||||
|
||||
为了让 Gitea 变得更好，进行重大变更是不可避免的，尤其是一些里程碑更新的发布。
|
||||
在更新前，请 [在 Gitea 博客上阅读更新日志](https://blog.gitea.io/)
|
||||
并检查重大变更是否会影响你的 Gitea 实例。
|
||||
|
||||
## 降级前的备份
|
||||
|
||||
Gitea 会保留首二位版本号相同的版本的兼容性 (`a.b.x` -> `a.b.y`)，
|
||||
这些版本拥有相同的数据库结构，可以自由升级或降级。
|
||||
其他情况 (`a.b.?` -> `a.c.?`)下，
|
||||
新版 Gitea 可能将会将数据库升级到与旧版数据库不同的结构。
|
||||
|
||||
举个例子:
|
||||
|
||||
| 当前 | 目标 | 结果 |
|
||||
| ----- | ----- | ---------------------------------------------------------------------------------------------------- |
|
||||
| 1.4.0 | 1.4.1 | ✅ |
|
||||
| 1.4.1 | 1.4.0 | ⚠️ 不建议，后果自负！尽管数据库结构可能不会变更，让它可以正常工作。我们强烈建议降级前进行完全的备份。 |
|
||||
| 1.4.x | 1.5.y | ✅ 数据库会被自动升级。你可以直接从 1.4.x 升级到最新的 1.5.y。 |
|
||||
| 1.5.y | 1.4.x | ❌ 数据库已被升级且不可被旧版 Gitea 利用，使用备份来进行降级。 |
|
||||
|
||||
**因为你不能基于升级后的数据库运行旧版 Gitea，所以你应该在数据库升级前完成数据备份。**
|
||||
|
||||
如果你在生产环境下使用 Gitea，你应该在升级前做好备份，哪怕只是小版本的补丁更新。
|
||||
|
||||
备份步骤:
|
||||
|
||||
* 停止 Gitea 实例
|
||||
* 备份数据库
|
||||
* 备份 Gitea 配置文件
|
||||
* 备份 Gitea 在 `APP_DATA_PATH` 中的数据文件
|
||||
* 备份 Gitea 的外部存储 (例如: S3/MinIO 或被使用的其他存储)
|
||||
|
||||
如果你在使用云服务或拥有快照功能的文件系统，
|
||||
最好对 Gitea 的数据盘及相关资料存储进行一次快照。
|
||||
|
||||
## 从 Docker 升级
|
||||
|
||||
* `docker pull` 拉取 Gitea 的最新发布版。
|
||||
* 停止运行中的实例，备份数据。
|
||||
* 使用 `docker` 或 `docker-compose` 启动更新的 Gitea Docker 容器.
|
||||
|
||||
## 从包升级
|
||||
|
||||
* 停止运行中的实例，备份数据。
|
||||
* 使用你的包管理器更新 Gitea 到最新版本。
|
||||
* 启动 Gitea 实例。
|
||||
|
||||
## 从二进制升级
|
||||
|
||||
* 下载最新的 Gitea 二进制文件到临时文件夹中。
|
||||
* 停止运行中的实例，备份数据。
|
||||
* 将旧的 Gitea 二进制文件覆盖成新的。
|
||||
* 启动 Gitea 实例。
|
||||
|
||||
在 Linux 系统上自动执行以上步骤的脚本可在 [Gitea 的 source tree 中找到 `contrib/upgrade.sh` 来获取](https://github.com/go-gitea/gitea/blob/main/contrib/upgrade.sh).
|
||||
|
||||
## 小心你的自定义模板
|
||||
|
||||
Gitea 的模板结构与变量可能会随着各个版本的发布发生变化，如果你使用了自定义模板，
|
||||
你得注意你的模板与你使用的 Gitea 版本的兼容性。
|
||||
|
||||
如果自定义模板与 Gitea 版本不兼容，你可能会得到：
|
||||
`50x` 服务器错误，页面元素丢失或故障，莫名其妙的页面布局，等等…
|
||||
移除或更新不兼容的模板，Gitea Web 才可以正常工作。
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "upgrade-from-gogs"
|
||||
sidebar_position: 101
|
||||
---
|
||||
|
||||
# 从 Gogs 升级
|
||||
|
||||
如果你正在运行Gogs 0.9.146以下版本，你可以平滑的升级到Gitea。该升级需要如下的步骤：
|
||||
|
||||
* 停止 Gogs 的运行
|
||||
* 拷贝 Gogs 的配置文件 `custom/conf/app.ini` 到 Gitea 的相应位置。
|
||||
* 拷贝 Gitea 的 `options/` 到 Home 目录下。
|
||||
* 如果你还有更多的自定义内容，比如templates和localization文件，你需要手工合并你的修改到 Gitea 的 Options 下对应目录。
|
||||
* 拷贝 Gogs 的数据目录 `data/` 到 Gitea 相应位置。这个目录包含附件和头像文件。
|
||||
* 运行 Gitea
|
||||
* 登录 Gitea 并进入 管理面板, 运行 `重新生成 '.ssh/authorized_keys' 文件（警告：不是 Gitea 的密钥也会被删除）` 和 `重新生成所有仓库的 Update 钩子（用于自定义配置文件被修改）`。
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
date: "2016-12-21T15:00:00-02:00"
|
||||
slug: "windows-service"
|
||||
sidebar_position: 50
|
||||
---
|
||||
|
||||
# 注册为Windows服务
|
||||
|
||||
要注册为Windows服务，首先以Administrator身份运行 `cmd`，然后执行以下命令：
|
||||
|
||||
```
|
||||
sc create gitea start= auto binPath= "\"C:\gitea\gitea.exe\" web --config \"C:\gitea\custom\conf\app.ini\""
|
||||
```
|
||||
|
||||
别忘了将 `C:\gitea` 替换成你的 Gitea 安装目录。
|
||||
|
||||
之后在控制面板打开 "Windows Services"，搜索 "gitea"，右键选择 "Run"。在浏览器打开 `http://localhost:3000` 就可以访问了。（如果你修改了端口，请访问对应的端口，3000是默认端口）。
|
||||
|
||||
## 从Windows服务中删除
|
||||
|
||||
以Administrator身份运行 `cmd`，然后执行以下命令：
|
||||
|
||||
```
|
||||
sc delete gitea
|
||||
```
|
||||
@@ -1,325 +0,0 @@
|
||||
---
|
||||
date: "2020-02-09T20:00:00+02:00"
|
||||
slug: "install-with-docker-rootless"
|
||||
sidebar_position: 60
|
||||
aliases:
|
||||
- /zh-cn/install-with-docker-rootless
|
||||
---
|
||||
|
||||
# 使用 Docker 安装 (rootless)
|
||||
|
||||
Gitea 在其 Docker Hub 组织中提供自动更新的 Docker 镜像。您可以始终使用最新的稳定标签，或使用其他处理 Docker 镜像更新的服务。
|
||||
|
||||
rootless 镜像使用 Gitea 内部 SSH 功能来提供 Git 协议，但不支持 OpenSSH。
|
||||
|
||||
本参考设置指南将用户引导通过基于 `docker-compose` 的设置。但是，`docker-compose` 的安装超出了本文档的范围。要安装`docker-compose` 本身， 请按照官方的 [安装说明](https://docs.docker.com/compose/install/)进行操作。
|
||||
|
||||
## 基础设置
|
||||
|
||||
最简单的设置只需创建一个卷和一个网络，并将 `docker.gitea.com/gitea:latest-rootless` 镜像作为服务启动。由于没有可用的数据库，可以使用 SQLite3 来初始化一个。
|
||||
|
||||
创建一个名为 `data` 和 `config`:
|
||||
|
||||
```sh
|
||||
mkdir -p gitea/{data,config}
|
||||
cd gitea
|
||||
touch docker-compose.yml
|
||||
```
|
||||
|
||||
然后将以下内容粘贴到名为 `docker-compose.yml` 的文件中：
|
||||
|
||||
```yaml
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
restart: always
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:2222"
|
||||
```
|
||||
|
||||
请注意，卷应由在配置文件中指定的 UID/GID 的用户/组所有。默认情况下，Docker 中的 Gitea 将使用 uid:1000 gid:1000。如果需要，您可以使用以下命令设置这些文件夹的所有权：
|
||||
|
||||
```sh
|
||||
sudo chown 1000:1000 config/ data/
|
||||
```
|
||||
|
||||
> 如果未为卷设置正确的权限，容器可能无法启动。
|
||||
|
||||
对于稳定版本，您可以使用 `:latest-rootless`、`:1-rootless`，或指定特定的版本，如: `@dockerVersion@-rootless`。如果您想使用最新的开发版本，则可以使用 `:dev-rootless` 标签。如果您想运行发布分支的最新提交，可以使用 `:1.x-dev-rootless` 标签，其中 x 是 Gitea 的次要版本号（例如:`1.16-dev-rootless`）。
|
||||
|
||||
## 自定义端口
|
||||
|
||||
要将集成的 SSH 和 Web 服务器绑定到不同的端口，请调整端口部分。通常只需更改主机端口并保持容器内的端口不变。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
restart: always
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- - "3000:3000"
|
||||
- - "2222:2222"
|
||||
+ - "80:3000"
|
||||
+ - "22:2222"
|
||||
```
|
||||
|
||||
## MySQL 数据库
|
||||
|
||||
要将 Gitea 与 MySQL 数据库结合使用，请对上面创建的 `docker-compose.yml` 文件进行以下更改。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
+ environment:
|
||||
+ - GITEA__database__DB_TYPE=mysql
|
||||
+ - GITEA__database__HOST=db:3306
|
||||
+ - GITEA__database__NAME=gitea
|
||||
+ - GITEA__database__USER=gitea
|
||||
+ - GITEA__database__PASSWD=gitea
|
||||
restart: always
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "222:22"
|
||||
+ depends_on:
|
||||
+ - db
|
||||
+
|
||||
+ db:
|
||||
+ image: docker.io/library/mysql:8
|
||||
+ restart: always
|
||||
+ environment:
|
||||
+ - MYSQL_ROOT_PASSWORD=gitea
|
||||
+ - MYSQL_USER=gitea
|
||||
+ - MYSQL_PASSWORD=gitea
|
||||
+ - MYSQL_DATABASE=gitea
|
||||
+ volumes:
|
||||
+ - ./mysql:/var/lib/mysql
|
||||
```
|
||||
|
||||
## PostgreSQL 数据库
|
||||
|
||||
要将 Gitea 与 PostgreSQL 数据库结合使用，请对上面创建的 `docker-compose.yml` 文件进行以下更改。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
environment:
|
||||
+ - GITEA__database__DB_TYPE=postgres
|
||||
+ - GITEA__database__HOST=db:5432
|
||||
+ - GITEA__database__NAME=gitea
|
||||
+ - GITEA__database__USER=gitea
|
||||
+ - GITEA__database__PASSWD=gitea
|
||||
restart: always
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:2222"
|
||||
+ depends_on:
|
||||
+ - db
|
||||
+
|
||||
+ db:
|
||||
+ image: docker.io/library/postgres:14
|
||||
+ restart: always
|
||||
+ environment:
|
||||
+ - POSTGRES_USER=gitea
|
||||
+ - POSTGRES_PASSWORD=gitea
|
||||
+ - POSTGRES_DB=gitea
|
||||
+ volumes:
|
||||
+ - ./postgres:/var/lib/postgresql/data
|
||||
```
|
||||
|
||||
## 命名卷 (Named Volumes)
|
||||
|
||||
要使用命名卷 (Named Volumes) 而不是主机卷 (Host Volumes)，请在 `docker-compose.yml` 配置中定义和使用命名卷。这样的更改将自动创建所需的卷。您不需要担心权限问题，Docker 会自动处理。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
+volumes:
|
||||
+ gitea-data:
|
||||
+ driver: local
|
||||
+ gitea-config:
|
||||
+ driver: local
|
||||
+
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
restart: always
|
||||
volumes:
|
||||
- - ./data:/var/lib/gitea
|
||||
+ - gitea-data:/var/lib/gitea
|
||||
- - ./config:/etc/gitea
|
||||
+ - gitea-config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:2222"
|
||||
```
|
||||
|
||||
MySQL 或 PostgreSQL 容器需要单独创建。
|
||||
|
||||
## 自定义用户
|
||||
|
||||
你可以选择使用自定义用户 (遵循 --user 标志定义 https://docs.docker.com/engine/reference/run/#user)。
|
||||
例如，要克隆主机用户 `git` 的定义，请使用命令 `id -u git` 并将其添加到 `docker-compose.yml` 文件中：
|
||||
请确用户对保挂载的文件夹具有写权限。
|
||||
|
||||
```diff
|
||||
version: "2"
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@-rootless
|
||||
restart: always
|
||||
+ user: 1001
|
||||
volumes:
|
||||
- ./data:/var/lib/gitea
|
||||
- ./config:/etc/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "2222:2222"
|
||||
```
|
||||
|
||||
## 启动
|
||||
|
||||
要启动基于 `docker-compose` 的这个设置，请执行 `docker-compose up -d`，以在后台启动 Gitea。使用 `docker-compose ps` 命令可以查看 Gitea 是否正确启动。可以使用 `docker-compose logs` 命令查看日志。
|
||||
|
||||
要关闭设置，请执行 `docker-compose down` 命令。这将停止和终止容器，但卷仍将存在。
|
||||
|
||||
注意：如果在 HTTP 上使用的是非 3000 端口，请将 app.ini 更改为匹配 `LOCAL_ROOT_URL = http://localhost:3000/`。
|
||||
|
||||
## 安装
|
||||
|
||||
在通过 `docker-compose` 启动 Docker 设置后，可以使用喜爱的浏览器访问 Gitea，完成安装过程。访问 `http://<服务器-IP>:3000` 并按照安装向导进行操作。如果数据库是使用上述文档中的 `docker-compose` 设置启动的，请注意必须使用 `db` 作为数据库主机名。
|
||||
|
||||
## 自定义
|
||||
|
||||
自定义文件的位置位于 `/var/lib/gitea/custom` 目录中，可以在这里找到有关自定义的文件说明。如果使用主机卷（host volumes），很容易访问这些文件；如果使用命名卷（named volumes），则可以通过另一个容器或直接访问 `/var/lib/docker/volumes/gitea_gitea/_/var_lib_gitea` 来进行访问。在安装后，配置文件将保存在 `/etc/gitea/app.ini` 中。
|
||||
|
||||
## 升级
|
||||
|
||||
:::warning
|
||||
:exclamation::exclamation: **确保您已将数据卷迁移到 Docker 容器之外的其他位置** :exclamation::exclamation:
|
||||
:::
|
||||
|
||||
要将安装升级到最新版本，请按照以下步骤操作：
|
||||
|
||||
```bash
|
||||
# 如果在 docker-compose.yml 中指定了版本，请编辑该文件以更新版本
|
||||
# 拉取新的镜像
|
||||
docker-compose pull
|
||||
# 启动一个新的容器，自动移除旧的容器
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
## 从标准镜像升级
|
||||
|
||||
- 备份您的设置
|
||||
- 将卷挂载点从 `/data` 更改为 `/var/lib/gitea`
|
||||
- 如果使用了自定义的 `app.ini`，请将其移动到新的挂载到 `/etc/gitea` 的卷中
|
||||
- 将卷中的文件夹（gitea）重命名为 custom
|
||||
- 如果需要，编辑 `app.ini`
|
||||
- 设置 `START_SSH_SERVER = true`
|
||||
- 使用镜像 ` docker.gitea.com/gitea:@dockerVersion@-rootless`
|
||||
|
||||
## 使用环境变量管理部署
|
||||
|
||||
除了上述的环境变量外，`app.ini` 中的任何设置都可以通过形式为 `GITEA__SECTION_NAME__KEY_NAME` 的环境变量进行设置或覆盖。这些设置在每次 Docker 容器启动时都会生效。完整信息请参考[这里](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini).
|
||||
|
||||
这些环境变量可以在 `docker-compose.yml` 中传递给 Docker 容器。以下示例将启用 SMTP 邮件服务器，如果主机上设置了所需的环境变量 GITEA**mailer**FROM、GITEA**mailer**HOST、GITEA**mailer**PASSWD，或者在与 `docker-compose.yml` 相同目录中的 `.env` 文件中设置了这些环境变量：
|
||||
|
||||
```bash
|
||||
...
|
||||
services:
|
||||
server:
|
||||
environment:
|
||||
- GITEA__mailer__ENABLED=true
|
||||
- GITEA__mailer__FROM=${GITEA__mailer__FROM:?GITEA__mailer__FROM not set}
|
||||
- GITEA__mailer__MAILER_TYPE=smtp
|
||||
- GITEA__mailer__HOST=${GITEA__mailer__HOST:?GITEA__mailer__HOST not set}
|
||||
- GITEA__mailer__IS_TLS_ENABLED=true
|
||||
- GITEA__mailer__USER=${GITEA__mailer__USER:-apikey}
|
||||
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
|
||||
```
|
||||
|
||||
要设置所需的 TOKEN 和 SECRET 值，可以使用 Gitea 的内置[生成使用函数](https://docs.gitea.io/en-us/command-line/#generate).
|
||||
|
||||
# SSH 容器透传
|
||||
|
||||
由于 SSH 在容器内运行，如果需要 SSH 支持，需要将 SSH 从主机透传到容器。一种选择是在容器内运行 SSH，并使用非标准端口（或将主机端口移动到非标准端口）。另一种可能更直接的选择是将主机上的 SSH 命令转发到容器。下面解释了这种设置。
|
||||
|
||||
本指南假设您已在主机上创建了一个名为 `git` 的用户，并具有运行 `docker exec` 的权限，并且 Gitea 容器的名称为 `gitea`。您需要修改该用户的 shell，以将命令转发到容器内的 `sh` 可执行文件，使用 `docker exec`。
|
||||
|
||||
首先，在主机上创建文件 `/usr/local/bin/gitea-shell`，并填入以下内容：
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
/usr/bin/docker exec -i --env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea sh "$@"
|
||||
```
|
||||
|
||||
注意上述 docker 命令中的 `gitea` 是容器的名称。如果您的容器名称不同，请记得更改。
|
||||
|
||||
还应确保正确设置了 shell 包装器的权限：
|
||||
|
||||
```bash
|
||||
sudo chmod +x /usr/local/bin/gitea-shell
|
||||
```
|
||||
|
||||
一旦包装器就位，您可以将其设置为 `git` 用户的 shell：
|
||||
|
||||
```bash
|
||||
sudo usermod -s /usr/local/bin/gitea-shell git
|
||||
```
|
||||
|
||||
现在，所有的 SSH 命令都会被转发到容器，您需要在主机上设置 SSH 认证。这可以通过利用 [SSH AuthorizedKeysCommand](https://docs.gitea.io/en-us/command-line/#keys) 来匹配 Gitea 接受的密钥。在主机的 `/etc/ssh/sshd_config` 文件中添加以下代码块：
|
||||
|
||||
```bash
|
||||
Match User git
|
||||
AuthorizedKeysCommandUser git
|
||||
AuthorizedKeysCommand /usr/bin/docker exec -i gitea /usr/local/bin/gitea keys -c /etc/gitea/app.ini -e git -u %u -t %t -k %k
|
||||
```
|
||||
|
||||
（从 1.16.0 开始，您将不需要设置 `-c /etc/gitea/app.ini` 选项。）
|
||||
|
||||
剩下的就是重新启动 SSH 服务器：
|
||||
|
||||
```bash
|
||||
sudo systemctl restart sshd
|
||||
```
|
||||
|
||||
**注意**
|
||||
|
||||
这实际上并没有使用 Docker 的 SSH，而是仅仅使用了围绕它的命令。
|
||||
从理论上讲，您可以不运行内部的 SSH 服务器。
|
||||
@@ -1,372 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "install-with-docker"
|
||||
sidebar_position: 70
|
||||
---
|
||||
|
||||
# 使用 Docker 安装
|
||||
|
||||
Gitea 在其 Docker Hub 组织内提供自动更新的 Docker 镜像。可以始终使用最新的稳定标签或使用其他服务来更新 Docker 镜像。
|
||||
|
||||
该参考设置指导用户完成基于 `docker-compose` 的设置，但是 `docker-compose` 的安装不在本文档的范围之内。要安装 `docker-compose` 本身，请遵循官方[安装说明](https://docs.docker.com/compose/install/)。
|
||||
|
||||
## 基本
|
||||
|
||||
最简单的设置只是创建一个卷和一个网络，然后将 `docker.gitea.com/gitea:latest` 镜像作为服务启动。由于没有可用的数据库，因此可以使用 SQLite3 初始化数据库。创建一个类似 `gitea` 的目录，并将以下内容粘贴到名为 `docker-compose.yml` 的文件中。请注意，该卷应由配置文件中指定的 UID/GID 的用户/组拥有。如果您不授予卷正确的权限，则容器可能无法启动。另请注意，标签 `:latest` 将安装当前的开发版本。对于稳定的发行版，您可以使用 `:1` 或指定某个发行版，例如 `@dockerVersion@`。
|
||||
|
||||
```yaml
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- ./gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "222:22"
|
||||
```
|
||||
|
||||
## 端口
|
||||
|
||||
要将集成的 openSSH 守护进程和 Web 服务器绑定到其他端口，请调整端口部分。通常，只需更改主机端口，容器内的端口保持原样即可。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- ./gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- - "3000:3000"
|
||||
- - "222:22"
|
||||
+ - "8080:3000"
|
||||
+ - "2221:22"
|
||||
```
|
||||
|
||||
## 数据库
|
||||
|
||||
### MySQL 数据库
|
||||
|
||||
要将 Gitea 与 MySQL 数据库结合使用，请将这些更改应用于上面创建的 `docker-compose.yml` 文件。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
+ - GITEA__database__DB_TYPE=mysql
|
||||
+ - GITEA__database__HOST=db:3306
|
||||
+ - GITEA__database__NAME=gitea
|
||||
+ - GITEA__database__USER=gitea
|
||||
+ - GITEA__database__PASSWD=gitea
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- ./gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "222:22"
|
||||
+ depends_on:
|
||||
+ - db
|
||||
+
|
||||
+ db:
|
||||
+ image: docker.io/library/mysql:8
|
||||
+ restart: always
|
||||
+ environment:
|
||||
+ - MYSQL_ROOT_PASSWORD=gitea
|
||||
+ - MYSQL_USER=gitea
|
||||
+ - MYSQL_PASSWORD=gitea
|
||||
+ - MYSQL_DATABASE=gitea
|
||||
+ networks:
|
||||
+ - gitea
|
||||
+ volumes:
|
||||
+ - ./mysql:/var/lib/mysql
|
||||
```
|
||||
|
||||
### PostgreSQL 数据库
|
||||
|
||||
要将 Gitea 与 PostgreSQL 数据库结合使用，请将这些更改应用于上面创建的 `docker-compose.yml` 文件。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
+ - GITEA__database__DB_TYPE=postgres
|
||||
+ - GITEA__database__HOST=db:5432
|
||||
+ - GITEA__database__NAME=gitea
|
||||
+ - GITEA__database__USER=gitea
|
||||
+ - GITEA__database__PASSWD=gitea
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- ./gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "222:22"
|
||||
+ depends_on:
|
||||
+ - db
|
||||
+
|
||||
+ db:
|
||||
+ image: docker.io/library/postgres:14
|
||||
+ restart: always
|
||||
+ environment:
|
||||
+ - POSTGRES_USER=gitea
|
||||
+ - POSTGRES_PASSWORD=gitea
|
||||
+ - POSTGRES_DB=gitea
|
||||
+ networks:
|
||||
+ - gitea
|
||||
+ volumes:
|
||||
+ - ./postgres:/var/lib/postgresql/data
|
||||
```
|
||||
|
||||
## 命名卷
|
||||
|
||||
要使用命名卷而不是主机卷，请在 `docker-compose.yml` 配置中定义并使用命名卷。此更改将自动创建所需的卷。您无需担心命名卷的权限；Docker 将自动处理该问题。
|
||||
|
||||
```diff
|
||||
version: "3"
|
||||
|
||||
networks:
|
||||
gitea:
|
||||
external: false
|
||||
|
||||
+volumes:
|
||||
+ gitea:
|
||||
+ driver: local
|
||||
+
|
||||
services:
|
||||
server:
|
||||
image: docker.gitea.com/gitea:@dockerVersion@
|
||||
container_name: gitea
|
||||
restart: always
|
||||
networks:
|
||||
- gitea
|
||||
volumes:
|
||||
- - ./gitea:/data
|
||||
+ - gitea:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
ports:
|
||||
- "3000:3000"
|
||||
- "222:22"
|
||||
```
|
||||
|
||||
MySQL 或 PostgreSQL 容器将需要分别创建。
|
||||
|
||||
## 启动
|
||||
|
||||
要基于 `docker-compose` 启动此设置，请执行 `docker-compose up -d`，以在后台启动 Gitea。使用 `docker-compose ps` 将显示 Gitea 是否正确启动。可以使用 `docker-compose logs` 查看日志。
|
||||
|
||||
要关闭设置，请执行 `docker-compose down`。这将停止并杀死容器。这些卷将仍然存在。
|
||||
|
||||
注意：如果在 http 上使用非 3000 端口，请更改 app.ini 以匹配 `LOCAL_ROOT_URL = http://localhost:3000/`。
|
||||
|
||||
## 安装
|
||||
|
||||
通过 `docker-compose` 启动 Docker 安装后，应该可以使用喜欢的浏览器访问 Gitea，以完成安装。访问 http://server-ip:3000 并遵循安装向导。如果数据库是通过上述 `docker-compose` 设置启动的，请注意，必须将 `db` 用作数据库主机名。
|
||||
|
||||
## 环境变量
|
||||
|
||||
您可以通过环境变量配置 Gitea 的一些设置：
|
||||
|
||||
（默认值以**粗体**显示）
|
||||
|
||||
- `APP_NAME`：**“Gitea: Git with a cup of tea”**：应用程序名称，在页面标题中使用。
|
||||
- `RUN_MODE`：**prod**：应用程序运行模式，会影响性能和调试。"dev"，"prod"或"test"。
|
||||
- `DOMAIN`：**localhost**：此服务器的域名，用于 Gitea UI 中显示的 http 克隆 URL。
|
||||
- `SSH_DOMAIN`：**localhost**：该服务器的域名，用于 Gitea UI 中显示的 ssh 克隆 URL。如果启用了安装页面，则 SSH 域服务器将采用以下形式的 DOMAIN 值（保存时将覆盖此设置）。
|
||||
- `SSH_PORT`：**22**：克隆 URL 中显示的 SSH 端口。
|
||||
- `SSH_LISTEN_PORT`：**%(SSH_PORT)s**：内置 SSH 服务器的端口。
|
||||
- `DISABLE_SSH`：**false**：如果不可用，请禁用 SSH 功能。如果要禁用 SSH 功能，则在安装 Gitea 时应将 SSH 端口设置为 `0`。
|
||||
- `HTTP_PORT`：**3000**：HTTP 监听端口。
|
||||
- `ROOT_URL`：**""**：覆盖自动生成的公共 URL。如果内部 URL 和外部 URL 不匹配（例如在 Docker 中），这很有用。
|
||||
- `LFS_START_SERVER`：**false**：启用 git-lfs 支持。
|
||||
- `DB_TYPE`：**sqlite3**：正在使用的数据库类型[mysql，postgres，mssql，sqlite3]。
|
||||
- `DB_HOST`：**localhost:3306**：数据库主机地址和端口。
|
||||
- `DB_NAME`：**gitea**：数据库名称。
|
||||
- `DB_USER`：**root**：数据库用户名。
|
||||
- `DB_PASSWD`：**"_empty_"** ：数据库用户密码。如果您在密码中使用特殊字符，请使用“您的密码”进行引用。
|
||||
- `INSTALL_LOCK`：**false**：禁止访问安装页面。
|
||||
- `SECRET_KEY`：**""** ：全局密钥。这应该更改。如果它具有一个值并且 `INSTALL_LOCK` 为空，则 `INSTALL_LOCK` 将自动设置为 `true`。
|
||||
- `DISABLE_REGISTRATION`：**false**：禁用注册，之后只有管理员才能为用户创建帐户。
|
||||
- `REQUIRE_SIGNIN_VIEW`：**false**：启用此选项可强制用户登录以查看任何页面。
|
||||
- `USER_UID`：**1000**：在容器内运行 Gitea 的用户的 UID（Unix 用户 ID）。如果使用主机卷，则将其与 `/data` 卷的所有者的 UID 匹配（对于命名卷，则不需要这样做）。
|
||||
- `USER_GID`：**1000**：在容器内运行 Gitea 的用户的 GID（Unix 组 ID）。如果使用主机卷，则将其与 `/data` 卷的所有者的 GID 匹配（对于命名卷，则不需要这样做）。
|
||||
|
||||
## 自定义
|
||||
|
||||
[此处](https://docs.gitea.io/zh-cn/customizing-gitea/)描述的定制文件应放在 `/data/gitea` 目录中。如果使用主机卷，则访问这些文件非常容易；对于命名卷，可以通过另一个容器或通过直接访问 `/var/lib/docker/volumes/gitea_gitea/_data` 来完成。安装后，配置文件将保存在 `/data/gitea/conf/app.ini` 中。
|
||||
|
||||
## 升级
|
||||
|
||||
:::warning
|
||||
:exclamation::exclamation: **确保已将数据卷到 Docker 容器外部的某个位置** :exclamation::exclamation:
|
||||
:::
|
||||
|
||||
要将安装升级到最新版本：
|
||||
|
||||
```bash
|
||||
# Edit `docker-compose.yml` to update the version, if you have one specified
|
||||
# Pull new images
|
||||
docker-compose pull
|
||||
# Start a new container, automatically removes old one
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
## 使用环境变量管理部署
|
||||
|
||||
除了上面的环境变量之外，`app.ini` 中的任何设置都可以使用以下形式的环境变量进行设置或覆盖：`GITEA__SECTION_NAME__KEY_NAME`。 每次 docker 容器启动时都会应用这些设置。 完整信息在[这里](https://github.com/go-gitea/gitea/tree/master/contrib/environment-to-ini)。
|
||||
|
||||
```bash
|
||||
...
|
||||
services:
|
||||
server:
|
||||
environment:
|
||||
- GITEA__mailer__ENABLED=true
|
||||
- GITEA__mailer__FROM=${GITEA__mailer__FROM:?GITEA__mailer__FROM not set}
|
||||
- GITEA__mailer__MAILER_TYPE=smtp
|
||||
- GITEA__mailer__HOST=${GITEA__mailer__HOST:?GITEA__mailer__HOST not set}
|
||||
- GITEA__mailer__IS_TLS_ENABLED=true
|
||||
- GITEA__mailer__USER=${GITEA__mailer__USER:-apikey}
|
||||
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
|
||||
```
|
||||
|
||||
Gitea 将为每次新安装自动生成新的 `SECRET_KEY` 并将它们写入 `app.ini`。 如果您想手动设置 `SECRET_KEY`，您可以使用以下 docker 命令来使用 Gitea 内置的[方法](https://docs.gitea.io/en-us/command-line/#generate)生成 `SECRET_KEY`。 安装后请妥善保管您的 `SECRET_KEY`，如若丢失则无法解密已加密的数据。
|
||||
|
||||
以下命令将向 `stdout` 输出一个新的 `SECRET_KEY` 和 `INTERNAL_TOKEN`，然后您可以将其放入环境变量中。
|
||||
|
||||
```bash
|
||||
docker run -it --rm docker.gitea.com/gitea:1 gitea generate secret SECRET_KEY
|
||||
docker run -it --rm docker.gitea.com/gitea:1 gitea generate secret INTERNAL_TOKEN
|
||||
```
|
||||
|
||||
```yaml
|
||||
---
|
||||
services:
|
||||
server:
|
||||
environment:
|
||||
- GITEA__security__SECRET_KEY=[value returned by generate secret SECRET_KEY]
|
||||
- GITEA__security__INTERNAL_TOKEN=[value returned by generate secret INTERNAL_TOKEN]
|
||||
```
|
||||
|
||||
## SSH 容器直通
|
||||
|
||||
由于 SSH 在容器内运行，因此，如果需要 SSH 支持，则需要将 SSH 从主机传递到容器。一种选择是在非标准端口上运行容器 SSH（或将主机端口移至非标准端口）。另一个可能更直接的选择是将 SSH 连接从主机转发到容器。下面将说明此设置。
|
||||
|
||||
本指南假定您已经在名为 `git` 的主机上创建了一个用户，该用户与容器值 `USER_UID`/`USER_GID` 共享相同的 `UID`/`GID`。这些值可以在 `docker-compose.yml` 中设置为环境变量：
|
||||
|
||||
```bash
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
```
|
||||
|
||||
接下来将主机的 `/home/git/.ssh` 装入容器。否则，SSH 身份验证将无法在容器内运行。
|
||||
|
||||
```bash
|
||||
volumes:
|
||||
- /home/git/.ssh/:/data/git/.ssh
|
||||
```
|
||||
|
||||
现在，需要在主机上创建 SSH 密钥对。该密钥对将用于向主机验证主机上的 `git` 用户。
|
||||
|
||||
```bash
|
||||
sudo -u git ssh-keygen -t rsa -b 4096 -C "Gitea Host Key"
|
||||
```
|
||||
|
||||
在下一步中，需要在主机上创建一个名为 `/usr/local/bin/gitea` 的文件（具有可执行权限）。该文件将发出从主机到容器的 SSH 转发。将以下内容添加到 `/usr/local/bin/gitea`：
|
||||
|
||||
```bash
|
||||
ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@"
|
||||
```
|
||||
|
||||
为了使转发正常工作，需要将容器（22）的 SSH 端口映射到 `docker-compose.yml` 中的主机端口 2222。由于此端口不需要暴露给外界，因此可以将其映射到主机的 `localhost`：
|
||||
|
||||
```bash
|
||||
ports:
|
||||
# [...]
|
||||
- "127.0.0.1:2222:22"
|
||||
```
|
||||
|
||||
另外，主机上的 `/home/git/.ssh/authorized_keys` 需要修改。它需要以与 Gitea 容器内的 `authorized_keys` 相同的方式进行操作。因此，将您在上面创建的密钥（“Gitea 主机密钥”）的公共密钥添加到 `/home/git/.ssh/authorized_keys`。这可以通过 `echo "$(cat /home/git/.ssh/id_rsa.pub)" >> /home/git/.ssh/authorized_keys` 完成。重要提示：来自 `git` 用户的公钥需要“按原样”添加，而通过 Gitea 网络界面添加的所有其他公钥将以 `command="/app [...]` 作为前缀。
|
||||
|
||||
该文件应该看起来像：
|
||||
|
||||
```bash
|
||||
# SSH pubkey from git user
|
||||
ssh-rsa <Gitea Host Key>
|
||||
|
||||
# other keys from users
|
||||
command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty <user pubkey>
|
||||
```
|
||||
|
||||
这是详细的说明，当发出 SSH 请求时会发生什么：
|
||||
|
||||
1. 使用 `git` 用户向主机发出 SSH 请求，例如 `git clone git@domain:user/repo.git`。
|
||||
2. 在 `/home/git/.ssh/authorized_keys` 中，该命令执行 `/usr/local/bin/gitea` 脚本。
|
||||
3. `/usr/local/bin/gitea` 将 SSH 请求转发到端口 2222，该端口已映射到容器的 SSH 端口（22）。
|
||||
4. 由于 `/home/git/.ssh/authorized_keys` 中存在 `git` 用户的公钥，因此身份验证主机 → 容器成功，并且 SSH 请求转发到在 docker 容器中运行的 Gitea。
|
||||
|
||||
如果在 Gitea Web 界面中添加了新的 SSH 密钥，它将以与现有密钥相同的方式附加到 `.ssh/authorized_keys` 中。
|
||||
|
||||
**注意**
|
||||
|
||||
SSH 容器直通仅在以下情况下有效
|
||||
|
||||
- 在容器中使用 `opensshd`
|
||||
- 如果未将 `AuthorizedKeysCommand` 与 `SSH_CREATE_AUTHORIZED_KEYS_FILE = false` 结合使用以禁用授权文件密钥生成
|
||||
- `LOCAL_ROOT_URL` 不变
|
||||
@@ -1,97 +0,0 @@
|
||||
---
|
||||
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 = "https://gitea.example.com/{owner}/_cargo-index.git"
|
||||
|
||||
[net]
|
||||
git-fetch-with-cli = true
|
||||
```
|
||||
|
||||
| 参数 | 描述 |
|
||||
| ------- | ---------------- |
|
||||
| `owner` | 软件包的所有者。 |
|
||||
|
||||
如果这个注册表是私有的或者您想要发布新的软件包，您必须配置您的凭据。
|
||||
将凭据部分添加到位于当前用户主目录中的凭据文件中（例如 `~/.cargo/credentials.toml`）：
|
||||
|
||||
```
|
||||
[registries.gitea]
|
||||
token = "Bearer {token}"
|
||||
```
|
||||
|
||||
| 参数 | 描述 |
|
||||
| ------- | ------------------------------------------------------------------------------------- |
|
||||
| `token` | 您的[个人访问令牌](development/api-usage.md#通过-api-认证) |
|
||||
|
||||
## 发布软件包
|
||||
|
||||
在项目中运行以下命令来发布软件包：
|
||||
|
||||
```shell
|
||||
cargo publish
|
||||
```
|
||||
|
||||
如果已经存在同名和版本的软件包，您将无法发布新的软件包。您必须先删除现有的软件包。
|
||||
|
||||
## 安装软件包
|
||||
|
||||
要从软件包注册表安装软件包，请执行以下命令：
|
||||
|
||||
```shell
|
||||
cargo add {package_name}
|
||||
```
|
||||
|
||||
| 参数 | 描述 |
|
||||
| -------------- | ------------ |
|
||||
| `package_name` | 软件包名称。 |
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
cargo publish
|
||||
cargo add
|
||||
cargo install
|
||||
cargo yank
|
||||
cargo unyank
|
||||
cargo search
|
||||
```
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
date: "2023-01-20T00:00:00+00:00"
|
||||
slug: "chef"
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Chef 软件包注册表
|
||||
|
||||
为您的用户或组织发布 [Chef](https://chef.io/) cookbooks。
|
||||
|
||||
## 要求
|
||||
|
||||
要使用 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` | 软件包版本 |
|
||||
@@ -1,110 +0,0 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "composer"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# 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#通过-api-认证)替代密码。
|
||||
|
||||
服务器将以以下 HTTP 状态码响应。
|
||||
|
||||
| HTTP 状态码 | 含义 |
|
||||
| ----------------- | ----------------------------------------------------------- |
|
||||
| `201 Created` | 软件包已发布 |
|
||||
| `400 Bad Request` | 软件包名称和/或版本无效，或具有相同名称和版本的软件包已存在 |
|
||||
|
||||
## 配置软件包注册表
|
||||
|
||||
要注册软件包注册表，您需要将其添加到 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` | 软件包版本 |
|
||||
@@ -1,89 +0,0 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "conan"
|
||||
sidebar_position: 20
|
||||
---
|
||||
|
||||
# Conan 软件包注册表
|
||||
|
||||
为您的用户或组织发布 [Conan](https://conan.io/) 软件包。
|
||||
|
||||
## 要求
|
||||
|
||||
要使用 [conan](https://conan.io/downloads.html) 软件包注册表，您需要使用 conan 命令行工具来消费和发布软件包。
|
||||
|
||||
## 配置软件包注册表
|
||||
|
||||
要注册软件包注册表，您需要配置一个新的 Conan remote：
|
||||
|
||||
```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#通过-api-认证)替代密码。 |
|
||||
| `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` | 要上传的 recipe |
|
||||
|
||||
For example:
|
||||
|
||||
```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` | 要下载的 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
|
||||
```
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
date: "2022-12-28T00:00:00+00:00"
|
||||
slug: "conda"
|
||||
sidebar_position: 25
|
||||
---
|
||||
|
||||
# Conda 软件包注册表
|
||||
|
||||
为您的用户或组织发布 [Conda](https://docs.conda.io/en/latest/) 软件包。
|
||||
|
||||
## 要求
|
||||
|
||||
要使用 Conda 软件包注册表，您需要使用 [conda](https://docs.conda.io/projects/conda/en/stable/user-guide/install/index.html) 命令行工具。
|
||||
|
||||
## 配置软件包注册表
|
||||
|
||||
要注册软件包注册表并提供凭据，请编辑您的 `.condarc` 文件：
|
||||
|
||||
```yaml
|
||||
channel_alias: https://gitea.example.com/api/packages/{owner}/conda
|
||||
channels:
|
||||
- https://gitea.example.com/api/packages/{owner}/conda
|
||||
default_channels:
|
||||
- https://gitea.example.com/api/packages/{owner}/conda
|
||||
```
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| ------- | -------------- |
|
||||
| `owner` | 软件包的所有者 |
|
||||
|
||||
有关各个设置的解释，请参阅[官方文档](https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html)。
|
||||
|
||||
如果需要提供凭据，可以将它们作为通道 URL 的一部分嵌入（`https://user:password@gitea.example.com/...`）。
|
||||
|
||||
## 发布软件包
|
||||
|
||||
要发布一个软件包，请执行一个HTTP `PUT`操作，请求正文中包含软件包内容。
|
||||
|
||||
```
|
||||
PUT https://gitea.example.com/api/packages/{owner}/conda/{channel}/{filename}
|
||||
```
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| ---------- | --------------------------------------------------------------------------------------------------- |
|
||||
| `owner` | 软件包的所有者 |
|
||||
| `channel` | 软件包的[通道](https://conda.io/projects/conda/en/latest/user-guide/concepts/channels.html)（可选） |
|
||||
| `filename` | 文件名 |
|
||||
|
||||
使用HTTP基本身份验证的示例请求：
|
||||
|
||||
```shell
|
||||
curl --user your_username:your_password_or_token \
|
||||
--upload-file path/to/package-1.0.conda \
|
||||
https://gitea.example.com/api/packages/testuser/conda/package-1.0.conda
|
||||
```
|
||||
|
||||
如果已经存在同名和版本的软件包，则无法发布软件包。您必须先删除现有的软件包。
|
||||
|
||||
## 安装软件包
|
||||
|
||||
要从软件包注册表中安装软件包，请执行以下命令之一：
|
||||
|
||||
```shell
|
||||
conda install {package_name}
|
||||
conda install {package_name}={package_version}
|
||||
conda install -c {channel} {package_name}
|
||||
```
|
||||
|
||||
| 参数 | 描述 |
|
||||
| ----------------- | -------------------- |
|
||||
| `package_name` | 软件包的名称 |
|
||||
| `package_version` | 软件包的版本 |
|
||||
| `channel` | 软件包的通道（可选） |
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "container"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
# 容器注册表
|
||||
|
||||
为您的用户或组织发布符合 [Open Container Initiative(OCI)](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#通过-api-认证)替代密码进行身份验证。
|
||||
|
||||
## 镜像命名约定
|
||||
|
||||
镜像必须遵循以下命名约定：
|
||||
|
||||
`{registry}/{owner}/{image}`
|
||||
|
||||
例如，以下是所有者为 `testuser` 的有效镜像名称示例：
|
||||
|
||||
`gitea.example.com/testuser/myimage`
|
||||
|
||||
`gitea.example.com/testuser/my-image`
|
||||
|
||||
`gitea.example.com/testuser/my/image`
|
||||
|
||||
**注意:** 该注册表仅支持大小写不敏感的标签名称。因此，`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}
|
||||
```
|
||||
|
||||
| Parameter | Description |
|
||||
| --------- | ------------ |
|
||||
| `owner` | 镜像的所有者 |
|
||||
| `image` | 镜像的名称 |
|
||||
| `tag` | 镜像的标签 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
docker pull gitea.example.com/testuser/myimage:latest
|
||||
```
|
||||
@@ -1,135 +0,0 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "generic"
|
||||
sidebar_position: 500
|
||||
---
|
||||
|
||||
# 通用软件包注册表
|
||||
|
||||
发布通用文件，如发布二进制文件或其他输出，供您的用户或组织使用。
|
||||
|
||||
## 身份验证软件包注册表
|
||||
|
||||
要身份验证软件包注册表，您需要提供[自定义 HTTP 头或使用 HTTP 基本身份验证](development/api-usage.md#通过-api-认证)。
|
||||
|
||||
## 发布软件包
|
||||
|
||||
要发布通用软件包，请执行 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#通过-api-认证)替代密码。
|
||||
|
||||
服务器将使用以下 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
|
||||
```
|
||||
|
||||
The server responds with the following HTTP Status codes.
|
||||
|
||||
| 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` | 找不到软件包或文件 |
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
date: "2022-04-14T00:00:00+00:00"
|
||||
slug: "helm"
|
||||
sidebar_position: 50
|
||||
---
|
||||
|
||||
# Helm Chart 注册表
|
||||
|
||||
为您的用户或组织发布 [Helm](https://helm.sh/) charts。
|
||||
|
||||
## 要求
|
||||
|
||||
要使用 Helm Chart 注册表，可以使用诸如 `curl` 或 [`helm cm-push`](https://github.com/chartmuseum/helm-push/) 插件之类的简单HTTP客户端。
|
||||
|
||||
## 发布软件包
|
||||
|
||||
通过运行以下命令来发布软件包：
|
||||
|
||||
```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#通过-api-认证)替代密码进行身份验证。 |
|
||||
| `repo` | 仓库名称 |
|
||||
| `chart_file` | Helm Chart 归档文件 |
|
||||
| `owner` | 软件包的所有者 |
|
||||
|
||||
## 安装软件包
|
||||
|
||||
要从注册表中安装Helm Chart，请执行以下命令：
|
||||
|
||||
```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的名称 |
|
||||
@@ -1,154 +0,0 @@
|
||||
---
|
||||
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#通过-api-认证) |
|
||||
| `owner` | 软件包的所有者 |
|
||||
|
||||
### Gradle variant
|
||||
|
||||
如果您计划在项目中添加来自 Gitea 实例的一些软件包，请将其添加到 repositories 部分中：
|
||||
|
||||
```groovy
|
||||
repositories {
|
||||
// other 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，请使用 `gradle` 命令和 `publishAllPublicationsToGiteaRepository` 任务：
|
||||
|
||||
```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:
|
||||
```
|
||||
@@ -1,132 +0,0 @@
|
||||
---
|
||||
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/)和非作用域软件包。
|
||||
|
||||
以下示例使用具有作用域 `@test` 的 `npm` 工具。
|
||||
|
||||
## 配置软件包注册表
|
||||
|
||||
要注册软件包注册表，您需要配置一个新的软件包源。
|
||||
|
||||
```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#通过-api-认证)。 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
npm config set @test:registry https://gitea.example.com/api/packages/testuser/npm/
|
||||
npm config set -- '//gitea.example.com/api/packages/testuser/npm/:_authToken' "personal_access_token"
|
||||
```
|
||||
|
||||
或者，不使用作用域：
|
||||
|
||||
```shell
|
||||
npm config set registry https://gitea.example.com/api/packages/testuser/npm/
|
||||
npm config set -- '//gitea.example.com/api/packages/testuser/npm/:_authToken' "personal_access_token"
|
||||
```
|
||||
|
||||
## 发布软件包
|
||||
|
||||
在项目中运行以下命令发布软件包：
|
||||
|
||||
```shell
|
||||
npm publish
|
||||
```
|
||||
|
||||
如果已经存在相同名称和版本的软件包，您无法发布该软件包。您必须先删除现有的软件包。
|
||||
|
||||
## 删除软件包
|
||||
|
||||
通过运行以下命令删除软件包：
|
||||
|
||||
```shell
|
||||
npm unpublish {package_name}[@{package_version}]
|
||||
```
|
||||
|
||||
| 参数 | 描述 |
|
||||
| ----------------- | ---------- |
|
||||
| `package_name` | 软件包名称 |
|
||||
| `package_version` | 软件包版本 |
|
||||
|
||||
例如
|
||||
|
||||
```shell
|
||||
npm unpublish @test/test_package
|
||||
npm unpublish @test/test_package@1.0.0
|
||||
```
|
||||
|
||||
## 安装软件包
|
||||
|
||||
要从软件包注册表中安装软件包，请执行以下命令：
|
||||
|
||||
```shell
|
||||
npm install {package_name}
|
||||
```
|
||||
|
||||
| 参数 | 描述 |
|
||||
| -------------- | ---------- |
|
||||
| `package_name` | 软件包名称 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
npm install @test/test_package
|
||||
```
|
||||
|
||||
## 给软件包打标签
|
||||
|
||||
该注册表支持[版本标签](https://docs.npmjs.com/adding-dist-tags-to-packages/)，可以通过 `npm dist-tag` 管理：
|
||||
|
||||
```shell
|
||||
npm dist-tag add {package_name}@{version} {tag}
|
||||
```
|
||||
|
||||
| 参数 | 描述 |
|
||||
| -------------- | ---------- |
|
||||
| `package_name` | 软件包名称 |
|
||||
| `version` | 软件包版本 |
|
||||
| `tag` | 软件包标签 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
npm dist-tag add test_package@1.0.2 release
|
||||
```
|
||||
|
||||
标签名称不能是有效的版本。所有可解析为版本的标签名称都将被拒绝。
|
||||
|
||||
## 搜索软件包
|
||||
|
||||
该注册表支持[搜索](https://docs.npmjs.com/cli/v7/commands/npm-search/)，但不支持像 `author:gitea` 这样的特殊搜索限定符。
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
npm install
|
||||
npm ci
|
||||
npm publish
|
||||
npm unpublish
|
||||
npm dist-tag
|
||||
npm view
|
||||
npm search
|
||||
```
|
||||
@@ -1,105 +0,0 @@
|
||||
---
|
||||
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/en-us/nuget/create-packages/symbol-packages-snupkg)。
|
||||
|
||||
## 要求
|
||||
|
||||
要使用 NuGet 软件包注册表，您可以使用命令行界面工具，以及各种集成开发环境（IDE）中的 NuGet 功能，如 Visual Studio。有关 NuGet 客户端的更多信息，请参[阅官方文档](https://docs.microsoft.com/en-us/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#通过-api-认证)代替密码。 |
|
||||
| `owner` | 软件包的所有者 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
dotnet nuget add source --name gitea --username testuser --password password123 https://gitea.example.com/api/packages/testuser/nuget/index.json
|
||||
```
|
||||
|
||||
您可以在不提供凭据的情况下添加源，并在发布软件包时使用--api-key参数。在这种情况下，您需要提供[个人访问令牌](development/api-usage.md#通过-api-认证)。
|
||||
|
||||
## 发布软件包
|
||||
|
||||
通过运行以下命令发布软件包：
|
||||
|
||||
```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
|
||||
```
|
||||
@@ -1,91 +0,0 @@
|
||||
---
|
||||
date: "2021-07-20T00:00:00+00:00"
|
||||
slug: "overview"
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# 软件包注册表
|
||||
|
||||
从Gitea **1.17**版本开始，软件包注册表可以用作常见软件包管理器的公共或私有注册表。
|
||||
|
||||
## 支持的软件包管理器
|
||||
|
||||
目前支持以下软件包管理器：
|
||||
|
||||
| Name | Language | Package client |
|
||||
| ------------------------------------------------------------- | ---------- | ------------------------- |
|
||||
| [Cargo](packages/cargo.md) | Rust | `cargo` |
|
||||
| [Chef](packages/chef.md) | - | `knife` |
|
||||
| [Composer](packages/composer.md) | PHP | `composer` |
|
||||
| [Conan](packages/conan.md) | C++ | `conan` |
|
||||
| [Conda](packages/conda.md) | - | `conda` |
|
||||
| [Container](packages/container.md) | - | 任何符合OCI规范的客户端 |
|
||||
| [Generic](packages/generic.md) | - | 任何HTTP客户端 |
|
||||
| [Helm](packages/helm.md) | - | 任何HTTP客户端, `cm-push` |
|
||||
| [Maven](packages/maven.md) | Java | `mvn`, `gradle` |
|
||||
| [npm](packages/npm.md) | JavaScript | `npm`, `yarn`, `pnpm` |
|
||||
| [NuGet](packages/nuget.md) | .NET | `nuget` |
|
||||
| [Pub](packages/pub.md) | Dart | `dart`, `flutter` |
|
||||
| [PyPI](packages/pypi.md) | Python | `pip`, `twine` |
|
||||
| [RubyGems](packages/rubygems.md) | Ruby | `gem`, `Bundler` |
|
||||
| [Swift](packages/rubygems.md) | Swift | `swift` |
|
||||
| [Vagrant](packages/vagrant.md) | - | `vagrant` |
|
||||
|
||||
**以下段落仅适用于未全局禁用软件包的情况！**
|
||||
|
||||
## 仓库 x 软件包
|
||||
|
||||
软件包始终属于所有者（用户或组织），而不是仓库。
|
||||
要将（已上传的）软件包链接到仓库，请打开该软件包的设置页面，并选择要将此软件包链接到的仓库。
|
||||
将链接到整个软件包，而不仅是单个版本。
|
||||
|
||||
链接软件包将导致在仓库的软件包列表中显示该软件包，并在软件包页面上显示到仓库的链接（以及到仓库工单的链接）。
|
||||
|
||||
## 访问限制
|
||||
|
||||
| 软件包所有者类型 | 用户 | 组织 |
|
||||
| ---------------- | ---------------------------------------- | ------------------------------------------ |
|
||||
| **读取** 访问 | 公开，如果用户也是公开的；否则仅限此用户 | 公开，如果组织是公开的，否则仅限组织成员 |
|
||||
| **写入** 访问 | 仅软件包所有者 | 具有组织中的管理员或写入访问权限的组织成员 |
|
||||
|
||||
注意：这些访问限制可能会[变化](https://github.com/go-gitea/gitea/issues/19270)，将通过专门的组织团队权限添加更细粒度的控制。
|
||||
|
||||
## 创建或上传软件包
|
||||
|
||||
根据软件包类型，使用相应的软件包管理器。请查看特定软件包管理器的子页面以获取说明。
|
||||
|
||||
## 查看软件包
|
||||
|
||||
您可以在仓库页面上查看仓库的软件包。
|
||||
|
||||
1. 转到仓库主页。
|
||||
2. 在导航栏中选择**软件包**
|
||||
|
||||
要查看有关软件包的更多详细信息，请选择软件包的名称。
|
||||
|
||||
## 下载软件包
|
||||
|
||||
要从仓库下载软件包：
|
||||
|
||||
1. 在导航栏中选择**软件包**
|
||||
2. 选择软件包的名称以查看详细信息。
|
||||
3. 在 **Assets** 部分，选择要下载的软件包文件的名称。
|
||||
|
||||
## 删除软件包
|
||||
|
||||
在将软件包发布到软件包注册表后，您无法编辑软件包。相反，您必须删除并重新创建它。
|
||||
|
||||
要从仓库中删除软件包：
|
||||
|
||||
1. 在导航栏中选择**软件包**
|
||||
2. 选择软件包的名称以查看详细信息。
|
||||
3. 单击**删除软件包**以永久删除软件包。
|
||||
|
||||
## 禁用软件包注册表
|
||||
|
||||
包注册表已自动启用。要在单个存储库中禁用它：
|
||||
|
||||
1. 在导航栏中选择**设置**。
|
||||
2. 禁用**启用仓库软件包注册表**.
|
||||
|
||||
禁用软件包注册表不会删除先前发布的软件包。
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
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#通过-api-认证)。
|
||||
|
||||
## 发布软件包
|
||||
|
||||
要发布软件包，请编辑 `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
|
||||
# use latest version
|
||||
dart pub add mypackage --hosted-url=https://gitea.example.com/api/packages/testuser/pub/
|
||||
# specify version
|
||||
dart pub add mypackage:1.0.8 --hosted-url=https://gitea.example.com/api/packages/testuser/pub/
|
||||
```
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
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#通过-api-认证)替代密码 |
|
||||
|
||||
## 发布软件包
|
||||
|
||||
通过运行以下命令来发布软件包：
|
||||
|
||||
```shell
|
||||
python3 -m twine upload --repository gitea /path/to/files/*
|
||||
```
|
||||
|
||||
软件包文件的扩展名为 `.tar.gz` 和 `.whl`。
|
||||
|
||||
如果已存在具有相同名称和版本的软件包，则无法发布软件包。您必须先删除现有的软件包。
|
||||
|
||||
## 安装软件包
|
||||
|
||||
要从软件包注册表安装 PyPI 软件包，请执行以下命令：
|
||||
|
||||
```shell
|
||||
pip install --index-url https://{username}:{password}@gitea.example.com/api/packages/{owner}/pypi/simple --no-deps {package_name}
|
||||
```
|
||||
|
||||
| 参数 | 描述 |
|
||||
| -------------- | ----------------------------- |
|
||||
| `username` | 您的 Gitea 用户名 |
|
||||
| `password` | 您的 Gitea 密码或个人访问令牌 |
|
||||
| `owner` | 软件包的所有者 |
|
||||
| `package_name` | 软件包名称 |
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
pip install --index-url https://testuser:password123@gitea.example.com/api/packages/testuser/pypi/simple --no-deps test_package
|
||||
```
|
||||
|
||||
您可以使用 `--extra-index-url` 替代 `--index-url`，但这样会使您容易受到依赖混淆攻击，因为 `pip` 会先检查官方 PyPi 仓库中的软件包，然后再检查指定的自定义仓库。请阅读 `pip` 文档以获取更多信息。
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
pip install
|
||||
twine upload
|
||||
```
|
||||
@@ -1,115 +0,0 @@
|
||||
---
|
||||
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#通过-api-认证) |
|
||||
|
||||
例如：
|
||||
|
||||
```
|
||||
---
|
||||
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
|
||||
```
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
date: "2022-11-01T00:00:00+00:00"
|
||||
slug: "storage"
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# 存储
|
||||
|
||||
本文档描述了软件包注册表的存储方式以及如何管理存储。
|
||||
|
||||
## 去重
|
||||
|
||||
软件包注册表具有内置的去重功能，可以对上传的 Blob 进行去重处理。
|
||||
如果上传了两个相同的文件，只会在文件系统上保存一个 Blob。
|
||||
这样可以确保不会浪费空间用于重复的文件。
|
||||
|
||||
如果上传了两个具有相同文件的软件包，这两个软件包将显示相同的大小，但在文件系统上，它们只需要一半的大小。
|
||||
每当删除一个软件包时，只会删除对底层 Blob 的引用。
|
||||
此时，Blob 不会被删除，因此它们仍然占用文件系统上的空间。
|
||||
当上传新的软件包时，现有的 Blob 可能会再次被引用。
|
||||
|
||||
这些无引用的 Blob 会在一个清理任务中被删除。
|
||||
配置设置 `OLDER_THAN` 可以配置无引用的 Blob 在被删除之前保留的时间。
|
||||
|
||||
## 清理规则
|
||||
|
||||
软件包注册表可能会随着时间的推移而变得很大，如果不进行清理的话。
|
||||
建议删除不必要的软件包并设置清理规则以自动管理软件包注册表的使用情况。
|
||||
每个软件包所有者（用户或组织）都可以管理应用于其软件包的清理规则。
|
||||
|
||||
| 设置 | 描述 |
|
||||
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 启用 | 打开或关闭清理规则。 |
|
||||
| 类型 | 每个规则管理特定的软件包类型。 |
|
||||
| 将模式应用于完整的软件包名称 | 如果启用，则应用以下模式到完整的软件包名称（`package/version`），否则只使用版本号（`version`）。 |
|
||||
| 保留最近的版本数 | 对于每个软件包要始终保留的版本数量。 |
|
||||
| 保留与以下模式匹配的版本 | 确定要保留哪些版本的正则表达式模式。空模式表示不保留任何版本，而 `.+` 表示保留所有版本。即使未配置，容器注册表也始终保留 `latest` 版本。 |
|
||||
| 删除早于多少天的版本 | 仅删除早于所选天数的版本。 |
|
||||
| 删除与以下模式匹配的版本 | 确定要删除哪些版本的正则表达式模式。空模式或 `.+` 表示如果没有其他设置指定，则删除所有软件包。 |
|
||||
|
||||
每个清理规则都可以显示受影响的软件包的预览。
|
||||
这可以用来检查清理规则是否正确配置。
|
||||
|
||||
### 正则表达式示例
|
||||
|
||||
正则表达式模式会自动使用 `\A` 和 `\z` 锚点进行包围。
|
||||
不要在正则表达式模式中包含任何 `\A`、`\z`、`^` 或 `$` 标记，因为它们不是必要的。
|
||||
模式是不区分大小写的，与 Gitea 中的软件包注册表的行为相匹配。
|
||||
|
||||
| Pattern | Description |
|
||||
| ---------------------------- | ------------------------------------------------------------------------------------------------------------- |
|
||||
| `.*` | 匹配任何可能的版本。 |
|
||||
| `v.+` | 匹配以 `v` 开头的版本。 |
|
||||
| `release` | 仅匹配版本号为 `release`。 |
|
||||
| `release.*` | 匹配以 `release` 命名或以 `release` 开头的版本。 |
|
||||
| `.+-temp-.+` | 匹配包含 `-temp-` 的版本。 |
|
||||
| `v.+\|release` | 匹配以 `v` 开头的版本或版本号为 `release`。 |
|
||||
| `package/v.+\|other/release` | 匹配以 `v` 开头的 package 的版本或 `other` 的版本号为 `release`。需要启用*将模式应用于完整的软件包名称*设置。 |
|
||||
|
||||
### 清理规则的工作原理
|
||||
|
||||
清理规则是清理任务的一部分，定期运行。
|
||||
|
||||
清理规则：
|
||||
|
||||
1. 收集所有属于所有者注册表的特定软件包类型的软件包。
|
||||
2. 对于每个软件包，收集所有版本。
|
||||
3. 根据 *保留最近的版本数* 的值，从列表中排除版本。
|
||||
4. 根据 *保留与以下模式匹配的版本* 的值，从列表中排除任何版本。
|
||||
5. 根据 *删除早于多少天的版本* 的值，从列表中排除比这个值更近的版本。
|
||||
6. 根据 *删除与以下模式匹配的版本* 的值，从列表中排除任何不匹配的版本。
|
||||
7. 删除剩余的版本。
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
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 -login {username} -password {password}
|
||||
```
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `owner` | 软件包的所有者。 |
|
||||
| `username` | 您的 Gitea 用户名。 |
|
||||
| `password` | 您的 Gitea 密码。如果您使用两步验证或 OAuth，请使用[个人访问令牌](development/api-usage.md#通过-api-认证)代替密码。 |
|
||||
|
||||
登录是可选的，只有在软件包注册表是私有的情况下才需要。
|
||||
|
||||
## 发布软件包
|
||||
|
||||
首先，您需要打包软件包的内容：
|
||||
|
||||
```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 密码。如果您使用两步验证或 OAuth，请使用[个人访问令牌](development/api-usage.md#通过-api-认证)代替密码。 |
|
||||
| `owner` | 软件包的所有者。 |
|
||||
| `scope` | 软件包的作用域。 |
|
||||
| `name` | 软件包的名称。 |
|
||||
| `version` | 软件包的版本。 |
|
||||
| `metadata` | （可选）软件包的元数据。以 JSON 编码的子集，格式参考 https://schema.org/SoftwareSourceCode |
|
||||
|
||||
如果已经存在相同名称和版本的软件包，则无法发布软件包。您必须首先删除现有的软件包。
|
||||
|
||||
## 安装软件包
|
||||
|
||||
要从软件包注册表安装 Swift 软件包，请将其添加到 `Package.swift` 文件的依赖项列表中：
|
||||
|
||||
```
|
||||
dependencies: [
|
||||
.package(id: "{scope}.{name}", from:"{version}")
|
||||
]
|
||||
```
|
||||
|
||||
| 参数 | 描述 |
|
||||
| --------- | -------------- |
|
||||
| `scope` | 软件包的作用域 |
|
||||
| `name` | 软件包的名称 |
|
||||
| `version` | 软件包的版本 |
|
||||
|
||||
之后，执行以下命令来安装它：
|
||||
|
||||
```shell
|
||||
swift package resolve
|
||||
```
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
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) 并使用类似于 `curl` 的工具进行 HTTP 请求。
|
||||
|
||||
## 发布软件包
|
||||
|
||||
通过执行 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
|
||||
```
|
||||
|
||||
如果已经存在相同名称、版本和提供程序的软件包，则无法发布软件包。您必须首先删除现有的软件包。
|
||||
|
||||
## 安装软件包
|
||||
|
||||
要从软件包注册表安装软件包，请执行以下命令：
|
||||
|
||||
```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` 参数。
|
||||
如果注册表是私有的，您可以将您的[个人访问令牌](development/api-usage.md#通过-api-认证)传递给 `VAGRANT_CLOUD_TOKEN` 环境变量。
|
||||
|
||||
## 支持的命令
|
||||
|
||||
```
|
||||
vagrant box add
|
||||
```
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
date: "2016-12-27T16:00:00+02:00"
|
||||
title: "使用指南"
|
||||
slug: "usage"
|
||||
sidebar_position: 35
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "使用指南"
|
||||
sidebar_position: 30
|
||||
identifier: "usage"
|
||||
---
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "agit-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-cn/agit-setup
|
||||
---
|
||||
|
||||
# AGit 设置
|
||||
|
||||
在 Gitea `1.13` 版本中，添加了对 [agit](https://git-repo.info/zh/2020/03/agit-flow-and-git-repo/) 的支持。
|
||||
|
||||
## 使用 AGit 创建 PR
|
||||
|
||||
AGit 允许在推送代码到远程仓库时创建 PR（合并请求）。
|
||||
通过在推送时使用特定的 refspec（git 中已知的位置标识符），可以实现这一功能。
|
||||
下面的示例说明了这一点：
|
||||
|
||||
```shell
|
||||
git push origin HEAD:refs/for/master
|
||||
```
|
||||
|
||||
该命令的结构如下：
|
||||
|
||||
- `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，目标分支是 `master`：
|
||||
|
||||
```shell
|
||||
git push origin HEAD:refs/for/master -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"
|
||||
```
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "clone-filters"
|
||||
sidebar_position: 25
|
||||
aliases:
|
||||
- /zh-cn/clone-filters
|
||||
---
|
||||
|
||||
# 克隆过滤器 (部分克隆)
|
||||
|
||||
Git 引入了 `--filter` 选项用于 `git clone` 命令，该选项可以过滤掉大文件和对象（如 blob），从而创建一个仓库的部分克隆。克隆过滤器对于大型仓库和/或按流量计费的连接特别有用，因为完全克隆（不使用 `--filter`）可能会很昂贵（需要下载所有历史数据）。
|
||||
|
||||
这需要 Git 2.22 或更高版本，无论是在 Gitea 服务器上还是在客户端上都需要如此。为了使克隆过滤器正常工作，请确保客户端上的 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) 以获取更高级的用法（例如按文件大小过滤和取消过滤以将部分克隆转换为完全克隆）。
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "incoming-email"
|
||||
sidebar_position: 13
|
||||
aliases:
|
||||
- /zh-cn/incoming-email
|
||||
---
|
||||
|
||||
# 邮件接收
|
||||
|
||||
Gitea 支持通过接收邮件执行多种操作。本页面描述了如何进行设置。
|
||||
|
||||
## 要求
|
||||
|
||||
处理接收的电子邮件需要启用 IMAP 功能的电子邮件帐户。
|
||||
推荐的策略是使用 [电子邮件子地址](https://en.wikipedia.org/wiki/Email_address#Sub-addressing)，但也可以使用 catch-all 邮箱。
|
||||
接收电子邮件地址中包含一个用户/操作特定的令牌，告诉 Gitea 应执行哪个操作。
|
||||
此令牌应该出现在 `To` 和 `Delivered-To` 头字段中。
|
||||
|
||||
Gitea 会尝试检测自动回复并跳过它们，电子邮件服务器也应该配置以减少接收到的干扰（垃圾邮件、通讯订阅等）。
|
||||
|
||||
## 配置
|
||||
|
||||
要激活处理接收的电子邮件消息功能，您需要在配置文件中配置 `email.incoming` 部分。
|
||||
|
||||
`REPLY_TO_ADDRESS` 包含电子邮件客户端将要回复的地址。
|
||||
该地址需要包含 `%{token}` 占位符，该占位符将被替换为描述用户/操作的令牌。
|
||||
此占位符在地址中只能出现一次，并且必须位于地址的用户部分（`@` 之前）。
|
||||
|
||||
使用电子邮件子地址的示例可能如下：`incoming+%{token}@example.com`
|
||||
|
||||
如果使用 catch-all 邮箱，则占位符可以出现在地址的用户部分的任何位置：`incoming+%{token}@example.com`、`incoming_%{token}@example.com`、`%{token}@example.com`
|
||||
|
||||
## 安全性
|
||||
|
||||
在选择用于接收传入电子邮件的域时要小心。
|
||||
建议在子域名上接收传入电子邮件，例如 `incoming.example.com`，以防止与运行在 `example.com` 上的其他服务可能存在的安全问题。
|
||||
@@ -1,284 +0,0 @@
|
||||
---
|
||||
date: "2022-09-07T16:00:00+08:00"
|
||||
slug: "issue-pull-request-templates"
|
||||
sidebar_position: 15
|
||||
toc: true
|
||||
---
|
||||
|
||||
# 从模板创建工单与合并请求
|
||||
|
||||
开发者可以利用问题模板创建工单与合并请求，其目的在于规范参与者的语言表达。
|
||||
|
||||
## 模板介绍
|
||||
|
||||
Gitea 支持两种格式的模板：Markdown 和 YAML。
|
||||
|
||||
### Markdown 模板
|
||||
|
||||
在 Gitea 中存在两种用途的 Markdown 模板：
|
||||
|
||||
- `ISSUE_TEMPLATE/bug-report.md` 用于规范工单的 Markdown 文本描述
|
||||
- `PULL_REQUEST_TEMPLATE.md` 用于规范合并请求的 Markdown 文本描述
|
||||
|
||||
对于以上 Markdown 模板，我们推荐您将它们放置到项目目录 `.gitea` 进行收纳。
|
||||
|
||||
### YAML 模板
|
||||
|
||||
用 YAML 语法编写的模板相比 Markdown 可以实现更丰富的功能，利用表单实现诸如：问卷调查、字符校验。在 Gitea 中的 YAML 同样支持两种用途：
|
||||
|
||||
- `ISSUE_TEMPLATE/bug-report.yaml` 用于创建问卷调查形式的工单
|
||||
- `PULL_REQUEST_TEMPLATE.yaml` 用于创建表单形式的合并请求
|
||||
|
||||
对于以上 YAML 模板，我们同样推荐您将它们放置到项目目录 `.gitea` 进行收纳。
|
||||
|
||||
##### 表单支持通过 URL 查询参数传值
|
||||
|
||||
当新建工单页面 URL 以 `?title=Issue+Title&body=Issue+Text` 为查询参数，表单将使用其中的参数（key-value）填充表单内容。
|
||||
|
||||
### Gitea 支持的模板文件路径
|
||||
|
||||
工单模板文件名:
|
||||
|
||||
- `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`
|
||||
|
||||
合并请求模板:
|
||||
|
||||
- `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`
|
||||
|
||||
#### 工单模板目录
|
||||
|
||||
由于工单存在多种类型，Gitea 支持将工单模板统一收纳到 `ISSUE_TEMPLATE` 目录。以下是 Gitea 支持的工单模板目录:
|
||||
|
||||
- `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: "Template Name"
|
||||
about: "This template is for testing!"
|
||||
title: "[TEST] "
|
||||
ref: "main"
|
||||
labels:
|
||||
|
||||
- bug
|
||||
- "help needed"
|
||||
|
||||
---
|
||||
|
||||
This is the template!
|
||||
```
|
||||
|
||||
上面的示例表示用户从列表中选择一个工单模板时，列表会展示模板名称 `Template Name` 和模板描述 `This template is for testing!`。 同时，标题会预先填充为 `[TEST]`，而正文将预先填充 `This is the template!`。 最后，Issue 还会被分配两个标签，`bug` 和 `help needed`，并且将问题指向 `main` 分支。
|
||||
|
||||
## YAML 模板语法
|
||||
|
||||
YAML 模板格式如下，相比 Markdown 模板提供了更多实用性的功能。
|
||||
|
||||
```yaml
|
||||
name: 表单名称
|
||||
about: 表单描述
|
||||
title: 默认标题
|
||||
body: 主体内容
|
||||
type: 定义表单元素类型
|
||||
id: 定义表单标号
|
||||
attributes: 扩展的属性
|
||||
validations: 内容校验
|
||||
```
|
||||
|
||||
下例 YAML 配置文件完整定义了一个用于提交 bug 的问卷调查。
|
||||
|
||||
```yaml
|
||||
name: Bug Report
|
||||
about: File a bug report
|
||||
title: "[Bug]: "
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
Thanks for taking the time to fill out this bug report!
|
||||
- type: input
|
||||
id: contact
|
||||
attributes:
|
||||
label: Contact Details
|
||||
description: How can we get in touch with you if we need more info?
|
||||
placeholder: ex. email@example.com
|
||||
validations:
|
||||
required: false
|
||||
- type: textarea
|
||||
id: what-happened
|
||||
attributes:
|
||||
label: What happened?
|
||||
description: Also tell us, what did you expect to happen?
|
||||
placeholder: Tell us what you see!
|
||||
value: "A bug happened!"
|
||||
validations:
|
||||
required: true
|
||||
- type: dropdown
|
||||
id: version
|
||||
attributes:
|
||||
label: Version
|
||||
description: What version of our software are you running?
|
||||
options:
|
||||
- 1.0.2 (Default)
|
||||
- 1.0.3 (Edge)
|
||||
validations:
|
||||
required: true
|
||||
- type: dropdown
|
||||
id: browsers
|
||||
attributes:
|
||||
label: What browsers are you seeing the problem on?
|
||||
multiple: true
|
||||
options:
|
||||
- Firefox
|
||||
- Chrome
|
||||
- Safari
|
||||
- Microsoft Edge
|
||||
- type: textarea
|
||||
id: logs
|
||||
attributes:
|
||||
label: Relevant log output
|
||||
description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
|
||||
render: shell
|
||||
- type: checkboxes
|
||||
id: terms
|
||||
attributes:
|
||||
label: Code of Conduct
|
||||
description: By submitting this issue, you agree to follow our [Code of Conduct](https://example.com)
|
||||
options:
|
||||
- label: I agree to follow this project's Code of Conduct
|
||||
required: true
|
||||
```
|
||||
|
||||
### Markdown 段落
|
||||
|
||||
您可以在 YAML 模板中使用 `markdown` 元素为开发者提供额外的上下文支撑，这部分内容会作为创建工单的提示但不会作为工单内容提交。
|
||||
|
||||
`attributes` 子项提供了以下扩展能力：
|
||||
|
||||
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
|
||||
| ------- | ------------------------------ | ---- | ------ | ------ | ------ |
|
||||
| `value` | 渲染的文本。支持 Markdown 格式 | 必选 | 字符串 | - | - |
|
||||
|
||||
### Textarea 多行文本输入框
|
||||
|
||||
您可以使用 `textarea` 元素在表单中添加多行文本输入框。 除了输入文本，开发者还可以在 `textarea` 区域附加文件。
|
||||
|
||||
`attributes` 子项提供了以下扩展能力：
|
||||
|
||||
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
|
||||
| ------------- | ----------------------------------------------------------------------------------------------------- | ---- | ------ | -------- | ------------------ |
|
||||
| `label` | 预期用户输入的简短描述，也以表单形式显示。 | 必选 | 字符串 | - | - |
|
||||
| `description` | 提供上下文或指导的文本区域的描述，以表单形式显示。 | 可选 | 字符串 | 空字符串 | - |
|
||||
| `placeholder` | 半透明的占位符，在文本区域空白时呈现 | 可选 | 字符串 | 空字符串 | - |
|
||||
| `value` | 在文本区域中预填充的文本。 | 可选 | 字符串 | - | - |
|
||||
| `render` | 如果提供了值，提交的文本将格式化为代码块。 提供此键时，文本区域将不会扩展到文件附件或 Markdown 编辑。 | 可选 | 字符串 | - | Gitea 支持的语言。 |
|
||||
|
||||
`validations` 子项提供以下文本校验参数：
|
||||
|
||||
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
|
||||
| ---------- | ---------------------------- | ---- | ------ | ------ | ------ |
|
||||
| `required` | 防止在元素完成之前提交表单。 | 可选 | 布尔型 | false | - |
|
||||
|
||||
### Input 单行输入框
|
||||
|
||||
您可以使用 `input` 元素添加单行文本字段到表单。
|
||||
|
||||
`attributes` 子项提供了以下扩展能力：
|
||||
|
||||
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
|
||||
| ------------- | ---------------------------------------------- | ---- | ------ | -------- | ------ |
|
||||
| `label` | 预期用户输入的简短描述，也以表单形式显示。 | 必选 | 字符串 | - | - |
|
||||
| `description` | 提供上下文或指导的字段的描述，以表单形式显示。 | 可选 | 字符串 | 空字符串 | - |
|
||||
| `placeholder` | 半透明的占位符，在字段空白时呈现。 | 可选 | 字符串 | 空字符串 | - |
|
||||
| `value` | 字段中预填的文本。 | 可选 | 字符串 | - | - |
|
||||
|
||||
`validations` 子项提供以下文本校验参数：
|
||||
|
||||
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
|
||||
| ----------- | -------------------------------- | ---- | ------ | ------ | -------------------------------------------------------------- |
|
||||
| `required` | 防止在未填内容时提交表单。 | 可选 | 布尔型 | false | - |
|
||||
| `is_number` | 防止在未填数字时提交表单。 | 可选 | 布尔型 | false | - |
|
||||
| `regex` | 直到满足了与正则表达式匹配的值。 | 可选 | 字符串 | - | [正则表达式](https://en.wikipedia.org/wiki/Regular_expression) |
|
||||
|
||||
### Dropdown 下拉菜单
|
||||
|
||||
您可以使用 `dropdown` 元素在表单中添加下拉菜单。
|
||||
|
||||
`attributes` 子项提供了以下扩展能力：
|
||||
|
||||
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
|
||||
| ------------- | --------------------------------------------------------- | ---- | ---------- | -------- | ------ |
|
||||
| `label` | 预期用户输入的简短描述，以表单形式显示。 | 必选 | 字符串 | - | - |
|
||||
| `description` | 提供上下文或指导的下拉列表的描述，以表单形式显示。 | 可选 | 字符串 | 空字符串 | - |
|
||||
| `multiple` | 确定用户是否可以选择多个选项。 | 可选 | 布尔型 | false | - |
|
||||
| `options` | 用户可以选择的选项列表。 不能为空，所有选择必须是不同的。 | 必选 | 字符串数组 | - | - |
|
||||
|
||||
`validations` 子项提供以下文本校验参数：
|
||||
|
||||
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
|
||||
| ---------- | ---------------------------- | ---- | ------ | ------ | ------ |
|
||||
| `required` | 防止在元素完成之前提交表单。 | 可选 | 布尔型 | false | - |
|
||||
|
||||
### Checkboxes 复选框
|
||||
|
||||
您可以使用 `checkboxes` 元素添加一组复选框到表单。
|
||||
|
||||
`attributes` 子项提供了以下扩展能力：
|
||||
|
||||
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
|
||||
| ------------- | ----------------------------------------------------- | ---- | ------ | -------- | ------ |
|
||||
| `label` | 预期用户输入的简短描述，以表单形式显示。 | 必选 | 字符串 | - | - |
|
||||
| `description` | 复选框集的描述，以表单形式显示。 支持 Markdown 格式。 | 可选 | 字符串 | 空字符串 | - |
|
||||
| `options` | 用户可以选择的复选框列表。 有关语法，请参阅下文。 | 必选 | 数组 | - | - |
|
||||
|
||||
对于 `options`，您可以设置以下参数：
|
||||
|
||||
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
|
||||
| ---------- | --------------------------------------------------------------------------------- | ---- | ------ | ------ | ------ |
|
||||
| `label` | 选项的标识符，显示在表单中。 支持 Markdown 用于粗体或斜体文本格式化和超文本链接。 | 必选 | 字符串 | - | - |
|
||||
| `required` | 防止在元素完成之前提交表单。 | 可选 | 布尔型 | false | - |
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "labels"
|
||||
sidebar_position: 13
|
||||
aliases:
|
||||
- /zh-cn/labels
|
||||
---
|
||||
|
||||
# 标签
|
||||
|
||||
您可以使用标签对工单和合并请求进行分类，并提高对它们的概览。
|
||||
|
||||
## 创建标签
|
||||
|
||||
对于仓库，可以在 `工单（Issues）` 中点击 `标签（Labels）` 来创建标签。
|
||||
|
||||
对于组织，您可以定义组织级别的标签，这些标签与所有组织仓库共享，包括已存在的仓库和新创建的仓库。可以在组织的 `设置（Settings）` 中创建组织级别的标签。
|
||||
|
||||
标签具有必填的名称和颜色，可选的描述，以及必须是独占的或非独占的（见下面的“作用域标签”）。
|
||||
|
||||
当您创建一个仓库时，可以通过使用 `工单标签（Issue Labels）` 选项来选择标签集。该选项列出了一些在您的实例上 [全局配置的可用标签集](../administration/customizing-gitea.md#labels)。在创建仓库时，这些标签也将被创建。
|
||||
|
||||
## 作用域标签
|
||||
|
||||
作用域标签用于确保将至多一个具有相同作用域的标签分配给工单或合并请求。例如，如果标签 `kind/bug` 和 `kind/enhancement` 的独占选项被设置，那么工单只能被分类为 bug 或 enhancement 中的一个。
|
||||
|
||||
作用域标签的名称必须包含 `/`（不能在名称的任一端）。标签的作用域是基于最后一个 `/` 决定的，因此例如标签 `scope/subscope/item` 的作用域是 `scope/subscope`。
|
||||
|
||||
## 按标签筛选
|
||||
|
||||
工单和合并请求列表可以按标签进行筛选。选择多个标签将显示具有所有选定标签的工单和合并请求。
|
||||
|
||||
通过按住 alt 键并单击标签，可以将具有所选标签的工单和合并请求从列表中排除。
|
||||
@@ -1,143 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "automatically-linked-references"
|
||||
sidebar_position: 15
|
||||
aliases:
|
||||
- /zh-cn/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)。
|
||||
|
||||
示例：
|
||||
|
||||
> 这个合并请求 _closes_ [#1234](#)
|
||||
|
||||
如果可操作的引用被接受，这将在被引用的工单上创建一个通知，宣布当引用的合并请求被合并时该工单将被关闭。
|
||||
|
||||
为了接受可操作的引用，必须满足以下至少一项条件之一：
|
||||
|
||||
- 评论者在创建引用时具有关闭或重新打开工单的权限。
|
||||
- 引用位于提交消息中。
|
||||
- 引用作为合并请求描述的一部分发布。
|
||||
|
||||
在最后一种情况下，只有当合并合并请求的人具有相应权限时，工单才会被关闭或重新打开。
|
||||
|
||||
此外，只有合并请求和提交消息可以创建一个操作，只有工单可以通过这种方式被关闭或重新打开。
|
||||
|
||||
默认的关键字如下：
|
||||
|
||||
- **关闭工单**: 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 小时半。
|
||||
|
||||
## 外部跟踪器
|
||||
|
||||
Gitea 支持使用外部工单跟踪器，并可以在合并请求中创建对外部托管的工单的引用。但是，如果外部跟踪器使用数字来标识工单，那么它们将与 Gitea 中托管的合并请求无法区分。为了解决这个工单，Gitea 允许使用 `!` 标记来标识合并请求。例如：
|
||||
|
||||
> 这是工单 [#1234](#)，并链接到外部跟踪器。
|
||||
> 这是合并请求 [!1234](#)，并链接到 Gitea 中的合并请求。
|
||||
|
||||
在工单和合并请求中，`!` 和 `#` 可以互换使用，除非需要进行区分。如果仓库使用外部跟踪器，默认情况下，合并提交消息将使用 `!` 作为引用。
|
||||
|
||||
## 工单和合并请求引用摘要
|
||||
|
||||
下表说明了工单和合并请求的不同类型的交叉引用。在示例中，`User1/Repo1` 指的是使用引用的仓库，而 `UserZ/RepoZ` 表示另一个仓库。
|
||||
|
||||
| 在 User1/Repo1 中的引用 | Repo1 的工单是外部的 | RepoZ 的工单是外部的 | 渲染效果 |
|
||||
| ----------------------- | :------------------: | :------------------: | --------------------------------------------- |
|
||||
| `#1234` | 否 | - | 链接到 `User1/Repo1` 中的工单/合并请求 1234 |
|
||||
| `!1234` | 否 | - | 链接到 `User1/Repo1` 中的工单/合并请求 1234 |
|
||||
| `#1234` | 是 | - | 链接到 `User1/Repo1` 的 _外部工单_ 1234 |
|
||||
| `!1234` | 是 | - | 链接到 `User1/Repo1` 的 _PR_ 1234 |
|
||||
| `User1/Repo1#1234` | 否 | - | 链接到 `User1/Repo1` 中的工单/合并请求 1234 |
|
||||
| `User1/Repo1!1234` | 否 | - | 链接到 `User1/Repo1` 中的工单/合并请求 1234 |
|
||||
| `User1/Repo1#1234` | 是 | - | 链接到 `User1/Repo1` 的 _外部工单_ 1234 |
|
||||
| `User1/Repo1!1234` | 是 | - | 链接到 `User1/Repo1` 的 _PR_ 1234 |
|
||||
| `UserZ/RepoZ#1234` | - | 否 | 链接到 `UserZ/RepoZ` 中的工单/合并请求 1234 |
|
||||
| `UserZ/RepoZ!1234` | - | 否 | 链接到 `UserZ/RepoZ` 中的工单/合并请求 1234 |
|
||||
| `UserZ/RepoZ#1234` | - | 是 | 链接到 `UserZ/RepoZ` 的 _外部工单_ 1234 |
|
||||
| `UserZ/RepoZ!1234` | - | 是 | 链接到 `UserZ/RepoZ` 的 _PR_ 1234 |
|
||||
| **字母数字工单编号:** | - | - | - |
|
||||
| `AAA-1234` | 是 | - | 链接到 `User1/Repo1` 的 _外部工单_ `AAA-1234` |
|
||||
| `!1234` | 是 | - | 链接到 `User1/Repo1` 的 _PR_ 1234 |
|
||||
| `User1/Repo1!1234` | 是 | - | 链接到 `User1/Repo1` 的 _PR_ 1234 |
|
||||
| _不支持_ | - | 是 | 链接到 `UserZ/RepoZ` 的 _外部工单_ `AAA-1234` |
|
||||
| `UserZ/RepoZ!1234` | - | 是 | 链接到 `UserZ/RepoZ` 中的 _PR_ 1234 |
|
||||
|
||||
_最后一部分适用于使用字母数字格式的外部工单跟踪器的仓库。_
|
||||
|
||||
_**-**: 不适用_
|
||||
|
||||
注意：不完全支持具有不同类型工单（外部 vs. 内部）的仓库之间的自动引用，可能会导致无效链接。
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "merge-message-templates"
|
||||
sidebar_position: 15
|
||||
aliases:
|
||||
- /zh-cn/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`
|
||||
|
||||
## 变基（Rebase）
|
||||
|
||||
在没有合并提交的情况下进行变基时，`REBASE_TEMPLATE.md` 修改最后一次提交的消息。此模板还提供以下附加变量：
|
||||
|
||||
- CommitTitle：提交的标题
|
||||
- CommitBody：提交的正文文本
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "permissions"
|
||||
sidebar_position: 14
|
||||
aliases:
|
||||
- /zh-cn/permissions
|
||||
---
|
||||
|
||||
# 权限
|
||||
|
||||
Gitea 支持对仓库进行权限管理，这样您就可以为不同的人员提供不同的访问权限。首先，我们需要了解 `单元（Unit）`。
|
||||
|
||||
## 单元（Unit）
|
||||
|
||||
在 Gitea 中，我们将仓库的子模块称为 `单元（Unit）`。现在我们有以下几个单元。
|
||||
|
||||
| 名称 | 描述 | 权限 |
|
||||
| -------------- | ------------------------------ | --------- |
|
||||
| 代码 | 访问源代码、文件、提交和分支。 | 读取 写入 |
|
||||
| 工单 | 组织缺陷报告、任务和里程碑。 | 读取 写入 |
|
||||
| 合并请求 | 启用合并请求和代码审核。 | 读取 写入 |
|
||||
| 发布 | 跟踪项目版本和下载。 | 读取 写入 |
|
||||
| 维基 | 与协作者编写和共享文档。 | 读取 写入 |
|
||||
| 外部维基 | 链接到外部维基。 | 读取 |
|
||||
| 外部工单跟踪器 | 链接到外部工单跟踪器。 | 读取 |
|
||||
| 项目 | 模板仓库的 URL。 | 读取 写入 |
|
||||
| 设置 | 管理仓库。 | 管理员 |
|
||||
|
||||
通过不同的权限，用户可以在这些单元上执行不同的操作。
|
||||
|
||||
| 名称 | 读取 | 写入 | 管理员 |
|
||||
| -------------- | -------------------------------- | ------------------------------ | -------- |
|
||||
| 代码 | 查看代码树、文件、提交、分支等。 | 推送代码。 | - |
|
||||
| 工单 | 查看工单并创建新工单。 | 添加标签、分配、关闭工单。 | - |
|
||||
| 合并请求 | 查看合并请求并创建新合并请求。 | 添加标签、分配、关闭合并请求。 | - |
|
||||
| 发布 | 查看发布和下载文件。 | 创建/编辑发布。 | - |
|
||||
| 维基 | 查看维基页面。克隆维基仓库。 | 创建/编辑维基页面，推送更改。 | - |
|
||||
| 外部维基 | 链接到外部维基。 | - | - |
|
||||
| 外部工单跟踪器 | 链接到外部工单跟踪器。 | - | - |
|
||||
| 项目 | 查看面板。 | 在面板之间移动工单。 | - |
|
||||
| 设置 | - | - | 管理仓库 |
|
||||
|
||||
个人仓库和组织仓库之间的权限存在一些差异。
|
||||
|
||||
## 个人仓库
|
||||
|
||||
对于个人仓库，创建者是仓库的唯一所有者，对于该仓库的任何更改或删除没有限制。仓库所有者可以添加协作者来帮助维护仓库。协作者可以拥有 `读取（Read）`、`写入（Write）` 和 `管理员（Admin）` 权限。
|
||||
|
||||
## 组织仓库
|
||||
|
||||
与个人仓库不同，组织仓库的所有者是组织的所有者团队。
|
||||
|
||||
### 团队
|
||||
|
||||
组织中的一个团队具有单元权限设置。它可以拥有成员和仓库的范围。团队可以访问组织中的所有仓库或者由所有者团队授权访问的特定仓库。团队也可以被允许创建新的仓库。
|
||||
|
||||
所有者团队（Owners）将在创建组织时自动创建，并且创建者将成为所有者团队的第一个成员。
|
||||
组织的每个成员必须至少属于一个团队。所有者团队不能被删除，只有所有者团队的成员可以创建新的团队。可以创建一个管理员团队来管理某些仓库，该团队的成员可以对这些仓库进行任何操作。可以由所有者团队创建一个生成团队来执行其权限允许的操作。
|
||||
@@ -1,11 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "profile-readme"
|
||||
sidebar_position: 12
|
||||
---
|
||||
|
||||
# 个人资料 README
|
||||
|
||||
要在您的 Gitea 个人资料页面显示一个 Markdown 文件，只需创建一个名为 ".profile" 的仓库，并编辑其中的 README.md 文件。Gitea 将自动获取该文件并在您的仓库上方显示。
|
||||
|
||||
注意：您可以将此仓库设为私有。这样可以隐藏您的源文件，使其对公众不可见，并允许您将某些文件设为私有。但是，README.md 文件将是您个人资料上唯一存在的文件。如果您希望完全私有化 .profile 仓库，则需删除或重命名 README.md 文件。
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "protected-tags"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-cn/protected-tags
|
||||
---
|
||||
|
||||
# 受保护的标签
|
||||
|
||||
受保护的标签允许控制谁有权限创建或更新 Git 标签。每个规则可以匹配单个标签名称，或者使用适当的模式来同时控制多个标签。
|
||||
|
||||
## 设置受保护的标签
|
||||
|
||||
要保护一个标签，你需要按照以下步骤进行操作：
|
||||
|
||||
1. 进入仓库的**设置** > **标签**页面。
|
||||
2. 输入一个用于匹配名称的模式。你可以使用单个名称、[glob 模式](https://pkg.go.dev/github.com/gobwas/glob#Compile) 或正则表达式。
|
||||
3. 选择允许的用户和/或团队。如果将这些字段留空，则不允许任何人创建或修改此标签。
|
||||
4. 选择**保存**以保存配置。
|
||||
|
||||
## 模式受保护的标签
|
||||
|
||||
该模式使用 [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 | `/.+/` | 匹配所有可能的标签名称 |
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
date: "2018-06-01T19:00:00+02:00"
|
||||
slug: "pull-request"
|
||||
sidebar_position: 13
|
||||
---
|
||||
|
||||
# 合并请求
|
||||
|
||||
## 在合并请求中使用“Work In Progress”标记
|
||||
|
||||
您可以通过在一个进行中的 pull request 的标题上添加前缀 `WIP:` 或者 `[WIP]`（此处大小写敏感）来防止它被意外合并，具体的前缀设置可以在配置文件 `app.ini` 中找到：
|
||||
|
||||
```
|
||||
[repository.pull-request]
|
||||
WORK_IN_PROGRESS_PREFIXES=WIP:,[WIP]
|
||||
```
|
||||
|
||||
列表的第一个值将用于 helpers 程序。
|
||||
|
||||
## 合并请求模板
|
||||
|
||||
有关合并请求模板的更多信息请您移步 : [工单和合并请求模板](issue-pull-request-templates)
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "push"
|
||||
sidebar_position: 15
|
||||
aliases:
|
||||
- /zh-cn/push-to-create
|
||||
- /zh-cn/push-options
|
||||
---
|
||||
|
||||
# 推送
|
||||
|
||||
在将提交推送到 Gitea 服务器时，还有一些额外的功能。
|
||||
|
||||
## 通过推送打开 PR
|
||||
|
||||
当您第一次将提交推送到非默认分支时，您将收到一个链接，您可以单击该链接访问分支与主分支的比较页面。
|
||||
从那里，您可以轻松创建一个拉取请求，即使您想要将其目标指向另一个分支。
|
||||
|
||||
|
||||
|
||||
## 推送选项
|
||||
|
||||
在 Gitea `1.13` 版本中，添加了对一些 [推送选项](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt) 的支持。
|
||||
|
||||
### 支持的选项
|
||||
|
||||
- `repo.private` (true|false) - 更改仓库的可见性。
|
||||
|
||||
这在与 push-to-create 结合使用时特别有用。
|
||||
|
||||
- `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#仓库) 中了解有关这两个选项的更多信息。
|
||||
|
||||
### 使用推送创建
|
||||
|
||||
假设您在当前目录中有一个 git 仓库，您可以通过运行以下命令将提交推送到在 Gitea 中尚不存在的仓库：
|
||||
|
||||
```shell
|
||||
# 添加要推送到的远程仓库
|
||||
git remote add origin git@{domain}:{username}/{尚不存在的仓库名称}.git
|
||||
|
||||
# 推送到远程仓库
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
这假设您使用的是 SSH 远程，但您也可以使用 HTTPS 远程。
|
||||
|
||||
推送创建将默认使用 `app.ini` 中定义的可见性 `DEFAULT_PUSH_CREATE_PRIVATE`。
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "repo-mirror"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-cn/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. 创建一个具有选中 _public_repo_ 选项的 [GitHub 个人访问令牌](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token)。
|
||||
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. 创建具有 _write_repository_ 作用域的 [GitLab 个人访问令牌](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)。
|
||||
2. 填写**Git 远程仓库 URL**：`https://<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`。
|
||||
3. 在**授权**字段中填写 `oauth2` 作为**用户名**，并将您的 GitLab 个人访问令牌作为**密码**。
|
||||
4. 选择**添加推送镜像**以保存配置。
|
||||
|
||||
仓库会很快进行推送。要强制推送，请选择**立即同步**按钮。
|
||||
|
||||
### 从 Gitea 向 Bitbucket 设置推送镜像
|
||||
|
||||
要从 Gitea 设置镜像到 Bitbucket，您需要按照以下步骤进行操作：
|
||||
|
||||
1. 创建一个具有选中 _Repository Write_ 选项的 [Bitbucket 应用密码](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/)。
|
||||
2. 填写**Git 远程仓库 URL**：`https://bitbucket.org/<your_bitbucket_group_or_name>/<your_bitbucket_project>.git`。
|
||||
3. 使用您的 Bitbucket 用户名填写**授权**字段，并将应用密码作为**密码**。
|
||||
4. 选择**添加推送镜像**以保存配置。
|
||||
|
||||
仓库会很快进行推送。要强制推送，请选择**立即同步**按钮。
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "secrets"
|
||||
sidebar_position: 50
|
||||
aliases:
|
||||
- /zh-cn/secrets
|
||||
---
|
||||
|
||||
# 密钥管理
|
||||
|
||||
密钥管理允许您在用户、组织或仓库中存储敏感信息。
|
||||
密钥管理在 Gitea 1.19+ 版本中可用。
|
||||
|
||||
## 设置密钥名称
|
||||
|
||||
以下规则适用于密钥名称：
|
||||
|
||||
- 密钥名称只能包含字母数字字符 (`[a-z]`, `[A-Z]`, `[0-9]`) 或下划线 (`_`)。不允许使用空格。
|
||||
|
||||
- 密钥名称不能以 `GITHUB_` 和 `GITEA_` 前缀开头。
|
||||
|
||||
- 密钥名称不能以数字开头。
|
||||
|
||||
- 密钥名称不区分大小写。
|
||||
|
||||
- 密钥名称在创建它们的级别上必须是唯一的。
|
||||
|
||||
例如，对于在仓库级别创建的密钥，它在该仓库中必须具有唯一的名称；对于在组织级别创建的密钥，它在该级别上必须具有唯一的名称。
|
||||
|
||||
如果在多个级别上存在具有相同名称的密钥，则最低级别的密钥优先生效。例如，如果组织级别的密钥与仓库级别的密钥具有相同的名称，则仓库级别的密钥将优先生效。
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "template-repositories"
|
||||
sidebar_position: 14
|
||||
aliases:
|
||||
- /zh-cn/template-repositories
|
||||
---
|
||||
|
||||
# 模板仓库
|
||||
|
||||
Gitea `1.11.0` 及以上版本引入了模板仓库，并且其中一个实现的功能是自动展开模板文件中的特定变量。
|
||||
|
||||
要告诉 Gitea 哪些文件需要展开，您必须在模板仓库的 `.gitea` 目录中包含一个 `template` 文件。
|
||||
|
||||
Gitea 使用 [gobwas/glob](https://github.com/gobwas/glob) 作为其 glob 语法。它与传统的 `.gitignore` 语法非常相似，但可能存在细微的差异。
|
||||
|
||||
## `.gitea/template` 文件示例
|
||||
|
||||
所有路径都是相对于仓库的根目录
|
||||
|
||||
```gitignore
|
||||
# 仓库中的所有 .go 文件
|
||||
**.go
|
||||
|
||||
# text 目录中的所有文本文件
|
||||
text/*.txt
|
||||
|
||||
# 特定文件
|
||||
a/b/c/d.json
|
||||
|
||||
# 匹配批处理文件的大小写变体
|
||||
**.[bB][aA][tT]
|
||||
```
|
||||
|
||||
**注意：** 当从模板生成仓库时，`.gitea` 目录中的 `template` 文件将被删除。
|
||||
|
||||
## 参数展开
|
||||
|
||||
在与上述通配符匹配的任何文件中，将会扩展某些变量。
|
||||
|
||||
所有变量都必须采用`$VAR`或`${VAR}`的形式。要转义扩展，使用双重`$$`，例如`$$VAR`或`$${VAR}`。
|
||||
|
||||
| 变量 | 扩展为 | 可转换 |
|
||||
| -------------------- | ----------------------------- | ------ |
|
||||
| REPO_NAME | 生成的仓库名称 | ✓ |
|
||||
| TEMPLATE_NAME | 模板仓库名称 | ✓ |
|
||||
| REPO_DESCRIPTION | 生成的仓库描述 | ✘ |
|
||||
| TEMPLATE_DESCRIPTION | 模板仓库描述 | ✘ |
|
||||
| REPO_OWNER | 生成的仓库所有者 | ✓ |
|
||||
| TEMPLATE_OWNER | 模板仓库所有者 | ✓ |
|
||||
| REPO_LINK | 生成的仓库链接 | ✘ |
|
||||
| TEMPLATE_LINK | 模板仓库链接 | ✘ |
|
||||
| REPO_HTTPS_URL | 生成的仓库的 HTTP(S) 克隆链接 | ✘ |
|
||||
| TEMPLATE_HTTPS_URL | 模板仓库的 HTTP(S) 克隆链接 | ✘ |
|
||||
| REPO_SSH_URL | 生成的仓库的 SSH 克隆链接 | ✘ |
|
||||
| TEMPLATE_SSH_URL | 模板仓库的 SSH 克隆链接 | ✘ |
|
||||
|
||||
## 转换器 :robot:
|
||||
|
||||
Gitea `1.12.0` 添加了一些转换器以应用于上述适用的变量。
|
||||
|
||||
例如，要以 `PASCAL`-case 获取 `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 |
|
||||
@@ -1,183 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "webhooks"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
# Webhooks
|
||||
|
||||
Gitea支持用于仓库事件的Webhooks。这可以在仓库管理员在设置页面 `/:username/:reponame/settings/hooks` 中进行配置。Webhooks还可以基于组织和整个系统进行配置。
|
||||
所有事件推送都是 POST 请求。目前支持：
|
||||
|
||||
- Gitea (也可以是 GET 请求)
|
||||
- Gogs
|
||||
- Slack
|
||||
- Discord
|
||||
- Dingtalk（钉钉）
|
||||
- Telegram
|
||||
- Microsoft Teams
|
||||
- Feishu
|
||||
- Wechatwork（企业微信）
|
||||
- Packagist
|
||||
|
||||
### 事件信息
|
||||
|
||||
**警告**：自 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": "someone@gitea.io",
|
||||
"username": "gitea"
|
||||
},
|
||||
"committer": {
|
||||
"name": "Gitea",
|
||||
"email": "someone@gitea.io",
|
||||
"username": "gitea"
|
||||
},
|
||||
"timestamp": "2017-03-13T13:52:11-04:00"
|
||||
}
|
||||
],
|
||||
"repository": {
|
||||
"id": 140,
|
||||
"owner": {
|
||||
"id": 1,
|
||||
"login": "gitea",
|
||||
"full_name": "Gitea",
|
||||
"email": "someone@gitea.io",
|
||||
"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": "someone@gitea.io",
|
||||
"avatar_url": "https://localhost:3000/avatars/1",
|
||||
"username": "gitea"
|
||||
},
|
||||
"sender": {
|
||||
"id": 1,
|
||||
"login": "gitea",
|
||||
"full_name": "Gitea",
|
||||
"email": "someone@gitea.io",
|
||||
"avatar_url": "https://localhost:3000/avatars/1",
|
||||
"username": "gitea"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 示例
|
||||
|
||||
这是一个示例，演示如何使用 Webhooks 在推送请求到达仓库时运行一个 php 脚本。
|
||||
在你的仓库设置中，在 Webhooks 下，设置一个如下的 Gitea webhook：
|
||||
|
||||
- 目标 URL：http://mydomain.com/webhook.php
|
||||
- HTTP 方法：POST
|
||||
- POST Content Type：application/json
|
||||
- Secret：123
|
||||
- 触发条件：推送事件
|
||||
- 激活：勾选
|
||||
|
||||
现在在你的服务器上创建 php 文件 webhook.php。
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
$secret_key = '123';
|
||||
|
||||
// check for POST request
|
||||
if ($_SERVER['REQUEST_METHOD'] != 'POST') {
|
||||
error_log('FAILED - not POST - '. $_SERVER['REQUEST_METHOD']);
|
||||
exit();
|
||||
}
|
||||
|
||||
// get content type
|
||||
$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();
|
||||
}
|
||||
|
||||
// get payload
|
||||
$payload = trim(file_get_contents("php://input"));
|
||||
|
||||
if (empty($payload)) {
|
||||
error_log('FAILED - no payload');
|
||||
exit();
|
||||
}
|
||||
|
||||
// get header signature
|
||||
$header_signature = isset($_SERVER['HTTP_X_GITEA_SIGNATURE']) ? $_SERVER['HTTP_X_GITEA_SIGNATURE'] : '';
|
||||
|
||||
if (empty($header_signature)) {
|
||||
error_log('FAILED - header signature missing');
|
||||
exit();
|
||||
}
|
||||
|
||||
// calculate payload signature
|
||||
$payload_signature = hash_hmac('sha256', $payload, $secret_key, false);
|
||||
|
||||
// check payload signature against header signature
|
||||
if ($header_signature !== $payload_signature) {
|
||||
error_log('FAILED - payload signature');
|
||||
exit();
|
||||
}
|
||||
|
||||
// convert json to array
|
||||
$decoded = json_decode($payload, true);
|
||||
|
||||
// check for json decode errors
|
||||
if (json_last_error() !== JSON_ERROR_NONE) {
|
||||
error_log('FAILED - json decode - '. json_last_error());
|
||||
exit();
|
||||
}
|
||||
|
||||
// success, do something
|
||||
```
|
||||
|
||||
在 Webhook 设置中有一个“测试推送（Test Delivery）”按钮，可以测试配置，还有一个“最近推送记录（Recent Deliveries）”的列表。
|
||||
|
||||
### 授权头（Authorization header）
|
||||
|
||||
**从1.19版本开始**，Gitea 的 Webhook 可以配置为向 Webhook 目标发送一个 [授权头（authorization header）](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization)。
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
title: "运维"
|
||||
slug: "administration"
|
||||
sidebar_position: 30
|
||||
|
||||
menu:
|
||||
sidebar:
|
||||
name: "运维"
|
||||
sidebar_position: 20
|
||||
identifier: "administration"
|
||||
---
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: adding-legal-pages
|
||||
sidebar_position: 110
|
||||
aliases:
|
||||
- /zh-cn/adding-legal-pages
|
||||
---
|
||||
|
||||
# 添加法律页面
|
||||
|
||||
一些法域（例如欧盟）要求在网站上添加特定的法律页面（例如隐私政策）。按照以下步骤将它们添加到你的 Gitea 实例中。
|
||||
|
||||
## 获取页面
|
||||
|
||||
Gitea 源代码附带了示例页面，位于 `contrib/legal` 目录中。将它们复制到 `custom/public/` 目录下。例如，如果要添加隐私政策：
|
||||
|
||||
```
|
||||
wget -O /path/to/custom/public/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/legal/privacy.html.sample
|
||||
```
|
||||
|
||||
现在，你需要编辑该页面以满足你的需求。特别是，你必须更改电子邮件地址、网址以及与 "Your Gitea Instance" 相关的引用，以匹配你的情况。
|
||||
|
||||
请务必不要放置会暗示 Gitea 项目对你的服务器负责的一般服务条款或隐私声明。
|
||||
|
||||
## 使其可见
|
||||
|
||||
创建或追加到 `/path/to/custom/templates/custom/extra_links_footer.tmpl` 文件中：
|
||||
|
||||
```go
|
||||
<a class="item" href="{{AppSubUrl}}/assets/privacy.html">隐私政策</a>
|
||||
```
|
||||
|
||||
重启 Gitea 以查看更改。
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
|
||||
slug: "authentication"
|
||||
sidebar_position: 10
|
||||
|
||||
aliases:
|
||||
- /zh-cn/authentication
|
||||
---
|
||||
|
||||
# 认证
|
||||
|
||||
## 反向代理认证
|
||||
|
||||
Gitea 支持通过读取反向代理传递的 HTTP 头中的登录名或者 email 地址来支持反向代理来认证。默认是不启用的，你可以用以下配置启用。
|
||||
|
||||
```ini
|
||||
[service]
|
||||
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
|
||||
```
|
||||
|
||||
默认的登录用户名的 HTTP 头是 `X-WEBAUTH-USER`，你可以通过修改 `REVERSE_PROXY_AUTHENTICATION_USER` 来变更它。如果用户不存在，可以自动创建用户，当然你需要修改 `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true` 来启用它。
|
||||
|
||||
默认的登录用户 Email 的 HTTP 头是 `X-WEBAUTH-EMAIL`，你可以通过修改 `REVERSE_PROXY_AUTHENTICATION_EMAIL` 来变更它。如果用户不存在，可以自动创建用户，当然你需要修改 `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true` 来启用它。你也可以通过修改 `ENABLE_REVERSE_PROXY_EMAIL` 来启用或停用这个 HTTP 头。
|
||||
|
||||
如果设置了 `ENABLE_REVERSE_PROXY_FULL_NAME=true`，则用户的全名会从 `X-WEBAUTH-FULLNAME` 读取，这样在自动创建用户时将使用这个字段作为用户全名，你也可以通过修改 `REVERSE_PROXY_AUTHENTICATION_FULL_NAME` 来变更 HTTP 头。
|
||||
|
||||
你也可以通过修改 `REVERSE_PROXY_TRUSTED_PROXIES` 来设置反向代理的 IP 地址范围，加强安全性，默认值是 `127.0.0.0/8,::1/128`。 通过 `REVERSE_PROXY_LIMIT`， 可以设置最多信任几级反向代理。
|
||||
|
||||
注意：反向代理认证不支持认证 API，API 仍旧需要用 access token 来进行认证。
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
date: "2018-06-06T09:33:00+08:00"
|
||||
slug: "backup-and-restore"
|
||||
sidebar_position: 11
|
||||
aliases:
|
||||
- /zh-cn/backup-and-restore
|
||||
---
|
||||
|
||||
# 备份与恢复
|
||||
|
||||
Gitea 已经实现了 `dump` 命令可以用来备份所有需要的文件到一个 zip 压缩文件。该压缩文件可以被用来进行数据恢复。
|
||||
|
||||
## 备份命令 (`dump`)
|
||||
|
||||
先转到 git 用户的权限: `su git`. 再 Gitea 目录运行 `./gitea dump`。一般会显示类似如下的输出：
|
||||
|
||||
```
|
||||
2016/12/27 22:32:09 Creating tmp work dir: /tmp/gitea-dump-417443001
|
||||
2016/12/27 22:32:09 Dumping local repositories.../home/git/gitea-repositories
|
||||
2016/12/27 22:32:22 Dumping database...
|
||||
2016/12/27 22:32:22 Packing dump files...
|
||||
2016/12/27 22:32:34 Removing tmp work dir: /tmp/gitea-dump-417443001
|
||||
2016/12/27 22:32:34 Finish dumping in file gitea-dump-1482906742.zip
|
||||
```
|
||||
|
||||
最后生成的 `gitea-dump-1482906742.zip` 文件将会包含如下内容：
|
||||
|
||||
- `custom` - 所有保存在 `custom/` 目录下的配置和自定义的文件。
|
||||
- `data` - 数据目录下的所有内容不包含使用文件 session 的文件。该目录包含 `attachments`, `avatars`, `lfs`, `indexers`, 如果使用 sqlite 还会包含 sqlite 数据库文件。
|
||||
- `gitea-db.sql` - 数据库 dump 出来的 SQL。
|
||||
- `gitea-repo.zip` - Git 仓库压缩文件。
|
||||
- `log/` - Logs 文件，如果用作迁移不是必须的。
|
||||
|
||||
中间备份文件将会在临时目录进行创建，如果您要重新指定临时目录，可以用 `--tempdir` 参数，或者用 `TMPDIR` 环境变量。
|
||||
|
||||
## Restore Command (`restore`)
|
||||
|
||||
当前还没有恢复命令，恢复需要人工进行。主要是把文件和数据库进行恢复。
|
||||
|
||||
例如：
|
||||
|
||||
```sh
|
||||
unzip gitea-dump-1610949662.zip
|
||||
cd gitea-dump-1610949662
|
||||
mv data/conf/app.ini /etc/gitea/conf/app.ini
|
||||
mv data/* /var/lib/gitea/data/
|
||||
mv log/* /var/lib/gitea/log/
|
||||
mv repos/* /var/lib/gitea/repositories/
|
||||
chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea
|
||||
|
||||
# mysql
|
||||
mysql --default-character-set=utf8mb4 -u$USER -p$PASS $DATABASE <gitea-db.sql
|
||||
# sqlite3
|
||||
sqlite3 $DATABASE_PATH <gitea-db.sql
|
||||
# postgres
|
||||
psql -U $USER -d $DATABASE < gitea-db.sql
|
||||
|
||||
service gitea restart
|
||||
```
|
||||
@@ -1,92 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "cmd-embedded"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-cn/cmd-embedded
|
||||
---
|
||||
|
||||
# 嵌入资源提取工具
|
||||
|
||||
Gitea 的可执行文件包含了运行所需的所有资源：模板、图片、样式表和翻译文件。你可以通过在 `custom` 目录下的相应路径中放置替换文件来覆盖其中的任何资源（详见 [自定义 Gitea 配置](../administration/customizing-gitea.md)）。
|
||||
|
||||
要获取嵌入资源的副本以进行编辑，可以使用 CLI 中的 `embedded` 命令，通过操作系统的 shell 执行。
|
||||
|
||||
**注意：** 嵌入资源提取工具包含在 Gitea 1.12 及以上版本中。
|
||||
|
||||
## 资源列表
|
||||
|
||||
要列出嵌入在 Gitea 可执行文件中的资源，请使用以下语法：
|
||||
|
||||
```sh
|
||||
gitea embedded list [--include-vendored] [patterns...]
|
||||
```
|
||||
|
||||
`--include-vendored` 标志使命令包括被供应的文件，这些文件通常被排除在外；即来自外部库的文件，这些文件是 Gitea 所需的（例如 [octicons](https://octicons.github.com/) 等）。
|
||||
|
||||
可以提供一系列文件搜索模式。Gitea 使用 [gobwas/glob](https://github.com/gobwas/glob) 作为其 glob 语法。以下是一些示例：
|
||||
|
||||
- 列出所有模板文件，无论在哪个虚拟目录下：`**.tmpl`
|
||||
- 列出所有邮件模板文件：`templates/mail/**.tmpl`
|
||||
- 列出 `public/img` 目录下的所有文件：`public/img/**`
|
||||
|
||||
不要忘记为模式使用引号，因为空格、`*` 和其他字符可能对命令行解释器有特殊含义。
|
||||
|
||||
如果未提供模式，则列出所有文件。
|
||||
|
||||
### 示例
|
||||
|
||||
列出所有路径中包含 `openid` 的嵌入文件：
|
||||
|
||||
```sh
|
||||
$ gitea embedded list '**openid**'
|
||||
public/img/auth/openid_connect.svg
|
||||
public/img/openid-16x16.png
|
||||
templates/user/auth/finalize_openid.tmpl
|
||||
templates/user/auth/signin_openid.tmpl
|
||||
templates/user/auth/signup_openid_connect.tmpl
|
||||
templates/user/auth/signup_openid_navbar.tmpl
|
||||
templates/user/auth/signup_openid_register.tmpl
|
||||
templates/user/settings/security_openid.tmpl
|
||||
```
|
||||
|
||||
## 提取资源
|
||||
|
||||
要提取嵌入在 Gitea 可执行文件中的资源，请使用以下语法：
|
||||
|
||||
```sh
|
||||
gitea [--config {file}] embedded extract [--destination {dir}|--custom] [--overwrite|--rename] [--include-vendored] {patterns...}
|
||||
```
|
||||
|
||||
`--config` 选项用于告知 Gitea `app.ini` 配置文件的位置（如果不在默认位置）。此选项仅在使用 `--custom` 标志时使用。
|
||||
|
||||
`--destination` 选项用于指定提取文件的目标目录。默认为当前目录。
|
||||
|
||||
`--custom` 标志告知 Gitea 直接将文件提取到 `custom` 目录中。为使其正常工作，该命令需要知道 `app.ini` 配置文件的位置（通过 `--config` 指定），并且根据配置的不同，需要从 Gitea 通常启动的目录运行。有关详细信息，请参阅 [自定义 Gitea 配置](../administration/customizing-gitea.md)。
|
||||
|
||||
`--overwrite` 标志允许覆盖目标目录中的任何现有文件。
|
||||
|
||||
`--rename` 标志告知 Gitea 将目标目录中的任何现有文件重命名为 `filename.bak`。之前的 `.bak` 文件将被覆盖。
|
||||
|
||||
至少需要提供一个文件搜索模式；有关模式的语法和示例，请参阅上述 `list` 子命令。
|
||||
|
||||
### 重要提示
|
||||
|
||||
请确保**只提取需要自定义的文件**。位于 `custom` 目录中的文件不会受到 Gitea 的升级过程的影响。当 Gitea 升级到新版本（通过替换可执行文件）时，许多嵌入文件将发生变化。Gitea 将尊重并使用在 `custom` 目录中找到的任何文件，即使这些文件是旧的和不兼容的。
|
||||
|
||||
### 示例
|
||||
|
||||
将邮件模板提取到临时目录：
|
||||
|
||||
```sh
|
||||
$ mkdir tempdir
|
||||
$ gitea embedded extract --destination tempdir 'templates/mail/**.tmpl'
|
||||
Extracting to tempdir:
|
||||
tempdir/templates/mail/auth/activate.tmpl
|
||||
tempdir/templates/mail/auth/activate_email.tmpl
|
||||
tempdir/templates/mail/auth/register_notify.tmpl
|
||||
tempdir/templates/mail/auth/reset_passwd.tmpl
|
||||
tempdir/templates/mail/issue/assigned.tmpl
|
||||
tempdir/templates/mail/issue/default.tmpl
|
||||
tempdir/templates/mail/notify/collaborator.tmpl
|
||||
```
|
||||
@@ -1,543 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "command-line"
|
||||
sidebar_position: 1
|
||||
aliases:
|
||||
- /zh-cn/command-line
|
||||
---
|
||||
|
||||
# 命令行
|
||||
|
||||
## 用法
|
||||
|
||||
`gitea [全局选项] 命令 [命令或全局选项] [参数...]`
|
||||
|
||||
## 全局选项
|
||||
|
||||
所有全局选项均可被放置在命令级别。
|
||||
|
||||
- `--help`，`-h`：显示帮助文本并退出。可选。
|
||||
- `--version`，`-v`：显示版本信息并退出。可选。 (示例：`Gitea version 1.1.0+218-g7b907ed built with: bindata, sqlite`)。
|
||||
- `--custom-path path`，`-C path`：Gitea 自定义文件夹的路径。可选。 (默认值：`AppWorkPath`/custom 或 `$GITEA_CUSTOM`)。
|
||||
- `--config path`，`-c path`：Gitea 配置文件的路径。可选。 (默认值：`custom`/conf/app.ini)。
|
||||
- `--work-path path`，`-w path`：Gitea 的 `AppWorkPath`。可选。 (默认值：LOCATION_OF_GITEA_BINARY 或 `$GITEA_WORK_DIR`)
|
||||
|
||||
注意：默认的 custom-path、config 和 work-path 也可以在构建时更改（如果需要）。
|
||||
|
||||
## 命令
|
||||
|
||||
### web
|
||||
|
||||
启动服务器：
|
||||
|
||||
- 选项：
|
||||
- `--port number`，`-p number`：端口号。可选。 (默认值：3000)。覆盖配置文件中的设置。
|
||||
- `--install-port number`：运行安装页面的端口号。可选。 (默认值：3000)。覆盖配置文件中的设置。
|
||||
- `--pid path`，`-P path`：Pid 文件的路径。可选。
|
||||
- `--quiet`，`-q`：只在控制台上输出 Fatal 日志，用于在设置日志之前发出的日志。
|
||||
- `--verbose`：在控制台上输出跟踪日志，用于在设置日志之前发出的日志。
|
||||
- 示例：
|
||||
- `gitea web`
|
||||
- `gitea web --port 80`
|
||||
- `gitea web --config /etc/gitea.ini --pid /some/custom/gitea.pid`
|
||||
- 注意：
|
||||
- Gitea 不应以 root 用户身份运行。要绑定到低于 1024 的端口，您可以在 Linux 上使用 setcap 命令：`sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`。每次更新 Gitea 都需要重新执行此操作。
|
||||
|
||||
### admin
|
||||
|
||||
管理员操作：
|
||||
|
||||
- 命令：
|
||||
- `user`：
|
||||
- `list`：
|
||||
- 选项：
|
||||
- `--admin`：仅列出管理员用户。可选。
|
||||
- 描述：列出所有现有用户。
|
||||
- 示例：
|
||||
- `gitea admin user list`
|
||||
- `delete`：
|
||||
- 选项：
|
||||
- `--email`：要删除的用户的电子邮件。
|
||||
- `--username`：要删除的用户的用户名。
|
||||
- `--id`：要删除的用户的 ID。
|
||||
- 必须提供 `--id`、`--username` 或 `--email` 中的一个。如果提供多个，则所有条件必须匹配。
|
||||
- 示例：
|
||||
- `gitea admin user delete --id 1`
|
||||
- `create`：
|
||||
- 选项：
|
||||
- `--name value`：用户名。必填。自 Gitea 1.9.0 版本起，请改用 `--username` 标志。
|
||||
- `--username value`：用户名。必填。Gitea 1.9.0 新增。
|
||||
- `--password value`：密码。必填。
|
||||
- `--email value`：邮箱。必填。
|
||||
- `--admin`：如果提供此选项，将创建一个管理员用户。可选。
|
||||
- `--access-token`：如果提供，将为用户创建访问令牌。可选。（默认值：false）。
|
||||
- `--must-change-password`：如果提供，创建的用户将在初始登录后需要选择一个新密码。可选。（默认值：true）。
|
||||
- `--random-password`：如果提供，将使用随机生成的密码作为创建用户的密码。`--password` 的值将被忽略。可选。
|
||||
- `--random-password-length`：如果提供，将用于配置随机生成密码的长度。可选。（默认值：12）
|
||||
- 示例：
|
||||
- `gitea admin user create --username myname --password asecurepassword --email me@example.com`
|
||||
- `change-password`：
|
||||
- 选项：
|
||||
- `--username value`，`-u value`：用户名。必填。
|
||||
- `--password value`，`-p value`：新密码。必填。
|
||||
- 示例：
|
||||
- `gitea admin user change-password --username myname --password asecurepassword`
|
||||
- `must-change-password`：
|
||||
- 参数：
|
||||
- `[username...]`：需要更改密码的用户
|
||||
- 选项：
|
||||
- `--all`，`-A`：强制所有用户更改密码
|
||||
- `--exclude username`，`-e username`：排除给定的用户。可以多次设置。
|
||||
- `--unset`：撤销对给定用户的强制密码更改
|
||||
- `regenerate`：
|
||||
- 选项：
|
||||
- `hooks`：重新生成所有仓库的 Git Hooks。
|
||||
- `keys`：重新生成 authorized_keys 文件。
|
||||
- 示例：
|
||||
- `gitea admin regenerate hooks`
|
||||
- `gitea admin regenerate keys`
|
||||
- `auth`：
|
||||
- `list`：
|
||||
- 描述：列出所有存在的外部认证源。
|
||||
- 示例：
|
||||
- `gitea admin auth list`
|
||||
- `delete`：
|
||||
- 选项：
|
||||
- `--id`：要删除的源的 ID。必填。
|
||||
- 示例：
|
||||
- `gitea admin auth delete --id 1`
|
||||
- `add-oauth`：
|
||||
- 选项：
|
||||
- `--name`：应用程序名称。
|
||||
- `--provider`：OAuth2 提供者。
|
||||
- `--key`：客户端 ID（Key）。
|
||||
- `--secret`：客户端密钥。
|
||||
- `--auto-discover-url`：OpenID Connect 自动发现 URL（仅在使用 OpenID Connect 作为提供程序时需要）。
|
||||
- `--use-custom-urls`：在 GitLab/GitHub OAuth 端点上使用自定义 URL。
|
||||
- `--custom-tenant-id`：在 OAuth 端点上使用自定义租户 ID。
|
||||
- `--custom-auth-url`：使用自定义授权 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-token-url`：使用自定义令牌 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-profile-url`：使用自定义配置文件 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-email-url`：使用自定义电子邮件 URL（GitHub 的选项）。
|
||||
- `--icon-url`：OAuth2 登录源的自定义图标 URL。
|
||||
- `--skip-local-2fa`：允许源覆盖本地 2FA。（可选）
|
||||
- `--scopes`：请求此 OAuth2 源的附加范围。（可选）
|
||||
- `--required-claim-name`：必须设置的声明名称，以允许用户使用此源登录。（可选）
|
||||
- `--required-claim-value`：必须设置的声明值，以允许用户使用此源登录。（可选）
|
||||
- `--group-claim-name`：提供此源的组名的声明名称。（可选）
|
||||
- `--admin-group`：管理员用户的组声明值。（可选）
|
||||
- `--restricted-group`：受限用户的组声明值。（可选）
|
||||
- `--group-team-map`：组与组织团队之间的 JSON 映射。（可选）
|
||||
- `--group-team-map-removal`：根据组自动激活团队成员资格的删除。（可选）
|
||||
- 示例：
|
||||
- `gitea admin auth add-oauth --name external-github --provider github --key OBTAIN_FROM_SOURCE --secret OBTAIN_FROM_SOURCE`
|
||||
- `update-oauth`：
|
||||
- 选项：
|
||||
- `--id`：要更新的源的 ID。必填。
|
||||
- `--name`：应用程序名称。
|
||||
- `--provider`：OAuth2 提供者。
|
||||
- `--key`：客户端 ID（Key）。
|
||||
- `--secret`：客户端密钥。
|
||||
- `--auto-discover-url`：OpenID Connect 自动发现 URL（仅在使用 OpenID Connect 作为提供程序时需要）。
|
||||
- `--use-custom-urls`：在 GitLab/GitHub OAuth 端点上使用自定义 URL。
|
||||
- `--custom-tenant-id`：在 OAuth 端点上使用自定义租户 ID。
|
||||
- `--custom-auth-url`：使用自定义授权 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-token-url`：使用自定义令牌 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-profile-url`：使用自定义配置文件 URL（GitLab/GitHub 的选项）。
|
||||
- `--custom-email-url`：使用自定义电子邮件 URL（GitHub 的选项）。
|
||||
- `--icon-url`：OAuth2 登录源的自定义图标 URL。
|
||||
- `--skip-local-2fa`：允许源覆盖本地 2FA。（可选）
|
||||
- `--scopes`：请求此 OAuth2 源的附加范围。
|
||||
- `--required-claim-name`：必须设置的声明名称，以允许用户使用此源登录。（可选）
|
||||
- `--required-claim-value`：必须设置的声明值，以允许用户使用此源登录。（可选）
|
||||
- `--group-claim-name`：提供此源的组名的声明名称。（可选）
|
||||
- `--admin-group`：管理员用户的组声明值。（可选）
|
||||
- `--restricted-group`：受限用户的组声明值。（可选）
|
||||
- 示例：
|
||||
- `gitea admin auth update-oauth --id 1 --name external-github-updated`
|
||||
- `add-smtp`：
|
||||
- 选项：
|
||||
- `--name`：应用程序名称。必填。
|
||||
- `--auth-type`：SMTP 认证类型（PLAIN/LOGIN/CRAM-MD5）。默认为 PLAIN。
|
||||
- `--host`：SMTP 主机。必填。
|
||||
- `--port`：SMTP 端口。必填。
|
||||
- `--force-smtps`：SMTPS 始终在端口 465 上使用。设置此选项以强制在其他端口上使用 SMTPS。
|
||||
- `--skip-verify`：跳过 TLS 验证。
|
||||
- `--helo-hostname`：发送 HELO 时使用的主机名。留空以发送当前主机名。
|
||||
- `--disable-helo`：禁用 SMTP helo。
|
||||
- `--allowed-domains`：留空以允许所有域。使用逗号（','）分隔多个域。
|
||||
- `--skip-local-2fa`：跳过 2FA 登录。
|
||||
- `--active`：启用此认证源。
|
||||
备注：
|
||||
`--force-smtps`、`--skip-verify`、`--disable-helo`、`--skip-local-2fs` 和 `--active` 选项可以采用以下形式使用：
|
||||
- `--option`、`--option=true` 以启用选项
|
||||
- `--option=false` 以禁用选项
|
||||
如果未指定这些选项，则在 `update-smtp` 中不会更改值，或者在 `add-smtp` 中将使用默认的 `false` 值。
|
||||
- 示例：
|
||||
- `gitea admin auth add-smtp --name ldap --host smtp.mydomain.org --port 587 --skip-verify --active`
|
||||
- `update-smtp`：
|
||||
- 选项：
|
||||
- `--id`：要更新的源的 ID。必填。
|
||||
- 其他选项与 `add-smtp` 共享
|
||||
- 示例：
|
||||
- `gitea admin auth update-smtp --id 1 --host smtp.mydomain.org --port 587 --skip-verify=false`
|
||||
- `gitea admin auth update-smtp --id 1 --active=false`
|
||||
- `add-ldap`：添加新的 LDAP（通过 Bind DN）认证源
|
||||
- 选项：
|
||||
- `--name value`：认证名称。必填。
|
||||
- `--not-active`：停用认证源。
|
||||
- `--security-protocol value`：安全协议名称。必填。
|
||||
- `--skip-tls-verify`：禁用 TLS 验证。
|
||||
- `--host value`：LDAP 服务器的地址。必填。
|
||||
- `--port value`：连接到 LDAP 服务器时使用的端口。必填。
|
||||
- `--user-search-base value`：用户帐户将在其中搜索的 LDAP 基础路径。必填。
|
||||
- `--user-filter value`：声明如何查找试图进行身份验证的用户记录的 LDAP 过滤器。必填。
|
||||
- `--admin-filter value`：指定是否应授予用户管理员特权的 LDAP 过滤器。
|
||||
- `--restricted-filter value`：指定是否应将用户设置为受限状态的 LDAP 过滤器。
|
||||
- `--username-attribute value`：用户 LDAP 记录中包含用户名的属性。
|
||||
- `--firstname-attribute value`：用户 LDAP 记录中包含用户名字的属性。
|
||||
- `--surname-attribute value`：用户 LDAP 记录中包含用户姓氏的属性。
|
||||
- `--email-attribute value`：用户 LDAP 记录中包含用户电子邮件地址的属性。必填。
|
||||
- `--public-ssh-key-attribute value`：用户 LDAP 记录中包含用户公共 SSH 密钥的属性。
|
||||
- `--avatar-attribute value`：用户 LDAP 记录中包含用户头像的属性。
|
||||
- `--bind-dn value`：在搜索用户时绑定到 LDAP 服务器的 DN。
|
||||
- `--bind-password value`：绑定 DN 的密码（如果有）。
|
||||
- `--attributes-in-bind`：在绑定 DN 上下文中获取属性。
|
||||
- `--synchronize-users`：启用用户同步。
|
||||
- `--page-size value`：搜索页面大小。
|
||||
- 示例：
|
||||
- `gitea admin auth add-ldap --name ldap --security-protocol unencrypted --host mydomain.org --port 389 --user-search-base "ou=Users,dc=mydomain,dc=org" --user-filter "(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))" --email-attribute mail`
|
||||
- `update-ldap`：更新现有的 LDAP（通过 Bind DN）认证源
|
||||
- 选项：
|
||||
- `--id value`：认证源的 ID。必填。
|
||||
- `--name value`：认证名称。
|
||||
- `--not-active`：停用认证源。
|
||||
- `--security-protocol value`：安全协议名称。
|
||||
- `--skip-tls-verify`：禁用 TLS 验证。
|
||||
- `--host value`：LDAP 服务器的地址。
|
||||
- `--port value`：连接到 LDAP 服务器时使用的端口。
|
||||
- `--user-search-base value`：用户帐户将在其中搜索的 LDAP 基础路径。
|
||||
- `--user-filter value`：声明如何查找试图进行身份验证的用户记录的 LDAP 过滤器。
|
||||
- `--admin-filter value`：指定是否应授予用户管理员特权的 LDAP 过滤器。
|
||||
- `--restricted-filter value`：指定是否应将用户设置为受限状态的 LDAP 过滤器。
|
||||
- `--username-attribute value`：用户 LDAP 记录中包含用户名的属性。
|
||||
- `--firstname-attribute value`：用户 LDAP 记录中包含用户名字的属性。
|
||||
- `--surname-attribute value`：用户 LDAP 记录中包含用户姓氏的属性。
|
||||
- `--email-attribute value`：用户 LDAP 记录中包含用户电子邮件地址的属性。
|
||||
- `--public-ssh-key-attribute value`：用户 LDAP 记录中包含用户公共 SSH 密钥的属性。
|
||||
- `--avatar-attribute value`：用户 LDAP 记录中包含用户头像的属性。
|
||||
- `--bind-dn value`：在搜索用户时绑定到 LDAP 服务器的 DN。
|
||||
- `--bind-password value`：绑定 DN 的密码（如果有）。
|
||||
- `--attributes-in-bind`：在绑定 DN 上下文中获取属性。
|
||||
- `--synchronize-users`：启用用户同步。
|
||||
- `--page-size value`：搜索页面大小。
|
||||
- 示例：
|
||||
- `gitea admin auth update-ldap --id 1 --name "my ldap auth source"`
|
||||
- `gitea admin auth update-ldap --id 1 --username-attribute uid --firstname-attribute givenName --surname-attribute sn`
|
||||
- `add-ldap-simple`：添加新的 LDAP（简单身份验证）认证源
|
||||
- 选项：
|
||||
- `--name value`：认证名称。必填。
|
||||
- `--not-active`：停用认证源。
|
||||
- `--security-protocol value`：安全协议名称。必填。
|
||||
- `--skip-tls-verify`：禁用 TLS 验证。
|
||||
- `--host value`：LDAP 服务器的地址。必填。
|
||||
- `--port value`：连接到 LDAP 服务器时使用的端口。必填。
|
||||
- `--user-search-base value`：用户帐户将在其中搜索的 LDAP 基础路径。
|
||||
- `--user-filter value`：声明如何查找试图进行身份验证的用户记录的 LDAP 过滤器。必填。
|
||||
- `--admin-filter value`：指定是否应授予用户管理员特权的 LDAP 过滤器。
|
||||
- `--restricted-filter value`：指定是否应将用户设置为受限状态的 LDAP 过滤器。
|
||||
- `--username-attribute value`：用户 LDAP 记录中包含用户名的属性。
|
||||
- `--firstname-attribute value`：用户 LDAP 记录中包含用户名字的属性。
|
||||
- `--surname-attribute value`：用户 LDAP 记录中包含用户姓氏的属性。
|
||||
- `--email-attribute value`：用户 LDAP 记录中包含用户电子邮件地址的属性。必填。
|
||||
- `--public-ssh-key-attribute value`：用户 LDAP 记录中包含用户公共 SSH 密钥的属性。
|
||||
- `--avatar-attribute value`：用户 LDAP 记录中包含用户头像的属性。
|
||||
- `--user-dn value`：用户的 DN。必填。
|
||||
- 示例：
|
||||
- `gitea admin auth add-ldap-simple --name ldap --security-protocol unencrypted --host mydomain.org --port 389 --user-dn "cn=%s,ou=Users,dc=mydomain,dc=org" --user-filter "(&(objectClass=posixAccount)(cn=%s))" --email-attribute mail`
|
||||
- `update-ldap-simple`：更新现有的 LDAP（简单身份验证）认证源
|
||||
- 选项：
|
||||
- `--id value`：认证源的 ID。必填。
|
||||
- `--name value`：认证名称。
|
||||
- `--not-active`：停用认证源。
|
||||
- `--security-protocol value`：安全协议名称。
|
||||
- `--skip-tls-verify`：禁用 TLS 验证。
|
||||
- `--host value`：LDAP 服务器的地址。
|
||||
- `--port value`：连接到 LDAP 服务器时使用的端口。
|
||||
- `--user-search-base value`：用户帐户将在其中搜索的 LDAP 基础路径。
|
||||
- `--user-filter value`：声明如何查找试图进行身份验证的用户记录的 LDAP 过滤器。
|
||||
- `--admin-filter value`：指定是否应授予用户管理员特权的 LDAP 过滤器。
|
||||
- `--restricted-filter value`：指定是否应将用户设置为受限状态的 LDAP 过滤器。
|
||||
- `--username-attribute value`：用户 LDAP 记录中包含用户名的属性。
|
||||
- `--firstname-attribute value`：用户 LDAP 记录中包含用户名字的属性。
|
||||
- `--surname-attribute value`：用户 LDAP 记录中包含用户姓氏的属性。
|
||||
- `--email-attribute value`：用户 LDAP 记录中包含用户电子邮件地址的属性。
|
||||
- `--public-ssh-key-attribute value`：用户 LDAP 记录中包含用户公共 SSH 密钥的属性。
|
||||
- `--avatar-attribute value`：用户 LDAP 记录中包含用户头像的属性。
|
||||
- `--user-dn value`：用户的 DN。
|
||||
- 示例：
|
||||
- `gitea admin auth update-ldap-simple --id 1 --name "my ldap auth source"`
|
||||
- `gitea admin auth update-ldap-simple --id 1 --username-attribute uid --firstname-attribute givenName --surname-attribute sn`
|
||||
|
||||
### cert
|
||||
|
||||
生成自签名的 SSL 证书。将输出到当前目录下的`cert.pem`和`key.pem`文件中，并且会覆盖任何现有文件。
|
||||
|
||||
- 选项：
|
||||
- `--host value`：逗号分隔的主机名和 IP 地址列表，此证书适用于这些主机。支持使用通配符。必填。
|
||||
- `--ecdsa-curve value`：用于生成密钥的 ECDSA 曲线。可选。有效选项为 P224、P256、P384、P521。
|
||||
- `--rsa-bits value`：要生成的 RSA 密钥的大小。可选。如果设置了--ecdsa-curve，则忽略此选项。（默认值：2048）。
|
||||
- `--start-date value`：证书的创建日期。可选。（格式：`Jan 1 15:04:05 2011`）。
|
||||
- `--duration value`：证书有效期。可选。（默认值：8760h0m0s）
|
||||
- `--ca`：如果提供此选项，则证书将生成自己的证书颁发机构。可选。
|
||||
- 示例：
|
||||
- `gitea cert --host git.example.com,example.com,www.example.com --ca`
|
||||
|
||||
### dump
|
||||
|
||||
将所有文件和数据库导出到一个 zip 文件中。输出文件将保存在当前目录下，类似于`gitea-dump-1482906742.zip`。
|
||||
|
||||
- 选项：
|
||||
- `--file name`，`-f name`：指定要创建的导出文件的名称。可选。（默认值：gitea-dump-[timestamp].zip）。
|
||||
- `--tempdir path`，`-t path`：指定临时目录的路径。可选。（默认值：/tmp）。
|
||||
- `--skip-repository`，`-R`：跳过仓库的导出。可选。
|
||||
- `--skip-custom-dir`：跳过自定义目录的导出。可选。
|
||||
- `--skip-lfs-data`：跳过 LFS 数据的导出。可选。
|
||||
- `--skip-attachment-data`：跳过附件数据的导出。可选。
|
||||
- `--skip-package-data`：跳过包数据的导出。可选。
|
||||
- `--skip-log`：跳过日志数据的导出。可选。
|
||||
- `--database`，`-d`：指定数据库的 SQL 语法。可选。
|
||||
- `--verbose`，`-V`：如果提供此选项，显示附加详细信息。可选。
|
||||
- `--type`：设置导出的格式。可选。（默认值：zip）
|
||||
- 示例：
|
||||
- `gitea dump`
|
||||
- `gitea dump --verbose`
|
||||
|
||||
### generate
|
||||
|
||||
用于在配置文件中生成随机值和令牌。对于自动部署时生成值非常有用。
|
||||
|
||||
- 命令:
|
||||
- `secret`:
|
||||
- 选项:
|
||||
- `INTERNAL_TOKEN`: 用于内部 API 调用身份验证的令牌。
|
||||
- `JWT_SECRET`: 用于 LFS 和 OAUTH2 JWT 身份验证的密钥（LFS_JWT_SECRET 是此选项的别名，用于向后兼容）。
|
||||
- `SECRET_KEY`: 全局密钥。
|
||||
- 示例:
|
||||
- `gitea generate secret INTERNAL_TOKEN`
|
||||
- `gitea generate secret JWT_SECRET`
|
||||
- `gitea generate secret SECRET_KEY`
|
||||
|
||||
### keys
|
||||
|
||||
提供一个 SSHD AuthorizedKeysCommand。需要在 sshd 配置文件中进行配置:
|
||||
|
||||
```ini
|
||||
...
|
||||
# -e 的值和 AuthorizedKeysCommandUser 应与运行 Gitea 的用户名匹配
|
||||
AuthorizedKeysCommandUser git
|
||||
AuthorizedKeysCommand /path/to/gitea keys -e git -u %u -t %t -k %k
|
||||
```
|
||||
|
||||
该命令将返回适用于提供的密钥的合适 authorized_keys 行。您还应在 `app.ini` 的 `[server]` 部分设置值 `SSH_CREATE_AUTHORIZED_KEYS_FILE=false`。
|
||||
|
||||
注意: opensshd 要求 Gitea 程序由 root 拥有，并且不可由组或其他人写入。程序必须使用绝对路径指定。
|
||||
注意: Gitea 必须在运行此命令时处于运行状态才能成功。
|
||||
|
||||
### migrate
|
||||
|
||||
迁移数据库。该命令可用于在首次启动服务器之前运行其他命令。此命令是幂等的。
|
||||
|
||||
### convert
|
||||
|
||||
将现有的 MySQL 数据库从 utf8 转换为 utf8mb4。
|
||||
|
||||
### doctor
|
||||
|
||||
根据给定的配置诊断当前 Gitea 实例的问题。目前有以下检查清单:
|
||||
|
||||
- 检查 OpenSSH 的 authorized_keys 文件是否正确
|
||||
当您的 Gitea 实例支持 OpenSSH 时，当您的 Gitea 实例添加或更改任何公钥时，Gitea 实例的二进制路径将被写入 `authorized_keys` 文件。
|
||||
有时，如果您在升级时移动或重命名了 Gitea 二进制文件，并且您没有在管理面板上运行“使用 Gitea 的 SSH 密钥更新「.ssh/authorized_keys」文件”操作。那么通过 SSH 的所有拉取/推送操作将无法正常工作。
|
||||
此检查将帮助您检查它是否正常工作。
|
||||
|
||||
对于贡献者，如果您想添加更多的检查项，您可以编写一个新的函数，如 `func(ctx *cli.Context) ([]string, error)`，并将其追加到 `doctor.go` 文件中。
|
||||
|
||||
```go
|
||||
var checklist = []check{
|
||||
{
|
||||
title: "Check if OpenSSH authorized_keys file id correct",
|
||||
f: runDoctorLocationMoved,
|
||||
},
|
||||
// more checks please append here
|
||||
}
|
||||
```
|
||||
|
||||
此函数将接收一个命令行上下文，并返回有关问题或错误的详细信息列表。
|
||||
|
||||
#### doctor recreate-table
|
||||
|
||||
有时，在迁移时，旧的列和默认值可能会在数据库模式中保持不变。这可能会导致警告，如下所示:
|
||||
|
||||
```
|
||||
2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync2() [W] Table user Column keep_activity_private db default is , struct default is 0
|
||||
```
|
||||
|
||||
您可以通过以下方式让 Gitea 重新创建这些表，并将旧数据复制到新表中，并适当设置默认值：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table user
|
||||
```
|
||||
|
||||
您可以使用以下方式让 Gitea 重新创建多个表：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table table1 table2 ...
|
||||
```
|
||||
|
||||
如果您希望 Gitea 重新创建所有表，请直接调用：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table
|
||||
```
|
||||
|
||||
强烈建议在运行这些命令之前备份您的数据库。
|
||||
|
||||
### manager
|
||||
|
||||
管理运行中的服务器操作：
|
||||
|
||||
- 命令:
|
||||
- `shutdown`: 优雅地关闭运行中的进程
|
||||
- `restart`: 优雅地重新启动运行中的进程（对于 Windows 服务器尚未实现）
|
||||
- `flush-queues`: 刷新运行中的进程中的队列
|
||||
- 选项:
|
||||
- `--timeout value`: 刷新过程的超时时间（默认值: 1m0s）
|
||||
- `--non-blocking`: 设置为 true，以在返回之前不等待刷新完成
|
||||
- `logging`: 调整日志命令
|
||||
- 命令:
|
||||
- `pause`: 暂停日志记录
|
||||
- 注意:
|
||||
- 如果日志级别低于此级别，日志级别将被临时提升为 INFO。
|
||||
- Gitea 将在一定程度上缓冲日志，并在超过该点后丢弃日志。
|
||||
- `resume`: 恢复日志记录
|
||||
- `release-and-reopen`: 使 Gitea 释放和重新打开用于日志记录的文件和连接（相当于向 Gitea 发送 SIGUSR1 信号）。
|
||||
- `remove name`: 删除指定的日志记录器
|
||||
- 选项:
|
||||
- `--group group`, `-g group`: 从中删除子记录器的组（默认为`default`）
|
||||
- `add`: 添加日志记录器
|
||||
- 命令:
|
||||
- `console`: 添加控制台日志记录器
|
||||
- 选项:
|
||||
- `--group value`, `-g value`: 要添加日志记录器的组 - 默认为"default"
|
||||
- `--name value`, `-n value`: 新日志记录器的名称 - 默认为模式
|
||||
- `--level value`, `-l value`: 新日志记录器的日志级别
|
||||
- `--stacktrace-level value`, `-L value`: 堆栈跟踪日志级别
|
||||
- `--flags value`, `-F value`: 日志记录器的标志
|
||||
- `--expression value`, `-e value`: 日志记录器的匹配表达式
|
||||
- `--prefix value`, `-p value`: 日志记录器的前缀
|
||||
- `--color`: 在日志中使用颜色
|
||||
- `--stderr`: 将控制台日志输出到 stderr - 仅适用于控制台
|
||||
- `file`: 添加文件日志记录器
|
||||
- 选项:
|
||||
- `--group value`, `-g value`: 要添加日志记录器的组 - 默认为"default"
|
||||
- `--name value`, `-n value`: 新日志记录器的名称 - 默认为模式
|
||||
- `--level value`, `-l value`: 新日志记录器的日志级别
|
||||
- `--stacktrace-level value`, `-L value`: 堆栈跟踪日志级别
|
||||
- `--flags value`, `-F value`: 日志记录器的标志
|
||||
- `--expression value`, `-e value`: 日志记录器的匹配表达式
|
||||
- `--prefix value`, `-p value`: 日志记录器的前缀
|
||||
- `--color`: 在日志中使用颜色
|
||||
- `--filename value`, `-f value`: 日志记录器的文件名
|
||||
- `--rotate`, `-r`: 轮转日志
|
||||
- `--max-size value`, `-s value`: 在轮转之前的最大大小（以字节为单位）
|
||||
- `--daily`, `-d`: 每天轮转日志
|
||||
- `--max-days value`, `-D value`: 保留的每日日志的最大数量
|
||||
- `--compress`, `-z`: 压缩轮转的日志
|
||||
- `--compression-level value`, `-Z value`: 使用的压缩级别
|
||||
- `conn`: 添加网络连接日志记录器
|
||||
- 选项:
|
||||
- `--group value`, `-g value`: 要添加日志记录器的组 - 默认为"default"
|
||||
- `--name value`, `-n value`: 新日志记录器的名称 - 默认为模式
|
||||
- `--level value`, `-l value`: 新日志记录器的日志级别
|
||||
- `--stacktrace-level value`, `-L value`: 堆栈跟踪日志级别
|
||||
- `--flags value`, `-F value`: 日志记录器的标志
|
||||
- `--expression value`, `-e value`: 日志记录器的匹配表达式
|
||||
- `--prefix value`, `-p value`: 日志记录器的前缀
|
||||
- `--color`: 在日志中使用颜色
|
||||
- `--reconnect-on-message`, `-R`: 对于每个消息重新连接主机
|
||||
- `--reconnect`, `-r`: 连接中断时重新连接主机
|
||||
- `--protocol value`, `-P value`: 设置要使用的协议：tcp、unix 或 udp（默认为 tcp）
|
||||
- `--address value`, `-a value`: 要连接到的主机地址和端口（默认为:7020）
|
||||
- `smtp`: 添加 SMTP 日志记录器
|
||||
- 选项:
|
||||
- `--group value`, `-g value`: 要添加日志记录器的组 - 默认为"default"
|
||||
- `--name value`, `-n value`: 新日志记录器的名称 - 默认为模式
|
||||
- `--level value`, `-l value`: 新日志记录器的日志级别
|
||||
- `--stacktrace-level value`, `-L value`: 堆栈跟踪日志级别
|
||||
- `--flags value`, `-F value`: 日志记录器的标志
|
||||
- `--expression value`, `-e value`: 日志记录器的匹配表达式
|
||||
- `--prefix value`, `-p value`: 日志记录器的前缀
|
||||
- `--color`: 在日志中使用颜色
|
||||
- `--username value`, `-u value`: 邮件服务器用户名
|
||||
- `--password value`, `-P value`: 邮件服务器密码
|
||||
- `--host value`, `-H value`: 邮件服务器主机（默认为: 127.0.0.1:25）
|
||||
- `--send-to value`, `-s value`: 要发送到的电子邮件地址
|
||||
- `--subject value`, `-S value`: 发送电子邮件的主题标题
|
||||
- `processes`: 显示 Gitea 进程和 Goroutine 信息
|
||||
- 选项:
|
||||
- `--flat`: 以平面表格形式显示进程，而不是树形结构
|
||||
- `--no-system`: 不显示系统进程
|
||||
- `--stacktraces`: 显示与进程关联的 Goroutine 的堆栈跟踪
|
||||
- `--json`: 输出为 JSON 格式
|
||||
- `--cancel PID`: 向具有 PID 的进程发送取消命令（仅适用于非系统进程）
|
||||
|
||||
### dump-repo
|
||||
|
||||
`dump-repo` 从 Git/GitHub/Gitea/GitLab 中转储存储库数据：
|
||||
|
||||
- 选项：
|
||||
- `--git_service service`：Git 服务，可以是 `git`、`github`、`gitea`、`gitlab`。如果 `clone_addr` 可以被识别，则可以忽略此选项。
|
||||
- `--repo_dir dir`，`-r dir`：存储数据的存储库目录路径。
|
||||
- `--clone_addr addr`：将被克隆的 URL，目前可以是 git/github/gitea/gitlab 的 http/https URL。例如：https://github.com/lunny/tango.git
|
||||
- `--auth_username lunny`：访问 `clone_addr` 的用户名。
|
||||
- `--auth_password <password>`：访问 `clone_addr` 的密码。
|
||||
- `--auth_token <token>`：访问 `clone_addr` 的个人令牌。
|
||||
- `--owner_name lunny`：如果非空，数据将存储在具有所有者名称的目录中。
|
||||
- `--repo_name tango`：如果非空，数据将存储在具有存储库名称的目录中。
|
||||
- `--units <units>`：要迁移的项目，一个或多个项目应以逗号分隔。允许的项目有 wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments。如果为空，则表示所有项目。
|
||||
|
||||
### restore-repo
|
||||
|
||||
`restore-repo` 从磁盘目录中还原存储库数据：
|
||||
|
||||
- 选项：
|
||||
- `--repo_dir dir`，`-r dir`：还原数据的存储库目录路径。
|
||||
- `--owner_name lunny`：还原目标所有者名称。
|
||||
- `--repo_name tango`：还原目标存储库名称。
|
||||
- `--units <units>`：要还原的项目，一个或多个项目应以逗号分隔。允许的项目有 wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments。如果为空，则表示所有项目。
|
||||
|
||||
### actions generate-runner-token
|
||||
|
||||
生成一个供 Runner 使用的新令牌，用于向服务器注册。
|
||||
|
||||
- 选项：
|
||||
- `--scope {owner}[/{repo}]`，`-s {owner}[/{repo}]`：限制 Runner 的范围，没有范围表示该 Runner 可用于所有仓库，但你也可以将其限制为特定的仓库或所有者。
|
||||
|
||||
要注册全局 Runner：
|
||||
|
||||
```
|
||||
gitea actions generate-runner-token
|
||||
```
|
||||
|
||||
要注册特定组织的 Runner，例如 `org`：
|
||||
|
||||
```
|
||||
gitea actions generate-runner-token -s org
|
||||
```
|
||||
|
||||
要注册特定仓库的 Runner，例如 `username/test-repo`：
|
||||
|
||||
```
|
||||
gitea actions generate-runner-token -s username/test-repo
|
||||
```
|
||||
@@ -1,520 +0,0 @@
|
||||
---
|
||||
date: "2016-12-26T16:00:00+02:00"
|
||||
slug: "config-cheat-sheet"
|
||||
sidebar_position: 30
|
||||
aliases:
|
||||
- /zh-cn/config-cheat-sheet
|
||||
---
|
||||
|
||||
# 配置说明
|
||||
|
||||
这是针对 Gitea 配置文件的说明，你可以了解 Gitea 的强大配置。需要说明的是，你的所有改变请修改 `custom/conf/app.ini` 文件而不是源文件。
|
||||
所有默认值可以通过 [app.example.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) 查看到。
|
||||
如果你发现 `%(X)s` 这样的内容，请查看 [ini](https://github.com/go-ini/ini/#recursive-values) 这里的说明。
|
||||
标注了 :exclamation: 的配置项表明除非你真的理解这个配置项的意义，否则最好使用默认值。
|
||||
|
||||
## ⚠️ 时效性警告 ⚠️
|
||||
|
||||
此文档的内容可能过于陈旧或者错误，请参考英文文档。
|
||||
|
||||
## Overall (`DEFAULT`)
|
||||
|
||||
- `APP_NAME`: 应用名称，改成你希望的名字。
|
||||
- `RUN_USER`: 运行 Gitea 的用户，推荐使用 `git`；如果在你自己的个人电脑使用改成你自己的用户名。如果设置不正确，Gitea 可能崩溃。
|
||||
- `RUN_MODE`: 从性能考虑，如果在产品级的服务上改成 `prod`。如果您使用安装向导安装的那么会自动设置为 `prod`。
|
||||
|
||||
## Repository (`repository`)
|
||||
|
||||
- `ROOT`: 存放 git 工程的根目录。这里必须填绝对路径，默认值是 `~/<username>/gitea-repositories`。
|
||||
- `SCRIPT_TYPE`: 服务器支持的 Shell 类型，通常是 `bash`，但有些服务器也有可能是 `sh`。
|
||||
- `ANSI_CHARSET`: 默认字符编码。
|
||||
- `FORCE_PRIVATE`: 强制所有 git 工程必须私有。
|
||||
- `DEFAULT_PRIVATE`: 默认创建的 git 工程为私有。 可以是`last`, `private` 或 `public`。默认值是 `last`表示用户最后创建的 Repo 的选择。
|
||||
- `DEFAULT_PUSH_CREATE_PRIVATE`: **true**: 通过 `push-to-create` 方式创建的仓库是否默认为私有仓库.
|
||||
- `MAX_CREATION_LIMIT`: 全局最大每个用户创建的 git 工程数目， `-1` 表示没限制。
|
||||
|
||||
### Repository - Release (`repository.release`)
|
||||
|
||||
- `ALLOWED_TYPES`: **_empty_**: 允许扩展名的列表，用逗号分隔 (`.zip`), mime 类型 (`text/plain`) 或者匹配符号 (`image/*`, `audio/*`, `video/*`). 空值或者 `*/*` 允许所有类型。
|
||||
- `DEFAULT_PAGING_NUM`: **10**: 默认的发布版本页面分页。
|
||||
|
||||
## UI (`ui`)
|
||||
|
||||
- `EXPLORE_PAGING_NUM`: 探索页面每页显示的仓库数量。
|
||||
- `ISSUE_PAGING_NUM`: 工单页面每页显示的工单数量。
|
||||
- `MEMBERS_PAGING_NUM`: **20**: 组织成员页面每页显示的成员数量。
|
||||
- `FEED_MAX_COMMIT_NUM`: 活动流页面显示的最大提交数量。
|
||||
|
||||
### UI - Admin (`ui.admin`)
|
||||
|
||||
- `USER_PAGING_NUM`: 用户管理页面每页显示的用户数量。
|
||||
- `REPO_PAGING_NUM`: 仓库管理页面每页显示的仓库数量。
|
||||
- `NOTICE_PAGING_NUM`: 系统提示页面每页显示的提示数量。
|
||||
- `ORG_PAGING_NUM`: 组织管理页面每页显示的组织数量。
|
||||
|
||||
## Markdown (`markdown`)
|
||||
|
||||
- `ENABLE_HARD_LINE_BREAK`: 是否启用硬换行扩展。
|
||||
|
||||
## Server (`server`)
|
||||
|
||||
- `PROTOCOL`: 可选 `http` 或 `https`。
|
||||
- `DOMAIN`: 服务器域名。
|
||||
- `ROOT_URL`: Gitea 服务器的对外 URL。
|
||||
- `HTTP_ADDR`: HTTP 监听地址。
|
||||
- `HTTP_PORT`: HTTP 监听端口。
|
||||
- `DISABLE_SSH`: 是否禁用 SSH。
|
||||
- `START_SSH_SERVER`: 是否启用内部 SSH 服务器。
|
||||
- `SSH_PORT`: SSH 端口，默认为 `22`。
|
||||
- `OFFLINE_MODE`: 针对静态和头像文件禁用 CDN。
|
||||
- `DISABLE_ROUTER_LOG`: 关闭日志中的路由日志。
|
||||
- `CERT_FILE`: 启用 HTTPS 的证书文件。
|
||||
- `KEY_FILE`: 启用 HTTPS 的密钥文件。
|
||||
- `STATIC_ROOT_PATH`: 存放模板和静态文件的根目录，默认是 Gitea 的根目录。
|
||||
- `STATIC_CACHE_TIME`: **6h**: 静态资源文件，包括 `custom/`, `public/` 和所有上传的头像的浏览器缓存时间。
|
||||
- `ENABLE_GZIP`: 启用实时生成的数据启用 GZIP 压缩，不包括静态资源。
|
||||
- `LANDING_PAGE`: 未登录用户的默认页面，可选 `home` 或 `explore`。
|
||||
|
||||
- `LFS_START_SERVER`: 是否启用 git-lfs 支持. 可以为 `true` 或 `false`， 默认是 `false`。
|
||||
- `LFS_JWT_SECRET`: LFS 认证密钥，改成自己的。
|
||||
- `LFS_CONTENT_PATH`: **已废弃**, 存放 lfs 命令上传的文件的地方，默认是 `data/lfs`。**废弃** 请使用 `[lfs]` 的设置。
|
||||
|
||||
## Database (`database`)
|
||||
|
||||
- `DB_TYPE`: 数据库类型，可选 `mysql`, `postgres`, `mssql` 或 `sqlite3`。
|
||||
- `HOST`: 数据库服务器地址和端口。
|
||||
- `NAME`: 数据库名称。
|
||||
- `USER`: 数据库用户名。
|
||||
- `PASSWD`: 数据库用户密码。
|
||||
- `SSL_MODE`: MySQL 或 PostgreSQL 数据库是否启用 SSL 模式。
|
||||
- `CHARSET`: **utf8mb4**: 仅当数据库为 MySQL 时有效, 可以为 "utf8" 或 "utf8mb4"。注意：如果使用 "utf8mb4"，你的 MySQL InnoDB 版本必须在 5.6 以上。
|
||||
- `PATH`: SQLite3 数据文件存放路径。
|
||||
- `LOG_SQL`: **false**: 显示生成的 SQL，默认为真。
|
||||
- `MAX_IDLE_CONNS` **0**: 最大空闲数据库连接
|
||||
- `CONN_MAX_LIFETIME` **3s**: 数据库连接最大存活时间
|
||||
|
||||
## Indexer (`indexer`)
|
||||
|
||||
- `ISSUE_INDEXER_TYPE`: **bleve**: 工单索引类型，当前支持 `bleve`, `db` 和 `elasticsearch`，当为 `db` 时其它工单索引项可不用设置。
|
||||
- `ISSUE_INDEXER_CONN_STR`: \*\*\*\*: 工单索引连接字符串，仅当 ISSUE_INDEXER_TYPE 为 `elasticsearch` 时有效。例如: http://elastic:changeme@localhost:9200
|
||||
- `ISSUE_INDEXER_NAME`: **gitea_issues**: 工单索引名称，仅当 ISSUE_INDEXER_TYPE 为 `elasticsearch` 时有效。
|
||||
- `ISSUE_INDEXER_PATH`: **indexers/issues.bleve**: 工单索引文件存放路径，当索引类型为 `bleve` 时有效。
|
||||
|
||||
- `REPO_INDEXER_ENABLED`: **false**: 是否启用代码搜索（启用后会占用比较大的磁盘空间，如果是 bleve 可能需要占用约 6 倍存储空间）。
|
||||
- `REPO_INDEXER_TYPE`: **bleve**: 代码搜索引擎类型，可以为 `bleve` 或者 `elasticsearch`。
|
||||
- `REPO_INDEXER_PATH`: **indexers/repos.bleve**: 用于代码搜索的索引文件路径。
|
||||
- `REPO_INDEXER_CONN_STR`: \*\*\*\*: 代码搜索引擎连接字符串，当 `REPO_INDEXER_TYPE` 为 `elasticsearch` 时有效。例如： http://elastic:changeme@localhost:9200
|
||||
- `REPO_INDEXER_NAME`: **gitea_codes**: 代码搜索引擎的名字，当 `REPO_INDEXER_TYPE` 为 `elasticsearch` 时有效。
|
||||
|
||||
- `MAX_FILE_SIZE`: **1048576**: 进行解析的源代码文件的最大长度，小于该值时才会索引。
|
||||
|
||||
## Security (`security`)
|
||||
|
||||
- `INSTALL_LOCK`: 是否允许运行安装向导，(跟管理员账号有关，十分重要)。
|
||||
- `SECRET_KEY`: 全局服务器安全密钥 **最好改成你自己的** (当你运行安装向导的时候会被设置为一个随机值)。
|
||||
- `LOGIN_REMEMBER_DAYS`: Cookie 保存时间，单位天。
|
||||
- `COOKIE_USERNAME`: 保存用户名的 cookie 名称。
|
||||
- `COOKIE_REMEMBER_NAME`: 保存自动登录信息的 cookie 名称。
|
||||
- `REVERSE_PROXY_AUTHENTICATION_USER`: 反向代理认证的 HTTP 头名称。
|
||||
|
||||
## Service (`service`)
|
||||
|
||||
- `ACTIVE_CODE_LIVE_MINUTES`: 登录验证码失效时间，单位分钟。
|
||||
- `RESET_PASSWD_CODE_LIVE_MINUTES`: 重置密码失效时间，单位分钟。
|
||||
- `REGISTER_EMAIL_CONFIRM`: 启用注册邮件激活，前提是 `Mailer` 已经启用。
|
||||
- `REGISTER_MANUAL_CONFIRM`: **false**: 新注册用户必须由管理员手动激活,启用此选项需取消`REGISTER_EMAIL_CONFIRM`.
|
||||
- `DISABLE_REGISTRATION`: 禁用注册，启用后只能用管理员添加用户。
|
||||
- `SHOW_REGISTRATION_BUTTON`: 是否显示注册按钮。
|
||||
- `REQUIRE_SIGNIN_VIEW`: 是否所有页面都必须登录后才可访问。
|
||||
- `ENABLE_CACHE_AVATAR`: 是否缓存来自 Gravatar 的头像。
|
||||
- `ENABLE_NOTIFY_MAIL`: 是否发送工单创建等提醒邮件，需要 `Mailer` 被激活。
|
||||
- `ENABLE_REVERSE_PROXY_AUTHENTICATION`: 允许反向代理认证，更多细节见：https://github.com/gogits/gogs/issues/165
|
||||
- `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION`: 允许通过反向认证做自动注册。
|
||||
- `ENABLE_CAPTCHA`: **false**: 注册时使用图片验证码。
|
||||
- `REQUIRE_CAPTCHA_FOR_LOGIN`: **false**: 登录时需要图片验证码。需要同时开启 `ENABLE_CAPTCHA`。
|
||||
- `CAPTCHA_TYPE`: **image**: \[image, recaptcha, hcaptcha, mcaptcha, cfturnstile\]，人机验证类型，分别表示图片认证、 recaptcha 、 hcaptcha 、mcaptcha 、和 cloudlfare 的 turnstile。
|
||||
- `RECAPTCHA_SECRET`: **""**: recaptcha 服务的密钥，可在 https://www.google.com/recaptcha/admin 获取。
|
||||
- `RECAPTCHA_SITEKEY`: **""**: recaptcha 服务的网站密钥 ，可在 https://www.google.com/recaptcha/admin 获取。
|
||||
- `RECAPTCHA_URL`: **https://www.google.com/recaptcha/**: 设置 recaptcha 的 url 。
|
||||
- `HCAPTCHA_SECRET`: **""**: hcaptcha 服务的密钥，可在 https://www.hcaptcha.com/ 获取。
|
||||
- `HCAPTCHA_SITEKEY`: **""**: hcaptcha 服务的网站密钥，可在 https://www.hcaptcha.com/ 获取。
|
||||
- `MCAPTCHA_SECRET`: **""**: mCaptcha 服务的密钥。
|
||||
- `MCAPTCHA_SITEKEY`: **""**: mCaptcha 服务的网站密钥。
|
||||
- `MCAPTCHA_URL` **https://demo.mcaptcha.org/**: 设置 remCaptchacaptcha 的 url 。
|
||||
- `CF_TURNSTILE_SECRET` **""**: cloudlfare turnstile 服务的密钥，可在 https://dash.cloudflare.com/?to=/:account/turnstile 获取。
|
||||
- `CF_TURNSTILE_SITEKEY` **""**: cloudlfare turnstile 服务的网站密钥 ，可在 https://www.google.com/recaptcha/admin 获取。
|
||||
|
||||
### Service - Expore (`service.explore`)
|
||||
|
||||
- `REQUIRE_SIGNIN_VIEW`: **false**: 仅允许已登录的用户查看探索页面。
|
||||
- `DISABLE_USERS_PAGE`: **false**: 不显示用户探索页面。
|
||||
|
||||
## Webhook (`webhook`)
|
||||
|
||||
- `QUEUE_LENGTH`: 说明: Hook 任务队列长度。
|
||||
- `DELIVER_TIMEOUT`: 请求 webhooks 的超时时间，单位秒。
|
||||
- `SKIP_TLS_VERIFY`: 是否允许不安全的证书。
|
||||
- `PAGING_NUM`: 每页显示的 Webhook 历史数量。
|
||||
- `PROXY_URL`: \*\*\*\*: 代理服务器网址，支持 http://, https//, socks://, 为空将使用环境变量中的 http_proxy/https_proxy 设置。
|
||||
- `PROXY_HOSTS`: \***_: 逗号分隔的需要代理的域名或 IP 地址。支持 _ 号匹配符，使用 ** 匹配所有域名和 IP 地址。
|
||||
|
||||
## Mailer (`mailer`)
|
||||
|
||||
- `ENABLED`: 是否启用邮件服务。
|
||||
- `DISABLE_HELO`: 禁用 HELO 命令。
|
||||
- `HELO_HOSTNAME`: 自定义主机名来回应 HELO 命令。
|
||||
- `HOST`: SMTP 主机地址和端口 (例如：smtp.gitea.io:587)。
|
||||
- `FROM`: 邮件发送地址，RFC 5322. 这里可以填一个邮件地址或者 "Name" \<email@example.com\> 格式。
|
||||
- `USER`: 用户名(通常就是邮件地址)。
|
||||
- `PASSWD`: 密码。
|
||||
- `SKIP_VERIFY`: 忽略证书验证。
|
||||
|
||||
说明：实际上 Gitea 仅仅支持基于 STARTTLS 的 SMTP。
|
||||
|
||||
## Cache (`cache`)
|
||||
|
||||
- `ENABLED`: **true**: 是否启用。
|
||||
- `ADAPTER`: **memory**: 缓存引擎，可以为 `memory`, `redis` 或 `memcache`。
|
||||
- `INTERVAL`: **60**: 只对内存缓存有效，GC 间隔，单位秒。
|
||||
- `HOST`: **_empty_**: 针对 redis 和 memcache 有效，主机地址和端口。
|
||||
- Redis: `network=tcp,addr=127.0.0.1:6379,password=macaron,db=0,pool_size=100,idle_timeout=180`
|
||||
- Memache: `127.0.0.1:9090;127.0.0.1:9091`
|
||||
- `ITEM_TTL`: **16h**: 缓存项目失效时间，设置为 -1 则禁用缓存。
|
||||
|
||||
## Cache - LastCommitCache settings (`cache.last_commit`)
|
||||
|
||||
- `ENABLED`: **true**: 是否启用。
|
||||
- `ITEM_TTL`: **8760h**: 缓存项目失效时间，设置为 -1 则禁用缓存。
|
||||
- `COMMITS_COUNT`: **1000**: 仅当仓库的提交数大于时才启用缓存。
|
||||
|
||||
## Session (`session`)
|
||||
|
||||
- `PROVIDER`: Session 内容存储方式，可选 `memory`, `file`, `redis` 或 `mysql`。
|
||||
- `PROVIDER_CONFIG`: 如果是文件，那么这里填根目录；其他的要填主机地址和端口。
|
||||
- `COOKIE_SECURE`: **_empty_**: `true` 或 `false`。启用此选项以强制在所有会话访问中使用 HTTPS。如果没有设置，当 ROOT_URL 是 https 链接的时候默认设置为 true。
|
||||
- `GC_INTERVAL_TIME`: Session 失效时间。
|
||||
|
||||
## Picture (`picture`)
|
||||
|
||||
- `GRAVATAR_SOURCE`: 头像来源，可以是 `gravatar`, `duoshuo` 或者类似 `http://cn.gravatar.com/avatar/` 的来源
|
||||
- `DISABLE_GRAVATAR`: 开启则只使用内部头像。
|
||||
- `ENABLE_FEDERATED_AVATAR`: 启用头像联盟支持 (参见 http://www.libravatar.org)
|
||||
|
||||
- `AVATAR_STORAGE_TYPE`: **local**: 头像存储类型，可以为 `local` 或 `minio`，分别支持本地文件系统和 minio 兼容的 API。
|
||||
- `AVATAR_UPLOAD_PATH`: **data/avatars**: 存储头像的文件系统路径。
|
||||
- `AVATAR_MAX_WIDTH`: **4096**: 头像最大宽度，单位像素。
|
||||
- `AVATAR_MAX_HEIGHT`: **4096**: 头像最大高度，单位像素。
|
||||
- `AVATAR_MAX_FILE_SIZE`: **1048576** (1MiB): 头像最大大小。
|
||||
|
||||
- `REPOSITORY_AVATAR_STORAGE_TYPE`: **local**: 仓库头像存储类型，可以为 `local` 或 `minio`，分别支持本地文件系统和 minio 兼容的 API。
|
||||
- `REPOSITORY_AVATAR_UPLOAD_PATH`: **data/repo-avatars**: 存储仓库头像的路径。
|
||||
- `REPOSITORY_AVATAR_FALLBACK`: **none**: 当头像丢失时的处理方式
|
||||
- none = 不显示头像
|
||||
- random = 显示随机生成的头像
|
||||
- image = 显示默认头像，通过 `REPOSITORY_AVATAR_FALLBACK_IMAGE` 设置
|
||||
- `REPOSITORY_AVATAR_FALLBACK_IMAGE`: **/img/repo_default.png**: 默认仓库头像
|
||||
|
||||
## Attachment (`attachment`)
|
||||
|
||||
- `ENABLED`: 是否允许用户上传附件。
|
||||
- `ALLOWED_TYPES`: 允许上传的附件类型。比如：`image/jpeg|image/png`，用 `*/*` 表示允许任何类型。
|
||||
- `MAX_SIZE`: 附件最大限制，单位 MB，比如： `4`。
|
||||
- `MAX_FILES`: 一次最多上传的附件数量，比如： `5`。
|
||||
- `STORAGE_TYPE`: **local**: 附件存储类型，`local` 将存储到本地文件夹， `minio` 将存储到 s3 兼容的对象存储服务中。
|
||||
- `PATH`: **attachments**: 存储附件的路径，仅当 STORAGE_TYPE 为 `local` 时可用。如果是相对路径，将会被解析为 `${AppDataPath}/${attachment.PATH}`.
|
||||
- `MINIO_ENDPOINT`: **localhost:9000**: Minio 终端，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID ，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_BUCKET`: **gitea**: Minio bucket to store the attachments，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_LOCATION`: **us-east-1**: Minio location to create bucket，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_BASE_PATH`: **attachments/**: Minio base path on the bucket，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_USE_SSL`: **false**: Minio enabled ssl，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
|
||||
关于 `ALLOWED_TYPES`， 在 (\*)unix 系统中可以使用`file -I <filename>` 来快速获得对应的 `MIME type`。
|
||||
|
||||
```shell
|
||||
$ file -I test00.tar.xz
|
||||
test00.tar.xz: application/x-xz; charset=binary
|
||||
|
||||
$ file --mime test00.xlsx
|
||||
test00.xlsx: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; charset=binary
|
||||
|
||||
file -I test01.xls
|
||||
test01.xls: application/vnd.ms-excel; charset=binary
|
||||
```
|
||||
|
||||
## Log (`log`)
|
||||
|
||||
- `ROOT_PATH`: 日志文件根目录。
|
||||
- `MODE`: 日志记录模式，默认是为 `console`。如果要写到多个通道，用逗号分隔
|
||||
- `LEVEL`: 日志级别，默认为 `Trace`。
|
||||
- `DISABLE_ROUTER_LOG`: 关闭日志中的路由日志。
|
||||
- `ENABLE_ACCESS_LOG`: 是否开启 Access Log, 默认为 false。
|
||||
- `ACCESS_LOG_TEMPLATE`: `access.log` 输出内容的模板，默认模板：**`{{.Ctx.RemoteHost}} - {{.Identity}} {{.Start.Format "[02/Jan/2006:15:04:05 -0700]" }} "{{.Ctx.Req.Method}} {{.Ctx.Req.URL.RequestURI}} {{.Ctx.Req.Proto}}" {{.ResponseWriter.Status}} {{.ResponseWriter.Size}} "{{.Ctx.Req.Referer}}" "{{.Ctx.Req.UserAgent}}"`**
|
||||
模板支持以下参数:
|
||||
- `Ctx`: 请求上下文。
|
||||
- `Identity`: 登录用户名，默认: “`-`”。
|
||||
- `Start`: 请求开始时间。
|
||||
- `ResponseWriter`:
|
||||
- `RequestID`: 从请求头中解析得到的与 `REQUEST_ID_HEADERS` 匹配的值，默认: “`-`”。
|
||||
- 一定要谨慎配置该模板，否则可能会引起 panic.
|
||||
- `REQUEST_ID_HEADERS`: 从 Request Header 中匹配指定 Key，并将匹配到的值输出到 `access.log` 中(需要在 `ACCESS_LOG_TEMPLATE` 中指定输出位置)。如果在该参数中配置多个 Key， 请用逗号分割，程序将按照配置的顺序进行匹配。
|
||||
- 示例：
|
||||
- 请求头： X-Request-ID: **test-id-123**
|
||||
- 配置文件： REQUEST_ID_HEADERS = X-Request-ID
|
||||
- 日志输出： 127.0.0.1:58384 - - [14/Feb/2023:16:33:51 +0800] "**test-id-123**" ...
|
||||
|
||||
## Cron (`cron`)
|
||||
|
||||
- `ENABLED`: 是否在后台运行定期任务。
|
||||
- `RUN_AT_START`: 是否启动时自动运行。
|
||||
- `SCHEDULE` 所接受的格式
|
||||
- 完整 crontab 控制, 例如 `* * * * * ?`
|
||||
- 描述符, 例如 `@midnight`, `@every 1h30m` ...
|
||||
- 更多细节参见 [cron api 文档](https://pkg.go.dev/github.com/gogs/cron@v0.0.0-20171120032916-9f6c956d3e14)
|
||||
|
||||
### Cron - Update Mirrors (`cron.update_mirrors`)
|
||||
|
||||
- `SCHEDULE`: 自动同步镜像仓库的 Cron 语法，比如：`@every 1h`。
|
||||
|
||||
### Cron - Repository Health Check (`cron.repo_health_check`)
|
||||
|
||||
- `SCHEDULE`: 仓库健康监测的 Cron 语法，比如：`@midnight`。
|
||||
- `TIMEOUT`: 仓库健康监测的超时时间，比如：`60s`.
|
||||
- `ARGS`: 执行 `git fsck` 命令的参数，比如：`--unreachable --tags`。
|
||||
|
||||
### Cron - Repository Statistics Check (`cron.check_repo_stats`)
|
||||
|
||||
- `RUN_AT_START`: 是否启动时自动运行仓库统计。
|
||||
- `SCHEDULE`: 仓库统计时的 Cron 语法，比如：`@midnight`.
|
||||
|
||||
### Cron - Update Migration Poster ID (`cron.update_migration_poster_id`)
|
||||
|
||||
- `SCHEDULE`: **@midnight** : 每次同步的间隔时间。此任务总是在启动时自动进行。
|
||||
|
||||
## Git (`git`)
|
||||
|
||||
- `MAX_GIT_DIFF_LINES`: 比较视图中，一个文件最多显示行数。
|
||||
- `MAX_GIT_DIFF_LINE_CHARACTERS`: 比较视图中一行最大字符数。
|
||||
- `MAX_GIT_DIFF_FILES`: 比较视图中的最大现实文件数目。
|
||||
- `GC_ARGS`: 执行 `git gc` 命令的参数, 比如： `--aggressive --auto`。
|
||||
|
||||
## Git - 超时设置 (`git.timeout`)
|
||||
|
||||
- `DEFAUlT`: **360**: Git 操作默认超时时间，单位秒
|
||||
- `MIGRATE`: **600**: 迁移外部仓库时的超时时间，单位秒
|
||||
- `MIRROR`: **300**: 镜像外部仓库的超时时间，单位秒
|
||||
- `CLONE`: **300**: 内部仓库间克隆的超时时间，单位秒
|
||||
- `PULL`: **300**: 内部仓库间拉取的超时时间，单位秒
|
||||
- `GC`: **60**: git 仓库 GC 的超时时间，单位秒
|
||||
- `ENABLE_AUTO_GIT_WIRE_PROTOCOL`: **true**: 是否根据 Git Wire Protocol 协议支持情况自动切换版本，当 git 版本在 2.18 及以上时会自动切换到版本 2。为 `false` 则不切换。
|
||||
|
||||
## API (`api`)
|
||||
|
||||
- `ENABLE_SWAGGER`: **true**: 是否启用 swagger 路由 /api/swagger, /api/v1/swagger etc. endpoints. True 或 false.
|
||||
- `MAX_RESPONSE_ITEMS`: **50**: 一个页面最大的项目数。
|
||||
- `DEFAULT_PAGING_NUM`: **30**: API 中默认分页条数。
|
||||
- `DEFAULT_GIT_TREES_PER_PAGE`: **1000**: GIT TREES API 每页的默认最大项数.
|
||||
- `DEFAULT_MAX_BLOB_SIZE`: **10485760**: BLOBS API 默认最大大小.
|
||||
|
||||
## Markup (`markup`)
|
||||
|
||||
外部渲染工具支持，你可以用你熟悉的文档渲染工具. 比如一下将新增一个名字为 `asciidoc` 的渲染工具 which is followed `markup.` ini section. And there are some config items below.
|
||||
|
||||
```ini
|
||||
[markup.asciidoc]
|
||||
ENABLED = false
|
||||
NEED_POSTPROCESS = true
|
||||
FILE_EXTENSIONS = .adoc,.asciidoc
|
||||
RENDER_COMMAND = "asciidoctor --embedded --safe-mode=secure --out-file=- -"
|
||||
IS_INPUT_FILE = false
|
||||
```
|
||||
|
||||
- ENABLED: 是否启用，默认为 false。
|
||||
- NEED_POSTPROCESS: **true** 设置为 true 则会替换渲染文件中的内部链接和 Commit ID 等。
|
||||
- FILE_EXTENSIONS: 关联的文档的扩展名，多个扩展名用都好分隔。
|
||||
- RENDER_COMMAND: 工具的命令行命令及参数。
|
||||
- IS_INPUT_FILE: 输入方式是最后一个参数为文件路径还是从标准输入读取。
|
||||
- RENDER_CONTENT_MODE: **sanitized** 内容如何被渲染。
|
||||
- sanitized: 对内容进行净化并渲染到当前页面中，仅有一部分 HTML 标签和属性是被允许的。
|
||||
- no-sanitizer: 禁用净化器，把内容渲染到当前页面中。此模式是**不安全**的，如果内容中含有恶意代码，可能会导致 XSS 攻击。
|
||||
- iframe: 把内容渲染在一个独立的页面中并使用 iframe 嵌入到当前页面中。使用的 iframe 工作在沙箱模式并禁用了同源请求，JS 代码被安全的从父页面中隔离出去。
|
||||
|
||||
以下两个环境变量将会被传递给渲染命令：
|
||||
|
||||
- `GITEA_PREFIX_SRC`：包含当前的`src`路径的 URL 前缀，可以被用于链接的前缀。
|
||||
- `GITEA_PREFIX_RAW`：包含当前的`raw`路径的 URL 前缀，可以被用于图片的前缀。
|
||||
|
||||
如果 `RENDER_CONTENT_MODE` 为 `sanitized`，则 Gitea 支持自定义渲染 HTML 的净化策略。以下例子将用 pandoc 支持 KaTeX 输出。
|
||||
|
||||
```ini
|
||||
[markup.sanitizer.TeX]
|
||||
; Pandoc renders TeX segments as <span>s with the "math" class, optionally
|
||||
; with "inline" or "display" classes depending on context.
|
||||
ELEMENT = span
|
||||
ALLOW_ATTR = class
|
||||
REGEXP = ^\s*((math(\s+|$)|inline(\s+|$)|display(\s+|$)))+
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
- `ELEMENT`: 将要被应用到该策略的 HTML 元素，不能为空。
|
||||
- `ALLOW_ATTR`: 将要被应用到该策略的属性，不能为空。
|
||||
- `REGEXP`: 正则表达式，用来匹配属性的内容。如果为空，则跟属性内容无关。
|
||||
- `ALLOW_DATA_URI_IMAGES`: **false** 允许 data uri 图片 (`<img src="data:image/png;base64,..."/>`)。
|
||||
|
||||
多个净化规则可以被同时定义，只要 section 名称最后一位不重复即可。如： `[markup.sanitizer.TeX-2]`。
|
||||
为了针对一种渲染类型进行一个特殊的净化策略，必须使用形如 `[markup.sanitizer.asciidoc.rule-1]` 的方式来命名 section。
|
||||
如果此规则没有匹配到任何渲染类型，它将会被应用到所有的渲染类型。
|
||||
|
||||
## Time (`time`)
|
||||
|
||||
- `FORMAT`: 显示在界面上的时间格式。比如： RFC1123 或者 2006-01-02 15:04:05
|
||||
- `DEFAULT_UI_LOCATION`: 默认显示在界面上的时区，默认为本地时区。比如： Asia/Shanghai
|
||||
|
||||
## Task (`task`)
|
||||
|
||||
- `QUEUE_TYPE`: **channel**: 任务队列类型，可以为 `channel` 或 `redis`。
|
||||
- `QUEUE_LENGTH`: **1000**: 任务队列长度，当 `QUEUE_TYPE` 为 `channel` 时有效。
|
||||
- `QUEUE_CONN_STR`: **addrs=127.0.0.1:6379 db=0**: 任务队列连接字符串，当 `QUEUE_TYPE` 为 `redis` 时有效。如果 redis 有密码，则可以 `addrs=127.0.0.1:6379 password=123 db=0`。
|
||||
|
||||
## Migrations (`migrations`)
|
||||
|
||||
- `MAX_ATTEMPTS`: **3**: 在迁移过程中的 http/https 请求重试次数。
|
||||
- `RETRY_BACKOFF`: **3**: 等待下一次重试的时间，单位秒。
|
||||
- `ALLOWED_DOMAINS`: **_empty_**: 迁移仓库的域名白名单，默认为空，表示允许从任意域名迁移仓库，多个域名用逗号分隔。
|
||||
- `BLOCKED_DOMAINS`: **_empty_**: 迁移仓库的域名黑名单，默认为空，多个域名用逗号分隔。如果 `ALLOWED_DOMAINS` 不为空，此选项有更高的优先级拒绝这里的域名。
|
||||
- `ALLOW_LOCALNETWORKS`: **false**: Allow private addresses defined by RFC 1918
|
||||
- `SKIP_TLS_VERIFY`: **false**: 允许忽略 TLS 认证
|
||||
|
||||
## LFS (`lfs`)
|
||||
|
||||
LFS 的存储配置。 如果 `STORAGE_TYPE` 为空，则此配置将从 `[storage]` 继承。如果不为 `local` 或者 `minio` 而为 `xxx`， 则从 `[storage.xxx]` 继承。当继承时， `PATH` 默认为 `data/lfs`，`MINIO_BASE_PATH` 默认为 `lfs/`。
|
||||
|
||||
- `STORAGE_TYPE`: **local**: LFS 的存储类型，`local` 将存储到磁盘，`minio` 将存储到 s3 兼容的对象服务。
|
||||
- `SERVE_DIRECT`: **false**: 允许直接重定向到存储系统。当前，仅 Minio/S3 是支持的。
|
||||
- `PATH`: 存放 lfs 命令上传的文件的地方，默认是 `data/lfs`。
|
||||
- `MINIO_ENDPOINT`: **localhost:9000**: Minio 地址，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_BUCKET`: **gitea**: Minio bucket，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_LOCATION`: **us-east-1**: Minio location ，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_BASE_PATH`: **lfs/**: Minio base path ，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_USE_SSL`: **false**: Minio 是否启用 ssl ，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
|
||||
|
||||
## Storage (`storage`)
|
||||
|
||||
Attachments, lfs, avatars, repo-avatars, repo-archive, packages, actions_log, actions_artifact 的默认存储配置。
|
||||
|
||||
- `STORAGE_TYPE`: **local**: 附件存储类型，`local` 将存储到本地文件夹， `minio` 将存储到 s3 兼容的对象存储服务中。
|
||||
- `SERVE_DIRECT`: **false**: 允许直接重定向到存储系统。当前，仅 Minio/S3 是支持的。
|
||||
- `MINIO_ENDPOINT`: **localhost:9000**: Minio 终端，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID ，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_BUCKET`: **gitea**: Minio bucket to store the attachments，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_LOCATION`: **us-east-1**: Minio location to create bucket，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
- `MINIO_USE_SSL`: **false**: Minio enabled ssl，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
|
||||
|
||||
以下为推荐的 recommanded storage configuration for minio like below:
|
||||
|
||||
```ini
|
||||
[storage]
|
||||
STORAGE_TYPE = minio
|
||||
; uncomment when STORAGE_TYPE = local
|
||||
; PATH = storage root path
|
||||
; Minio endpoint to connect only available when STORAGE_TYPE is `minio`
|
||||
MINIO_ENDPOINT = localhost:9000
|
||||
; Minio accessKeyID to connect only available when STORAGE_TYPE is `minio`
|
||||
MINIO_ACCESS_KEY_ID =
|
||||
; Minio secretAccessKey to connect only available when STORAGE_TYPE is `minio`
|
||||
MINIO_SECRET_ACCESS_KEY =
|
||||
; Minio bucket to store the attachments only available when STORAGE_TYPE is `minio`
|
||||
MINIO_BUCKET = gitea
|
||||
; Minio location to create bucket only available when STORAGE_TYPE is `minio`
|
||||
MINIO_LOCATION = us-east-1
|
||||
; Minio enabled ssl only available when STORAGE_TYPE is `minio`
|
||||
MINIO_USE_SSL = false
|
||||
; Minio skip SSL verification available when STORAGE_TYPE is `minio`
|
||||
MINIO_INSECURE_SKIP_VERIFY = false
|
||||
SERVE_DIRECT = true
|
||||
```
|
||||
|
||||
默认的，每一个存储都会有各自默认的 BasePath 在同一个 minio 中，默认值如下：
|
||||
|
||||
| storage | default base path |
|
||||
| ----------------- | ------------------ |
|
||||
| attachments | attachments/ |
|
||||
| lfs | lfs/ |
|
||||
| avatars | avatars/ |
|
||||
| repo-avatars | repo-avatars/ |
|
||||
| repo-archive | repo-archive/ |
|
||||
| packages | packages/ |
|
||||
| actions_log | actions_log/ |
|
||||
| actions_artifacts | actions_artifacts/ |
|
||||
|
||||
同时 bucket, basepath or `SERVE_DIRECT` 是可以被覆写的，像如下所示：
|
||||
|
||||
```ini
|
||||
[storage.actions_log]
|
||||
MINIO_BUCKET = gitea_actions_log
|
||||
SERVE_DIRECT = true
|
||||
MINIO_BASE_PATH = my_actions_log/ ; default is actions_log/ if blank
|
||||
```
|
||||
|
||||
当然你也可以完全自定义，像如下
|
||||
|
||||
```ini
|
||||
[lfs]
|
||||
STORAGE_TYPE = my_minio
|
||||
MINIO_BASE_PATH = my_lfs_basepath
|
||||
|
||||
[storage.my_minio]
|
||||
STORAGE_TYPE = minio
|
||||
; Minio endpoint to connect only available when STORAGE_TYPE is `minio`
|
||||
MINIO_ENDPOINT = localhost:9000
|
||||
; Minio accessKeyID to connect only available when STORAGE_TYPE is `minio`
|
||||
MINIO_ACCESS_KEY_ID =
|
||||
; Minio secretAccessKey to connect only available when STORAGE_TYPE is `minio`
|
||||
MINIO_SECRET_ACCESS_KEY =
|
||||
; Minio bucket to store the attachments only available when STORAGE_TYPE is `minio`
|
||||
MINIO_BUCKET = gitea
|
||||
; Minio location to create bucket only available when STORAGE_TYPE is `minio`
|
||||
MINIO_LOCATION = us-east-1
|
||||
; Minio enabled ssl only available when STORAGE_TYPE is `minio`
|
||||
MINIO_USE_SSL = false
|
||||
; Minio skip SSL verification available when STORAGE_TYPE is `minio`
|
||||
MINIO_INSECURE_SKIP_VERIFY = false
|
||||
SERVE_DIRECT = true
|
||||
```
|
||||
|
||||
## Repository Archive Storage (`storage.repo-archive`)
|
||||
|
||||
Repository archive 的存储配置。 如果 `STORAGE_TYPE` 为空，则此配置将从 `[storage]` 继承。如果不为 `local` 或者 `minio` 而为 `xxx`， 则从 `[storage.xxx]` 继承。当继承时， `PATH` 默认为 `data/repo-archive`，`MINIO_BASE_PATH` 默认为 `repo-archive/`。
|
||||
|
||||
- `STORAGE_TYPE`: **local**: Repository archive 的存储类型，`local` 将存储到磁盘，`minio` 将存储到 s3 兼容的对象服务。
|
||||
- `SERVE_DIRECT`: **false**: 允许直接重定向到存储系统。当前，仅 Minio/S3 是支持的。
|
||||
- `PATH`: 存放 Repository archive 上传的文件的地方，默认是 `data/repo-archive`。
|
||||
- `MINIO_ENDPOINT`: **localhost:9000**: Minio 地址，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_BUCKET`: **gitea**: Minio bucket，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_LOCATION`: **us-east-1**: Minio location ，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_BASE_PATH`: **repo-archive/**: Minio base path ，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
- `MINIO_USE_SSL`: **false**: Minio 是否启用 ssl ，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
|
||||
|
||||
## Proxy (`proxy`)
|
||||
|
||||
- `PROXY_ENABLED`: **false**: 是否启用全局代理。如果为否，则不使用代理，环境变量中的代理也不使用
|
||||
- `PROXY_URL`: **_empty_**: 代理服务器地址，支持 http://, https//, socks://，为空则不启用代理而使用环境变量中的 http_proxy/https_proxy
|
||||
- `PROXY_HOSTS`: **_empty_**: 逗号分隔的多个需要代理的网址，支持 \* 号匹配符号， \*\* 表示匹配所有网站
|
||||
|
||||
i.e.
|
||||
|
||||
```ini
|
||||
PROXY_ENABLED = true
|
||||
PROXY_URL = socks://127.0.0.1:1080
|
||||
PROXY_HOSTS = *.github.com
|
||||
```
|
||||
|
||||
## Other (`other`)
|
||||
|
||||
- `SHOW_FOOTER_VERSION`: 为真则在页面底部显示 Gitea 的版本。
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
date: "2017-04-15T14:56:00+02:00"
|
||||
slug: "customizing-gitea"
|
||||
sidebar_position: 100
|
||||
aliases:
|
||||
- /zh-cn/customizing-gitea
|
||||
---
|
||||
|
||||
# 自定义 Gitea 配置
|
||||
|
||||
Gitea 引用 `custom` 目录中的自定义配置文件来覆盖配置、模板等默认配置。
|
||||
|
||||
如果从二进制部署 Gitea ，则所有默认路径都将相对于该 gitea 二进制文件；如果从发行版安装，则可能会将这些路径修改为 Linux 文件系统标准。Gitea
|
||||
将会自动创建包括 `custom/` 在内的必要应用目录，应用本身的配置存放在
|
||||
`custom/conf/app.ini` 当中。在发行版中可能会以 `/etc/gitea/` 的形式为 `custom` 设置一个符号链接，查看配置详情请移步：
|
||||
|
||||
- [快速备忘单](../administration/config-cheat-sheet.md)
|
||||
- [完整配置清单](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
|
||||
|
||||
如果您在 binary 同目录下无法找到 `custom` 文件夹，请检查您的 `GITEA_CUSTOM`
|
||||
环境变量配置， 因为它可能被配置到了其他地方（可能被一些启动脚本设置指定了目录）。
|
||||
|
||||
- [环境变量清单](../administration/environment-variables.md)
|
||||
|
||||
**注：** 必须完全重启 Gitea 以使配置生效。
|
||||
|
||||
## 使用自定义 /robots.txt
|
||||
|
||||
将 [想要展示的内容](http://www.robotstxt.org/) 存放在 `custom` 目录中的
|
||||
`robots.txt` 文件来让 Gitea 使用自定义的`/robots.txt` （默认：空 404）。
|
||||
|
||||
## 使用自定义的公共文件
|
||||
|
||||
将自定义的公共文件（比如页面和图片）作为 webroot 放在 `custom/public/` 中来让 Gitea 提供这些自定义内容（符号链接将被追踪）。
|
||||
|
||||
举例说明：`image.png` 存放在 `custom/public/`中，那么它可以通过链接 http://gitea.domain.tld/assets/image.png 访问。
|
||||
|
||||
## 修改默认头像
|
||||
|
||||
替换以下目录中的 png 图片： `custom/public/img/avatar\_default.png`
|
||||
|
||||
## 自定义 Gitea 页面
|
||||
|
||||
您可以改变 Gitea `custom/templates` 的每个单页面。您可以在 Gitea 源码的 `templates` 目录中找到用于覆盖的模板文件，应用将根据
|
||||
`custom/templates` 目录下的路径结构进行匹配和覆盖。
|
||||
|
||||
包含在 `{{` 和 `}}` 中的任何语句都是 Gitea 的模板语法，如果您不完全理解这些组件，不建议您对它们进行修改。
|
||||
|
||||
### 添加链接和页签
|
||||
|
||||
如果您只是想添加额外的链接到顶部导航栏或额外的选项卡到存储库视图，您可以将它们放在您 `custom/templates/custom/` 目录下的 `extra_links.tmpl` 和 `extra_tabs.tmpl` 文件中。
|
||||
|
||||
举例说明：假设您需要在网站放置一个静态的“关于”页面，您只需将该页面放在您的
|
||||
"custom/public/"目录下（比如 `custom/public/impressum.html`）并且将它与 `custom/templates/custom/extra_links.tmpl` 链接起来即可。
|
||||
|
||||
这个链接应当使用一个名为“item”的 class 来匹配当前样式，您可以使用 `{{AppSubUrl}}` 来获取 base URL:
|
||||
`<a class="item" href="{{AppSubUrl}}/assets/impressum.html">Impressum</a>`
|
||||
|
||||
同理，您可以将页签添加到 `extra_tabs.tmpl` 中，使用同样的方式来添加页签。它的具体样式需要与
|
||||
`templates/repo/header.tmpl` 中已有的其他选项卡的样式匹配
|
||||
([source in GitHub](https://github.com/go-gitea/gitea/blob/main/templates/repo/header.tmpl))
|
||||
|
||||
### 页面的其他新增内容
|
||||
|
||||
除了 `extra_links.tmpl` 和 `extra_tabs.tmpl`，您可以在您的 `custom/templates/custom/` 目录中存放一些其他有用的模板，例如：
|
||||
|
||||
- `header.tmpl`，在 `<head>` 标记结束之前的模板，例如添加自定义 CSS 文件
|
||||
- `body_outer_pre.tmpl`，在 `<body>` 标记开始处的模板
|
||||
- `body_inner_pre.tmpl`，在顶部导航栏之前，但在主 container 内部的模板，例如添加一个 `<div class="full height">`
|
||||
- `body_inner_post.tmpl`，在主 container 结束处的模板
|
||||
- `body_outer_post.tmpl`，在底部 `<footer>` 元素之前.
|
||||
- `footer.tmpl`，在 `<body>` 标签结束处的模板，可以在这里填写一些附加的 Javascript 脚本。
|
||||
|
||||
## 自定义 gitignores，labels， licenses， locales 以及 readmes
|
||||
|
||||
将自定义文件放在 `custom/options` 下相应子的文件夹中即可
|
||||
|
||||
## 更改 Gitea 外观
|
||||
|
||||
Gitea 目前由两种内置主题，分别为默认 `gitea` 主题和深色主题 `arc-green`，您可以通过修改
|
||||
`app.ini` [ui](../administration/config-cheat-sheet.md#界面) 部分的 `DEFAULT_THEME` 的值来变更至一个可用的 Gitea 外观。
|
||||
@@ -1,76 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "email-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-cn/email-setup
|
||||
---
|
||||
|
||||
# Email 设置
|
||||
|
||||
Gitea 具有邮件功能，用于发送事务性邮件（例如注册确认邮件）。它可以配置为使用 Sendmail（或兼容的 MTA，例如 Postfix 和 msmtp）或直接使用 SMTP 服务器。
|
||||
|
||||
## 使用 Sendmail
|
||||
|
||||
使用 `sendmail` 命令作为邮件传输代理（mailer）。
|
||||
|
||||
注意：对于在官方 Gitea Docker 镜像中使用，请使用 SMTP 版本进行配置（请参考下一节）。
|
||||
|
||||
注意：对于面向互联网的网站，请查阅您的 MTA 文档以了解通过 TLS 发送邮件的说明。同时设置 SPF、DMARC 和 DKIM DNS 记录，以使发送的邮件被各个电子邮件提供商接受为合法邮件。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = gitea@mydomain.com
|
||||
PROTOCOL = sendmail
|
||||
SENDMAIL_PATH = /usr/sbin/sendmail
|
||||
SENDMAIL_ARGS = "--" ; 大多数 "sendmail" 程序都接受选项，使用 "--" 将防止电子邮件地址被解释为选项。
|
||||
```
|
||||
|
||||
## 使用 SMTP
|
||||
|
||||
直接使用 SMTP 服务器作为中继。如果您不想在实例上设置 MTA，但在电子邮件提供商那里有一个帐户，这个选项非常有用。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = gitea@mydomain.com
|
||||
PROTOCOL = smtps
|
||||
SMTP_ADDR = mail.mydomain.com
|
||||
SMTP_PORT = 587
|
||||
USER = gitea@mydomain.com
|
||||
PASSWD = `password`
|
||||
```
|
||||
|
||||
重启 Gitea 以使配置更改生效。
|
||||
|
||||
要发送测试邮件以验证设置，请转到 Gitea > 站点管理 > 配置 > SMTP 邮件配置。
|
||||
|
||||
有关所有选项的完整列表，请查看[配置速查表](../administration/config-cheat-sheet.md)。
|
||||
|
||||
请注意：只有在使用 TLS 或 `HOST=localhost` 加密 SMTP 服务器通信时才支持身份验证。TLS 加密可以通过以下方式进行：
|
||||
|
||||
- 通过端口 587 的 STARTTLS（也称为 Opportunistic TLS）。初始连接是明文的，但如果服务器支持，则可以升级为 TLS。
|
||||
- 通过默认端口 465 的 SMTPS 连接。连接到服务器从一开始就使用 TLS。
|
||||
- 使用 `IS_TLS_ENABLED=true` 进行强制的 SMTPS 连接。（这两种方式都被称为 Implicit TLS）
|
||||
这是由于 Go 内部库对 STRIPTLS 攻击的保护机制。
|
||||
|
||||
请注意，自 2018 年起，[RFC8314](https://tools.ietf.org/html/rfc8314#section-3) 推荐使用 Implicit TLS。
|
||||
|
||||
### Gmail
|
||||
|
||||
以下配置应该适用于 Gmail 的 SMTP 服务器：
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
HOST = smtp.gmail.com:465 ; 对于 Gitea >= 1.18.0，删除此行
|
||||
SMTP_ADDR = smtp.gmail.com
|
||||
SMTP_PORT = 465
|
||||
FROM = example.user@gmail.com
|
||||
USER = example.user
|
||||
PASSWD = `***`
|
||||
PROTOCOL = smtps
|
||||
```
|
||||
|
||||
请注意，您需要创建并使用一个 [应用密码](https://support.google.com/accounts/answer/185833?hl=en) 并在您的 Google 帐户上启用 2FA。您将无法直接使用您的 Google 帐户密码。
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
date: "2017-04-08T11:34:00+02:00"
|
||||
slug: "environment-variables"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
- /zh-cn/environment-variables
|
||||
---
|
||||
|
||||
# 环境变量清单
|
||||
|
||||
这里是用来控制 Gitea 行为表现的的环境变量清单，您需要在执行如下 Gitea 启动命令前设置它们来确保配置生效：
|
||||
|
||||
```
|
||||
GITEA_CUSTOM=/home/gitea/custom ./gitea web
|
||||
```
|
||||
|
||||
## Go 的配置
|
||||
|
||||
因为 Gitea 使用 Go 语言编写，因此它使用了一些相关的 Go 的配置参数：
|
||||
|
||||
- `GOOS`
|
||||
- `GOARCH`
|
||||
- [`GOPATH`](https://golang.org/cmd/go/#hdr-GOPATH_environment_variable)
|
||||
|
||||
您可以在[官方文档](https://golang.org/cmd/go/#hdr-Environment_variables)中查阅这些配置参数的详细信息。
|
||||
|
||||
## Gitea 的文件目录
|
||||
|
||||
- `GITEA_WORK_DIR`：工作目录的绝对路径
|
||||
- `GITEA_CUSTOM`：默认情况下 Gitea 使用默认目录 `GITEA_WORK_DIR`/custom，您可以使用这个参数来配置 _custom_ 目录
|
||||
- `GOGS_WORK_DIR`： 已废弃，请使用 `GITEA_WORK_DIR` 替代
|
||||
- `GOGS_CUSTOM`： 已废弃，请使用 `GITEA_CUSTOM` 替代
|
||||
|
||||
## 操作系统配置
|
||||
|
||||
- `USER`：Gitea 运行时使用的系统用户，它将作为一些 repository 的访问地址的一部分
|
||||
- `USERNAME`： 如果没有配置 `USER`， Gitea 将使用 `USERNAME`
|
||||
- `HOME`： 用户的 home 目录，在 Windows 中会使用 `USERPROFILE` 环境变量
|
||||
|
||||
### 仅限于 Windows 的配置
|
||||
|
||||
- `USERPROFILE`： 用户的主目录，如果未配置则会使用 `HOMEDRIVE` + `HOMEPATH`
|
||||
- `HOMEDRIVE`: 用于访问 home 目录的主驱动器路径（C 盘）
|
||||
- `HOMEPATH`：在指定主驱动器下的 home 目录相对路径
|
||||
|
||||
## Miscellaneous
|
||||
|
||||
- `SKIP_MINWINSVC`：如果设置为 1，在 Windows 上不会以 service 的形式运行。
|
||||
@@ -1,195 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "external-renderers"
|
||||
sidebar_position: 60
|
||||
aliases:
|
||||
- /zh-cn/external-renderers
|
||||
---
|
||||
|
||||
# 外部渲染器
|
||||
|
||||
Gitea 通过外部二进制文件支持自定义文件渲染（例如 Jupyter notebooks、asciidoc 等），只需要进行以下步骤：
|
||||
|
||||
- 安装外部二进制文件
|
||||
- 在您的 `app.ini` 文件中添加一些配置
|
||||
- 重新启动 Gitea 实例
|
||||
|
||||
此功能支持整个文件的渲染。如果您想要在 Markdown 中渲染代码块，您需要使用 JavaScript 进行一些操作。请参阅 [自定义 Gitea 配置](../administration/customizing-gitea.md) 页面上的一些示例。
|
||||
|
||||
## 安装外部二进制文件
|
||||
|
||||
为了通过外部二进制文件进行文件渲染，必须安装它们的关联软件包。
|
||||
如果您正在使用 Docker 镜像，则您的 `Dockerfile` 应该包含以下内容：
|
||||
|
||||
```docker
|
||||
FROM docker.gitea.com/gitea:@dockerVersion@
|
||||
[...]
|
||||
|
||||
COPY custom/app.ini /data/gitea/conf/app.ini
|
||||
[...]
|
||||
|
||||
RUN apk --no-cache add asciidoctor freetype freetype-dev gcc g++ libpng libffi-dev py-pip python3-dev py3-pip py3-pyzmq
|
||||
# 安装其他您需要的外部渲染器的软件包
|
||||
|
||||
RUN pip3 install --upgrade pip
|
||||
RUN pip3 install -U setuptools
|
||||
RUN pip3 install jupyter docutils
|
||||
# 在上面添加您需要安装的任何其他 Python 软件包
|
||||
```
|
||||
|
||||
## `app.ini` 文件配置
|
||||
|
||||
在您的自定义 `app.ini` 文件中为每个外部渲染器添加一个 `[markup.XXXXX]` 部分：
|
||||
|
||||
```ini
|
||||
[markup.asciidoc]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .adoc,.asciidoc
|
||||
RENDER_COMMAND = "asciidoctor -s -a showtitle --out-file=- -"
|
||||
; 输入不是标准输入而是文件
|
||||
IS_INPUT_FILE = false
|
||||
|
||||
[markup.jupyter]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .ipynb
|
||||
RENDER_COMMAND = "jupyter nbconvert --stdin --stdout --to html --template basic"
|
||||
IS_INPUT_FILE = false
|
||||
|
||||
[markup.restructuredtext]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .rst
|
||||
RENDER_COMMAND = "timeout 30s pandoc +RTS -M512M -RTS -f rst"
|
||||
IS_INPUT_FILE = false
|
||||
```
|
||||
|
||||
如果您的外部标记语言依赖于在生成的 HTML 元素上的额外类和属性，您可能需要启用自定义的清理策略。Gitea 使用 [`bluemonday`](https://godoc.org/github.com/microcosm-cc/bluemonday) 包作为我们的 HTML 清理器。下面的示例可以用于支持从 [`pandoc`](https://pandoc.org/) 输出的服务器端 [KaTeX](https://katex.org/) 渲染结果。
|
||||
|
||||
```ini
|
||||
[markup.sanitizer.TeX]
|
||||
; Pandoc 渲染 TeX 段落为带有 "math" 类的 <span> 元素，根据上下文可能还带有 "inline" 或 "display" 类。
|
||||
; - 请注意，这与我们的 Markdown 解析器中内置的数学支持不同，后者使用 <code> 元素。
|
||||
ELEMENT = span
|
||||
ALLOW_ATTR = class
|
||||
REGEXP = ^\s*((math(\s+|$)|inline(\s+|$)|display(\s+|$)))+
|
||||
|
||||
[markup.markdown]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .md,.markdown
|
||||
RENDER_COMMAND = pandoc -f markdown -t html --katex
|
||||
```
|
||||
|
||||
您必须在每个部分中定义 `ELEMENT` 和 `ALLOW_ATTR`。
|
||||
|
||||
要定义多个条目，请添加唯一的字母数字后缀（例如，`[markup.sanitizer.1]` 和 `[markup.sanitizer.something]`）。
|
||||
|
||||
要仅为特定的外部渲染器应用清理规则，它们必须使用渲染器名称，例如 `[markup.sanitizer.asciidoc.rule-1]`、`[markup.sanitizer.<renderer>.rule-1]`。
|
||||
|
||||
**注意**：如果规则在渲染器 ini 部分之前定义，或者名称与渲染器不匹配，它将应用于所有渲染器。
|
||||
|
||||
完成配置更改后，请重新启动 Gitea 以使更改生效。
|
||||
|
||||
**注意**：在 Gitea 1.12 之前，存在一个名为 `markup.sanitiser` 的单个部分，其中的键被重新定义为多个规则，但是，这种配置方法存在重大问题，需要通过多个部分进行配置。
|
||||
|
||||
### 示例：HTML
|
||||
|
||||
直接渲染 HTML 文件：
|
||||
|
||||
```ini
|
||||
[markup.html]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .html,.htm
|
||||
RENDER_COMMAND = cat
|
||||
; 输入不是标准输入，而是文件
|
||||
IS_INPUT_FILE = true
|
||||
|
||||
[markup.sanitizer.html.1]
|
||||
ELEMENT = div
|
||||
ALLOW_ATTR = class
|
||||
|
||||
[markup.sanitizer.html.2]
|
||||
ELEMENT = a
|
||||
ALLOW_ATTR = class
|
||||
```
|
||||
|
||||
请注意：此示例中的配置将允许渲染 HTML 文件，并使用 `cat` 命令将文件内容输出为 HTML。此外，配置中的两个清理规则将允许 `<div>` 和 `<a>` 元素使用 `class` 属性。
|
||||
|
||||
在进行配置更改后，请重新启动 Gitea 以使更改生效。
|
||||
|
||||
### 示例：Office DOCX
|
||||
|
||||
使用 [`pandoc`](https://pandoc.org/) 显示 Office DOCX 文件：
|
||||
|
||||
```ini
|
||||
[markup.docx]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .docx
|
||||
RENDER_COMMAND = "pandoc --from docx --to html --self-contained --template /path/to/basic.html"
|
||||
|
||||
[markup.sanitizer.docx.img]
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
在此示例中，配置将允许显示 Office DOCX 文件，并使用 `pandoc` 命令将文件转换为 HTML 格式。同时，清理规则中的 `ALLOW_DATA_URI_IMAGES` 设置为 `true`，允许使用 Data URI 格式的图片。
|
||||
|
||||
模板文件的内容如下：
|
||||
|
||||
```
|
||||
$body$
|
||||
```
|
||||
|
||||
### 示例：Jupyter Notebook
|
||||
|
||||
使用 [`nbconvert`](https://github.com/jupyter/nbconvert) 显示 Jupyter Notebook 文件：
|
||||
|
||||
```ini
|
||||
[markup.jupyter]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .ipynb
|
||||
RENDER_COMMAND = "jupyter-nbconvert --stdin --stdout --to html --template basic"
|
||||
|
||||
[markup.sanitizer.jupyter.img]
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
在此示例中，配置将允许显示 Jupyter Notebook 文件，并使用 `nbconvert` 命令将文件转换为 HTML 格式。同样，清理规则中的 `ALLOW_DATA_URI_IMAGES` 设置为 `true`，允许使用 Data URI 格式的图片。
|
||||
|
||||
在进行配置更改后，请重新启动 Gitea 以使更改生效。
|
||||
|
||||
## 自定义 CSS
|
||||
|
||||
在 `.ini` 文件中，可以使用 `[markup.XXXXX]` 的格式指定外部渲染器，并且由外部渲染器生成的 HTML 将被包装在一个带有 `markup` 和 `XXXXX` 类的 `<div>` 中。`markup` 类提供了预定义的样式（如果 `XXXXX` 是 `markdown`，则使用 `markdown` 类）。否则，您可以使用这些类来针对渲染的 HTML 内容进行定制样式。
|
||||
|
||||
因此，您可以编写一些 CSS 样式：
|
||||
|
||||
```css
|
||||
.markup.XXXXX html {
|
||||
font-size: 100%;
|
||||
overflow-y: scroll;
|
||||
-webkit-text-size-adjust: 100%;
|
||||
-ms-text-size-adjust: 100%;
|
||||
}
|
||||
|
||||
.markup.XXXXX body {
|
||||
color: #444;
|
||||
font-family: Georgia, Palatino, "Palatino Linotype", Times, "Times New Roman",
|
||||
serif;
|
||||
font-size: 12px;
|
||||
line-height: 1.7;
|
||||
padding: 1em;
|
||||
margin: auto;
|
||||
max-width: 42em;
|
||||
background: #fefefe;
|
||||
}
|
||||
|
||||
.markup.XXXXX p {
|
||||
color: orangered;
|
||||
}
|
||||
```
|
||||
|
||||
将您的样式表添加到自定义目录中，例如 `custom/public/css/my-style-XXXXX.css`，并使用自定义的头文件 `custom/templates/custom/header.tmpl` 进行导入：
|
||||
|
||||
```html
|
||||
<link rel="stylesheet" href="{{AppSubUrl}}/assets/css/my-style-XXXXX.css" />
|
||||
```
|
||||
|
||||
通过以上步骤，您可以将自定义的 CSS 样式应用到特定的外部渲染器，使其具有所需的样式效果。
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
date: "2022-08-01T00:00:00+00:00"
|
||||
slug: "fail2ban-setup"
|
||||
sidebar_position: 16
|
||||
aliases:
|
||||
- /zh-cn/fail2ban-setup
|
||||
---
|
||||
|
||||
# 设置 Fail2ban
|
||||
|
||||
**Fail2ban 检查客户端登录日志，将多次登录失败的客户端识别为攻击者并在一段时间内阻止其访问服务。如果你的实例是公开的，这一点尤其重要。请管理员仔细设置 fail2ban，错误的配置将导致防火墙阻止你访问自己的服务器。**
|
||||
|
||||
Gitea 会在日志文件 `log/gitea.log` 中记录登录失败的 CLI、SSH 或 HTTP 客户端 IP 地址，而你需要将 Gitea 的日志输出模式从默认的 `console` 更改为 `file`。这表示将日志输出到文件，使得 fail2ban 可以定期扫描日志内容。
|
||||
|
||||
当用户的身份验证失败时，日志中会记录此类信息：
|
||||
|
||||
```log
|
||||
2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
```log
|
||||
2020/10/15 16:08:44 [E] invalid credentials from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
## Fail2ban 规则
|
||||
|
||||
添加日志过滤器规则到配置文件 `/etc/fail2ban/filter.d/gitea.conf`:
|
||||
|
||||
```ini
|
||||
[Definition]
|
||||
failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST>
|
||||
ignoreregex =
|
||||
```
|
||||
|
||||
添加监狱规则到配置文件 `/etc/fail2ban/jail.d/gitea.conf`:
|
||||
|
||||
```ini
|
||||
[gitea]
|
||||
enabled = true
|
||||
filter = gitea
|
||||
logpath = /var/lib/gitea/log/gitea.log
|
||||
maxretry = 10
|
||||
findtime = 3600
|
||||
bantime = 900
|
||||
action = iptables-allports
|
||||
```
|
||||
|
||||
如果你的 Gitea 实例运行在 Docker 容器中，并且直接将容器端口暴露到外部网络，
|
||||
你还需要添加 `chain="FORWARD"` 到监狱规则配置文件 `/etc/fail2ban/jail.d/gitea-docker.conf`
|
||||
以适应 Docker 的网络转发规则。但如果你在容器的宿主机上使用 Nginx 反向代理连接到 Gitea 则无需这样配置。
|
||||
|
||||
```ini
|
||||
[gitea-docker]
|
||||
enabled = true
|
||||
filter = gitea
|
||||
logpath = /var/lib/gitea/log/gitea.log
|
||||
maxretry = 10
|
||||
findtime = 3600
|
||||
bantime = 900
|
||||
action = iptables-allports[chain="FORWARD"]
|
||||
```
|
||||
|
||||
最后，运行 `systemctl restart fail2ban` 即可应用更改。现在，你可以使用 `systemctl status fail2ban` 检查 fail2ban 运行状态。
|
||||
|
||||
上述规则规定客户端在 1 小时内，如果登录失败的次数达到 10 次，则通过 iptables 锁定该客户端 IP 地址 15 分钟。
|
||||
|
||||
## 设置反向代理
|
||||
|
||||
如果你使用 Nginx 反向代理到 Gitea 实例，你还需要设置 Nginx 的 HTTP 头部值 `X-Real-IP` 将真实的客户端 IP 地址传递给 Gitea。否则 Gitea 程序会将客户端地址错误解析为反向代理服务器的地址，例如回环地址 `127.0.0.1`。
|
||||
|
||||
```
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
```
|
||||
|
||||
额外注意，在 Gitea 的配置文件 `app.ini` 中存在下列默认值：
|
||||
|
||||
```
|
||||
REVERSE_PROXY_LIMIT = 1
|
||||
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.0/8,::1/128
|
||||
```
|
||||
|
||||
`REVERSE_PROXY_LIMIT` 限制反向代理服务器的层数，设置为 `0` 表示不使用这些标头。
|
||||
`REVERSE_PROXY_TRUSTED_PROXIES` 表示受信任的反向代理服务器网络地址，
|
||||
经过该网络地址转发来的流量会经过解析 `X-Real-IP` 头部得到真实客户端地址。
|
||||
（参考 [configuration cheat sheet](../administration/config-cheat-sheet.md#安全性)）
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "git-lfs-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-cn/git-lfs-setup
|
||||
---
|
||||
|
||||
# Git LFS 设置
|
||||
|
||||
要使用 Gitea 内置的 LFS 支持，您需要更新 `app.ini` 文件：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
; 启用 git-lfs 支持。true 或 false，默认为 false。
|
||||
LFS_START_SERVER = true
|
||||
|
||||
[lfs]
|
||||
; 存放 LFS 文件的路径，默认为 data/lfs。
|
||||
PATH = /home/gitea/data/lfs
|
||||
```
|
||||
|
||||
**注意**：LFS 服务器支持需要服务器上安装 Git v2.1.2 以上版本。
|
||||
@@ -1,89 +0,0 @@
|
||||
---
|
||||
date: "2023-04-09T11:00:00+02:00"
|
||||
slug: "https-setup"
|
||||
sidebar_position: 12
|
||||
|
||||
---
|
||||
|
||||
# HTTPS配置
|
||||
|
||||
## 使用内置服务器
|
||||
|
||||
在启用HTTPS之前，确保您拥有有效的SSL/TLS证书。
|
||||
建议在测试和评估情况下使用自签名证书，请运行 `gitea cert --host [HOST]` 以生成自签名证书
|
||||
|
||||
如果您在服务器上使用阿帕奇（Apache）或Nginx，建议参考 [反向代理指南](reverse-proxies.md)。
|
||||
|
||||
要使用Gitea内置HTTPS支持，您必须编辑`app.ini`文件。
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL = https
|
||||
ROOT_URL = https://git.example.com:3000/
|
||||
HTTP_PORT = 3000
|
||||
CERT_FILE = cert.pem
|
||||
KEY_FILE = key.pem
|
||||
```
|
||||
|
||||
请注意，如果您的证书由第三方证书颁发机构签名（即不是自签名的），则 cert.pem 应包含证书链。服务器证书必须是 cert.pem 中的第一个条目，后跟中介（如果有）。不必包含根证书，因为连接客户端必须已经拥有根证书才能建立信任关系。要了解有关配置值的更多信息，请查看 [配置备忘单](../administration/config-cheat-sheet.md#server-server)。
|
||||
|
||||
对于“CERT_FILE”或“KEY_FILE”字段，当文件路径是相对路径时，文件路径相对于“GITEA_CUSTOM”环境变量。它也可以是绝对路径。
|
||||
|
||||
### 设置HTTP重定向
|
||||
|
||||
Gitea服务器仅支持监听一个端口；要重定向HTTP请求致HTTPS端口，您需要启用HTTP重定向服务：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
REDIRECT_OTHER_PORT = true
|
||||
; Port the redirection service should listen on
|
||||
PORT_TO_REDIRECT = 3080
|
||||
```
|
||||
|
||||
如果您使用Docker，确保端口已配置在 `docker-compose.yml` 文件
|
||||
|
||||
## 使用 ACME (默认: Let's Encrypt)
|
||||
|
||||
[ACME](https://tools.ietf.org/html/rfc8555) 是一种证书颁发机构标准协议，允许您自动请求和续订 SSL/TLS 证书。[Let`s Encrypt](https://letsencrypt.org/) 是使用此标准的免费公开信任的证书颁发机构服务器。仅实施“HTTP-01”和“TLS-ALPN-01”挑战。为了使 ACME 质询通过并验证您的域所有权，“80”端口（“HTTP-01”）或“443”端口（“TLS-ALPN-01”）上 gitea 域的外部流量必须由 gitea 实例提供服务。可能需要设置 [HTTP 重定向](#设置http重定向) 和端口转发才能正确路由外部流量。否则，到端口“80”的正常流量将自动重定向到 HTTPS。**您必须同意**ACME提供商的服务条款（默认为Let's Encrypt的 [服务条款](https://letsencrypt.org/documents/LE-SA-v1.2-2017年11月15日.pdf)。
|
||||
|
||||
使用默认 Let's Encrypt 的最小配置如下：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL=https
|
||||
DOMAIN=git.example.com
|
||||
ENABLE_ACME=true
|
||||
ACME_ACCEPTTOS=true
|
||||
ACME_DIRECTORY=https
|
||||
;; Email can be omitted here and provided manually at first run, after which it is cached
|
||||
ACME_EMAIL=email@example.com
|
||||
```
|
||||
|
||||
小型配置请使用 [smallstep CA](https://github.com/smallstep/certificates), 点击 [教程](https://smallstep.com/docs/tutorials/acme-challenge) 了解更多信息。
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL=https
|
||||
DOMAIN=git.example.com
|
||||
ENABLE_ACME=true
|
||||
ACME_ACCEPTTOS=true
|
||||
ACME_URL=https://ca.example.com/acme/acme/directory
|
||||
;; Can be omitted if using the system's trust is preferred
|
||||
;ACME_CA_ROOT=/path/to/root_ca.crt
|
||||
ACME_DIRECTORY=https
|
||||
ACME_EMAIL=email@example.com
|
||||
```
|
||||
|
||||
要了解关于配置, 请访问 [配置备忘单](../administration/config-cheat-sheet.md#server-server)获取更多信息
|
||||
|
||||
## 使用反向代理服务器
|
||||
|
||||
按照 [反向代理指南](reverse-proxies.md) 的规则设置你的反向代理服务器
|
||||
|
||||
然后，按照下面的向导启用 HTTPS：
|
||||
|
||||
- [nginx](https://nginx.org/en/docs/http/configuring_https_servers.html)
|
||||
- [apache2/httpd](https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html)
|
||||
- [caddy](https://caddyserver.com/docs/tls)
|
||||
|
||||
注意：仅在代理层启用 HTTPS 被称为 [TLS 终止代理](https://en.wikipedia.org/wiki/TLS_termination_proxy)。代理服务器接受传入的 TLS 连接，解密内容，然后将现在未加密的内容传递给 Gitea。只要代理和 Gitea 实例在同一台计算机上或在私有网络中的不同计算机上（代理暴露给外部网络），这通常是可以接受的。如果您的 Gitea 实例与代理隔离在公共网络上，或者如果您想要全端到端的加密，您还可以直接在 Gitea 中 [启用内置服务器的 HTTPS 支持](#使用内置服务器)，并将连接转发到 HTTPS 上。
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user