mirror of
https://github.com/go-gitea/gitea.git
synced 2024-12-05 09:49:37 +08:00
Backport #24925, partially backport #24934 (`docs/content/doc/help/faq.zh-cn.md` file) Part of backport has already done by #24942 Also backport #24881 to avoid "deadlock" --------- Co-authored-by: Zettat123 <zettat123@gmail.com>
This commit is contained in:
parent
d2c9fb02dd
commit
37b73b3337
40
docs/content/doc/administration/adding-legal-pages.zh-cn.md
Normal file
40
docs/content/doc/administration/adding-legal-pages.zh-cn.md
Normal file
@ -0,0 +1,40 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "添加法律页面"
|
||||
slug: adding-legal-pages
|
||||
weight: 110
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/adding-legal-pages
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "添加法律页面"
|
||||
identifier: "adding-legal-pages"
|
||||
weight: 110
|
||||
---
|
||||
|
||||
一些法域(例如欧盟)要求在网站上添加特定的法律页面(例如隐私政策)。按照以下步骤将它们添加到你的 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 以查看更改。
|
105
docs/content/doc/administration/cmd-embedded.zh-cn.md
Normal file
105
docs/content/doc/administration/cmd-embedded.zh-cn.md
Normal file
@ -0,0 +1,105 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "嵌入资源提取工具"
|
||||
slug: "cmd-embedded"
|
||||
weight: 20
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/cmd-embedded
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "嵌入资源提取工具"
|
||||
weight: 20
|
||||
identifier: "cmd-embedded"
|
||||
---
|
||||
|
||||
# 嵌入资源提取工具
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
Gitea 的可执行文件包含了运行所需的所有资源:模板、图片、样式表和翻译文件。你可以通过在 `custom` 目录下的相应路径中放置替换文件来覆盖其中的任何资源(详见 [自定义 Gitea 配置]({{< relref "doc/administration/customizing-gitea.zh-cn.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 配置]({{< relref "doc/administration/customizing-gitea.zh-cn.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
|
||||
```
|
556
docs/content/doc/administration/command-line.zh-cn.md
Normal file
556
docs/content/doc/administration/command-line.zh-cn.md
Normal file
@ -0,0 +1,556 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "Gitea 命令行"
|
||||
slug: "command-line"
|
||||
weight: 1
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/command-line
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "Gitea 命令行"
|
||||
weight: 1
|
||||
identifier: "command-line"
|
||||
---
|
||||
|
||||
# 命令行
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## 用法
|
||||
|
||||
`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
|
||||
```
|
91
docs/content/doc/administration/email-setup.zh-cn.md
Normal file
91
docs/content/doc/administration/email-setup.zh-cn.md
Normal file
@ -0,0 +1,91 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "Email 设置"
|
||||
slug: "email-setup"
|
||||
weight: 12
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/email-setup
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "Email 设置"
|
||||
weight: 12
|
||||
identifier: "email-setup"
|
||||
---
|
||||
|
||||
# Email 设置
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
Gitea 具有邮件功能,用于发送事务性邮件(例如注册确认邮件)。它可以配置为使用 Sendmail(或兼容的 MTA,例如 Postfix 和 msmtp)或直接使用 SMTP 服务器。
|
||||
|
||||
## 使用 Sendmail
|
||||
|
||||
使用 `sendmail` 命令作为邮件传输代理(mailer)。
|
||||
|
||||
注意:对于在官方Gitea Docker镜像中使用,请使用SMTP版本进行配置(请参考下一节)。
|
||||
|
||||
注意:对于面向互联网的网站,请查阅您的 MTA 文档以了解通过TLS发送邮件的说明。同时设置 SPF、DMARC 和 DKIM DNS 记录,以使发送的邮件被各个电子邮件提供商接受为合法邮件。
|
||||
|
||||
```ini
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = gitea@mydomain.com
|
||||
MAILER_TYPE = sendmail
|
||||
SENDMAIL_PATH = /usr/sbin/sendmail
|
||||
SENDMAIL_ARGS = "--" ; 大多数 "sendmail" 程序都接受选项,使用 "--" 将防止电子邮件地址被解释为选项。
|
||||
```
|
||||
|
||||
## 使用 SMTP
|
||||
|
||||
直接使用 SMTP 服务器作为中继。如果您不想在实例上设置 MTA,但在电子邮件提供商那里有一个帐户,这个选项非常有用。
|
||||
|
||||
```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 邮件配置。
|
||||
|
||||
有关所有选项的完整列表,请查看[配置速查表](doc/administration/config-cheat-sheet.zh-cn.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
|
||||
[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 帐户密码。
|
207
docs/content/doc/administration/external-renderers.zh-cn.md
Normal file
207
docs/content/doc/administration/external-renderers.zh-cn.md
Normal file
@ -0,0 +1,207 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "外部渲染器"
|
||||
slug: "external-renderers"
|
||||
weight: 60
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/external-renderers
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "外部渲染器"
|
||||
weight: 60
|
||||
identifier: "external-renderers"
|
||||
---
|
||||
|
||||
# 自定义文件渲染配置
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
Gitea 通过外部二进制文件支持自定义文件渲染(例如 Jupyter notebooks、asciidoc 等),只需要进行以下步骤:
|
||||
|
||||
- 安装外部二进制文件
|
||||
- 在您的 `app.ini` 文件中添加一些配置
|
||||
- 重新启动 Gitea 实例
|
||||
|
||||
此功能支持整个文件的渲染。如果您想要在 Markdown 中渲染代码块,您需要使用 JavaScript 进行一些操作。请参阅 [自定义 Gitea 配置]({{< relref "doc/administration/customizing-gitea.zh-cn.md" >}}) 页面上的一些示例。
|
||||
|
||||
## 安装外部二进制文件
|
||||
|
||||
为了通过外部二进制文件进行文件渲染,必须安装它们的关联软件包。
|
||||
如果您正在使用 Docker 镜像,则您的 `Dockerfile` 应该包含以下内容:
|
||||
|
||||
```docker
|
||||
FROM gitea/gitea:{{< version >}}
|
||||
[...]
|
||||
|
||||
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 样式应用到特定的外部渲染器,使其具有所需的样式效果。
|
32
docs/content/doc/administration/git-lfs-support.zh-cn.md
Normal file
32
docs/content/doc/administration/git-lfs-support.zh-cn.md
Normal file
@ -0,0 +1,32 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "Git LFS 设置"
|
||||
slug: "git-lfs-setup"
|
||||
weight: 12
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/git-lfs-setup
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "Git LFS 设置"
|
||||
weight: 12
|
||||
identifier: "git-lfs-setup"
|
||||
---
|
||||
|
||||
# 配置 Git 大文件存储(Large File Storage,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 以上版本。
|
272
docs/content/doc/administration/logging-config.zh-cn.md
Normal file
272
docs/content/doc/administration/logging-config.zh-cn.md
Normal file
@ -0,0 +1,272 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "日志配置"
|
||||
slug: "logging-config"
|
||||
weight: 40
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/logging-configuration
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "日志配置"
|
||||
weight: 40
|
||||
identifier: "logging-config"
|
||||
---
|
||||
|
||||
# 日志配置
|
||||
|
||||
Gitea 的日志配置主要由以下三种类型的组件组成:
|
||||
|
||||
- `[log]` 部分用于一般配置
|
||||
- `[log.<mode-name>]` 部分用于配置不同的日志输出方式,也称为 "writer mode",模式名称同时也作为 "writer name"
|
||||
- `[log]` 部分还可以包含遵循 `logger.<logger-name>.<CONFIG-KEY>` 模式的子日志记录器的配置
|
||||
|
||||
默认情况下,已经有一个完全功能的日志输出,因此不需要重新定义。
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## `[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`。
|
265
docs/content/doc/administration/mail-templates.zh-cn.md
Normal file
265
docs/content/doc/administration/mail-templates.zh-cn.md
Normal file
@ -0,0 +1,265 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "邮件模板"
|
||||
slug: "mail-templates"
|
||||
weight: 45
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/mail-templates
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "邮件模板"
|
||||
weight: 45
|
||||
identifier: "mail-templates"
|
||||
---
|
||||
|
||||
# 邮件模板
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
为了定制特定操作的电子邮件主题和内容,可以使用模板来自定义 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}}
|
||||
```
|
63
docs/content/doc/administration/repo-indexer.zh-cn.md
Normal file
63
docs/content/doc/administration/repo-indexer.zh-cn.md
Normal file
@ -0,0 +1,63 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "仓库索引器"
|
||||
slug: "repo-indexer"
|
||||
weight: 45
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/repo-indexer
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "仓库索引器"
|
||||
weight: 45
|
||||
identifier: "repo-indexer"
|
||||
---
|
||||
|
||||
# 仓库索引器
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## 设置仓库索引器
|
||||
|
||||
通过在您的 [`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` 是等效的。
|
@ -0,0 +1,39 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "搜索引擎索引"
|
||||
slug: "search-engines-indexation"
|
||||
weight: 60
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/search-engines-indexation
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "搜索引擎索引"
|
||||
weight: 60
|
||||
identifier: "search-engines-indexation"
|
||||
---
|
||||
|
||||
# Gitea 安装的搜索引擎索引
|
||||
|
||||
默认情况下,您的 Gitea 安装将被搜索引擎索引。
|
||||
如果您不希望您的仓库对搜索引擎可见,请进一步阅读。
|
||||
|
||||
## 使用 robots.txt 阻止搜索引擎索引
|
||||
|
||||
为了使 Gitea 为顶级安装提供自定义的`robots.txt`(默认为空的 404),请在[`custom`文件夹或`CustomPath`]({{< relref "doc/administration/customizing-gitea.zh-cn.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/
|
||||
```
|
146
docs/content/doc/administration/signing.zh-cn.md
Normal file
146
docs/content/doc/administration/signing.zh-cn.md
Normal file
@ -0,0 +1,146 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
title: "GPG 提交签名"
|
||||
slug: "signing"
|
||||
weight: 50
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/signing
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "administration"
|
||||
name: "GPG 提交签名"
|
||||
weight: 50
|
||||
identifier: "signing"
|
||||
---
|
||||
|
||||
# GPG 提交签名
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
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` 为每个仓库提供不同的签名密钥。然而,这显然不是一个理想的用户界面,因此可能会发生更改。
|
||||
|
||||
**自 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` 环境变量为您首选的位置。
|
||||
|
||||
### `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
|
||||
```
|
123
docs/content/doc/contributing/guidelines-backend.zh-cn.md
Normal file
123
docs/content/doc/contributing/guidelines-backend.zh-cn.md
Normal file
@ -0,0 +1,123 @@
|
||||
---
|
||||
date: "2023-05-25T23:41:00+08:00"
|
||||
title: "后端开发指南"
|
||||
slug: "guidelines-backend"
|
||||
weight: 20
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/guidelines-backend
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "contributing"
|
||||
name: "后端开发指南"
|
||||
weight: 20
|
||||
identifier: "guidelines-backend"
|
||||
---
|
||||
|
||||
# 后端开发指南
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## 背景
|
||||
|
||||
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`中。
|
138
docs/content/doc/contributing/guidelines-frontend.zh-cn.md
Normal file
138
docs/content/doc/contributing/guidelines-frontend.zh-cn.md
Normal file
@ -0,0 +1,138 @@
|
||||
---
|
||||
date: "2023-05-25T16:00:00+02:00"
|
||||
title: "前端开发指南"
|
||||
slug: "guidelines-frontend"
|
||||
weight: 20
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/guidelines-frontend
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "contributing"
|
||||
name: "前端开发指南"
|
||||
weight: 20
|
||||
identifier: "guidelines-frontend"
|
||||
---
|
||||
|
||||
# 前端开发指南
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## 背景
|
||||
|
||||
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 代码分离。
|
@ -0,0 +1,53 @@
|
||||
---
|
||||
date: "2023-05-25T00:00:00+00:00"
|
||||
title: "重构指南"
|
||||
slug: "guidelines-refactoring"
|
||||
weight: 20
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/guidelines-refactoring
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "contributing"
|
||||
name: "重构指南"
|
||||
weight: 20
|
||||
identifier: "guidelines-refactoring"
|
||||
---
|
||||
|
||||
# 重构指南
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## 背景
|
||||
|
||||
自2014年2月12日编写了第一行代码以来,Gitea已经发展成为一个庞大的项目。
|
||||
因此,代码库变得越来越大。代码库越大,维护就越困难。
|
||||
存在许多过时的机制,许多框架混合在一起,一些遗留代码可能会导致错误并阻碍新功能的开发。
|
||||
为了使代码库更易于维护,使Gitea变得更好,开发人员应牢记使用现代机制来重构旧代码。
|
||||
|
||||
本文档是关于重构代码库的指南集合。
|
||||
|
||||
## 重构建议
|
||||
|
||||
* 设计更多关于未来的内容,而不仅仅解决当前问题。
|
||||
* 减少模糊性,减少冲突,提高可维护性。
|
||||
* 描述重构,例如:
|
||||
* 为什么需要重构。
|
||||
* 如何解决旧问题。
|
||||
* 重构的优点/缺点是什么。
|
||||
* 只做必要的更改,尽量保留旧逻辑。
|
||||
* 引入一些中间步骤,使重构更容易审查,完整的重构计划可以在几个PR中完成。
|
||||
* 如果存在分歧,应该请TOC(技术监督委员会)参与决策。
|
||||
* 添加必要的测试以确保重构的正确性。
|
||||
* 非错误重构优先在里程碑的开始时进行,这样可以更容易地在发布之前发现问题。
|
||||
|
||||
## 审查和合并建议
|
||||
|
||||
* 重构的PR不应该长时间保持打开状态(通常为7天),应尽快进行审查。
|
||||
* 重构的PR应尽快合并,不应被其他PR阻塞。
|
||||
* 如果TOC没有异议,重构的PR可以在7天后由一名核心成员(非作者)批准后合并。
|
||||
* 如果最终结果良好,容忍一些不完美/临时的步骤。
|
||||
* 如果重构是必要的,容忍一些回归错误,并尽快修复错误。
|
17
docs/content/doc/contributing/translation.zh-cn.md
Normal file
17
docs/content/doc/contributing/translation.zh-cn.md
Normal file
@ -0,0 +1,17 @@
|
||||
---
|
||||
date: "2023-05-25T00:00:00+02:00"
|
||||
title: "翻译指南"
|
||||
weight: 70
|
||||
toc: true
|
||||
draft: false
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "contributing"
|
||||
name: "翻译指南"
|
||||
weight: 70
|
||||
identifier: "translation-guidelines"
|
||||
---
|
||||
|
||||
本页面用于提供一套通用规则,以确保翻译的一致性。
|
||||
|
||||
* [German](/de-de/übersetzungs-richtlinien/)
|
46
docs/content/doc/development/integrations.zh-cn.md
Normal file
46
docs/content/doc/development/integrations.zh-cn.md
Normal file
@ -0,0 +1,46 @@
|
||||
---
|
||||
date: "2023-05-25T17:29:00+08:00"
|
||||
title: "集成"
|
||||
slug: "integrations"
|
||||
weight: 65
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/integrations
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "development"
|
||||
name: "集成"
|
||||
weight: 65
|
||||
identifier: "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!
|
||||
```
|
40
docs/content/doc/development/migrations.zh-cn.md
Normal file
40
docs/content/doc/development/migrations.zh-cn.md
Normal file
@ -0,0 +1,40 @@
|
||||
---
|
||||
date: "2023-05-25T17:29:00+08:00"
|
||||
title: "迁移界面"
|
||||
slug: "migrations-interfaces"
|
||||
weight: 55
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/migrations-interfaces
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "development"
|
||||
name: "迁移界面"
|
||||
weight: 55
|
||||
identifier: "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)中找到这些接口。
|
472
docs/content/doc/help/faq.zh-cn.md
Normal file
472
docs/content/doc/help/faq.zh-cn.md
Normal file
@ -0,0 +1,472 @@
|
||||
---
|
||||
date: "2023-05-25T16:00:00+02:00"
|
||||
title: "常见问题"
|
||||
slug: "faq"
|
||||
weight: 5
|
||||
toc: false
|
||||
draft: false
|
||||
aliases:
|
||||
- /zh-cn/faq
|
||||
menu:
|
||||
sidebar:
|
||||
parent: "help"
|
||||
name: "常见问题"
|
||||
weight: 5
|
||||
identifier: "faq"
|
||||
---
|
||||
|
||||
# 常见问题 <!-- omit in toc -->
|
||||
|
||||
本页面包含一些常见问题和答案。
|
||||
|
||||
有关更多帮助资源,请查看所有[支持选项]({{< relref "doc/help/seek-help.zh-cn.md" >}})。
|
||||
|
||||
**目录**
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## 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或更低]({{< relref "doc/installation/upgrade-from-gogs.zh-cn.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. 如果使用反向代理,请确保按照[反向代理指南]({{< relref "doc/administration/reverse-proxies.zh-cn.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解决此问题,请参阅[反向代理指南]({{< relref "doc/administration/reverse-proxies.zh-cn.md" >}})。
|
||||
|
||||
## 自定义模板无法加载或运行错误
|
||||
|
||||
Gitea的自定义模板必须将其添加到正确的位置,否则Gitea将无法找到并使用自定义模板。
|
||||
|
||||
模板的正确路径应该相对于`CustomPath`。
|
||||
|
||||
1. 要找到`CustomPath`,请在站点管理 -> 配置 中查找自定义文件根路径。
|
||||
|
||||
如果找不到,请尝试`echo $GITEA_CUSTOM`。
|
||||
|
||||
2. 如果仍然找不到,默认值可以被[计算]({{< relref "doc/help/faq.zh-cn.md#where-does-gitea-store-what-file" >}})
|
||||
3. 如果仍然找不到路径,则可以参考[自定义Gitea]({{< relref "doc/administration/customizing-gitea.zh-cn.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的用户。
|
||||
|
||||
## 设置日志记录
|
||||
|
||||
- [官方文档]({{< relref "doc/administration/logging-config.zh-cn.md" >}})
|
||||
|
||||
## 什么是Swagger?
|
||||
|
||||
[Swagger](https://swagger.io/) 是Gitea用于其API文档的工具。
|
||||
|
||||
所有Gitea实例都有内置的API,无法完全禁用它。
|
||||
但是,您可以在app.ini的api部分将ENABLE_SWAGGER设置为false,以禁用其文档显示。
|
||||
有关更多信息,请参阅Gitea的[API文档]({{< relref "doc/development/api-usage.zh-cn.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]({{< relref "doc/administration/command-line.zh-cn.md" >}})、[API]({{< relref "doc/development/api-usage.zh-cn.md" >}}) 或 Gitea 的管理界面创建新用户。
|
||||
|
||||
### 仅允许/阻止特定的电子邮件域名
|
||||
|
||||
您可以在`app.ini`中的`[service]`下的配置`EMAIL_DOMAIN_WHITELIST` 或 `EMAIL_DOMAIN_BLOCKLIST`。
|
||||
|
||||
### 仅允许/阻止特定的 OpenID 提供商
|
||||
|
||||
您可以在`app.ini`的`[openid]`下配置`WHITELISTED_URI`或`BLACKLISTED_URIS`。
|
||||
|
||||
**注意**: 白名单优先,如果白名单非空,则忽略黑名单。
|
||||
|
||||
### 仅允许发布问题的用户
|
||||
|
||||
目前实现这一点的方法是创建/修改一个具有最大仓库创建限制为 0 的用户。
|
||||
|
||||
### 受限制的用户
|
||||
|
||||
受限制的用户仅能访问其组织/团队成员和协作所在的内容的子集,而忽略组织/仓库等的公共标志。
|
||||
|
||||
示例用例:一个公司运行一个需要登录的 Gitea 实例。大多数仓库是公开的(所有同事都可以访问/浏览)。
|
||||
|
||||
在某些情况下,某个客户或第三方需要访问特定的仓库,并且只能访问该仓库。通过将此类客户帐户设置为受限制帐户,并使用团队成员身份和/或协作来授予所需的任何访问权限,可以简单地实现这一点,而无需使所有内容都变为私有。
|
||||
|
||||
### 启用 Fail2ban
|
||||
|
||||
使用 [Fail2Ban]({{< relref "doc/administration/fail2ban-setup.zh-cn.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]({{< relref "doc/help/faq.zh-cn.md#where-does-gitea-store-what-file" >}})
|
||||
|
||||
**适用于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`
|
||||
|
||||
如果连接成功,您应该会收到以下错误消息:
|
||||
|
||||
```
|
||||
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 常见错误
|
||||
|
||||
```
|
||||
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 无法访问正确的
|
||||
存储库。
|
||||
|
||||
```
|
||||
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`命令使用
|
||||
正确的配置文件。
|
||||
|
||||
## 迁移带有标签的存储库后缺失发布版本
|
||||
|
||||
要迁移带有所有标签的存储库,您需要执行两个操作:
|
||||
|
||||
- 推送标签到存储库:
|
||||
|
||||
```
|
||||
git push --tags
|
||||
```
|
||||
|
||||
- 在 Gitea 中重新同步所有存储库的标签:
|
||||
|
||||
```
|
||||
gitea admin repo-sync-releases
|
||||
```
|
||||
|
||||
## LFS 问题
|
||||
|
||||
针对涉及 LFS 数据上传的问题
|
||||
|
||||
```
|
||||
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 命令]({{< relref "doc/administration/command-line.zh-cn.md#admin" >}})像正常情况下添加用户。
|
||||
|
||||
## 如何启用密码重置
|
||||
|
||||
没有密码重置的设置。当配置了[邮件服务]({{< relref "doc/administration/email-setup.zh-cn.md" >}})时,密码重置将自动启用;否则将被禁用。
|
||||
|
||||
## 如何更改用户的密码
|
||||
|
||||
- 作为管理员,您可以更改任何用户的密码(并可选择强制其在下次登录时更改密码)...
|
||||
- 转到您的`站点管理 -> 用户账户`页面并编辑用户。
|
||||
- 使用[管理 CLI 命令]({{< relref "doc/administration/command-line.zh-cn.md#admin" >}})。
|
||||
|
||||
请注意,大多数命令还需要一个[全局标志]({{< relref "doc/administration/command-line.zh-cn.- md#global-options" >}})来指向正确的配置。
|
||||
- 作为**用户**,您可以更改密码...
|
||||
- 在您的账户的`设置 -> 账户`页面(此方法**需要**您知道当前密码)。
|
||||
- 使用`忘记密码`链接。
|
||||
|
||||
如果`忘记密码/账户恢复`页面被禁用,请联系管理员配置[邮件服务]({{< relref "doc/administration/email-setup.zh-cn.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,另一个可能的修复方法是:
|
||||
|
||||
```mysql
|
||||
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>`来查看。
|
||||
|
||||
要收集日志以进行帮助和问题报告,请参阅[支持选项]({{< relref "doc/help/seek-help.zh-cn.md" >}})。
|
||||
|
||||
## 初始日志记录
|
||||
|
||||
在 Gitea 读取配置文件并设置其日志记录之前,它会将一些内容记录到标准输出,以帮助调试日志记录无法工作的情况。
|
||||
|
||||
您可以通过设置`--quiet`或`-q`选项来停止此日志记录。请注意,这只会在 Gitea 设置自己的日志记录之前停止日志记录。
|
||||
|
||||
如果您报告了错误或问题,必须提供这些信息以恢复初始日志记录。
|
||||
|
||||
只有在完全配置了所有内容之后,您才应该设置此选项。
|
||||
|
||||
## 在数据库启动期间出现有关结构默认值的警告
|
||||
|
||||
有时,在迁移过程中,旧列和默认值可能在数据库架构中保持不变。
|
||||
这可能会导致警告,例如:
|
||||
|
||||
```
|
||||
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 重新创建多个表:
|
||||
|
||||
```
|
||||
gitea doctor recreate-table table1 table2 ...
|
||||
```
|
||||
|
||||
如果您希望 Gitea 重新创建所有表,请使用以下命令:
|
||||
|
||||
```
|
||||
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`]({{< relref "doc/administration/config-cheat-sheet.zh-cn.md#repository" >}}) 获得类似的权限。
|
||||
- 如果上述步骤都正确执行,您应该能够选择要采用的存储库。
|
||||
- 如果没有找到存储库,请启用[调试日志记录]({{< relref "doc/administration/config-cheat-sheet.zh-cn.md#repository" >}})以检查是否有特定错误。
|
Loading…
Reference in New Issue
Block a user