diff options
| author | John Olheiser <john.olheiser@gmail.com> | 2023-07-25 23:53:13 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-07-26 04:53:13 +0000 |
| commit | bd4c7ce578956d9839309b16753bd5505b63b2e3 (patch) | |
| tree | 1d3074ef542cee11707bc4985ce54dc40facb9b6 /docs/content/doc | |
| parent | 5dc37ef97a30628027a723ee944225a33a6511f8 (diff) | |
| download | gitea-bd4c7ce578956d9839309b16753bd5505b63b2e3.tar.gz gitea-bd4c7ce578956d9839309b16753bd5505b63b2e3.zip | |
Docusaurus-ify (#26051)
This PR cleans up the docs in a way to make them simpler to ingest by
our [docs repo](https://gitea.com/gitea/gitea-docusaurus).
1. It includes all of the sed invocations our ingestion did, removing
the need to do it at build time.
2. It replaces the shortcode variable replacement method with
`@variable@` style, simply for easier sed invocations when required.
3. It removes unused files and moves the docs up a level as cleanup.
---------
Signed-off-by: jolheiser <john.olheiser@gmail.com>
Diffstat (limited to 'docs/content/doc')
255 files changed, 0 insertions, 27861 deletions
diff --git a/docs/content/doc/actions.en-us.md b/docs/content/doc/actions.en-us.md deleted file mode 100644 index 7cd2ba0546..0000000000 --- a/docs/content/doc/actions.en-us.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2023-04-27T14:00:00+08:00" -title: "Actions" -slug: "actions" -weight: 36 -toc: false -draft: false -menu: - sidebar: - name: "Usage - Actions" - weight: 31 - identifier: "actions" ---- diff --git a/docs/content/doc/administration.en-us.md b/docs/content/doc/administration.en-us.md deleted file mode 100644 index 5d3ba385d9..0000000000 --- a/docs/content/doc/administration.en-us.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Administration" -slug: "administration" -weight: 30 -toc: false -draft: false -menu: - sidebar: - name: "Administration" - weight: 20 - collapse: true - identifier: "administration" ---- diff --git a/docs/content/doc/administration.fr-fr.md b/docs/content/doc/administration.fr-fr.md deleted file mode 100644 index 957ff7b194..0000000000 --- a/docs/content/doc/administration.fr-fr.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2017-08-23T09:00:00+02:00" -title: "Avancé" -slug: "administration" -weight: 30 -toc: false -draft: false -menu: - sidebar: - name: "Avancé" - weight: 20 - identifier: "administration" ---- diff --git a/docs/content/doc/administration.zh-cn.md b/docs/content/doc/administration.zh-cn.md deleted file mode 100644 index 6e032d3266..0000000000 --- a/docs/content/doc/administration.zh-cn.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "运维" -slug: "administration" -weight: 30 -toc: false -draft: false -menu: - sidebar: - name: "运维" - weight: 20 - identifier: "administration" ---- diff --git a/docs/content/doc/administration.zh-tw.md b/docs/content/doc/administration.zh-tw.md deleted file mode 100644 index daf8e3f105..0000000000 --- a/docs/content/doc/administration.zh-tw.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "運維" -slug: "administration" -weight: 30 -toc: false -draft: false -menu: - sidebar: - name: "運維" - weight: 20 - identifier: "administration" ---- diff --git a/docs/content/doc/administration/_index.en-us.md b/docs/content/doc/administration/_index.en-us.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/administration/_index.en-us.md +++ /dev/null diff --git a/docs/content/doc/administration/_index.zh-cn.md b/docs/content/doc/administration/_index.zh-cn.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/administration/_index.zh-cn.md +++ /dev/null diff --git a/docs/content/doc/administration/_index.zh-tw.md b/docs/content/doc/administration/_index.zh-tw.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/administration/_index.zh-tw.md +++ /dev/null diff --git a/docs/content/doc/administration/adding-legal-pages.en-us.md b/docs/content/doc/administration/adding-legal-pages.en-us.md deleted file mode 100644 index 6de145ce09..0000000000 --- a/docs/content/doc/administration/adding-legal-pages.en-us.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -date: "2019-12-28" -title: "Adding Legal Pages" -slug: adding-legal-pages -weight: 110 -toc: false -draft: false -aliases: - - /en-us/adding-legal-pages -menu: - sidebar: - parent: "administration" - name: "Adding Legal Pages" - identifier: "adding-legal-pages" - weight: 110 ---- - -Some jurisdictions (such as EU), requires certain legal pages (e.g. Privacy Policy) to be added to website. Follow these steps to add them to your Gitea instance. - -## Getting Pages - -Gitea source code ships with sample pages, available in `contrib/legal` directory. Copy them to `custom/public/`. For example, to add Privacy Policy: - -``` -wget -O /path/to/custom/public/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/legal/privacy.html.sample -``` - -Now you need to edit the page to meet your requirements. In particular you must change the email addresses, web addresses and references to "Your Gitea Instance" to match your situation. - -You absolutely must not place a general ToS or privacy statement that implies that the Gitea project is responsible for your server. - -## Make it Visible - -Create or append to `/path/to/custom/templates/custom/extra_links_footer.tmpl`: - -```go -<a class="item" href="{{AppSubUrl}}/assets/privacy.html">Privacy Policy</a> -``` - -Restart Gitea to see the changes. diff --git a/docs/content/doc/administration/adding-legal-pages.zh-cn.md b/docs/content/doc/administration/adding-legal-pages.zh-cn.md deleted file mode 100644 index dc0bccef3d..0000000000 --- a/docs/content/doc/administration/adding-legal-pages.zh-cn.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -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 以查看更改。 diff --git a/docs/content/doc/administration/backup-and-restore.en-us.md b/docs/content/doc/administration/backup-and-restore.en-us.md deleted file mode 100644 index 5a722f4965..0000000000 --- a/docs/content/doc/administration/backup-and-restore.en-us.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -date: "2017-01-01T16:00:00+02:00" -title: "Backup and Restore" -slug: "backup-and-restore" -weight: 11 -toc: false -draft: false -aliases: - - /en-us/backup-and-restore -menu: - sidebar: - parent: "administration" - name: "Backup and Restore" - weight: 11 - identifier: "backup-and-restore" ---- - -# Backup and Restore - -Gitea currently has a `dump` command that will save the installation to a ZIP file. This -file can be unpacked and used to restore an instance. - -**Table of Contents** - -{{< toc >}} - -## Backup Consistency - -To ensure the consistency of the Gitea instance, it must be shutdown during backup. - -Gitea consists of a database, files and git repositories, all of which change when it is used. For instance, when a migration is in progress, a transaction is created in the database while the git repository is being copied over. If the backup happens in the middle of the migration, the git repository may be incomplete although the database claims otherwise because it was dumped afterwards. The only way to avoid such race conditions is by stopping the Gitea instance during the backups. - -## Backup Command (`dump`) - -Switch to the user running Gitea: `su git`. Run `./gitea dump -c /path/to/app.ini` in the Gitea installation -directory. There should be some output similar to the following: - -```none -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 -``` - -Inside the `gitea-dump-1482906742.zip` file, will be the following: - -- `app.ini` - Optional copy of configuration file if originally stored outside the default `custom/` directory -- `custom` - All config or customization files in `custom/`. -- `data` - Data directory (APP_DATA_PATH), except sessions if you are using file session. This directory includes `attachments`, `avatars`, `lfs`, `indexers`, SQLite file if you are using SQLite. -- `gitea-db.sql` - SQL dump of database -- `gitea-repo.zip` - Complete copy of the repository directory. -- `log/` - Various logs. They are not needed for a recovery or migration. - -Intermediate backup files are created in a temporary directory specified either with the -`--tempdir` command-line parameter or the `TMPDIR` environment variable. - -## Backup the database - -The SQL dump created by `gitea dump` uses XORM and Gitea admins may prefer to use the native the MySQL and PostgreSQL dump tools instead. There are still open issues when using XORM for dumping the database that may cause problems when attempting to restore it. - -```sh -# mysql -mysqldump -u$USER -p$PASS --database $DATABASE > gitea-db.sql -# postgres -pg_dump -U $USER $DATABASE > gitea-db.sql -``` - -### Using Docker (`dump`) - -There are a few caveats for using the `dump` command with Docker. - -The command has to be executed with the `RUN_USER = <OS_USERNAME>` specified in `gitea/conf/app.ini`; and, for the zipping of the backup folder to occur without permission error the command `docker exec` must be executed inside of the `--tempdir`. - -Example: - -```none -docker exec -u <OS_USERNAME> -it -w <--tempdir> $(docker ps -qf 'name=^<NAME_OF_DOCKER_CONTAINER>$') bash -c '/usr/local/bin/gitea dump -c </path/to/app.ini>' -``` - -\*Note: `--tempdir` refers to the temporary directory of the docker environment used by Gitea; if you have not specified a custom `--tempdir`, then Gitea uses `/tmp` or the `TMPDIR` environment variable of the docker container. For `--tempdir` adjust your `docker exec` command options accordingly. - -The result should be a file, stored in the `--tempdir` specified, along the lines of: `gitea-dump-1482906742.zip` - -## Restore Command (`restore`) - -There is currently no support for a recovery command. It is a manual process that mostly -involves moving files to their correct locations and restoring a database dump. - -Example: - -```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 -``` - -Repository Git Hooks should be regenerated if installation method is changed (eg. binary -> Docker), or if Gitea is installed to a different directory than the previous installation. - -With Gitea running, and from the directory Gitea's binary is located, execute: `./gitea admin regenerate hooks` - -This ensures that application and configuration file paths in repository Git Hooks are consistent and applicable to the current installation. If these paths are not updated, repository `push` actions will fail. - -### Using Docker (`restore`) - -There is also no support for a recovery command in a Docker-based gitea instance. The restore process contains the same steps as described in the previous section but with different paths. - -Example: - -```sh -# open bash session in container -docker exec --user git -it 2a83b293548e bash -# unzip your backup file within the container -unzip gitea-dump-1610949662.zip -cd gitea-dump-1610949662 -# restore the gitea data -mv data/* /data/gitea -# restore the repositories itself -mv repos/* /data/git/repositories/ -# adjust file permissions -chown -R git:git /data -# Regenerate Git Hooks -/usr/local/bin/gitea -c '/data/gitea/conf/app.ini' admin regenerate hooks -``` - -The default user in the gitea container is `git` (1000:1000). Please replace `2a83b293548e` with your gitea container id or name. - -### Using Docker-rootless (`restore`) - -The restore workflow in Docker-rootless containers differs only in the directories to be used: - -```sh -# open bash session in container -docker exec --user git -it 2a83b293548e bash -# unzip your backup file within the container -unzip gitea-dump-1610949662.zip -cd gitea-dump-1610949662 -# restore the app.ini -mv data/conf/app.ini /etc/gitea/app.ini -# restore the gitea data -mv data/* /var/lib/gitea -# restore the repositories itself -mv repos/* /var/lib/gitea/git/repositories -# adjust file permissions -chown -R git:git /etc/gitea/app.ini /var/lib/gitea -# Regenerate Git Hooks -/usr/local/bin/gitea -c '/etc/gitea/app.ini' admin regenerate hooks -``` diff --git a/docs/content/doc/administration/backup-and-restore.zh-cn.md b/docs/content/doc/administration/backup-and-restore.zh-cn.md deleted file mode 100644 index 89ae93923a..0000000000 --- a/docs/content/doc/administration/backup-and-restore.zh-cn.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -date: "2018-06-06T09:33:00+08:00" -title: "备份与恢复" -slug: "backup-and-restore" -weight: 11 -toc: false -draft: false -aliases: - - /zh-cn/backup-and-restore -menu: - sidebar: - parent: "administration" - name: "备份与恢复" - weight: 11 - identifier: "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 -``` diff --git a/docs/content/doc/administration/backup-and-restore.zh-tw.md b/docs/content/doc/administration/backup-and-restore.zh-tw.md deleted file mode 100644 index 07b9b0726b..0000000000 --- a/docs/content/doc/administration/backup-and-restore.zh-tw.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -date: "2017-01-01T16:00:00+02:00" -title: "用法: 備份與還原" -slug: "backup-and-restore" -weight: 11 -toc: false -draft: false -aliases: - - /zh-tw/backup-and-restore -menu: - sidebar: - parent: "administration" - name: "備份與還原" - weight: 11 - identifier: "backup-and-restore" ---- - -# 備份與還原 - -Gitea 目前支援 `dump` 指令，用來將資料備份成 zip 檔案，後續會提供還原指令，讓你可以輕易的將備份資料及還原到另外一台機器。 - -## 備份指令 (`dump`) - -首先，切換到執行 Gitea 的使用者: `su git` (請修改成您指定的使用者)，並在安裝目錄內執行 `./gitea dump` 指令，你可以看到 console 畫面如下: - -``` -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/conf/app.ini` - 伺服器設定檔。 -* `gitea-db.sql` - SQL 備份檔案。 -* `gitea-repo.zip` - 此 zip 檔案為全部的 repo 目錄。 - 請參考 Config -> repository -> `ROOT` 所設定的路徑。 -* `log/` - 全部 logs 檔案，如果你要 migrate 到其他伺服器，此目錄不用保留。 - -你可以透過設定 `--tempdir` 指令參數來指定備份檔案目錄，或者是設定 `TMPDIR` 環境變數來達到此功能。 - -## 還原指令 (`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 -``` diff --git a/docs/content/doc/administration/cmd-embedded.en-us.md b/docs/content/doc/administration/cmd-embedded.en-us.md deleted file mode 100644 index a58cbbf7fc..0000000000 --- a/docs/content/doc/administration/cmd-embedded.en-us.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -date: "2020-01-25T21:00:00-03:00" -title: "Embedded data extraction tool" -slug: "cmd-embedded" -weight: 20 -toc: false -draft: false -aliases: - - /en-us/cmd-embedded -menu: - sidebar: - parent: "administration" - name: "Embedded data extraction tool" - weight: 20 - identifier: "cmd-embedded" ---- - -# Embedded data extraction tool - -**Table of Contents** - -{{< toc >}} - -Gitea's executable contains all the resources required to run: templates, images, style-sheets -and translations. Any of them can be overridden by placing a replacement in a matching path -inside the `custom` directory (see [Customizing Gitea]({{< relref "doc/administration/customizing-gitea.en-us.md" >}})). - -To obtain a copy of the embedded resources ready for editing, the `embedded` command from the CLI -can be used from the OS shell interface. - -**NOTE:** The embedded data extraction tool is included in Gitea versions 1.12 and above. - -## Listing resources - -To list resources embedded in Gitea's executable, use the following syntax: - -```sh -gitea embedded list [--include-vendored] [patterns...] -``` - -The `--include-vendored` flag makes the command include vendored files, which are -normally excluded; that is, files from external libraries that are required for Gitea -(e.g. [octicons](https://octicons.github.com/), etc). - -A list of file search patterns can be provided. Gitea uses [gobwas/glob](https://github.com/gobwas/glob) -for its glob syntax. Here are some examples: - -- List all template files, in any virtual directory: `**.tmpl` -- List all mail template files: `templates/mail/**.tmpl` -- List all files inside `public/assets/img`: `public/assets/img/**` - -Don't forget to use quotes for the patterns, as spaces, `*` and other characters might have -a special meaning for your command shell. - -If no pattern is provided, all files are listed. - -### Example - -Listing all embedded files with `openid` in their path: - -```sh -$ gitea embedded list '**openid**' -public/assets/img/auth/openid_connect.svg -public/assets/img/openid-16x16.png -templates/user/auth/finalize_openid.tmpl -templates/user/auth/signin_openid.tmpl -templates/user/auth/signup_openid_connect.tmpl -templates/user/auth/signup_openid_navbar.tmpl -templates/user/auth/signup_openid_register.tmpl -templates/user/settings/security_openid.tmpl -``` - -## Extracting resources - -To extract resources embedded in Gitea's executable, use the following syntax: - -```sh -gitea [--config {file}] embedded extract [--destination {dir}|--custom] [--overwrite|--rename] [--include-vendored] {patterns...} -``` - -The `--config` option tells Gitea the location of the `app.ini` configuration file if -it's not in its default location. This option is only used with the `--custom` flag. - -The `--destination` option tells Gitea the directory where the files must be extracted to. -The default is the current directory. - -The `--custom` flag tells Gitea to extract the files directly into the `custom` directory. -For this to work, the command needs to know the location of the `app.ini` configuration -file (`--config`) and, depending of the configuration, be ran from the directory where -Gitea normally starts. See [Customizing Gitea]({{< relref "doc/administration/customizing-gitea.en-us.md" >}}) for details. - -The `--overwrite` flag allows any existing files in the destination directory to be overwritten. - -The `--rename` flag tells Gitea to rename any existing files in the destination directory -as `filename.bak`. Previous `.bak` files are overwritten. - -At least one file search pattern must be provided; see `list` subcomand above for pattern -syntax and examples. - -### Important notice - -Make sure to **only extract those files that require customization**. Files that -are present in the `custom` directory are not upgraded by Gitea's upgrade process. -When Gitea is upgraded to a new version (by replacing the executable), many of the -embedded files will suffer changes. Gitea will honor and use any files found -in the `custom` directory, even if they are old and incompatible. - -### Example - -Extracting mail templates to a temporary directory: - -```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 -``` diff --git a/docs/content/doc/administration/cmd-embedded.zh-cn.md b/docs/content/doc/administration/cmd-embedded.zh-cn.md deleted file mode 100644 index 663d9cdada..0000000000 --- a/docs/content/doc/administration/cmd-embedded.zh-cn.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -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 -``` diff --git a/docs/content/doc/administration/command-line.en-us.md b/docs/content/doc/administration/command-line.en-us.md deleted file mode 100644 index a977ed3a64..0000000000 --- a/docs/content/doc/administration/command-line.en-us.md +++ /dev/null @@ -1,575 +0,0 @@ ---- -date: "2017-01-01T16:00:00+02:00" -title: "Gitea Command Line" -slug: "command-line" -weight: 1 -toc: false -draft: false -aliases: - - /en-us/command-line -menu: - sidebar: - parent: "administration" - name: "Command Line" - weight: 1 - identifier: "command-line" ---- - -# Command Line - -**Table of Contents** - -{{< toc >}} - -## Usage - -`gitea [global options] command [command or global options] [arguments...]` - -## Global options - -All global options can be placed at the command level. - -- `--help`, `-h`: Show help text and exit. Optional. -- `--version`, `-v`: Show version and exit. Optional. (example: `Gitea version 1.1.0+218-g7b907ed built with: bindata, sqlite`). -- `--work-path path`, `-w path`: Gitea's work path. Optional. (default: the binary's path or `$GITEA_WORK_DIR`) -- `--custom-path path`, `-C path`: Gitea's custom folder path. Optional. (default: `WorkPath`/custom or `$GITEA_CUSTOM`). -- `--config path`, `-c path`: Gitea configuration file path. Optional. (default: `CustomPath`/conf/app.ini). - -NB: The defaults custom-path, config and work-path can also be -changed at build time (if preferred). - -## Commands - -### web - -Starts the server: - -- Options: - - `--port number`, `-p number`: Port number. Optional. (default: 3000). Overrides configuration file. - - `--install-port number`: Port number to run the install page on. Optional. (default: 3000). Overrides configuration file. - - `--pid path`, `-P path`: Pidfile path. Optional. - - `--quiet`, `-q`: Only emit Fatal logs on the console for logs emitted before logging set up. - - `--verbose`: Emit tracing logs on the console for logs emitted before logging is set-up. -- Examples: - - `gitea web` - - `gitea web --port 80` - - `gitea web --config /etc/gitea.ini --pid /some/custom/gitea.pid` -- Notes: - - Gitea should not be run as root. To bind to a port below 1024, you can use setcap on - Linux: `sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`. This will need to be - redone every time you update Gitea. - -### admin - -Admin operations: - -- Commands: - - `user`: - - `list`: - - Options: - - `--admin`: List only admin users. Optional. - - Description: lists all users that exist - - Examples: - - `gitea admin user list` - - `delete`: - - Options: - - `--email`: Email of the user to be deleted. - - `--username`: Username of user to be deleted. - - `--id`: ID of user to be deleted. - - One of `--id`, `--username` or `--email` is required. If more than one is provided then all have to match. - - Examples: - - `gitea admin user delete --id 1` - - `create`: - - Options: - - `--name value`: Username. Required. As of Gitea 1.9.0, use the `--username` flag instead. - - `--username value`: Username. Required. New in Gitea 1.9.0. - - `--password value`: Password. Required. - - `--email value`: Email. Required. - - `--admin`: If provided, this makes the user an admin. Optional. - - `--access-token`: If provided, an access token will be created for the user. Optional. (default: false). - - `--must-change-password`: If provided, the created user will be required to choose a newer password after the - initial login. Optional. (default: true). - - `--random-password`: If provided, a randomly generated password will be used as the password of the created - user. The value of `--password` will be discarded. Optional. - - `--random-password-length`: If provided, it will be used to configure the length of the randomly generated - password. Optional. (default: 12) - - Examples: - - `gitea admin user create --username myname --password asecurepassword --email me@example.com` - - `change-password`: - - Options: - - `--username value`, `-u value`: Username. Required. - - `--password value`, `-p value`: New password. Required. - - Examples: - - `gitea admin user change-password --username myname --password asecurepassword` - - `must-change-password`: - - Args: - - `[username...]`: Users that must change their passwords - - Options: - - `--all`, `-A`: Force a password change for all users - - `--exclude username`, `-e username`: Exclude the given user. Can be set multiple times. - - `--unset`: Revoke forced password change for the given users - - `generate-access-token`: - - Options: - - `--username value`, `-u value`: Username. Required. - - `--token-name value`, `-t value`: Token name. Required. - - `--scopes value`: Comma-separated list of scopes. Scopes follow the format `[read|write]:<block>` or `all` where `<block>` is one of the available visual groups you can see when opening the API page showing the available routes (for example `repo`). - - Examples: - - `gitea admin user generate-access-token --username myname --token-name mytoken` - - `gitea admin user generate-access-token --help` - - `regenerate` - - Options: - - `hooks`: Regenerate Git Hooks for all repositories - - `keys`: Regenerate authorized_keys file - - Examples: - - `gitea admin regenerate hooks` - - `gitea admin regenerate keys` - - `auth`: - - `list`: - - Description: lists all external authentication sources that exist - - Examples: - - `gitea admin auth list` - - `delete`: - - Options: - - `--id`: ID of source to be deleted. Required. - - Examples: - - `gitea admin auth delete --id 1` - - `add-oauth`: - - Options: - - `--name`: Application Name. - - `--provider`: OAuth2 Provider. - - `--key`: Client ID (Key). - - `--secret`: Client Secret. - - `--auto-discover-url`: OpenID Connect Auto Discovery URL (only required when using OpenID Connect as provider). - - `--use-custom-urls`: Use custom URLs for GitLab/GitHub OAuth endpoints. - - `--custom-tenant-id`: Use custom Tenant ID for OAuth endpoints. - - `--custom-auth-url`: Use a custom Authorization URL (option for GitLab/GitHub). - - `--custom-token-url`: Use a custom Token URL (option for GitLab/GitHub). - - `--custom-profile-url`: Use a custom Profile URL (option for GitLab/GitHub). - - `--custom-email-url`: Use a custom Email URL (option for GitHub). - - `--icon-url`: Custom icon URL for OAuth2 login source. - - `--skip-local-2fa`: Allow source to override local 2FA. (Optional) - - `--scopes`: Additional scopes to request for this OAuth2 source. (Optional) - - `--required-claim-name`: Claim name that has to be set to allow users to login with this source. (Optional) - - `--required-claim-value`: Claim value that has to be set to allow users to login with this source. (Optional) - - `--group-claim-name`: Claim name providing group names for this source. (Optional) - - `--admin-group`: Group Claim value for administrator users. (Optional) - - `--restricted-group`: Group Claim value for restricted users. (Optional) - - `--group-team-map`: JSON mapping between groups and org teams. (Optional) - - `--group-team-map-removal`: Activate automatic team membership removal depending on groups. (Optional) - - Examples: - - `gitea admin auth add-oauth --name external-github --provider github --key OBTAIN_FROM_SOURCE --secret OBTAIN_FROM_SOURCE` - - `update-oauth`: - - Options: - - `--id`: ID of source to be updated. Required. - - `--name`: Application Name. - - `--provider`: OAuth2 Provider. - - `--key`: Client ID (Key). - - `--secret`: Client Secret. - - `--auto-discover-url`: OpenID Connect Auto Discovery URL (only required when using OpenID Connect as provider). - - `--use-custom-urls`: Use custom URLs for GitLab/GitHub OAuth endpoints. - - `--custom-tenant-id`: Use custom Tenant ID for OAuth endpoints. - - `--custom-auth-url`: Use a custom Authorization URL (option for GitLab/GitHub). - - `--custom-token-url`: Use a custom Token URL (option for GitLab/GitHub). - - `--custom-profile-url`: Use a custom Profile URL (option for GitLab/GitHub). - - `--custom-email-url`: Use a custom Email URL (option for GitHub). - - `--icon-url`: Custom icon URL for OAuth2 login source. - - `--skip-local-2fa`: Allow source to override local 2FA. (Optional) - - `--scopes`: Additional scopes to request for this OAuth2 source. - - `--required-claim-name`: Claim name that has to be set to allow users to login with this source. (Optional) - - `--required-claim-value`: Claim value that has to be set to allow users to login with this source. (Optional) - - `--group-claim-name`: Claim name providing group names for this source. (Optional) - - `--admin-group`: Group Claim value for administrator users. (Optional) - - `--restricted-group`: Group Claim value for restricted users. (Optional) - - Examples: - - `gitea admin auth update-oauth --id 1 --name external-github-updated` - - `add-smtp`: - - Options: - - `--name`: Application Name. Required. - - `--auth-type`: SMTP Authentication Type (PLAIN/LOGIN/CRAM-MD5). Default to PLAIN. - - `--host`: SMTP host. Required. - - `--port`: SMTP port. Required. - - `--force-smtps`: SMTPS is always used on port 465. Set this to force SMTPS on other ports. - - `--skip-verify`: Skip TLS verify. - - `--helo-hostname`: Hostname sent with HELO. Leave blank to send current hostname. - - `--disable-helo`: Disable SMTP helo. - - `--allowed-domains`: Leave empty to allow all domains. Separate multiple domains with a comma (','). - - `--skip-local-2fa`: Skip 2FA to log on. - - `--active`: This Authentication Source is Activated. - Remarks: - `--force-smtps`, `--skip-verify`, `--disable-helo`, `--skip-loca-2fs` and `--active` options can be used in form: - - `--option`, `--option=true` to enable - - `--option=false` to disable - If those options are not specified value would not be changed in `update-smtp` or would use default `false` value in `add-smtp` - - Examples: - - `gitea admin auth add-smtp --name ldap --host smtp.mydomain.org --port 587 --skip-verify --active` - - `update-smtp`: - - Options: - - `--id`: ID of source to be updated. Required. - - other options are shared with `add-smtp` - - Examples: - - `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`: Add new LDAP (via Bind DN) authentication source - - Options: - - `--name value`: Authentication name. Required. - - `--not-active`: Deactivate the authentication source. - - `--security-protocol value`: Security protocol name. Required. - - `--skip-tls-verify`: Disable TLS verification. - - `--host value`: The address where the LDAP server can be reached. Required. - - `--port value`: The port to use when connecting to the LDAP server. Required. - - `--user-search-base value`: The LDAP base at which user accounts will be searched for. Required. - - `--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate. Required. - - `--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges. - - `--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status. - - `--username-attribute value`: The attribute of the user’s LDAP record containing the user name. - - `--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name. - - `--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname. - - `--email-attribute value`: The attribute of the user’s LDAP record containing the user’s email address. Required. - - `--public-ssh-key-attribute value`: The attribute of the user’s LDAP record containing the user’s public ssh key. - - `--avatar-attribute value`: The attribute of the user’s LDAP record containing the user’s avatar. - - `--bind-dn value`: The DN to bind to the LDAP server with when searching for the user. - - `--bind-password value`: The password for the Bind DN, if any. - - `--attributes-in-bind`: Fetch attributes in bind DN context. - - `--synchronize-users`: Enable user synchronization. - - `--page-size value`: Search page size. - - Examples: - - `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`: Update existing LDAP (via Bind DN) authentication source - - Options: - - `--id value`: ID of authentication source. Required. - - `--name value`: Authentication name. - - `--not-active`: Deactivate the authentication source. - - `--security-protocol value`: Security protocol name. - - `--skip-tls-verify`: Disable TLS verification. - - `--host value`: The address where the LDAP server can be reached. - - `--port value`: The port to use when connecting to the LDAP server. - - `--user-search-base value`: The LDAP base at which user accounts will be searched for. - - `--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate. - - `--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges. - - `--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status. - - `--username-attribute value`: The attribute of the user’s LDAP record containing the user name. - - `--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name. - - `--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname. - - `--email-attribute value`: The attribute of the user’s LDAP record containing the user’s email address. - - `--public-ssh-key-attribute value`: The attribute of the user’s LDAP record containing the user’s public ssh key. - - `--avatar-attribute value`: The attribute of the user’s LDAP record containing the user’s avatar. - - `--bind-dn value`: The DN to bind to the LDAP server with when searching for the user. - - `--bind-password value`: The password for the Bind DN, if any. - - `--attributes-in-bind`: Fetch attributes in bind DN context. - - `--synchronize-users`: Enable user synchronization. - - `--page-size value`: Search page size. - - Examples: - - `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`: Add new LDAP (simple auth) authentication source - - Options: - - `--name value`: Authentication name. Required. - - `--not-active`: Deactivate the authentication source. - - `--security-protocol value`: Security protocol name. Required. - - `--skip-tls-verify`: Disable TLS verification. - - `--host value`: The address where the LDAP server can be reached. Required. - - `--port value`: The port to use when connecting to the LDAP server. Required. - - `--user-search-base value`: The LDAP base at which user accounts will be searched for. - - `--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate. Required. - - `--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges. - - `--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status. - - `--username-attribute value`: The attribute of the user’s LDAP record containing the user name. - - `--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name. - - `--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname. - - `--email-attribute value`: The attribute of the user’s LDAP record containing the user’s email address. Required. - - `--public-ssh-key-attribute value`: The attribute of the user’s LDAP record containing the user’s public ssh key. - - `--avatar-attribute value`: The attribute of the user’s LDAP record containing the user’s avatar. - - `--user-dn value`: The user’s DN. Required. - - Examples: - - `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`: Update existing LDAP (simple auth) authentication source - - Options: - - `--id value`: ID of authentication source. Required. - - `--name value`: Authentication name. - - `--not-active`: Deactivate the authentication source. - - `--security-protocol value`: Security protocol name. - - `--skip-tls-verify`: Disable TLS verification. - - `--host value`: The address where the LDAP server can be reached. - - `--port value`: The port to use when connecting to the LDAP server. - - `--user-search-base value`: The LDAP base at which user accounts will be searched for. - - `--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate. - - `--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges. - - `--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status. - - `--username-attribute value`: The attribute of the user’s LDAP record containing the user name. - - `--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name. - - `--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname. - - `--email-attribute value`: The attribute of the user’s LDAP record containing the user’s email address. - - `--public-ssh-key-attribute value`: The attribute of the user’s LDAP record containing the user’s public ssh key. - - `--avatar-attribute value`: The attribute of the user’s LDAP record containing the user’s avatar. - - `--user-dn value`: The user’s DN. - - Examples: - - `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 - -Generates a self-signed SSL certificate. Outputs to `cert.pem` and `key.pem` in the current -directory and will overwrite any existing files. - -- Options: - - `--host value`: Comma separated hostnames and ips which this certificate is valid for. - Wildcards are supported. Required. - - `--ecdsa-curve value`: ECDSA curve to use to generate a key. Optional. Valid options - are P224, P256, P384, P521. - - `--rsa-bits value`: Size of RSA key to generate. Optional. Ignored if --ecdsa-curve is - set. (default: 2048). - - `--start-date value`: Creation date. Optional. (format: `Jan 1 15:04:05 2011`). - - `--duration value`: Duration which the certificate is valid for. Optional. (default: 8760h0m0s) - - `--ca`: If provided, this cert generates it's own certificate authority. Optional. -- Examples: - - `gitea cert --host git.example.com,example.com,www.example.com --ca` - -### dump - -Dumps all files and databases into a zip file. Outputs into a file like `gitea-dump-1482906742.zip` -in the current directory. - -- Options: - - `--file name`, `-f name`: Name of the dump file with will be created. Optional. (default: gitea-dump-[timestamp].zip). - - `--tempdir path`, `-t path`: Path to the temporary directory used. Optional. (default: /tmp). - - `--skip-repository`, `-R`: Skip the repository dumping. Optional. - - `--skip-custom-dir`: Skip dumping of the custom dir. Optional. - - `--skip-lfs-data`: Skip dumping of LFS data. Optional. - - `--skip-attachment-data`: Skip dumping of attachment data. Optional. - - `--skip-package-data`: Skip dumping of package data. Optional. - - `--skip-log`: Skip dumping of log data. Optional. - - `--database`, `-d`: Specify the database SQL syntax. Optional. - - `--verbose`, `-V`: If provided, shows additional details. Optional. - - `--type`: Set the dump output format. Optional. (default: zip) -- Examples: - - `gitea dump` - - `gitea dump --verbose` - -### generate - -Generates random values and tokens for usage in configuration file. Useful for generating values -for automatic deployments. - -- Commands: - - `secret`: - - Options: - - `INTERNAL_TOKEN`: Token used for an internal API call authentication. - - `JWT_SECRET`: LFS & OAUTH2 JWT authentication secret (LFS_JWT_SECRET is aliased to this option for backwards compatibility). - - `SECRET_KEY`: Global secret key. - - Examples: - - `gitea generate secret INTERNAL_TOKEN` - - `gitea generate secret JWT_SECRET` - - `gitea generate secret SECRET_KEY` - -### keys - -Provides an SSHD AuthorizedKeysCommand. Needs to be configured in the sshd config file: - -```ini -... -# The value of -e and the AuthorizedKeysCommandUser should match the -# username running Gitea -AuthorizedKeysCommandUser git -AuthorizedKeysCommand /path/to/gitea keys -e git -u %u -t %t -k %k -``` - -The command will return the appropriate authorized_keys line for the -provided key. You should also set the value -`SSH_CREATE_AUTHORIZED_KEYS_FILE=false` in the `[server]` section of -`app.ini`. - -NB: opensshd requires the Gitea program to be owned by root and not -writable by group or others. The program must be specified by an absolute -path. -NB: Gitea must be running for this command to succeed. - -### migrate - -Migrates the database. This command can be used to run other commands before starting the server for the first time. -This command is idempotent. - -### doctor check - -Diagnose and potentially fix problems with the current Gitea instance. -Several checks are run by default, but additional ones can be run: - -- `gitea doctor check --list` - will list all the available checks -- `gitea doctor check --all` - will run all available checks -- `gitea doctor check --default` - will run the default checks -- `gitea doctor check --run [check(s),]...` - will run the named checks - -Some problems can be automatically fixed by passing the `--fix` option. -Extra logging can be set with `--log-file=...`. - -#### doctor recreate-table - -Sometimes when there are migrations the old columns and default values may be left -unchanged in the database schema. This may lead to warning such as: - -``` -2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync2() [W] Table user Column keep_activity_private db default is , struct default is 0 -``` - -You can cause Gitea to recreate these tables and copy the old data into the new table -with the defaults set appropriately by using: - -``` -gitea doctor recreate-table user -``` - -You can ask Gitea to recreate multiple tables using: - -``` -gitea doctor recreate-table table1 table2 ... -``` - -And if you would like Gitea to recreate all tables simply call: - -``` -gitea doctor recreate-table -``` - -It is highly recommended to back-up your database before running these commands. - -### doctor convert - -Converts a MySQL database from utf8 to utf8mb4 or a MSSQL database from varchar to nvarchar. - -### manager - -Manage running server operations: - -- Commands: - - `shutdown`: Gracefully shutdown the running process - - `restart`: Gracefully restart the running process - (not implemented for windows servers) - - `flush-queues`: Flush queues in the running process - - Options: - - `--timeout value`: Timeout for the flushing process (default: 1m0s) - - `--non-blocking`: Set to true to not wait for flush to complete before returning - - `logging`: Adjust logging commands - - Commands: - - `pause`: Pause logging - - Notes: - - The logging level will be raised to INFO temporarily if it is below this level. - - Gitea will buffer logs up to a certain point and will drop them after that point. - - `resume`: Resume logging - - `release-and-reopen`: Cause Gitea to release and re-open files and connections used for logging (Equivalent to sending SIGUSR1 to Gitea.) - - `remove name`: Remove the named logger - - Options: - - `--group group`, `-g group`: Set the group to remove the sublogger from. (defaults to `default`) - - `add`: Add a logger - - Commands: - - `console`: Add a console logger - - Options: - - `--group value`, `-g value`: Group to add logger to - will default to "default" - - `--name value`, `-n value`: Name of the new logger - will default to mode - - `--level value`, `-l value`: Logging level for the new logger - - `--stacktrace-level value`, `-L value`: Stacktrace logging level - - `--flags value`, `-F value`: Flags for the logger - - `--expression value`, `-e value`: Matching expression for the logger - - `--prefix value`, `-p value`: Prefix for the logger - - `--color`: Use color in the logs - - `--stderr`: Output console logs to stderr - only relevant for console - - `file`: Add a file logger - - Options: - - `--group value`, `-g value`: Group to add logger to - will default to "default" - - `--name value`, `-n value`: Name of the new logger - will default to mode - - `--level value`, `-l value`: Logging level for the new logger - - `--stacktrace-level value`, `-L value`: Stacktrace logging level - - `--flags value`, `-F value`: Flags for the logger - - `--expression value`, `-e value`: Matching expression for the logger - - `--prefix value`, `-p value`: Prefix for the logger - - `--color`: Use color in the logs - - `--filename value`, `-f value`: Filename for the logger - - - `--rotate`, `-r`: Rotate logs - - `--max-size value`, `-s value`: Maximum size in bytes before rotation - - `--daily`, `-d`: Rotate logs daily - - `--max-days value`, `-D value`: Maximum number of daily logs to keep - - `--compress`, `-z`: Compress rotated logs - - `--compression-level value`, `-Z value`: Compression level to use - - `conn`: Add a network connection logger - - Options: - - `--group value`, `-g value`: Group to add logger to - will default to "default" - - `--name value`, `-n value`: Name of the new logger - will default to mode - - `--level value`, `-l value`: Logging level for the new logger - - `--stacktrace-level value`, `-L value`: Stacktrace logging level - - `--flags value`, `-F value`: Flags for the logger - - `--expression value`, `-e value`: Matching expression for the logger - - `--prefix value`, `-p value`: Prefix for the logger - - `--color`: Use color in the logs - - `--reconnect-on-message`, `-R`: Reconnect to host for every message - - `--reconnect`, `-r`: Reconnect to host when connection is dropped - - `--protocol value`, `-P value`: Set protocol to use: tcp, unix, or udp (defaults to tcp) - - `--address value`, `-a value`: Host address and port to connect to (defaults to :7020) - - `smtp`: Add an SMTP logger - - Options: - - `--group value`, `-g value`: Group to add logger to - will default to "default" - - `--name value`, `-n value`: Name of the new logger - will default to mode - - `--level value`, `-l value`: Logging level for the new logger - - `--stacktrace-level value`, `-L value`: Stacktrace logging level - - `--flags value`, `-F value`: Flags for the logger - - `--expression value`, `-e value`: Matching expression for the logger - - `--prefix value`, `-p value`: Prefix for the logger - - `--color`: Use color in the logs - - `--username value`, `-u value`: Mail server username - - `--password value`, `-P value`: Mail server password - - `--host value`, `-H value`: Mail server host (defaults to: 127.0.0.1:25) - - `--send-to value`, `-s value`: Email address(es) to send to - - `--subject value`, `-S value`: Subject header of sent emails - - `processes`: Display Gitea processes and goroutine information - - Options: - - `--flat`: Show processes as flat table rather than as tree - - `--no-system`: Do not show system processes - - `--stacktraces`: Show stacktraces for goroutines associated with processes - - `--json`: Output as json - - `--cancel PID`: Send cancel to process with PID. (Only for non-system processes.) - -### dump-repo - -Dump-repo dumps repository data from Git/GitHub/Gitea/GitLab: - -- Options: - - `--git_service service` : Git service, it could be `git`, `github`, `gitea`, `gitlab`, If clone_addr could be recognized, this could be ignored. - - `--repo_dir dir`, `-r dir`: Repository dir path to store the data - - `--clone_addr addr`: The URL will be clone, currently could be a git/github/gitea/gitlab http/https URL. i.e. https://github.com/lunny/tango.git - - `--auth_username lunny`: The username to visit the clone_addr - - `--auth_password <password>`: The password to visit the clone_addr - - `--auth_token <token>`: The personal token to visit the clone_addr - - `--owner_name lunny`: The data will be stored on a directory with owner name if not empty - - `--repo_name tango`: The data will be stored on a directory with repository name if not empty - - `--units <units>`: Which items will be migrated, one or more units should be separated as comma. wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments are allowed. Empty means all units. - -### restore-repo - -Restore-repo restore repository data from disk dir: - -- Options: - - `--repo_dir dir`, `-r dir`: Repository dir path to restore from - - `--owner_name lunny`: Restore destination owner name - - `--repo_name tango`: Restore destination repository name - - `--units <units>`: Which items will be restored, one or more units should be separated as comma. wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments are allowed. Empty means all units. - -### actions generate-runner-token - -Generate a new token for a runner to use to register with the server - -- Options: - - `--scope {owner}[/{repo}]`, `-s {owner}[/{repo}]`: To limit the scope of the runner, no scope means the runner can be used for all repos, but you can also limit it to a specific repo or owner - -To register a global runner: - -``` -gitea actions generate-runner-token -``` - -To register a runner for a specific organization, in this case `org`: - -``` -gitea actions generate-runner-token -s org -``` - -To register a runner for a specific repo, in this case `username/test-repo`: - -``` -gitea actions generate-runner-token -s username/test-repo -``` diff --git a/docs/content/doc/administration/command-line.zh-cn.md b/docs/content/doc/administration/command-line.zh-cn.md deleted file mode 100644 index a832cbef97..0000000000 --- a/docs/content/doc/administration/command-line.zh-cn.md +++ /dev/null @@ -1,546 +0,0 @@ ---- -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 - -迁移数据库。该命令可用于在首次启动服务器之前运行其他命令。此命令是幂等的。 - -### doctor check - -对 Gitea 实例进行诊断，可以修复一些可修复的问题。 -默认只运行部分检查，额外的检查可以参考： - -- `gitea doctor check --list` - 列出所有可用的检查 -- `gitea doctor check --all` - 运行所有可用的检查 -- `gitea doctor check --default` - 运行默认的检查 -- `gitea doctor check --run [check(s),]...` - 运行指定的名字的检查 - -有些问题可以通过设置 `--fix` 选项进行自动修复。 -额外的日志可以通过 `--log-file=...` 进行设置。 - -#### 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 -``` - -强烈建议在运行这些命令之前备份您的数据库。 - -### doctor convert - -将现有的 MySQL 数据库从 utf8 转换为 utf8mb4，或者把 MSSQL 数据库从 varchar 转换为 nvarchar。 - -### 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 -``` diff --git a/docs/content/doc/administration/config-cheat-sheet.en-us.md b/docs/content/doc/administration/config-cheat-sheet.en-us.md deleted file mode 100644 index fc2184e884..0000000000 --- a/docs/content/doc/administration/config-cheat-sheet.en-us.md +++ /dev/null @@ -1,1403 +0,0 @@ ---- -date: "2016-12-26T16:00:00+02:00" -title: "Config Cheat Sheet" -slug: "config-cheat-sheet" -weight: 30 -toc: false -draft: false -aliases: - - /en-us/config-cheat-sheet -menu: - sidebar: - parent: "administration" - name: "Config Cheat Sheet" - weight: 30 - identifier: "config-cheat-sheet" ---- - -# Configuration Cheat Sheet - -This is a cheat sheet for the Gitea configuration file. It contains most of the settings -that can be configured as well as their default values. - -Any changes to the Gitea configuration file should be made in `custom/conf/app.ini` -or any corresponding location. When installing from a distribution, this will -typically be found at `/etc/gitea/conf/app.ini`. - -The defaults provided here are best-effort (not built automatically). They are -accurately recorded in [app.example.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) -(s/main/\<tag|release\>). Any string in the format `%(X)s` is a feature powered -by [ini](https://github.com/go-ini/ini/#recursive-values), for reading values recursively. - -In the default values below, a value in the form `$XYZ` refers to an environment variable. (However, see `environment-to-ini`.) Values in the form _`XxYyZz`_ refer to values listed as part of the default configuration. These notation forms will not work in your own `app.ini` file and are only listed here as documentation. - -Values containing `#` or `;` must be quoted using `` ` `` or `"""`. - -**Note:** A full restart is required for Gitea configuration changes to take effect. - -{{< toc >}} - -## Default Configuration (non-`app.ini` configuration) - -These values are environment-dependent but form the basis of a lot of values. They will be -reported as part of the default configuration when running `gitea help` or on start-up. The order they are emitted there is slightly different but we will list them here in the order they are set-up. - -- _`AppPath`_: This is the absolute path of the running gitea binary. -- _`AppWorkPath`_: This refers to "working path" of the `gitea` binary. It is determined by using the first set thing in the following hierarchy: - - The `WORK_PATH` option in `app.ini` - - The `--work-path` flag passed to the binary - - The environment variable `$GITEA_WORK_DIR` - - A built-in value set at build time (see building from source) - - Otherwise, it defaults to the directory of the _`AppPath`_ - - If any of the above are relative paths then they are made absolute against the directory of the _`AppPath`_ -- _`CustomPath`_: This is the base directory for custom templates and other options. -It is determined by using the first set thing in the following hierarchy: - - The `--custom-path` flag passed to the binary - - The environment variable `$GITEA_CUSTOM` - - A built-in value set at build time (see building from source) - - Otherwise, it defaults to _`AppWorkPath`_`/custom` - - If any of the above are relative paths then they are made absolute against the -the directory of the _`AppWorkPath`_ -- _`CustomConf`_: This is the path to the `app.ini` file. - - The `--config` flag passed to the binary - - A built-in value set at build time (see building from source) - - Otherwise, it defaults to _`CustomPath`_`/conf/app.ini` - - If any of the above are relative paths then they are made absolute against the directory of the _`CustomPath`_ - -In addition, there is _`StaticRootPath`_ which can be set as a built-in at build time, but will otherwise default to _`AppWorkPath`_ - -## Overall (`DEFAULT`) - -- `APP_NAME`: **Gitea: Git with a cup of tea**: Application name, used in the page title. -- `RUN_USER`: **_current OS username_/`$USER`/`$USERNAME` e.g. git**: The user Gitea will run as. - This should be a dedicated system (non-user) account. Setting this incorrectly will cause Gitea - to not start. -- `RUN_MODE`: **prod**: Application run mode, affects performance and debugging: `dev` or `prod`, default is `prod`. Mode `dev` makes Gitea easier to develop and debug, values other than `dev` are treated as `prod` which is for production use. -- `WORK_PATH`: **_the-work-path_**: The working directory, see the comment of AppWorkPath above. - -## Repository (`repository`) - -- `ROOT`: **%(APP_DATA_PATH)s/gitea-repositories**: Root path for storing all repository data. - A relative path is interpreted as **_`AppWorkPath`_/%(ROOT)s**. -- `SCRIPT_TYPE`: **bash**: The script type this server supports. Usually this is `bash`, - but some users report that only `sh` is available. -- `DETECTED_CHARSETS_ORDER`: **UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, ISO-8859, windows-1252, ISO-8859, windows-1250, ISO-8859, ISO-8859, ISO-8859, windows-1253, ISO-8859, windows-1255, ISO-8859, windows-1251, windows-1256, KOI8-R, ISO-8859, windows-1254, Shift_JIS, GB18030, EUC-JP, EUC-KR, Big5, ISO-2022, ISO-2022, ISO-2022, IBM424_rtl, IBM424_ltr, IBM420_rtl, IBM420_ltr**: Tie-break order of detected charsets - if the detected charsets have equal confidence, charsets earlier in the list will be chosen in preference to those later. Adding `defaults` will place the unnamed charsets at that point. -- `ANSI_CHARSET`: **\<empty\>**: Default ANSI charset to override non-UTF-8 charsets to. -- `FORCE_PRIVATE`: **false**: Force every new repository to be private. -- `DEFAULT_PRIVATE`: **last**: Default private when creating a new repository. - \[last, private, public\] -- `DEFAULT_PUSH_CREATE_PRIVATE`: **true**: Default private when creating a new repository with push-to-create. -- `MAX_CREATION_LIMIT`: **-1**: Global maximum creation limit of repositories per user, - `-1` means no limit. -- `PREFERRED_LICENSES`: **Apache License 2.0,MIT License**: Preferred Licenses to place at - the top of the list. Name must match file name in options/license or custom/options/license. -- `DISABLE_HTTP_GIT`: **false**: Disable the ability to interact with repositories over the - HTTP protocol. -- `USE_COMPAT_SSH_URI`: **false**: Force ssh:// clone url instead of scp-style uri when - default SSH port is used. -- `GO_GET_CLONE_URL_PROTOCOL`: **https**: Value for the "go get" request returns the repository url as https or ssh - default is https. -- `ACCESS_CONTROL_ALLOW_ORIGIN`: **\<empty\>**: Value for Access-Control-Allow-Origin header, - default is not to present. **WARNING**: This maybe harmful to you website if you do not - give it a right value. -- `DEFAULT_CLOSE_ISSUES_VIA_COMMITS_IN_ANY_BRANCH`: **false**: Close an issue if a commit on a non default branch marks it as closed. -- `ENABLE_PUSH_CREATE_USER`: **false**: Allow users to push local repositories to Gitea and have them automatically created for a user. -- `ENABLE_PUSH_CREATE_ORG`: **false**: Allow users to push local repositories to Gitea and have them automatically created for an org. -- `DISABLED_REPO_UNITS`: **_empty_**: Comma separated list of globally disabled repo units. Allowed values: \[repo.issues, repo.ext_issues, repo.pulls, repo.wiki, repo.ext_wiki, repo.projects, repo.packages, repo.actions\] -- `DEFAULT_REPO_UNITS`: **repo.code,repo.releases,repo.issues,repo.pulls,repo.wiki,repo.projects,repo.packages**: Comma separated list of default new repo units. Allowed values: \[repo.code, repo.releases, repo.issues, repo.pulls, repo.wiki, repo.projects, repo.packages, repo.actions\]. Note: Code and Releases can currently not be deactivated. If you specify default repo units you should still list them for future compatibility. External wiki and issue tracker can't be enabled by default as it requires additional settings. Disabled repo units will not be added to new repositories regardless if it is in the default list. -- `DEFAULT_FORK_REPO_UNITS`: **repo.code,repo.pulls**: Comma separated list of default forked repo units. The set of allowed values and rules is the same as `DEFAULT_REPO_UNITS`. -- `PREFIX_ARCHIVE_FILES`: **true**: Prefix archive files by placing them in a directory named after the repository. -- `DISABLE_MIGRATIONS`: **false**: Disable migrating feature. -- `DISABLE_STARS`: **false**: Disable stars feature. -- `DEFAULT_BRANCH`: **main**: Default branch name of all repositories. -- `ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`: **false**: Allow non-admin users to adopt unadopted repositories -- `ALLOW_DELETION_OF_UNADOPTED_REPOSITORIES`: **false**: Allow non-admin users to delete unadopted repositories -- `DISABLE_DOWNLOAD_SOURCE_ARCHIVES`: **false**: Don't allow download source archive files from UI -- `ALLOW_FORK_WITHOUT_MAXIMUM_LIMIT`: **true**: Allow fork repositories without maximum number limit - -### Repository - Editor (`repository.editor`) - -- `LINE_WRAP_EXTENSIONS`: **.txt,.md,.markdown,.mdown,.mkd,.livemd,**: List of file extensions for which lines should be wrapped in the Monaco editor. Separate extensions with a comma. To line wrap files without an extension, just put a comma -- `PREVIEWABLE_FILE_MODES`: **markdown**: Valid file modes that have a preview API associated with them, such as `api/v1/markdown`. Separate the values by commas. The preview tab in edit mode won't be displayed if the file extension doesn't match. - -### Repository - Pull Request (`repository.pull-request`) - -- `WORK_IN_PROGRESS_PREFIXES`: **WIP:,\[WIP\]**: List of prefixes used in Pull Request - title to mark them as Work In Progress. These are matched in a case-insensitive manner. -- `CLOSE_KEYWORDS`: **close**, **closes**, **closed**, **fix**, **fixes**, **fixed**, **resolve**, **resolves**, **resolved**: List of - keywords used in Pull Request comments to automatically close a related issue -- `REOPEN_KEYWORDS`: **reopen**, **reopens**, **reopened**: List of keywords used in Pull Request comments to automatically reopen - a related issue -- `DEFAULT_MERGE_STYLE`: **merge**: Set default merge style for repository creating, valid options: `merge`, `rebase`, `rebase-merge`, `squash` -- `DEFAULT_MERGE_MESSAGE_COMMITS_LIMIT`: **50**: In the default merge message for squash commits include at most this many commits. Set to `-1` to include all commits -- `DEFAULT_MERGE_MESSAGE_SIZE`: **5120**: In the default merge message for squash commits limit the size of the commit messages. Set to `-1` to have no limit. Only used if `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES` is `true`. -- `DEFAULT_MERGE_MESSAGE_ALL_AUTHORS`: **false**: In the default merge message for squash commits walk all commits to include all authors in the Co-authored-by otherwise just use those in the limited list -- `DEFAULT_MERGE_MESSAGE_MAX_APPROVERS`: **10**: In default merge messages limit the number of approvers listed as `Reviewed-by:`. Set to `-1` to include all. -- `DEFAULT_MERGE_MESSAGE_OFFICIAL_APPROVERS_ONLY`: **true**: In default merge messages only include approvers who are officially allowed to review. -- `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES`: **false**: In default squash-merge messages include the commit message of all commits comprising the pull request. -- `ADD_CO_COMMITTER_TRAILERS`: **true**: Add co-authored-by and co-committed-by trailers to merge commit messages if committer does not match author. -- `TEST_CONFLICTING_PATCHES_WITH_GIT_APPLY`: **false**: PR patches are tested using a three-way merge method to discover if there are conflicts. If this setting is set to **true**, conflicting patches will be retested using `git apply` - This was the previous behaviour in 1.18 (and earlier) but is somewhat inefficient. Please report if you find that this setting is required. - -### Repository - Issue (`repository.issue`) - -- `LOCK_REASONS`: **Too heated,Off-topic,Resolved,Spam**: A list of reasons why a Pull Request or Issue can be locked -- `MAX_PINNED`: **3**: Maximum number of pinned Issues per Repo. Set to 0 to disable pinning Issues. - -### Repository - Upload (`repository.upload`) - -- `ENABLED`: **true**: Whether repository file uploads are enabled -- `TEMP_PATH`: **data/tmp/uploads**: Path for uploads (content gets deleted on Gitea restart) -- `ALLOWED_TYPES`: **\<empty\>**: Comma-separated list of allowed file extensions (`.zip`), mime types (`text/plain`) or wildcard type (`image/*`, `audio/*`, `video/*`). Empty value or `*/*` allows all types. -- `FILE_MAX_SIZE`: **3**: Max size of each file in megabytes. -- `MAX_FILES`: **5**: Max number of files per upload - -### Repository - Release (`repository.release`) - -- `ALLOWED_TYPES`: **\<empty\>**: Comma-separated list of allowed file extensions (`.zip`), mime types (`text/plain`) or wildcard type (`image/*`, `audio/*`, `video/*`). Empty value or `*/*` allows all types. -- `DEFAULT_PAGING_NUM`: **10**: The default paging number of releases user interface -- For settings related to file attachments on releases, see the `attachment` section. - -### Repository - Signing (`repository.signing`) - -- `SIGNING_KEY`: **default**: \[none, KEYID, default \]: Key to sign with. -- `SIGNING_NAME` & `SIGNING_EMAIL`: if a KEYID is provided as the `SIGNING_KEY`, use these as the Name and Email address of the signer. These should match publicized name and email address for the key. -- `INITIAL_COMMIT`: **always**: \[never, pubkey, twofa, always\]: Sign initial commit. - - `never`: Never sign - - `pubkey`: Only sign if the user has a public key - - `twofa`: Only sign if the user is logged in with twofa - - `always`: Always sign - - Options other than `never` and `always` can be combined as a comma separated list. -- `DEFAULT_TRUST_MODEL`: **collaborator**: \[collaborator, committer, collaboratorcommitter\]: The default trust model used for verifying commits. - - `collaborator`: Trust signatures signed by keys of collaborators. - - `committer`: Trust signatures that match committers (This matches GitHub and will force Gitea signed commits to have Gitea as the committer). - - `collaboratorcommitter`: Trust signatures signed by keys of collaborators which match the committer. -- `WIKI`: **never**: \[never, pubkey, twofa, always, parentsigned\]: Sign commits to wiki. -- `CRUD_ACTIONS`: **pubkey, twofa, parentsigned**: \[never, pubkey, twofa, parentsigned, always\]: Sign CRUD actions. - - Options as above, with the addition of: - - `parentsigned`: Only sign if the parent commit is signed. -- `MERGES`: **pubkey, twofa, basesigned, commitssigned**: \[never, pubkey, twofa, approved, basesigned, commitssigned, always\]: Sign merges. - - `approved`: Only sign approved merges to a protected branch. - - `basesigned`: Only sign if the parent commit in the base repo is signed. - - `headsigned`: Only sign if the head commit in the head branch is signed. - - `commitssigned`: Only sign if all the commits in the head branch to the merge point are signed. - -## Repository - Local (`repository.local`) - -- `LOCAL_COPY_PATH`: **tmp/local-repo**: Path for temporary local repository copies. Defaults to `tmp/local-repo` (content gets deleted on Gitea restart) - -## Repository - MIME type mapping (`repository.mimetype_mapping`) - -Configuration for set the expected MIME type based on file extensions of downloadable files. Configuration presents in key-value pairs and file extensions starts with leading `.`. - -The following configuration set `Content-Type: application/vnd.android.package-archive` header when downloading files with `.apk` file extension. - -```ini -.apk=application/vnd.android.package-archive -``` - -## CORS (`cors`) - -- `ENABLED`: **false**: enable cors headers (disabled by default) -- `SCHEME`: **http**: scheme of allowed requests -- `ALLOW_DOMAIN`: **\***: list of requesting domains that are allowed -- `ALLOW_SUBDOMAIN`: **false**: allow subdomains of headers listed above to request -- `METHODS`: **GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS**: list of methods allowed to request -- `MAX_AGE`: **10m**: max time to cache response -- `ALLOW_CREDENTIALS`: **false**: allow request with credentials -- `HEADERS`: **Content-Type,User-Agent**: additional headers that are permitted in requests -- `X_FRAME_OPTIONS`: **SAMEORIGIN**: Set the `X-Frame-Options` header value. - -## UI (`ui`) - -- `EXPLORE_PAGING_NUM`: **20**: Number of repositories that are shown in one explore page. -- `ISSUE_PAGING_NUM`: **20**: Number of issues that are shown in one page (for all pages that list issues, milestones, projects). -- `MEMBERS_PAGING_NUM`: **20**: Number of members that are shown in organization members. -- `FEED_MAX_COMMIT_NUM`: **5**: Number of maximum commits shown in one activity feed. -- `FEED_PAGING_NUM`: **20**: Number of items that are displayed in home feed. -- `SITEMAP_PAGING_NUM`: **20**: Number of items that are displayed in a single subsitemap. -- `GRAPH_MAX_COMMIT_NUM`: **100**: Number of maximum commits shown in the commit graph. -- `CODE_COMMENT_LINES`: **4**: Number of line of codes shown for a code comment. -- `DEFAULT_THEME`: **auto**: \[auto, gitea, arc-green\]: Set the default theme for the Gitea install. -- `SHOW_USER_EMAIL`: **true**: Whether the email of the user should be shown in the Explore Users page. -- `THEMES`: **auto,gitea,arc-green**: All available themes. Allow users select personalized themes. - regardless of the value of `DEFAULT_THEME`. -- `MAX_DISPLAY_FILE_SIZE`: **8388608**: Max size of files to be displayed (default is 8MiB) -- `REACTIONS`: All available reactions users can choose on issues/prs and comments - Values can be emoji alias (:smile:) or a unicode emoji. - For custom reactions, add a tightly cropped square image to public/assets/img/emoji/reaction_name.png -- `CUSTOM_EMOJIS`: **gitea, codeberg, gitlab, git, github, gogs**: Additional Emojis not defined in the utf8 standard. - By default, we support Gitea (:gitea:), to add more copy them to public/assets/img/emoji/emoji_name.png and - add it to this config. -- `DEFAULT_SHOW_FULL_NAME`: **false**: Whether the full name of the users should be shown where possible. If the full name isn't set, the username will be used. -- `SEARCH_REPO_DESCRIPTION`: **true**: Whether to search within description at repository search on explore page. -- `ONLY_SHOW_RELEVANT_REPOS`: **false** Whether to only show relevant repos on the explore page when no keyword is specified and default sorting is used. - A repo is considered irrelevant if it's a fork or if it has no metadata (no description, no icon, no topic). - -### UI - Admin (`ui.admin`) - -- `USER_PAGING_NUM`: **50**: Number of users that are shown in one page. -- `REPO_PAGING_NUM`: **50**: Number of repos that are shown in one page. -- `NOTICE_PAGING_NUM`: **25**: Number of notices that are shown in one page. -- `ORG_PAGING_NUM`: **50**: Number of organizations that are shown in one page. - -### UI - User (`ui.user`) - -- `REPO_PAGING_NUM`: **15**: Number of repos that are shown in one page. - -### UI - Metadata (`ui.meta`) - -- `AUTHOR`: **Gitea - Git with a cup of tea**: Author meta tag of the homepage. -- `DESCRIPTION`: **Gitea (Git with a cup of tea) is a painless self-hosted Git service written in Go**: Description meta tag of the homepage. -- `KEYWORDS`: **go,git,self-hosted,gitea**: Keywords meta tag of the homepage. - -### UI - Notification (`ui.notification`) - -- `MIN_TIMEOUT`: **10s**: These options control how often notification endpoint is polled to update the notification count. On page load the notification count will be checked after `MIN_TIMEOUT`. The timeout will increase to `MAX_TIMEOUT` by `TIMEOUT_STEP` if the notification count is unchanged. Set MIN_TIMEOUT to -1 to turn off. -- `MAX_TIMEOUT`: **60s**. -- `TIMEOUT_STEP`: **10s**. -- `EVENT_SOURCE_UPDATE_TIME`: **10s**: This setting determines how often the database is queried to update notification counts. If the browser client supports `EventSource` and `SharedWorker`, a `SharedWorker` will be used in preference to polling notification endpoint. Set to **-1** to disable the `EventSource`. - -### UI - SVG Images (`ui.svg`) - -- `ENABLE_RENDER`: **true**: Whether to render SVG files as images. If SVG rendering is disabled, SVG files are displayed as text and cannot be embedded in markdown files as images. - -### UI - CSV Files (`ui.csv`) - -- `MAX_FILE_SIZE`: **524288** (512kb): Maximum allowed file size in bytes to render CSV files as table. (Set to 0 for no limit). - -## Markdown (`markdown`) - -- `ENABLE_HARD_LINE_BREAK_IN_COMMENTS`: **true**: Render soft line breaks as hard line breaks in comments, which - means a single newline character between paragraphs will cause a line break and adding - trailing whitespace to paragraphs is not necessary to force a line break. -- `ENABLE_HARD_LINE_BREAK_IN_DOCUMENTS`: **false**: Render soft line breaks as hard line breaks in documents, which - means a single newline character between paragraphs will cause a line break and adding - trailing whitespace to paragraphs is not necessary to force a line break. -- `CUSTOM_URL_SCHEMES`: Use a comma separated list (ftp,git,svn) to indicate additional - URL hyperlinks to be rendered in Markdown. URLs beginning in http and https are - always displayed. If this entry is empty, all URL schemes are allowed -- `FILE_EXTENSIONS`: **.md,.markdown,.mdown,.mkd,.livemd**: List of file extensions that should be rendered/edited as Markdown. Separate the extensions with a comma. To render files without any extension as markdown, just put a comma. -- `ENABLE_MATH`: **true**: Enables detection of `\(...\)`, `\[...\]`, `$...$` and `$$...$$` blocks as math blocks. - -## Server (`server`) - -- `APP_DATA_PATH`: **_`AppWorkPath`_/data**: This is the default root path for storing data. -- `PROTOCOL`: **http**: \[http, https, fcgi, http+unix, fcgi+unix\] -- `USE_PROXY_PROTOCOL`: **false**: Expect PROXY protocol headers on connections -- `PROXY_PROTOCOL_TLS_BRIDGING`: **false**: When protocol is https, expect PROXY protocol headers after TLS negotiation. -- `PROXY_PROTOCOL_HEADER_TIMEOUT`: **5s**: Timeout to wait for PROXY protocol header (set to 0 to have no timeout) -- `PROXY_PROTOCOL_ACCEPT_UNKNOWN`: **false**: Accept PROXY protocol headers with Unknown type. -- `DOMAIN`: **localhost**: Domain name of this server. -- `ROOT_URL`: **%(PROTOCOL)s://%(DOMAIN)s:%(HTTP\_PORT)s/**: - Overwrite the automatically generated public URL. - This is useful if the internal and the external URL don't match (e.g. in Docker). -- `STATIC_URL_PREFIX`: **\<empty\>**: - Overwrite this option to request static resources from a different URL. - This includes CSS files, images, JS files and web fonts. - Avatar images are dynamic resources and still served by Gitea. - The option can be just a different path, as in `/static`, or another domain, as in `https://cdn.example.com`. - Requests are then made as `%(ROOT_URL)s/static/assets/css/index.css` or `https://cdn.example.com/assets/css/index.css` respectively. - The static files are located in the `public/` directory of the Gitea source repository. - You can proxy the STATIC_URL_PREFIX requests to Gitea server to serve the static - assets, or copy the manually built Gitea assets from `$GITEA_BUILD/public` to - the assets location, eg: `/var/www/assets`, make sure `$STATIC_URL_PREFIX/assets/css/index.css` - points to `/var/www/assets/css/index.css`. - -- `HTTP_ADDR`: **0.0.0.0**: HTTP listen address. - - If `PROTOCOL` is set to `fcgi`, Gitea will listen for FastCGI requests on TCP socket - defined by `HTTP_ADDR` and `HTTP_PORT` configuration settings. - - If `PROTOCOL` is set to `http+unix` or `fcgi+unix`, this should be the name of the Unix socket file to use. Relative paths will be made absolute against the _`AppWorkPath`_. -- `HTTP_PORT`: **3000**: HTTP listen port. - - If `PROTOCOL` is set to `fcgi`, Gitea will listen for FastCGI requests on TCP socket - defined by `HTTP_ADDR` and `HTTP_PORT` configuration settings. -- `UNIX_SOCKET_PERMISSION`: **666**: Permissions for the Unix socket. -- `LOCAL_ROOT_URL`: **%(PROTOCOL)s://%(HTTP_ADDR)s:%(HTTP_PORT)s/**: Local - (DMZ) URL for Gitea workers (such as SSH update) accessing web service. In - most cases you do not need to change the default value. Alter it only if - your SSH server node is not the same as HTTP node. For different protocol, the default - values are different. If `PROTOCOL` is `http+unix`, the default value is `http://unix/`. - If `PROTOCOL` is `fcgi` or `fcgi+unix`, the default value is `%(PROTOCOL)s://%(HTTP_ADDR)s:%(HTTP_PORT)s/`. - If listen on `0.0.0.0`, the default value is `%(PROTOCOL)s://localhost:%(HTTP_PORT)s/`, Otherwise the default - value is `%(PROTOCOL)s://%(HTTP_ADDR)s:%(HTTP_PORT)s/`. -- `LOCAL_USE_PROXY_PROTOCOL`: **%(USE_PROXY_PROTOCOL)s**: When making local connections pass the PROXY protocol header. - This should be set to false if the local connection will go through the proxy. -- `PER_WRITE_TIMEOUT`: **30s**: Timeout for any write to the connection. (Set to -1 to - disable all timeouts.) -- `PER_WRITE_PER_KB_TIMEOUT`: **10s**: Timeout per Kb written to connections. - -- `DISABLE_SSH`: **false**: Disable SSH feature when it's not available. -- `START_SSH_SERVER`: **false**: When enabled, use the built-in SSH server. -- `SSH_SERVER_USE_PROXY_PROTOCOL`: **false**: Expect PROXY protocol header on connections to the built-in SSH Server. -- `BUILTIN_SSH_SERVER_USER`: **%(RUN_USER)s**: Username to use for the built-in SSH Server. -- `SSH_USER`: **%(BUILTIN_SSH_SERVER_USER)s**: SSH username displayed in clone URLs. This is only for people who configure the SSH server themselves; in most cases, you want to leave this blank and modify the `BUILTIN_SSH_SERVER_USER`. -- `SSH_DOMAIN`: **%(DOMAIN)s**: Domain name of this server, used for displayed clone URL. -- `SSH_PORT`: **22**: SSH port displayed in clone URL. -- `SSH_LISTEN_HOST`: **0.0.0.0**: Listen address for the built-in SSH server. -- `SSH_LISTEN_PORT`: **%(SSH\_PORT)s**: Port for the built-in SSH server. -- `SSH_ROOT_PATH`: **~/.ssh**: Root path of SSH directory. -- `SSH_CREATE_AUTHORIZED_KEYS_FILE`: **true**: Gitea will create a authorized_keys file by default when it is not using the internal ssh server. If you intend to use the AuthorizedKeysCommand functionality then you should turn this off. -- `SSH_AUTHORIZED_KEYS_BACKUP`: **false**: Enable SSH Authorized Key Backup when rewriting all keys, default is false. -- `SSH_TRUSTED_USER_CA_KEYS`: **\<empty\>**: Specifies the public keys of certificate authorities that are trusted to sign user certificates for authentication. Multiple keys should be comma separated. E.g.`ssh-<algorithm> <key>` or `ssh-<algorithm> <key1>, ssh-<algorithm> <key2>`. For more information see `TrustedUserCAKeys` in the sshd config man pages. When empty no file will be created and `SSH_AUTHORIZED_PRINCIPALS_ALLOW` will default to `off`. -- `SSH_TRUSTED_USER_CA_KEYS_FILENAME`: **`RUN_USER`/.ssh/gitea-trusted-user-ca-keys.pem**: Absolute path of the `TrustedUserCaKeys` file Gitea will manage. If you're running your own ssh server and you want to use the Gitea managed file you'll also need to modify your sshd_config to point to this file. The official docker image will automatically work without further configuration. -- `SSH_AUTHORIZED_PRINCIPALS_ALLOW`: **off** or **username, email**: \[off, username, email, anything\]: Specify the principals values that users are allowed to use as principal. When set to `anything` no checks are done on the principal string. When set to `off` authorized principal are not allowed to be set. -- `SSH_CREATE_AUTHORIZED_PRINCIPALS_FILE`: **false/true**: Gitea will create a authorized_principals file by default when it is not using the internal ssh server and `SSH_AUTHORIZED_PRINCIPALS_ALLOW` is not `off`. -- `SSH_AUTHORIZED_PRINCIPALS_BACKUP`: **false/true**: Enable SSH Authorized Principals Backup when rewriting all keys, default is true if `SSH_AUTHORIZED_PRINCIPALS_ALLOW` is not `off`. -- `SSH_AUTHORIZED_KEYS_COMMAND_TEMPLATE`: **{{.AppPath}} --config={{.CustomConf}} serv key-{{.Key.ID}}**: Set the template for the command to passed on authorized keys. Possible keys are: AppPath, AppWorkPath, CustomConf, CustomPath, Key - where Key is a `models/asymkey.PublicKey` and the others are strings which are shellquoted. -- `SSH_SERVER_CIPHERS`: **chacha20-poly1305@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm@openssh.com, aes256-gcm@openssh.com**: For the built-in SSH server, choose the ciphers to support for SSH connections, for system SSH this setting has no effect. -- `SSH_SERVER_KEY_EXCHANGES`: **curve25519-sha256, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group14-sha256, diffie-hellman-group14-sha1**: For the built-in SSH server, choose the key exchange algorithms to support for SSH connections, for system SSH this setting has no effect. -- `SSH_SERVER_MACS`: **hmac-sha2-256-etm@openssh.com, hmac-sha2-256, hmac-sha1**: For the built-in SSH server, choose the MACs to support for SSH connections, for system SSH this setting has no effect -- `SSH_SERVER_HOST_KEYS`: **ssh/gitea.rsa, ssh/gogs.rsa**: For the built-in SSH server, choose the keypairs to offer as the host key. The private key should be at `SSH_SERVER_HOST_KEY` and the public `SSH_SERVER_HOST_KEY.pub`. Relative paths are made absolute relative to the `APP_DATA_PATH`. If no key exists a 4096 bit RSA key will be created for you. -- `SSH_KEY_TEST_PATH`: **/tmp**: Directory to create temporary files in when testing public keys using ssh-keygen, default is the system temporary directory. -- `SSH_KEYGEN_PATH`: **\<empty\>**: Use `ssh-keygen` to parse public SSH keys. The value is passed to the shell. By default, Gitea does the parsing itself. -- `SSH_EXPOSE_ANONYMOUS`: **false**: Enable exposure of SSH clone URL to anonymous visitors, default is false. -- `SSH_PER_WRITE_TIMEOUT`: **30s**: Timeout for any write to the SSH connections. (Set to - -1 to disable all timeouts.) -- `SSH_PER_WRITE_PER_KB_TIMEOUT`: **10s**: Timeout per Kb written to SSH connections. -- `MINIMUM_KEY_SIZE_CHECK`: **true**: Indicate whether to check minimum key size with corresponding type. - -- `OFFLINE_MODE`: **false**: Disables use of CDN for static files and Gravatar for profile pictures. -- `CERT_FILE`: **https/cert.pem**: Cert file path used for HTTPS. When chaining, the server certificate must come first, then intermediate CA certificates (if any). This is ignored if `ENABLE_ACME=true`. Paths are relative to `CUSTOM_PATH`. -- `KEY_FILE`: **https/key.pem**: Key file path used for HTTPS. This is ignored if `ENABLE_ACME=true`. Paths are relative to `CUSTOM_PATH`. -- `STATIC_ROOT_PATH`: **_`StaticRootPath`_**: Upper level of template and static files path. -- `APP_DATA_PATH`: **data** (**/data/gitea** on docker): Default path for application data. Relative paths will be made absolute against _`AppWorkPath`_. -- `STATIC_CACHE_TIME`: **6h**: Web browser cache time for static resources on `custom/`, `public/` and all uploaded avatars. Note that this cache is disabled when `RUN_MODE` is "dev". -- `ENABLE_GZIP`: **false**: Enable gzip compression for runtime-generated content, static resources excluded. -- `ENABLE_PPROF`: **false**: Application profiling (memory and cpu). For "web" command it listens on `localhost:6060`. For "serv" command it dumps to disk at `PPROF_DATA_PATH` as `(cpuprofile|memprofile)_<username>_<temporary id>` -- `PPROF_DATA_PATH`: **_`AppWorkPath`_/data/tmp/pprof**: `PPROF_DATA_PATH`, use an absolute path when you start Gitea as service -- `LANDING_PAGE`: **home**: Landing page for unauthenticated users \[home, explore, organizations, login, **custom**\]. Where custom would instead be any URL such as "/org/repo" or even `https://anotherwebsite.com` -- `LFS_START_SERVER`: **false**: Enables Git LFS support. -- `LFS_CONTENT_PATH`: **%(APP_DATA_PATH)s/lfs**: Default LFS content path. (if it is on local storage.) **DEPRECATED** use settings in `[lfs]`. -- `LFS_JWT_SECRET`: **\<empty\>**: LFS authentication secret, change this a unique string. -- `LFS_JWT_SECRET_URI`: **\<empty\>**: Instead of defining LFS_JWT_SECRET in the configuration, this configuration option can be used to give Gitea a path to a file that contains the secret (example value: `file:/etc/gitea/lfs_jwt_secret`) -- `LFS_HTTP_AUTH_EXPIRY`: **24h**: LFS authentication validity period in time.Duration, pushes taking longer than this may fail. -- `LFS_MAX_FILE_SIZE`: **0**: Maximum allowed LFS file size in bytes (Set to 0 for no limit). -- `LFS_LOCKS_PAGING_NUM`: **50**: Maximum number of LFS Locks returned per page. - -- `REDIRECT_OTHER_PORT`: **false**: If true and `PROTOCOL` is https, allows redirecting http requests on `PORT_TO_REDIRECT` to the https port Gitea listens on. -- `REDIRECTOR_USE_PROXY_PROTOCOL`: **%(USE_PROXY_PROTOCOL)s**: expect PROXY protocol header on connections to https redirector. -- `PORT_TO_REDIRECT`: **80**: Port for the http redirection service to listen on. Used when `REDIRECT_OTHER_PORT` is true. -- `SSL_MIN_VERSION`: **TLSv1.2**: Set the minimum version of ssl support. -- `SSL_MAX_VERSION`: **\<empty\>**: Set the maximum version of ssl support. -- `SSL_CURVE_PREFERENCES`: **X25519,P256**: Set the preferred curves, -- `SSL_CIPHER_SUITES`: **ecdhe_ecdsa_with_aes_256_gcm_sha384,ecdhe_rsa_with_aes_256_gcm_sha384,ecdhe_ecdsa_with_aes_128_gcm_sha256,ecdhe_rsa_with_aes_128_gcm_sha256,ecdhe_ecdsa_with_chacha20_poly1305,ecdhe_rsa_with_chacha20_poly1305**: Set the preferred cipher suites. - - If there is no hardware support for AES suites, by default the ChaCha suites will be preferred over the AES suites. - - supported suites as of Go 1.18 are: - - TLS 1.0 - 1.2 cipher suites - - "rsa_with_rc4_128_sha" - - "rsa_with_3des_ede_cbc_sha" - - "rsa_with_aes_128_cbc_sha" - - "rsa_with_aes_256_cbc_sha" - - "rsa_with_aes_128_cbc_sha256" - - "rsa_with_aes_128_gcm_sha256" - - "rsa_with_aes_256_gcm_sha384" - - "ecdhe_ecdsa_with_rc4_128_sha" - - "ecdhe_ecdsa_with_aes_128_cbc_sha" - - "ecdhe_ecdsa_with_aes_256_cbc_sha" - - "ecdhe_rsa_with_rc4_128_sha" - - "ecdhe_rsa_with_3des_ede_cbc_sha" - - "ecdhe_rsa_with_aes_128_cbc_sha" - - "ecdhe_rsa_with_aes_256_cbc_sha" - - "ecdhe_ecdsa_with_aes_128_cbc_sha256" - - "ecdhe_rsa_with_aes_128_cbc_sha256" - - "ecdhe_rsa_with_aes_128_gcm_sha256" - - "ecdhe_ecdsa_with_aes_128_gcm_sha256" - - "ecdhe_rsa_with_aes_256_gcm_sha384" - - "ecdhe_ecdsa_with_aes_256_gcm_sha384" - - "ecdhe_rsa_with_chacha20_poly1305_sha256" - - "ecdhe_ecdsa_with_chacha20_poly1305_sha256" - - TLS 1.3 cipher suites - - "aes_128_gcm_sha256" - - "aes_256_gcm_sha384" - - "chacha20_poly1305_sha256" - - Aliased names - - "ecdhe_rsa_with_chacha20_poly1305" is an alias for "ecdhe_rsa_with_chacha20_poly1305_sha256" - - "ecdhe_ecdsa_with_chacha20_poly1305" is alias for "ecdhe_ecdsa_with_chacha20_poly1305_sha256" -- `ENABLE_ACME`: **false**: Flag to enable automatic certificate management via an ACME capable Certificate Authority (CA) server (default: Lets Encrypt). If enabled, `CERT_FILE` and `KEY_FILE` are ignored, and the CA must resolve `DOMAIN` to this gitea server. Ensure that DNS records are set and either port `80` or port `443` are accessible by the CA server (the public internet by default), and redirected to the appropriate ports `PORT_TO_REDIRECT` or `HTTP_PORT` respectively. -- `ACME_URL`: **\<empty\>**: The CA's ACME directory URL, e.g. for a self-hosted [smallstep CA server](https://github.com/smallstep/certificates), it can look like `https://ca.example.com/acme/acme/directory`. If left empty, it defaults to using Let's Encerypt's production CA (check `LETSENCRYPT_ACCEPTTOS` as well). -- `ACME_ACCEPTTOS`: **false**: This is an explicit check that you accept the terms of service of the ACME provider. The default is Lets Encrypt [terms of service](https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf). -- `ACME_DIRECTORY`: **https**: Directory that the certificate manager will use to cache information such as certs and private keys. -- `ACME_EMAIL`: **\<empty\>**: Email used for the ACME registration. Usually it is to notify about problems with issued certificates. -- `ACME_CA_ROOT`: **\<empty\>**: The CA's root certificate. If left empty, it defaults to using the system's trust chain. -- `ALLOW_GRACEFUL_RESTARTS`: **true**: Perform a graceful restart on SIGHUP -- `GRACEFUL_HAMMER_TIME`: **60s**: After a restart the parent process will stop accepting new connections and will allow requests to finish before stopping. Shutdown will be forced if it takes longer than this time. -- `STARTUP_TIMEOUT`: **0**: Shutsdown the server if startup takes longer than the provided time. On Windows setting this sends a waithint to the SVC host to tell the SVC host startup may take some time. Please note startup is determined by the opening of the listeners - HTTP/HTTPS/SSH. Indexers may take longer to startup and can have their own timeouts. - -## Database (`database`) - -- `DB_TYPE`: **mysql**: The database type in use \[mysql, postgres, mssql, sqlite3\]. -- `HOST`: **127.0.0.1:3306**: Database host address and port or absolute path for unix socket \[mysql, postgres\] (ex: /var/run/mysqld/mysqld.sock). -- `NAME`: **gitea**: Database name. -- `USER`: **root**: Database username. -- `PASSWD`: **\<empty\>**: Database user password. Use \`your password\` or """your password""" for quoting if you use special characters in the password. -- `SCHEMA`: **\<empty\>**: For PostgreSQL only, schema to use if different from "public". The schema must exist beforehand, - the user must have creation privileges on it, and the user search path must be set to the look into the schema first - (e.g. `ALTER USER user SET SEARCH_PATH = schema_name,"$user",public;`). -- `SSL_MODE`: **disable**: SSL/TLS encryption mode for connecting to the database. This option is only applied for PostgreSQL and MySQL. - - Valid values for MySQL: - - `true`: Enable TLS with verification of the database server certificate against its root certificate. When selecting this option make sure that the root certificate required to validate the database server certificate (e.g. the CA certificate) is on the system certificate store of both the database and Gitea servers. See your system documentation for instructions on how to add a CA certificate to the certificate store. - - `false`: Disable TLS. - - `disable`: Alias for `false`, for compatibility with PostgreSQL. - - `skip-verify`: Enable TLS without database server certificate verification. Use this option if you have self-signed or invalid certificate on the database server. - - `prefer`: Enable TLS with fallback to non-TLS connection. - - Valid values for PostgreSQL: - - `disable`: Disable TLS. - - `require`: Enable TLS without any verifications. - - `verify-ca`: Enable TLS with verification of the database server certificate against its root certificate. - - `verify-full`: Enable TLS and verify the database server name matches the given certificate in either the `Common Name` or `Subject Alternative Name` fields. -- `SQLITE_TIMEOUT`: **500**: Query timeout for SQLite3 only. -- `SQLITE_JOURNAL_MODE`: **""**: Change journal mode for SQlite3. Can be used to enable [WAL mode](https://www.sqlite.org/wal.html) when high load causes write congestion. See [SQlite3 docs](https://www.sqlite.org/pragma.html#pragma_journal_mode) for possible values. Defaults to the default for the database file, often DELETE. -- `ITERATE_BUFFER_SIZE`: **50**: Internal buffer size for iterating. -- `PATH`: **data/gitea.db**: For SQLite3 only, the database file path. -- `LOG_SQL`: **true**: Log the executed SQL. -- `DB_RETRIES`: **10**: How many ORM init / DB connect attempts allowed. -- `DB_RETRY_BACKOFF`: **3s**: time.Duration to wait before trying another ORM init / DB connect attempt, if failure occurred. -- `MAX_OPEN_CONNS` **0**: Database maximum open connections - default is 0, meaning there is no limit. -- `MAX_IDLE_CONNS` **2**: Max idle database connections on connection pool, default is 2 - this will be capped to `MAX_OPEN_CONNS`. -- `CONN_MAX_LIFETIME` **0 or 3s**: Sets the maximum amount of time a DB connection may be reused - default is 0, meaning there is no limit (except on MySQL where it is 3s - see #6804 & #7071). -- `AUTO_MIGRATION` **true**: Whether execute database models migrations automatically. - -Please see #8540 & #8273 for further discussion of the appropriate values for `MAX_OPEN_CONNS`, `MAX_IDLE_CONNS` & `CONN_MAX_LIFETIME` and their -relation to port exhaustion. - -## Indexer (`indexer`) - -- `ISSUE_INDEXER_TYPE`: **bleve**: Issue indexer type, currently supported: `bleve`, `db`, `elasticsearch` or `meilisearch`. -- `ISSUE_INDEXER_CONN_STR`: ****: Issue indexer connection string, available when ISSUE_INDEXER_TYPE is elasticsearch (e.g. http://elastic:password@localhost:9200) or meilisearch (e.g. http://:apikey@localhost:7700) -- `ISSUE_INDEXER_NAME`: **gitea_issues**: Issue indexer name, available when ISSUE_INDEXER_TYPE is elasticsearch or meilisearch. -- `ISSUE_INDEXER_PATH`: **indexers/issues.bleve**: Index file used for issue search; available when ISSUE_INDEXER_TYPE is bleve and elasticsearch. Relative paths will be made absolute against _`AppWorkPath`_. - -- `REPO_INDEXER_ENABLED`: **false**: Enables code search (uses a lot of disk space, about 6 times more than the repository size). -- `REPO_INDEXER_REPO_TYPES`: **sources,forks,mirrors,templates**: Repo indexer units. The items to index could be `sources`, `forks`, `mirrors`, `templates` or any combination of them separated by a comma. If empty then it defaults to `sources` only, as if you'd like to disable fully please see `REPO_INDEXER_ENABLED`. -- `REPO_INDEXER_TYPE`: **bleve**: Code search engine type, could be `bleve` or `elasticsearch`. -- `REPO_INDEXER_PATH`: **indexers/repos.bleve**: Index file used for code search. -- `REPO_INDEXER_CONN_STR`: ****: Code indexer connection string, available when `REPO_INDEXER_TYPE` is elasticsearch. i.e. http://elastic:password@localhost:9200 -- `REPO_INDEXER_NAME`: **gitea_codes**: Code indexer name, available when `REPO_INDEXER_TYPE` is elasticsearch - -- `REPO_INDEXER_INCLUDE`: **empty**: A comma separated list of glob patterns (see https://github.com/gobwas/glob) to **include** in the index. Use `**.txt` to match any files with .txt extension. An empty list means include all files. -- `REPO_INDEXER_EXCLUDE`: **empty**: A comma separated list of glob patterns (see https://github.com/gobwas/glob) to **exclude** from the index. Files that match this list will not be indexed, even if they match in `REPO_INDEXER_INCLUDE`. -- `REPO_INDEXER_EXCLUDE_VENDORED`: **true**: Exclude vendored files from index. -- `MAX_FILE_SIZE`: **1048576**: Maximum size in bytes of files to be indexed. -- `STARTUP_TIMEOUT`: **30s**: If the indexer takes longer than this timeout to start - fail. (This timeout will be added to the hammer time above for child processes - as bleve will not start until the previous parent is shutdown.) Set to -1 to never timeout. - -## Queue (`queue` and `queue.*`) - -Configuration at `[queue]` will set defaults for queues with overrides for individual queues at `[queue.*]`. (However see below.) - -- `TYPE`: **level**: General queue type, currently support: `level` (uses a LevelDB internally), `channel`, `redis`, `dummy`. Invalid types are treated as `level`. -- `DATADIR`: **queues/common**: Base DataDir for storing level queues. `DATADIR` for individual queues can be set in `queue.name` sections. Relative paths will be made absolute against `%(APP_DATA_PATH)s`. -- `LENGTH`: **100**: Maximal queue size before channel queues block -- `BATCH_LENGTH`: **20**: Batch data before passing to the handler -- `CONN_STR`: **redis://127.0.0.1:6379/0**: Connection string for the redis queue type. For `redis-cluster` use `redis+cluster://127.0.0.1:6379/0`. Options can be set using query params. Similarly, LevelDB options can also be set using: **leveldb://relative/path?option=value** or **leveldb:///absolute/path?option=value**, and will override `DATADIR` -- `QUEUE_NAME`: **_queue**: The suffix for default redis and disk queue name. Individual queues will default to **`name`**`QUEUE_NAME` but can be overridden in the specific `queue.name` section. -- `SET_NAME`: **_unique**: The suffix that will be added to the default redis and disk queue `set` name for unique queues. Individual queues will default to **`name`**`QUEUE_NAME`_`SET_NAME`_ but can be overridden in the specific `queue.name` section. -- `MAX_WORKERS`: **10**: Maximum number of worker go-routines for the queue. - -Gitea creates the following non-unique queues: - -- `code_indexer` -- `issue_indexer` -- `notification-service` -- `task` -- `mail` -- `push_update` - -And the following unique queues: - -- `repo_stats_update` -- `repo-archive` -- `mirror` -- `pr_patch_checker` - -## Admin (`admin`) - -- `DEFAULT_EMAIL_NOTIFICATIONS`: **enabled**: Default configuration for email notifications for users (user configurable). Options: enabled, onmention, disabled -- `DISABLE_REGULAR_ORG_CREATION`: **false**: Disallow regular (non-admin) users from creating organizations. - -## Security (`security`) - -- `INSTALL_LOCK`: **false**: Controls access to the installation page. When set to "true", the installation page is not accessible. -- `SECRET_KEY`: **\<random at every install\>**: Global secret key. This key is VERY IMPORTANT, if you lost it, the data encrypted by it (like 2FA secret) can't be decrypted anymore. -- `SECRET_KEY_URI`: **\<empty\>**: Instead of defining SECRET_KEY, this option can be used to use the key stored in a file (example value: `file:/etc/gitea/secret_key`). It shouldn't be lost like SECRET_KEY. -- `LOGIN_REMEMBER_DAYS`: **7**: Cookie lifetime, in days. -- `COOKIE_USERNAME`: **gitea\_awesome**: Name of the cookie used to store the current username. -- `COOKIE_REMEMBER_NAME`: **gitea\_incredible**: Name of cookie used to store authentication - information. -- `REVERSE_PROXY_AUTHENTICATION_USER`: **X-WEBAUTH-USER**: Header name for reverse proxy - authentication. -- `REVERSE_PROXY_AUTHENTICATION_EMAIL`: **X-WEBAUTH-EMAIL**: Header name for reverse proxy - authentication provided email. -- `REVERSE_PROXY_AUTHENTICATION_FULL_NAME`: **X-WEBAUTH-FULLNAME**: Header name for reverse proxy - authentication provided full name. -- `REVERSE_PROXY_LIMIT`: **1**: Interpret X-Forwarded-For header or the X-Real-IP header and set this as the remote IP for the request. - Number of trusted proxy count. Set to zero to not use these headers. -- `REVERSE_PROXY_TRUSTED_PROXIES`: **127.0.0.0/8,::1/128**: List of IP addresses and networks separated by comma of trusted proxy servers. Use `*` to trust all. -- `DISABLE_GIT_HOOKS`: **true**: Set to `false` to enable users with Git Hook privilege to create custom Git Hooks. - WARNING: Custom Git Hooks can be used to perform arbitrary code execution on the host operating system. - This enables the users to access and modify this config file and the Gitea database and interrupt the Gitea service. - By modifying the Gitea database, users can gain Gitea administrator privileges. - It also enables them to access other resources available to the user on the operating system that is running the - Gitea instance and perform arbitrary actions in the name of the Gitea OS user. - This maybe harmful to you website or your operating system. - Setting this to true does not change existing hooks in git repos; adjust it before if necessary. -- `DISABLE_WEBHOOKS`: **false**: Set to `true` to disable webhooks feature. -- `ONLY_ALLOW_PUSH_IF_GITEA_ENVIRONMENT_SET`: **true**: Set to `false` to allow local users to push to gitea-repositories without setting up the Gitea environment. This is not recommended and if you want local users to push to Gitea repositories you should set the environment appropriately. -- `IMPORT_LOCAL_PATHS`: **false**: Set to `false` to prevent all users (including admin) from importing local path on server. -- `INTERNAL_TOKEN`: **\<random at every install if no uri set\>**: Secret used to validate communication within Gitea binary. -- `INTERNAL_TOKEN_URI`: **\<empty\>**: Instead of defining INTERNAL_TOKEN in the configuration, this configuration option can be used to give Gitea a path to a file that contains the internal token (example value: `file:/etc/gitea/internal_token`) -- `PASSWORD_HASH_ALGO`: **pbkdf2**: The hash algorithm to use \[argon2, pbkdf2, pbkdf2_v1, pbkdf2_hi, scrypt, bcrypt\], argon2 and scrypt will spend significant amounts of memory. - - Note: The default parameters for `pbkdf2` hashing have changed - the previous settings are available as `pbkdf2_v1` but are not recommended. - - The hash functions may be tuned by using `$` after the algorithm: - - `argon2$<time>$<memory>$<threads>$<key-length>` - - `bcrypt$<cost>` - - `pbkdf2$<iterations>$<key-length>` - - `scrypt$<n>$<r>$<p>$<key-length>` - - The defaults are: - - `argon2`: `argon2$2$65536$8$50` - - `bcrypt`: `bcrypt$10` - - `pbkdf2`: `pbkdf2$50000$50` - - `pbkdf2_v1`: `pbkdf2$10000$50` - - `pbkdf2_v2`: `pbkdf2$50000$50` - - `pbkdf2_hi`: `pbkdf2$320000$50` - - `scrypt`: `scrypt$65536$16$2$50` - - Adjusting the algorithm parameters using this functionality is done at your own risk. -- `CSRF_COOKIE_HTTP_ONLY`: **true**: Set false to allow JavaScript to read CSRF cookie. -- `MIN_PASSWORD_LENGTH`: **6**: Minimum password length for new users. -- `PASSWORD_COMPLEXITY`: **off**: Comma separated list of character classes required to pass minimum complexity. If left empty or no valid values are specified, checking is disabled (off): - - lower - use one or more lower latin characters - - upper - use one or more upper latin characters - - digit - use one or more digits - - spec - use one or more special characters as ``!"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~`` - - off - do not check password complexity -- `PASSWORD_CHECK_PWN`: **false**: Check [HaveIBeenPwned](https://haveibeenpwned.com/Passwords) to see if a password has been exposed. -- `SUCCESSFUL_TOKENS_CACHE_SIZE`: **20**: Cache successful token hashes. API tokens are stored in the DB as pbkdf2 hashes however, this means that there is a potentially significant hashing load when there are multiple API operations. This cache will store the successfully hashed tokens in a LRU cache as a balance between performance and security. - -## Camo (`camo`) - -- `ENABLED`: **false**: Enable media proxy, we support images only at the moment. -- `SERVER_URL`: **\<empty\>**: URL of camo server, it **is required** if camo is enabled. -- `HMAC_KEY`: **\<empty\>**: Provide the HMAC key for encoding URLs, it **is required** if camo is enabled. -- `ALLWAYS`: **false**: Set to true to use camo for both HTTP and HTTPS content, otherwise only non-HTTPS URLs are proxied - -## OpenID (`openid`) - -- `ENABLE_OPENID_SIGNIN`: **false**: Allow authentication in via OpenID. -- `ENABLE_OPENID_SIGNUP`: **! DISABLE\_REGISTRATION**: Allow registering via OpenID. -- `WHITELISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching - OpenID URI's to permit. -- `BLACKLISTED_URIS`: **\<empty\>**: If non-empty, list of POSIX regex patterns matching - OpenID URI's to block. - -## OAuth2 Client (`oauth2_client`) - -- `REGISTER_EMAIL_CONFIRM`: _[service]_ **REGISTER\_EMAIL\_CONFIRM**: Set this to enable or disable email confirmation of OAuth2 auto-registration. (Overwrites the REGISTER\_EMAIL\_CONFIRM setting of the `[service]` section) -- `OPENID_CONNECT_SCOPES`: **\<empty\>**: List of additional openid connect scopes. (`openid` is implicitly added) -- `ENABLE_AUTO_REGISTRATION`: **false**: Automatically create user accounts for new oauth2 users. -- `USERNAME`: **nickname**: The source of the username for new oauth2 accounts: - - userid - use the userid / sub attribute - - nickname - use the nickname attribute - - email - use the username part of the email attribute -- `UPDATE_AVATAR`: **false**: Update avatar if available from oauth2 provider. Update will be performed on each login. -- `ACCOUNT_LINKING`: **login**: How to handle if an account / email already exists: - - disabled - show an error - - login - show an account linking login - - auto - automatically link with the account (Please be aware that this will grant access to an existing account just because the same username or email is provided. You must make sure that this does not cause issues with your authentication providers.) - -## Service (`service`) - -- `ACTIVE_CODE_LIVE_MINUTES`: **180**: Time limit (min) to confirm account/email registration. -- `RESET_PASSWD_CODE_LIVE_MINUTES`: **180**: Time limit (min) to confirm forgot password reset - process. -- `REGISTER_EMAIL_CONFIRM`: **false**: Enable this to ask for mail confirmation of registration. - Requires `Mailer` to be enabled. -- `REGISTER_MANUAL_CONFIRM`: **false**: Enable this to manually confirm new registrations. - Requires `REGISTER_EMAIL_CONFIRM` to be disabled. -- `DISABLE_REGISTRATION`: **false**: Disable registration, after which only admin can create - accounts for users. -- `REQUIRE_EXTERNAL_REGISTRATION_PASSWORD`: **false**: Enable this to force externally created - accounts (via GitHub, OpenID Connect, etc) to create a password. Warning: enabling this will - decrease security, so you should only enable it if you know what you're doing. -- `REQUIRE_SIGNIN_VIEW`: **false**: Enable this to force users to log in to view any page or to use API. -- `ENABLE_NOTIFY_MAIL`: **false**: Enable this to send e-mail to watchers of a repository when - something happens, like creating issues. Requires `Mailer` to be enabled. -- `ENABLE_BASIC_AUTHENTICATION`: **true**: Disable this to disallow authenticaton using HTTP - BASIC and the user's password. Please note if you disable this you will not be able to access the - tokens API endpoints using a password. Further, this only disables BASIC authentication using the - password - not tokens or OAuth Basic. -- `ENABLE_REVERSE_PROXY_AUTHENTICATION`: **false**: Enable this to allow reverse proxy authentication. -- `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION`: **false**: Enable this to allow auto-registration - for reverse authentication. -- `ENABLE_REVERSE_PROXY_EMAIL`: **false**: Enable this to allow to auto-registration with a - provided email rather than a generated email. -- `ENABLE_REVERSE_PROXY_FULL_NAME`: **false**: Enable this to allow to auto-registration with a - provided full name for the user. -- `ENABLE_CAPTCHA`: **false**: Enable this to use captcha validation for registration. -- `REQUIRE_CAPTCHA_FOR_LOGIN`: **false**: Enable this to require captcha validation for login. You also must enable `ENABLE_CAPTCHA`. -- `REQUIRE_EXTERNAL_REGISTRATION_CAPTCHA`: **false**: Enable this to force captcha validation - even for External Accounts (i.e. GitHub, OpenID Connect, etc). You also must enable `ENABLE_CAPTCHA`. -- `CAPTCHA_TYPE`: **image**: \[image, recaptcha, hcaptcha, mcaptcha, cfturnstile\] -- `RECAPTCHA_SECRET`: **""**: Go to https://www.google.com/recaptcha/admin to get a secret for recaptcha. -- `RECAPTCHA_SITEKEY`: **""**: Go to https://www.google.com/recaptcha/admin to get a sitekey for recaptcha. -- `RECAPTCHA_URL`: **https://www.google.com/recaptcha/**: Set the recaptcha url - allows the use of recaptcha net. -- `HCAPTCHA_SECRET`: **""**: Sign up at https://www.hcaptcha.com/ to get a secret for hcaptcha. -- `HCAPTCHA_SITEKEY`: **""**: Sign up at https://www.hcaptcha.com/ to get a sitekey for hcaptcha. -- `MCAPTCHA_SECRET`: **""**: Go to your mCaptcha instance to get a secret for mCaptcha. -- `MCAPTCHA_SITEKEY`: **""**: Go to your mCaptcha instance to get a sitekey for mCaptcha. -- `MCAPTCHA_URL` **https://demo.mcaptcha.org/**: Set the mCaptcha URL. -- `CF_TURNSTILE_SECRET` **""**: Go to https://dash.cloudflare.com/?to=/:account/turnstile to get a secret for cloudflare turnstile. -- `CF_TURNSTILE_SITEKEY` **""**: Go to https://dash.cloudflare.com/?to=/:account/turnstile to get a sitekey for cloudflare turnstile. -- `DEFAULT_KEEP_EMAIL_PRIVATE`: **false**: By default set users to keep their email address private. -- `DEFAULT_ALLOW_CREATE_ORGANIZATION`: **true**: Allow new users to create organizations by default. -- `DEFAULT_USER_IS_RESTRICTED`: **false**: Give new users restricted permissions by default -- `DEFAULT_ENABLE_DEPENDENCIES`: **true**: Enable this to have dependencies enabled by default. -- `ALLOW_CROSS_REPOSITORY_DEPENDENCIES` : **true** Enable this to allow dependencies on issues from any repository where the user is granted access. -- `ENABLE_USER_HEATMAP`: **true**: Enable this to display the heatmap on users profiles. -- `ENABLE_TIMETRACKING`: **true**: Enable Timetracking feature. -- `DEFAULT_ENABLE_TIMETRACKING`: **true**: Allow repositories to use timetracking by default. -- `DEFAULT_ALLOW_ONLY_CONTRIBUTORS_TO_TRACK_TIME`: **true**: Only allow users with write permissions to track time. -- `EMAIL_DOMAIN_ALLOWLIST`: **\<empty\>**: If non-empty, comma separated list of domain names that can only be used to register on this instance, wildcard is supported. -- `EMAIL_DOMAIN_BLOCKLIST`: **\<empty\>**: If non-empty, comma separated list of domain names that cannot be used to register on this instance, wildcard is supported. -- `SHOW_REGISTRATION_BUTTON`: **! DISABLE\_REGISTRATION**: Show Registration Button -- `SHOW_MILESTONES_DASHBOARD_PAGE`: **true** Enable this to show the milestones dashboard page - a view of all the user's milestones -- `AUTO_WATCH_NEW_REPOS`: **true**: Enable this to let all organisation users watch new repos when they are created -- `AUTO_WATCH_ON_CHANGES`: **false**: Enable this to make users watch a repository after their first commit to it -- `DEFAULT_USER_VISIBILITY`: **public**: Set default visibility mode for users, either "public", "limited" or "private". -- `ALLOWED_USER_VISIBILITY_MODES`: **public,limited,private**: Set which visibility modes a user can have -- `DEFAULT_ORG_VISIBILITY`: **public**: Set default visibility mode for organisations, either "public", "limited" or "private". -- `DEFAULT_ORG_MEMBER_VISIBLE`: **false** True will make the membership of the users visible when added to the organisation. -- `ALLOW_ONLY_INTERNAL_REGISTRATION`: **false** Set to true to force registration only via Gitea. -- `ALLOW_ONLY_EXTERNAL_REGISTRATION`: **false** Set to true to force registration only using third-party services. -- `NO_REPLY_ADDRESS`: **noreply.DOMAIN** Value for the domain part of the user's email address in the Git log if user has set KeepEmailPrivate to true. DOMAIN resolves to the value in server.DOMAIN. - The user's email will be replaced with a concatenation of the user name in lower case, "@" and NO_REPLY_ADDRESS. -- `USER_DELETE_WITH_COMMENTS_MAX_TIME`: **0** Minimum amount of time a user must exist before comments are kept when the user is deleted. -- `VALID_SITE_URL_SCHEMES`: **http, https**: Valid site url schemes for user profiles - -### Service - Explore (`service.explore`) - -- `REQUIRE_SIGNIN_VIEW`: **false**: Only allow signed in users to view the explore pages. -- `DISABLE_USERS_PAGE`: **false**: Disable the users explore page. - -## SSH Minimum Key Sizes (`ssh.minimum_key_sizes`) - -Define allowed algorithms and their minimum key length (use -1 to disable a type): - -- `ED25519`: **256** -- `ECDSA`: **256** -- `RSA`: **2047**: We set 2047 here because an otherwise valid 2048 RSA key can be reported as 2047 length. -- `DSA`: **-1**: DSA is now disabled by default. Set to **1024** to re-enable but ensure you may need to reconfigure your SSHD provider - -## Webhook (`webhook`) - -- `QUEUE_LENGTH`: **1000**: Hook task queue length. Use caution when editing this value. -- `DELIVER_TIMEOUT`: **5**: Delivery timeout (sec) for shooting webhooks. -- `ALLOWED_HOST_LIST`: **external**: Webhook can only call allowed hosts for security reasons. Comma separated list. - - Built-in networks: - - `loopback`: 127.0.0.0/8 for IPv4 and ::1/128 for IPv6, localhost is included. - - `private`: RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and RFC 4193 (FC00::/7). Also called LAN/Intranet. - - `external`: A valid non-private unicast IP, you can access all hosts on public internet. - - `*`: All hosts are allowed. - - CIDR list: `1.2.3.0/8` for IPv4 and `2001:db8::/32` for IPv6 - - Wildcard hosts: `*.mydomain.com`, `192.168.100.*` -- `SKIP_TLS_VERIFY`: **false**: Allow insecure certification. -- `PAGING_NUM`: **10**: Number of webhook history events that are shown in one page. -- `PROXY_URL`: **\<empty\>**: Proxy server URL, support http://, https//, socks://, blank will follow environment http_proxy/https_proxy. If not given, will use global proxy setting. -- `PROXY_HOSTS`: **\<empty\>`**: Comma separated list of host names requiring proxy. Glob patterns (*) are accepted; use ** to match all hosts. If not given, will use global proxy setting. - -## Mailer (`mailer`) - -⚠️ This section is for Gitea 1.18 and later. If you are using Gitea 1.17 or older, -please refer to -[Gitea 1.17 app.ini example](https://github.com/go-gitea/gitea/blob/release/v1.17/custom/conf/app.example.ini) -and -[Gitea 1.17 configuration document](https://github.com/go-gitea/gitea/blob/release/v1.17/docs/content/doc/advanced/config-cheat-sheet.en-us.md) - -- `ENABLED`: **false**: Enable to use a mail service. -- `PROTOCOL`: **\<empty\>**: Mail server protocol. One of "smtp", "smtps", "smtp+starttls", "smtp+unix", "sendmail", "dummy". _Before 1.18, this was inferred from a combination of `MAILER_TYPE` and `IS_TLS_ENABLED`._ - - SMTP family, if your provider does not explicitly say which protocol it uses but does provide a port, you can set SMTP_PORT instead and this will be inferred. - - **sendmail** Use the operating system's `sendmail` command instead of SMTP. This is common on Linux systems. - - **dummy** Send email messages to the log as a testing phase. - - Note that enabling sendmail will ignore all other `mailer` settings except `ENABLED`, `FROM`, `SUBJECT_PREFIX` and `SENDMAIL_PATH`. - - Enabling dummy will ignore all settings except `ENABLED`, `SUBJECT_PREFIX` and `FROM`. -- `SMTP_ADDR`: **\<empty\>**: Mail server address. e.g. smtp.gmail.com. For smtp+unix, this should be a path to a unix socket instead. _Before 1.18, this was combined with `SMTP_PORT` under the name `HOST`._ -- `SMTP_PORT`: **\<empty\>**: Mail server port. If no protocol is specified, it will be inferred by this setting. Common ports are listed below. _Before 1.18, this was combined with `SMTP_ADDR` under the name `HOST`._ - - 25: insecure SMTP - - 465: SMTP Secure - - 587: StartTLS -- `USE_CLIENT_CERT`: **false**: Use client certificate for TLS/SSL. -- `CLIENT_CERT_FILE`: **custom/mailer/cert.pem**: Client certificate file. -- `CLIENT_KEY_FILE`: **custom/mailer/key.pem**: Client key file. -- `FORCE_TRUST_SERVER_CERT`: **false**: If set to `true`, completely ignores server certificate validation errors. This option is unsafe. Consider adding the certificate to the system trust store instead. -- `USER`: **\<empty\>**: Username of mailing user (usually the sender's e-mail address). -- `PASSWD`: **\<empty\>**: Password of mailing user. Use \`your password\` for quoting if you use special characters in the password. - - Please note: authentication is only supported when the SMTP server communication is encrypted with TLS (this can be via `STARTTLS`) or SMTP host is localhost. See [Email Setup]({{< relref "doc/administration/email-setup.en-us.md" >}}) for more information. -- `ENABLE_HELO`: **true**: Enable HELO operation. -- `HELO_HOSTNAME`: **(retrieved from system)**: HELO hostname. -- `FROM`: **\<empty\>**: Mail from address, RFC 5322. This can be just an email address, or the "Name" \<email@example.com\> format. -- `ENVELOPE_FROM`: **\<empty\>**: Address set as the From address on the SMTP mail envelope. Set to `<>` to send an empty address. -- `SUBJECT_PREFIX`: **\<empty\>**: Prefix to be placed before e-mail subject lines. -- `SENDMAIL_PATH`: **sendmail**: The location of sendmail on the operating system (can be command or full path). -- `SENDMAIL_ARGS`: **\<empty\>**: Specify any extra sendmail arguments. (NOTE: you should be aware that email addresses can look like options - if your `sendmail` command takes options you must set the option terminator `--`) -- `SENDMAIL_TIMEOUT`: **5m**: default timeout for sending email through sendmail -- `SENDMAIL_CONVERT_CRLF`: **true**: Most versions of sendmail prefer LF line endings rather than CRLF line endings. Set this to false if your version of sendmail requires CRLF line endings. -- `SEND_BUFFER_LEN`: **100**: Buffer length of mailing queue. **DEPRECATED** use `LENGTH` in `[queue.mailer]` -- `SEND_AS_PLAIN_TEXT`: **false**: Send mails only in plain text, without HTML alternative. - -## Incoming Email (`email.incoming`) - -- `ENABLED`: **false**: Enable handling of incoming emails. -- `REPLY_TO_ADDRESS`: **\<empty\>**: The email address including the `%{token}` placeholder that will be replaced per user/action. Example: `incoming+%{token}@example.com`. The placeholder must appear in the user part of the address (before the `@`). -- `HOST`: **\<empty\>**: IMAP server host. -- `PORT`: **\<empty\>**: IMAP server port. -- `USERNAME`: **\<empty\>**: Username of the receiving account. -- `PASSWORD`: **\<empty\>**: Password of the receiving account. -- `USE_TLS`: **false**: Whether the IMAP server uses TLS. -- `SKIP_TLS_VERIFY`: **false**: If set to `true`, completely ignores server certificate validation errors. This option is unsafe. -- `MAILBOX`: **INBOX**: The mailbox name where incoming mail will end up. -- `DELETE_HANDLED_MESSAGE`: **true**: Whether handled messages should be deleted from the mailbox. -- `MAXIMUM_MESSAGE_SIZE`: **10485760**: Maximum size of a message to handle. Bigger messages are ignored. Set to 0 to allow every size. - -## Cache (`cache`) - -- `ENABLED`: **true**: Enable the cache. -- `ADAPTER`: **memory**: Cache engine adapter, either `memory`, `redis`, `redis-cluster`, `twoqueue` or `memcache`. (`twoqueue` represents a size limited LRU cache.) -- `INTERVAL`: **60**: Garbage Collection interval (sec), for memory and twoqueue cache only. -- `HOST`: **\<empty\>**: Connection string for `redis`, `redis-cluster` and `memcache`. For `twoqueue` sets configuration for the queue. - - Redis: `redis://:macaron@127.0.0.1:6379/0?pool_size=100&idle_timeout=180s` - - Redis-cluster `redis+cluster://:macaron@127.0.0.1:6379/0?pool_size=100&idle_timeout=180s` - - Memcache: `127.0.0.1:9090;127.0.0.1:9091` - - TwoQueue LRU cache: `{"size":50000,"recent_ratio":0.25,"ghost_ratio":0.5}` or `50000` representing the maximum number of objects stored in the cache. -- `ITEM_TTL`: **16h**: Time to keep items in cache if not used, Setting it to -1 disables caching. - -## Cache - LastCommitCache settings (`cache.last_commit`) - -- `ENABLED`: **true**: Enable the cache. -- `ITEM_TTL`: **8760h**: Time to keep items in cache if not used, Setting it to -1 disables caching. -- `COMMITS_COUNT`: **1000**: Only enable the cache when repository's commits count great than. - -## Session (`session`) - -- `PROVIDER`: **memory**: Session engine provider \[memory, file, redis, redis-cluster, db, mysql, couchbase, memcache, postgres\]. Setting `db` will reuse the configuration in `[database]` -- `PROVIDER_CONFIG`: **data/sessions**: For file, the root path; for db, empty (database config will be used); for others, the connection string. Relative paths will be made absolute against _`AppWorkPath`_. -- `COOKIE_SECURE`: **false**: Enable this to force using HTTPS for all session access. -- `COOKIE_NAME`: **i\_like\_gitea**: The name of the cookie used for the session ID. -- `GC_INTERVAL_TIME`: **86400**: GC interval in seconds. -- `SESSION_LIFE_TIME`: **86400**: Session life time in seconds, default is 86400 (1 day) -- `DOMAIN`: **\<empty\>**: Sets the cookie Domain -- `SAME_SITE`: **lax** \[strict, lax, none\]: Set the SameSite setting for the cookie. - -## Picture (`picture`) - -- `GRAVATAR_SOURCE`: **gravatar**: Can be `gravatar`, `duoshuo` or anything like - `http://cn.gravatar.com/avatar/`. -- `DISABLE_GRAVATAR`: **false**: Enable this to use local avatars only. **DEPRECATED [v1.18+]** moved to database. Use admin panel to configure. -- `ENABLE_FEDERATED_AVATAR`: **false**: Enable support for federated avatars (see - [http://www.libravatar.org](http://www.libravatar.org)). **DEPRECATED [v1.18+]** moved to database. Use admin panel to configure. - -- `AVATAR_STORAGE_TYPE`: **default**: Storage type defined in `[storage.xxx]`. Default is `default` which will read `[storage]` if no section `[storage]` will be a type `local`. -- `AVATAR_UPLOAD_PATH`: **data/avatars**: Path to store user avatar image files. -- `AVATAR_MAX_WIDTH`: **4096**: Maximum avatar image width in pixels. -- `AVATAR_MAX_HEIGHT`: **4096**: Maximum avatar image height in pixels. -- `AVATAR_MAX_FILE_SIZE`: **1048576** (1MiB): Maximum avatar image file size in bytes. -- `AVATAR_MAX_ORIGIN_SIZE`: **262144** (256KiB): If the uploaded file is not larger than this byte size, the image will be used as is, without resizing/converting. -- `AVATAR_RENDERED_SIZE_FACTOR`: **2**: The multiplication factor for rendered avatar images. Larger values result in finer rendering on HiDPI devices. - -- `REPOSITORY_AVATAR_STORAGE_TYPE`: **default**: Storage type defined in `[storage.xxx]`. Default is `default` which will read `[storage]` if no section `[storage]` will be a type `local`. -- `REPOSITORY_AVATAR_UPLOAD_PATH`: **data/repo-avatars**: Path to store repository avatar image files. -- `REPOSITORY_AVATAR_FALLBACK`: **none**: How Gitea deals with missing repository avatars - - none = no avatar will be displayed - - random = random avatar will be generated - - image = default image will be used (which is set in `REPOSITORY_AVATAR_FALLBACK_IMAGE`) -- `REPOSITORY_AVATAR_FALLBACK_IMAGE`: **/img/repo_default.png**: Image used as default repository avatar (if `REPOSITORY_AVATAR_FALLBACK` is set to image and none was uploaded) - -## Project (`project`) - -Default templates for project boards: - -- `PROJECT_BOARD_BASIC_KANBAN_TYPE`: **To Do, In Progress, Done** -- `PROJECT_BOARD_BUG_TRIAGE_TYPE`: **Needs Triage, High Priority, Low Priority, Closed** - -## Issue and pull request attachments (`attachment`) - -- `ENABLED`: **true**: Whether issue and pull request attachments are enabled. -- `ALLOWED_TYPES`: **.csv,.docx,.fodg,.fodp,.fods,.fodt,.gif,.gz,.jpeg,.jpg,.log,.md,.mov,.mp4,.odf,.odg,.odp,.ods,.odt,.patch,.pdf,.png,.pptx,.svg,.tgz,.txt,.webm,.xls,.xlsx,.zip**: Comma-separated list of allowed file extensions (`.zip`), mime types (`text/plain`) or wildcard type (`image/*`, `audio/*`, `video/*`). Empty value or `*/*` allows all types. -- `MAX_SIZE`: **4**: Maximum size (MB). -- `MAX_FILES`: **5**: Maximum number of attachments that can be uploaded at once. -- `STORAGE_TYPE`: **local**: Storage type for attachments, `local` for local disk or `minio` for s3 compatible object storage service, default is `local` or other name defined with `[storage.xxx]` -- `SERVE_DIRECT`: **false**: Allows the storage driver to redirect to authenticated URLs to serve files directly. Currently, only Minio/S3 is supported via signed URLs, local does nothing. -- `PATH`: **data/attachments**: Path to store attachments only available when STORAGE_TYPE is `local` -- `MINIO_ENDPOINT`: **localhost:9000**: Minio endpoint to connect only available when STORAGE_TYPE is `minio` -- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID to connect only available when STORAGE_TYPE is `minio` -- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey to connect only available when STORAGE_TYPE is `minio` -- `MINIO_BUCKET`: **gitea**: Minio bucket to store the attachments only available when STORAGE_TYPE is `minio` -- `MINIO_LOCATION`: **us-east-1**: Minio location to create bucket only available when STORAGE_TYPE is `minio` -- `MINIO_BASE_PATH`: **attachments/**: Minio base path on the bucket only available when STORAGE_TYPE is `minio` -- `MINIO_USE_SSL`: **false**: Minio enabled ssl only available when STORAGE_TYPE is `minio` -- `MINIO_INSECURE_SKIP_VERIFY`: **false**: Minio skip SSL verification available when STORAGE_TYPE is `minio` -- `MINIO_CHECKSUM_ALGORITHM`: **default**: Minio checksum algorithm: `default` (for MinIO or AWS S3) or `md5` (for Cloudflare or Backblaze) - -## Log (`log`) - -- `ROOT_PATH`: **\<empty\>**: Root path for log files. -- `MODE`: **console**: Logging mode. For multiple modes, use a comma to separate values. You can configure each mode in per mode log subsections `\[log.writer-mode-name\]`. -- `LEVEL`: **Info**: General log level. \[Trace, Debug, Info, Warn, Error, Critical, Fatal, None\] -- `STACKTRACE_LEVEL`: **None**: Default log level at which to log create stack traces (rarely useful, do not set it). \[Trace, Debug, Info, Warn, Error, Critical, Fatal, None\] -- `ENABLE_SSH_LOG`: **false**: save ssh log to log file -- `logger.access.MODE`: **\<empty\>**: The "access" logger -- `logger.router.MODE`: **,**: The "router" logger, a single comma means it will use the default MODE above -- `logger.xorm.MODE`: **,**: The "xorm" logger - -### Access Log (`log`) - -- `ACCESS_LOG_TEMPLATE`: **`{{.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}}"`**: Sets the template used to create the access log. - - The following variables are available: - - `Ctx`: the `context.Context` of the request. - - `Identity`: the SignedUserName or `"-"` if not logged in. - - `Start`: the start time of the request. - - `ResponseWriter`: the responseWriter from the request. - - `RequestID`: the value matching REQUEST_ID_HEADERS（default: `-`, if not matched）. - - You must be very careful to ensure that this template does not throw errors or panics as this template runs outside the panic/recovery script. -- `REQUEST_ID_HEADERS`: **\<empty\>**: You can configure multiple values that are splited by comma here. It will match in the order of configuration, and the first match will be finally printed in the access log. - - e.g. - - In the Request Header: X-Request-ID: **test-id-123** - - Configuration in app.ini: REQUEST_ID_HEADERS = X-Request-ID - - Print in log: 127.0.0.1:58384 - - [14/Feb/2023:16:33:51 +0800] "**test-id-123**" ... - -### Log subsections (`log.<writer-mode-name>`) - -- `MODE`: **name**: Sets the mode of this log writer - Defaults to the provided subsection name. This allows you to have two different file loggers at different levels. -- `LEVEL`: **log.LEVEL**: Sets the log-level of this writer. Defaults to the `LEVEL` set in the global `[log]` section. -- `STACKTRACE_LEVEL`: **log.STACKTRACE_LEVEL**: Sets the log level at which to log stack traces. -- `EXPRESSION`: **""**: A regular expression to match either the function name, file or message. Defaults to empty. Only log messages that match the expression will be saved in the logger. -- `FLAGS`: **stdflags**: A comma separated string representing the log flags. Defaults to `stdflags` which represents the prefix: `2009/01/23 01:23:23 ...a/b/c/d.go:23:runtime.Caller() [I]: message`. `none` means don't prefix log lines. See `modules/log/flags.go` for more information. -- `PREFIX`: **""**: An additional prefix for every log line in this logger. Defaults to empty. -- `COLORIZE`: **false**: Whether to colorize the log lines - -### Console log mode (`log.console`, or `MODE=console`) - -- For the console logger `COLORIZE` will default to `true` if not on windows or the terminal is determined to be able to color. -- `STDERR`: **false**: Use Stderr instead of Stdout. - -### File log mode (`log.file`, or `MODE=file`) - -- `FILE_NAME`: Set the file name for this logger. Defaults to `gitea.log` (exception: access log defaults to `access.log`). If relative will be relative to the `ROOT_PATH` -- `LOG_ROTATE`: **true**: Rotate the log files. -- `MAX_SIZE_SHIFT`: **28**: Maximum size shift of a single file, 28 represents 256Mb. -- `DAILY_ROTATE`: **true**: Rotate logs daily. -- `MAX_DAYS`: **7**: Delete the log file after n days -- `COMPRESS`: **true**: Compress old log files by default with gzip -- `COMPRESSION_LEVEL`: **-1**: Compression level - -### Conn log mode (`log.conn`, or `MODE=conn`) - -- `RECONNECT_ON_MSG`: **false**: Reconnect host for every single message. -- `RECONNECT`: **false**: Try to reconnect when connection is lost. -- `PROTOCOL`: **tcp**: Set the protocol, either "tcp", "unix" or "udp". -- `ADDR`: **:7020**: Sets the address to connect to. - -## Cron (`cron`) - -- `ENABLED`: **false**: Enable to run all cron tasks periodically with default settings. -- `RUN_AT_START`: **false**: Run cron tasks at application start-up. -- `NOTICE_ON_SUCCESS`: **false**: Set to true to switch on success notices. - -- `SCHEDULE` accept formats - - Full crontab specs, e.g. `* * * * * ?` - - Descriptors, e.g. `@midnight`, `@every 1h30m` ... - - See more: [cron documentation](https://pkg.go.dev/github.com/gogs/cron@v0.0.0-20171120032916-9f6c956d3e14) - -### Basic cron tasks - enabled by default - -#### Cron - Cleanup old repository archives (`cron.archive_cleanup`) - -- `ENABLED`: **true**: Enable service. -- `RUN_AT_START`: **true**: Run tasks at start up time (if ENABLED). -- `SCHEDULE`: **@midnight**: Cron syntax for scheduling repository archive cleanup, e.g. `@every 1h`. -- `OLDER_THAN`: **24h**: Archives created more than `OLDER_THAN` ago are subject to deletion, e.g. `12h`. - -#### Cron - Update Mirrors (`cron.update_mirrors`) - -- `SCHEDULE`: **@every 10m**: Cron syntax for scheduling update mirrors, e.g. `@every 3h`. -- `PULL_LIMIT`: **50**: Limit the number of mirrors added to the queue to this number (negative values mean no limit, 0 will result in no mirrors being queued effectively disabling pull mirror updating). -- `PUSH_LIMIT`: **50**: Limit the number of mirrors added to the queue to this number (negative values mean no limit, 0 will result in no mirrors being queued effectively disabling push mirror updating). - -#### Cron - Repository Health Check (`cron.repo_health_check`) - -- `SCHEDULE`: **@midnight**: Cron syntax for scheduling repository health check. -- `TIMEOUT`: **60s**: Time duration syntax for health check execution timeout. -- `ARGS`: **\<empty\>**: Arguments for command `git fsck`, e.g. `--unreachable --tags`. See more on http://git-scm.com/docs/git-fsck - -#### Cron - Repository Statistics Check (`cron.check_repo_stats`) - -- `RUN_AT_START`: **true**: Run repository statistics check at start time. -- `SCHEDULE`: **@midnight**: Cron syntax for scheduling repository statistics check. - -#### Cron - Cleanup hook_task Table (`cron.cleanup_hook_task_table`) - -- `ENABLED`: **true**: Enable cleanup hook_task job. -- `RUN_AT_START`: **false**: Run cleanup hook_task at start time (if ENABLED). -- `SCHEDULE`: **@midnight**: Cron syntax for cleaning hook_task table. -- `CLEANUP_TYPE` **OlderThan** OlderThan or PerWebhook Method to cleanup hook_task, either by age (i.e. how long ago hook_task record was delivered) or by the number to keep per webhook (i.e. keep most recent x deliveries per webhook). -- `OLDER_THAN`: **168h**: If CLEANUP_TYPE is set to OlderThan, then any delivered hook_task records older than this expression will be deleted. -- `NUMBER_TO_KEEP`: **10**: If CLEANUP_TYPE is set to PerWebhook, this is number of hook_task records to keep for a webhook (i.e. keep the most recent x deliveries). - -#### Cron - Cleanup expired packages (`cron.cleanup_packages`) - -- `ENABLED`: **true**: Enable cleanup expired packages job. -- `RUN_AT_START`: **true**: Run job at start time (if ENABLED). -- `NOTICE_ON_SUCCESS`: **false**: Notify every time this job runs. -- `SCHEDULE`: **@midnight**: Cron syntax for the job. -- `OLDER_THAN`: **24h**: Unreferenced package data created more than OLDER_THAN ago is subject to deletion. - -#### Cron - Update Migration Poster ID (`cron.update_migration_poster_id`) - -- `SCHEDULE`: **@midnight** : Interval as a duration between each synchronization, it will always attempt synchronization when the instance starts. - -#### Cron - Sync External Users (`cron.sync_external_users`) - -- `SCHEDULE`: **@midnight** : Interval as a duration between each synchronization, it will always attempt synchronization when the instance starts. -- `UPDATE_EXISTING`: **true**: Create new users, update existing user data and disable users that are not in external source anymore (default) or only create new users if UPDATE_EXISTING is set to false. - -### Extended cron tasks (not enabled by default) - -#### Cron - Garbage collect all repositories (`cron.git_gc_repos`) - -- `ENABLED`: **false**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `SCHEDULE`: **@every 72h**: Cron syntax for scheduling repository archive cleanup, e.g. `@every 1h`. -- `TIMEOUT`: **60s**: Time duration syntax for garbage collection execution timeout. -- `NOTICE_ON_SUCCESS`: **false**: Set to true to switch on success notices. -- `ARGS`: **\<empty\>**: Arguments for command `git gc`, e.g. `--aggressive --auto`. The default value is same with [git] -> GC_ARGS - -#### Cron - Update the '.ssh/authorized_keys' file with Gitea SSH keys (`cron.resync_all_sshkeys`) - -- `ENABLED`: **false**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `NOTICE_ON_SUCCESS`: **false**: Set to true to switch on success notices. -- `SCHEDULE`: **@every 72h**: Cron syntax for scheduling repository archive cleanup, e.g. `@every 1h`. - -#### Cron - Resynchronize pre-receive, update and post-receive hooks of all repositories (`cron.resync_all_hooks`) - -- `ENABLED`: **false**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `NOTICE_ON_SUCCESS`: **false**: Set to true to switch on success notices. -- `SCHEDULE`: **@every 72h**: Cron syntax for scheduling repository archive cleanup, e.g. `@every 1h`. - -#### Cron - Reinitialize all missing Git repositories for which records exist (`cron.reinit_missing_repos`) - -- `ENABLED`: **false**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `NOTICE_ON_SUCCESS`: **false**: Set to true to switch on success notices. -- `SCHEDULE`: **@every 72h**: Cron syntax for scheduling repository archive cleanup, e.g. `@every 1h`. - -#### Cron - Delete all repositories missing their Git files (`cron.delete_missing_repos`) - -- `ENABLED`: **false**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `NOTICE_ON_SUCCESS`: **false**: Set to true to switch on success notices. -- `SCHEDULE`: **@every 72h**: Cron syntax for scheduling repository archive cleanup, e.g. `@every 1h`. - -#### Cron - Delete generated repository avatars (`cron.delete_generated_repository_avatars`) - -- `ENABLED`: **false**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `NOTICE_ON_SUCCESS`: **false**: Set to true to switch on success notices. -- `SCHEDULE`: **@every 72h**: Cron syntax for scheduling repository archive cleanup, e.g. `@every 1h`. - -#### Cron - Delete all old actions from database (`cron.delete_old_actions`) - -- `ENABLED`: **false**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `NOTICE_ON_SUCCESS`: **false**: Set to true to switch on success notices. -- `SCHEDULE`: **@every 168h**: Cron syntax to set how often to check. -- `OLDER_THAN`: **8760h**: any action older than this expression will be deleted from database, suggest using `8760h` (1 year) because that's the max length of heatmap. - -#### Cron - Check for new Gitea versions (`cron.update_checker`) - -- `ENABLED`: **true**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `ENABLE_SUCCESS_NOTICE`: **true**: Set to false to switch off success notices. -- `SCHEDULE`: **@every 168h**: Cron syntax for scheduling a work, e.g. `@every 168h`. -- `HTTP_ENDPOINT`: **https://dl.gitea.com/gitea/version.json**: the endpoint that Gitea will check for newer versions - -#### Cron - Delete all old system notices from database (`cron.delete_old_system_notices`) - -- `ENABLED`: **false**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `NO_SUCCESS_NOTICE`: **false**: Set to true to switch off success notices. -- `SCHEDULE`: **@every 168h**: Cron syntax to set how often to check. -- `OLDER_THAN`: **8760h**: any system notice older than this expression will be deleted from database. - -#### Cron - Garbage collect LFS pointers in repositories (`cron.gc_lfs`) - -- `ENABLED`: **false**: Enable service. -- `RUN_AT_START`: **false**: Run tasks at start up time (if ENABLED). -- `SCHEDULE`: **@every 24h**: Cron syntax to set how often to check. -- `OLDER_THAN`: **168h**: Only attempt to garbage collect LFSMetaObjects older than this (default 7 days) -- `LAST_UPDATED_MORE_THAN_AGO`: **72h**: Only attempt to garbage collect LFSMetaObjects that have not been attempted to be garbage collected for this long (default 3 days) -- `NUMBER_TO_CHECK_PER_REPO`: **100**: Minimum number of stale LFSMetaObjects to check per repo. Set to `0` to always check all. -- `PROPORTION_TO_CHECK_PER_REPO`: **0.6**: Check at least this proportion of LFSMetaObjects per repo. (This may cause all stale LFSMetaObjects to be checked.) - -## Git (`git`) - -- `PATH`: **""**: The path of Git executable. If empty, Gitea searches through the PATH environment. -- `HOME_PATH`: **%(APP_DATA_PATH)s/home**: The HOME directory for Git. - This directory will be used to contain the `.gitconfig` and possible `.gnupg` directories that Gitea's git calls will use. If you can confirm Gitea is the only application running in this environment, you can set it to the normal home directory for Gitea user. -- `DISABLE_DIFF_HIGHLIGHT`: **false**: Disables highlight of added and removed changes. -- `MAX_GIT_DIFF_LINES`: **1000**: Max number of lines allowed of a single file in diff view. -- `MAX_GIT_DIFF_LINE_CHARACTERS`: **5000**: Max character count per line highlighted in diff view. -- `MAX_GIT_DIFF_FILES`: **100**: Max number of files shown in diff view. -- `COMMITS_RANGE_SIZE`: **50**: Set the default commits range size -- `BRANCHES_RANGE_SIZE`: **20**: Set the default branches range size -- `GC_ARGS`: **\<empty\>**: Arguments for command `git gc`, e.g. `--aggressive --auto`. See more on http://git-scm.com/docs/git-gc/ -- `ENABLE_AUTO_GIT_WIRE_PROTOCOL`: **true**: If use Git wire protocol version 2 when Git version >= 2.18, default is true, set to false when you always want Git wire protocol version 1. - To enable this for Git over SSH when using a OpenSSH server, add `AcceptEnv GIT_PROTOCOL` to your sshd_config file. -- `PULL_REQUEST_PUSH_MESSAGE`: **true**: Respond to pushes to a non-default branch with a URL for creating a Pull Request (if the repository has them enabled) -- `VERBOSE_PUSH`: **true**: Print status information about pushes as they are being processed. -- `VERBOSE_PUSH_DELAY`: **5s**: Only print verbose information if push takes longer than this delay. -- `LARGE_OBJECT_THRESHOLD`: **1048576**: (Go-Git only), don't cache objects greater than this in memory. (Set to 0 to disable.) -- `DISABLE_CORE_PROTECT_NTFS`: **false** Set to true to forcibly set `core.protectNTFS` to false. -- `DISABLE_PARTIAL_CLONE`: **false** Disable the usage of using partial clones for git. - -### Git - Timeout settings (`git.timeout`) - -- `DEFAULT`: **360**: Git operations default timeout seconds. -- `MIGRATE`: **600**: Migrate external repositories timeout seconds. -- `MIRROR`: **300**: Mirror external repositories timeout seconds. -- `CLONE`: **300**: Git clone from internal repositories timeout seconds. -- `PULL`: **300**: Git pull from internal repositories timeout seconds. -- `GC`: **60**: Git repository GC timeout seconds. - -### Git - Config options (`git.config`) - -The key/value pairs in this section will be used as git config. -This section only does "set" config, a removed config key from this section won't be removed from git config automatically. The format is `some.configKey = value`. - -- `diff.algorithm`: **histogram** -- `core.logAllRefUpdates`: **true** -- `gc.reflogExpire`: **90** - -## Metrics (`metrics`) - -- `ENABLED`: **false**: Enables /metrics endpoint for prometheus. -- `ENABLED_ISSUE_BY_LABEL`: **false**: Enable issue by label metrics with format `gitea_issues_by_label{label="bug"} 2`. -- `ENABLED_ISSUE_BY_REPOSITORY`: **false**: Enable issue by repository metrics with format `gitea_issues_by_repository{repository="org/repo"} 5`. -- `TOKEN`: **\<empty\>**: You need to specify the token, if you want to include in the authorization the metrics . The same token need to be used in prometheus parameters `bearer_token` or `bearer_token_file`. - -## API (`api`) - -- `ENABLE_SWAGGER`: **true**: Enables the API documentation endpoints (`/api/swagger`, `/api/v1/swagger`, …). True or false. -- `MAX_RESPONSE_ITEMS`: **50**: Max number of items in a page. -- `DEFAULT_PAGING_NUM`: **30**: Default paging number of API. -- `DEFAULT_GIT_TREES_PER_PAGE`: **1000**: Default and maximum number of items per page for Git trees API. -- `DEFAULT_MAX_BLOB_SIZE`: **10485760** (10MiB): Default max size of a blob that can be returned by the blobs API. - -## OAuth2 (`oauth2`) - -- `ENABLE`: **true**: Enables OAuth2 provider. -- `ACCESS_TOKEN_EXPIRATION_TIME`: **3600**: Lifetime of an OAuth2 access token in seconds -- `REFRESH_TOKEN_EXPIRATION_TIME`: **730**: Lifetime of an OAuth2 refresh token in hours -- `INVALIDATE_REFRESH_TOKENS`: **false**: Check if refresh token has already been used -- `JWT_SIGNING_ALGORITHM`: **RS256**: Algorithm used to sign OAuth2 tokens. Valid values: \[`HS256`, `HS384`, `HS512`, `RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`\] -- `JWT_SECRET`: **\<empty\>**: OAuth2 authentication secret for access and refresh tokens, change this to a unique string. This setting is only needed if `JWT_SIGNING_ALGORITHM` is set to `HS256`, `HS384` or `HS512`. -- `JWT_SECRET_URI`: **\<empty\>**: Instead of defining JWT_SECRET in the configuration, this configuration option can be used to give Gitea a path to a file that contains the secret (example value: `file:/etc/gitea/oauth2_jwt_secret`) -- `JWT_SIGNING_PRIVATE_KEY_FILE`: **jwt/private.pem**: Private key file path used to sign OAuth2 tokens. The path is relative to `APP_DATA_PATH`. This setting is only needed if `JWT_SIGNING_ALGORITHM` is set to `RS256`, `RS384`, `RS512`, `ES256`, `ES384` or `ES512`. The file must contain a RSA or ECDSA private key in the PKCS8 format. If no key exists a 4096 bit key will be created for you. -- `MAX_TOKEN_LENGTH`: **32767**: Maximum length of token/cookie to accept from OAuth2 provider - -## i18n (`i18n`) - -- `LANGS`: **en-US,zh-CN,zh-HK,zh-TW,de-DE,fr-FR,nl-NL,lv-LV,ru-RU,uk-UA,ja-JP,es-ES,pt-BR,pt-PT,pl-PL,bg-BG,it-IT,fi-FI,tr-TR,cs-CZ,sv-SE,ko-KR,el-GR,fa-IR,hu-HU,id-ID,ml-IN**: - List of locales shown in language selector. The first locale will be used as the default if user browser's language doesn't match any locale in the list. -- `NAMES`: **English,简体中文,繁體中文（香港）,繁體中文（台灣）,Deutsch,Français,Nederlands,Latviešu,Русский,Українська,日本語,Español,Português do Brasil,Português de Portugal,Polski,Български,Italiano,Suomi,Türkçe,Čeština,Српски,Svenska,한국어,Ελληνικά,فارسی,Magyar nyelv,Bahasa Indonesia,മലയാളം**: Visible names corresponding to the locales - -## Markup (`markup`) - -- `MERMAID_MAX_SOURCE_CHARACTERS`: **5000**: Set the maximum size of a Mermaid source. (Set to -1 to disable) - -Gitea can support Markup using external tools. The example below will add a markup named `asciidoc`. - -```ini -[markup.asciidoc] -ENABLED = true -NEED_POSTPROCESS = true -FILE_EXTENSIONS = .adoc,.asciidoc -RENDER_COMMAND = "asciidoctor --embedded --safe-mode=secure --out-file=- -" -IS_INPUT_FILE = false -``` - -- ENABLED: **false** Enable markup support; set to **true** to enable this renderer. -- NEED\_POSTPROCESS: **true** set to **true** to replace links / sha1 and etc. -- FILE\_EXTENSIONS: **\<empty\>** List of file extensions that should be rendered by an external - command. Multiple extensions needs a comma as splitter. -- RENDER\_COMMAND: External command to render all matching extensions. -- IS\_INPUT\_FILE: **false** Input is not a standard input but a file param followed `RENDER_COMMAND`. -- RENDER_CONTENT_MODE: **sanitized** How the content will be rendered. - - sanitized: Sanitize the content and render it inside current page, default to only allow a few HTML tags and attributes. Customized sanitizer rules can be defined in `[markup.sanitizer.*]`. - - no-sanitizer: Disable the sanitizer and render the content inside current page. It's **insecure** and may lead to XSS attack if the content contains malicious code. - - iframe: Render the content in a separate standalone page and embed it into current page by iframe. The iframe is in sandbox mode with same-origin disabled, and the JS code are safely isolated from parent page. - -Two special environment variables are passed to the render command: - -- `GITEA_PREFIX_SRC`, which contains the current URL prefix in the `src` path tree. To be used as prefix for links. -- `GITEA_PREFIX_RAW`, which contains the current URL prefix in the `raw` path tree. To be used as prefix for image paths. - -If `RENDER_CONTENT_MODE` is `sanitized`, Gitea supports customizing the sanitization policy for rendered HTML. The example below will support KaTeX output from pandoc. - -```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`: The element this policy applies to. Must be non-empty. -- `ALLOW_ATTR`: The attribute this policy allows. Must be non-empty. -- `REGEXP`: A regex to match the contents of the attribute against. Must be present but may be empty for unconditional whitelisting of this attribute. -- `ALLOW_DATA_URI_IMAGES`: **false** Allow data uri images (`<img src="data:image/png;base64,..."/>`). - -Multiple sanitisation rules can be defined by adding unique subsections, e.g. `[markup.sanitizer.TeX-2]`. -To apply a sanitisation rules only for a specify external renderer they must use the renderer name, e.g. `[markup.sanitizer.asciidoc.rule-1]`. -If the rule is defined above the renderer ini section or the name does not match a renderer it is applied to every renderer. - -## Highlight Mappings (`highlight.mapping`) - -- `file_extension e.g. .toml`: **language e.g. ini**. File extension to language mapping overrides. - -- Gitea will highlight files using the `linguist-language` or `gitlab-language` attribute from the `.gitattributes` file -if available. If this is not set or the language is unavailable, the file extension will be looked up -in this mapping or the filetype using heuristics. - -## Time (`time`) - -- `DEFAULT_UI_LOCATION`: Default location of time on the UI, so that we can display correct user's time on UI. i.e. Asia/Shanghai - -## Task (`task`) - -Task queue configuration has been moved to `queue.task`. However, the below configuration values are kept for backwards compatibility: - -- `QUEUE_TYPE`: **channel**: Task queue type, could be `channel` or `redis`. -- `QUEUE_LENGTH`: **1000**: Task queue length, available only when `QUEUE_TYPE` is `channel`. -- `QUEUE_CONN_STR`: **redis://127.0.0.1:6379/0**: Task queue connection string, available only when `QUEUE_TYPE` is `redis`. If redis needs a password, use `redis://123@127.0.0.1:6379/0` or `redis+cluster://123@127.0.0.1:6379/0`. - -## Migrations (`migrations`) - -- `MAX_ATTEMPTS`: **3**: Max attempts per http/https request on migrations. -- `RETRY_BACKOFF`: **3**: Backoff time per http/https request retry (seconds) -- `ALLOWED_DOMAINS`: **\<empty\>**: Domains allowlist for migrating repositories, default is blank. It means everything will be allowed. Multiple domains could be separated by commas. Wildcard is supported: `github.com, *.github.com`. -- `BLOCKED_DOMAINS`: **\<empty\>**: Domains blocklist for migrating repositories, default is blank. Multiple domains could be separated by commas. When `ALLOWED_DOMAINS` is not blank, this option has a higher priority to deny domains. Wildcard is supported. -- `ALLOW_LOCALNETWORKS`: **false**: Allow private addresses defined by RFC 1918, RFC 1122, RFC 4632 and RFC 4291. If a domain is allowed by `ALLOWED_DOMAINS`, this option will be ignored. -- `SKIP_TLS_VERIFY`: **false**: Allow skip tls verify - -## Federation (`federation`) - -- `ENABLED`: **false**: Enable/Disable federation capabilities -- `SHARE_USER_STATISTICS`: **true**: Enable/Disable user statistics for nodeinfo if federation is enabled -- `MAX_SIZE`: **4**: Maximum federation request and response size (MB) - - WARNING: Changing the settings below can break federation. - -- `ALGORITHMS`: **rsa-sha256, rsa-sha512, ed25519**: HTTP signature algorithms -- `DIGEST_ALGORITHM`: **SHA-256**: HTTP signature digest algorithm -- `GET_HEADERS`: **(request-target), Date**: GET headers for federation requests -- `POST_HEADERS`: **(request-target), Date, Digest**: POST headers for federation requests - -## Packages (`packages`) - -- `ENABLED`: **true**: Enable/Disable package registry capabilities -- `CHUNKED_UPLOAD_PATH`: **tmp/package-upload**: Path for chunked uploads. Defaults to `APP_DATA_PATH` + `tmp/package-upload` -- `LIMIT_TOTAL_OWNER_COUNT`: **-1**: Maximum count of package versions a single owner can have (`-1` means no limits) -- `LIMIT_TOTAL_OWNER_SIZE`: **-1**: Maximum size of packages a single owner can use (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_ALPINE`: **-1**: Maximum size of an Alpine upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_CARGO`: **-1**: Maximum size of a Cargo upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_CHEF`: **-1**: Maximum size of a Chef upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_COMPOSER`: **-1**: Maximum size of a Composer upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_CONAN`: **-1**: Maximum size of a Conan upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_CONDA`: **-1**: Maximum size of a Conda upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_CONTAINER`: **-1**: Maximum size of a Container upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_CRAN`: **-1**: Maximum size of a CRAN upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_DEBIAN`: **-1**: Maximum size of a Debian upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_GENERIC`: **-1**: Maximum size of a Generic upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_GO`: **-1**: Maximum size of a Go upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_HELM`: **-1**: Maximum size of a Helm upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_MAVEN`: **-1**: Maximum size of a Maven upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_NPM`: **-1**: Maximum size of a npm upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_NUGET`: **-1**: Maximum size of a NuGet upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_PUB`: **-1**: Maximum size of a Pub upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_PYPI`: **-1**: Maximum size of a PyPI upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_RPM`: **-1**: Maximum size of a RPM upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_RUBYGEMS`: **-1**: Maximum size of a RubyGems upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_SWIFT`: **-1**: Maximum size of a Swift upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) -- `LIMIT_SIZE_VAGRANT`: **-1**: Maximum size of a Vagrant upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`) - -## Mirror (`mirror`) - -- `ENABLED`: **true**: Enables the mirror functionality. Set to **false** to disable all mirrors. Pre-existing mirrors remain valid but won't be updated; may be converted to regular repo. -- `DISABLE_NEW_PULL`: **false**: Disable the creation of **new** pull mirrors. Pre-existing mirrors remain valid. Will be ignored if `mirror.ENABLED` is `false`. -- `DISABLE_NEW_PUSH`: **false**: Disable the creation of **new** push mirrors. Pre-existing mirrors remain valid. Will be ignored if `mirror.ENABLED` is `false`. -- `DEFAULT_INTERVAL`: **8h**: Default interval between each check -- `MIN_INTERVAL`: **10m**: Minimum interval for checking. (Must be >1m). - -## LFS (`lfs`) - -Storage configuration for lfs data. It will be derived from default `[storage]` or -`[storage.xxx]` when set `STORAGE_TYPE` to `xxx`. When derived, the default of `PATH` -is `data/lfs` and the default of `MINIO_BASE_PATH` is `lfs/`. - -- `STORAGE_TYPE`: **local**: Storage type for lfs, `local` for local disk or `minio` for s3 compatible object storage service or other name defined with `[storage.xxx]` -- `SERVE_DIRECT`: **false**: Allows the storage driver to redirect to authenticated URLs to serve files directly. Currently, only Minio/S3 is supported via signed URLs, local does nothing. -- `PATH`: **./data/lfs**: Where to store LFS files, only available when `STORAGE_TYPE` is `local`. If not set it fall back to deprecated LFS_CONTENT_PATH value in [server] section. -- `MINIO_ENDPOINT`: **localhost:9000**: Minio endpoint to connect only available when `STORAGE_TYPE` is `minio` -- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID to connect only available when `STORAGE_TYPE` is `minio` -- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey to connect only available when `STORAGE_TYPE is` `minio` -- `MINIO_BUCKET`: **gitea**: Minio bucket to store the lfs only available when `STORAGE_TYPE` is `minio` -- `MINIO_LOCATION`: **us-east-1**: Minio location to create bucket only available when `STORAGE_TYPE` is `minio` -- `MINIO_BASE_PATH`: **lfs/**: Minio base path on the bucket only available when `STORAGE_TYPE` is `minio` -- `MINIO_USE_SSL`: **false**: Minio enabled ssl only available when `STORAGE_TYPE` is `minio` -- `MINIO_INSECURE_SKIP_VERIFY`: **false**: Minio skip SSL verification available when STORAGE_TYPE is `minio` - -## Storage (`storage`) - -Default storage configuration for attachments, lfs, avatars, repo-avatars, repo-archive, packages, actions_log, actions_artifact. - -- `STORAGE_TYPE`: **local**: Storage type, `local` for local disk or `minio` for s3 compatible object storage service. -- `SERVE_DIRECT`: **false**: Allows the storage driver to redirect to authenticated URLs to serve files directly. Currently, only Minio/S3 is supported via signed URLs, local does nothing. -- `MINIO_ENDPOINT`: **localhost:9000**: Minio endpoint to connect only available when `STORAGE_TYPE` is `minio` -- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID to connect only available when `STORAGE_TYPE` is `minio` -- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey to connect only available when `STORAGE_TYPE is` `minio` -- `MINIO_BUCKET`: **gitea**: Minio bucket to store the data only available when `STORAGE_TYPE` is `minio` -- `MINIO_LOCATION`: **us-east-1**: Minio location to create bucket only available when `STORAGE_TYPE` is `minio` -- `MINIO_USE_SSL`: **false**: Minio enabled ssl only available when `STORAGE_TYPE` is `minio` -- `MINIO_INSECURE_SKIP_VERIFY`: **false**: Minio skip SSL verification available when STORAGE_TYPE is `minio` - -The recommanded storage configuration for minio like below: - -```ini -[storage] -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 -``` - -Defaultly every storage has their default base path like below - -| 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/ | - -And bucket, basepath or `SERVE_DIRECT` could be special or overrided, if you want to use a different you can: - -```ini -[storage.actions_log] -MINIO_BUCKET = gitea_actions_log -SERVE_DIRECT = true -MINIO_BASE_PATH = my_actions_log/ ; default is actions_log/ if blank -``` - -If you want to customerize a different storage for `lfs` if above default storage defined - -```ini -[lfs] -STORAGE_TYPE = my_minio - -[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 -``` - -## Repository Archive Storage (`storage.repo-archive`) - -Configuration for repository archive storage. It will inherit from default `[storage]` or -`[storage.xxx]` when set `STORAGE_TYPE` to `xxx`. The default of `PATH` -is `data/repo-archive` and the default of `MINIO_BASE_PATH` is `repo-archive/`. - -- `STORAGE_TYPE`: **local**: Storage type for repo archive, `local` for local disk or `minio` for s3 compatible object storage service or other name defined with `[storage.xxx]` -- `SERVE_DIRECT`: **false**: Allows the storage driver to redirect to authenticated URLs to serve files directly. Currently, only Minio/S3 is supported via signed URLs, local does nothing. -- `PATH`: **./data/repo-archive**: Where to store archive files, only available when `STORAGE_TYPE` is `local`. -- `MINIO_ENDPOINT`: **localhost:9000**: Minio endpoint to connect only available when `STORAGE_TYPE` is `minio` -- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID to connect only available when `STORAGE_TYPE` is `minio` -- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey to connect only available when `STORAGE_TYPE is` `minio` -- `MINIO_BUCKET`: **gitea**: Minio bucket to store the lfs only available when `STORAGE_TYPE` is `minio` -- `MINIO_LOCATION`: **us-east-1**: Minio location to create bucket only available when `STORAGE_TYPE` is `minio` -- `MINIO_BASE_PATH`: **repo-archive/**: Minio base path on the bucket only available when `STORAGE_TYPE` is `minio` -- `MINIO_USE_SSL`: **false**: Minio enabled ssl only available when `STORAGE_TYPE` is `minio` -- `MINIO_INSECURE_SKIP_VERIFY`: **false**: Minio skip SSL verification available when STORAGE_TYPE is `minio` - -## Repository Archives (`repo-archive`) - -- `STORAGE_TYPE`: **local**: Storage type for actions logs, `local` for local disk or `minio` for s3 compatible object storage service, default is `local` or other name defined with `[storage.xxx]` -- `MINIO_BASE_PATH`: **repo-archive/**: Minio base path on the bucket only available when STORAGE_TYPE is `minio` - -## Proxy (`proxy`) - -- `PROXY_ENABLED`: **false**: Enable the proxy if true, all requests to external via HTTP will be affected, if false, no proxy will be used even environment http_proxy/https_proxy -- `PROXY_URL`: **\<empty\>**: Proxy server URL, support http://, https//, socks://, blank will follow environment http_proxy/https_proxy -- `PROXY_HOSTS`: **\<empty\>**: Comma separated list of host names requiring proxy. Glob patterns (*) are accepted; use ** to match all hosts. - -i.e. - -```ini -PROXY_ENABLED = true -PROXY_URL = socks://127.0.0.1:1080 -PROXY_HOSTS = *.github.com -``` - -## Actions (`actions`) - -- `ENABLED`: **false**: Enable/Disable actions capabilities -- `DEFAULT_ACTIONS_URL`: **github**: Default platform to get action plugins, `github` for `https://github.com`, `self` for the current Gitea instance. -- `STORAGE_TYPE`: **local**: Storage type for actions logs, `local` for local disk or `minio` for s3 compatible object storage service, default is `local` or other name defined with `[storage.xxx]` -- `MINIO_BASE_PATH`: **actions_log/**: Minio base path on the bucket only available when STORAGE_TYPE is `minio` - -`DEFAULT_ACTIONS_URL` indicates where the Gitea Actions runners should find the actions with relative path. -For example, `uses: actions/checkout@v3` means `https://github.com/actions/checkout@v3` since the value of `DEFAULT_ACTIONS_URL` is `github`. -And it can be changed to `self` to make it `root_url_of_your_gitea/actions/checkout@v3`. - -Please note that using `self` is not recommended for most cases, as it could make names globally ambiguous. -Additionally, it requires you to mirror all the actions you need to your Gitea instance, which may not be worth it. -Therefore, please use `self` only if you understand what you are doing. - -In earlier versions (<= 1.19), `DEFAULT_ACTIONS_URL` cound be set to any custom URLs like `https://gitea.com` or `http://your-git-server,https://gitea.com`, and the default value was `https://gitea.com`. -However, later updates removed those options, and now the only options are `github` and `self`, with the default value being `github`. -However, if you want to use actions from other git server, you can use a complete URL in `uses` field, it's supported by Gitea (but not GitHub). -Like `uses: https://gitea.com/actions/checkout@v3` or `uses: http://your-git-server/actions/checkout@v3`. - -## Other (`other`) - -- `SHOW_FOOTER_VERSION`: **true**: Show Gitea and Go version information in the footer. -- `SHOW_FOOTER_TEMPLATE_LOAD_TIME`: **true**: Show time of template execution in the footer. -- `ENABLE_SITEMAP`: **true**: Generate sitemap. -- `ENABLE_FEED`: **true**: Enable/Disable RSS/Atom feed. diff --git a/docs/content/doc/administration/config-cheat-sheet.zh-cn.md b/docs/content/doc/administration/config-cheat-sheet.zh-cn.md deleted file mode 100644 index d0af323dc0..0000000000 --- a/docs/content/doc/administration/config-cheat-sheet.zh-cn.md +++ /dev/null @@ -1,531 +0,0 @@ ---- -date: "2016-12-26T16:00:00+02:00" -title: "配置说明" -slug: "config-cheat-sheet" -weight: 30 -toc: false -draft: false -aliases: - - /zh-cn/config-cheat-sheet -menu: - sidebar: - parent: "administration" - name: "配置说明" - weight: 30 - identifier: "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: 的配置项表明除非你真的理解这个配置项的意义，否则最好使用默认值。 - -## ⚠️时效性警告⚠️ - -此文档的内容可能过于陈旧或者错误，请参考英文文档。 - -{{< toc >}} - -## 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`: **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` 时有效。 - -- `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`: 强制使用 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`: **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`: **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`。 -- `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的版本。 diff --git a/docs/content/doc/administration/customizing-gitea.en-us.md b/docs/content/doc/administration/customizing-gitea.en-us.md deleted file mode 100644 index ccc5c1bc89..0000000000 --- a/docs/content/doc/administration/customizing-gitea.en-us.md +++ /dev/null @@ -1,396 +0,0 @@ ---- -date: "2017-04-15T14:56:00+02:00" -title: "Customizing Gitea" -slug: "customizing-gitea" -weight: 100 -toc: false -draft: false -aliases: - - /en-us/customizing-gitea -menu: - sidebar: - parent: "administration" - name: "Customizing Gitea" - identifier: "customizing-gitea" - weight: 100 ---- - -# Customizing Gitea - -Customizing Gitea is typically done using the `CustomPath` folder - by default this is -the `custom` folder from the working directory (WorkPath), but may be different if your build has -set this differently. This is the central place to override configuration settings, -templates, etc. You can check the `CustomPath` using `gitea help`. You can also find -the path on the _Configuration_ tab in the _Site Administration_ page. You can override -the `CustomPath` by setting either the `GITEA_CUSTOM` environment variable or by -using the `--custom-path` option on the `gitea` binary. (The option will override the -environment variable.) - -If Gitea is deployed from binary, all default paths will be relative to the Gitea -binary. If installed from a distribution, these paths will likely be modified to -the Linux Filesystem Standard. Gitea will attempt to create required folders, including -`custom/`. Distributions may provide a symlink for `custom` using `/etc/gitea/`. - -Application settings can be found in file `CustomConf` which is by default, -`$GITEA_CUSTOM/conf/app.ini` but may be different if your build has set this differently. -Again `gitea help` will allow you review this variable and you can override it using the -`--config` option on the `gitea` binary. - -- [Quick Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/) -- [Complete List](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) - -If the `CustomPath` folder can't be found despite checking `gitea help`, check the `GITEA_CUSTOM` -environment variable; this can be used to override the default path to something else. -`GITEA_CUSTOM` might, for example, be set by an init script. You can check whether the value -is set under the "Configuration" tab on the site administration page. - -- [List of Environment Variables](https://docs.gitea.io/en-us/environment-variables/) - -**Note:** Gitea must perform a full restart to see configuration changes. - -**Table of Contents** - -{{< toc >}} - -## Serving custom public files - -To make Gitea serve custom public files (like pages and images), use the folder -`$GITEA_CUSTOM/public/` as the webroot. Symbolic links will be followed. -At the moment, only the following files are served: - -- `public/robots.txt` -- files in the `public/.well-known/` folder -- files in the `public/assets/` folder - -For example, a file `image.png` stored in `$GITEA_CUSTOM/public/assets/`, can be accessed with -the url `http://gitea.domain.tld/assets/image.png`. - -## Changing the logo - -To build a custom logo and/or favicon clone the Gitea source repository, replace `assets/logo.svg` and/or `assets/favicon.svg` and run -`make generate-images`. `assets/favicon.svg` is used for the favicon only. This will update below output files which you can then place in `$GITEA_CUSTOM/public/assets/img` on your server: - -- `public/assets/img/logo.svg` - Used for site icon, app icon -- `public/assets/img/logo.png` - Used for Open Graph -- `public/assets/img/avatar_default.png` - Used as the default avatar image -- `public/assets/img/apple-touch-icon.png` - Used on iOS devices for bookmarks -- `public/assets/img/favicon.svg` - Used for favicon -- `public/assets/img/favicon.png` - Used as fallback for browsers that don't support SVG favicons - -In case the source image is not in vector format, you can attempt to convert a raster image using tools like [this](https://www.aconvert.com/image/png-to-svg/). - -## Customizing Gitea pages and resources - -Gitea's executable contains all the resources required to run: templates, images, style-sheets -and translations. Any of them can be overridden by placing a replacement in a matching path -inside the `custom` directory. For example, to replace the default `.gitignore` provided -for C++ repositories, we want to replace `options/gitignore/C++`. To do this, a replacement -must be placed in `$GITEA_CUSTOM/options/gitignore/C++` (see about the location of the `CustomPath` -directory at the top of this document). - -Every single page of Gitea can be changed. Dynamic content is generated using [go templates](https://golang.org/pkg/html/template/), -which can be modified by placing replacements below the `$GITEA_CUSTOM/templates` directory. - -To obtain any embedded file (including templates), the [`gitea embedded` tool]({{< relref "doc/administration/cmd-embedded.en-us.md" >}}) can be used. Alternatively, they can be found in the [`templates`](https://github.com/go-gitea/gitea/tree/main/templates) directory of Gitea source (Note: the example link is from the `main` branch. Make sure to use templates compatible with the release you are using). - -Be aware that any statement contained inside `{{` and `}}` are Gitea's template syntax and -shouldn't be touched without fully understanding these components. - -### Customizing startpage / homepage - -Copy [`home.tmpl`](https://github.com/go-gitea/gitea/blob/main/templates/home.tmpl) for your version of Gitea from `templates` to `$GITEA_CUSTOM/templates`. -Edit as you wish. -Dont forget to restart your Gitea to apply the changes. - -### Adding links and tabs - -If all you want is to add extra links to the top navigation bar or footer, or extra tabs to the repository view, you can put them in `extra_links.tmpl` (links added to the navbar), `extra_links_footer.tmpl` (links added to the left side of footer), and `extra_tabs.tmpl` inside your `$GITEA_CUSTOM/templates/custom/` directory. - -For instance, let's say you are in Germany and must add the famously legally-required "Impressum"/about page, listing who is responsible for the site's content: -just place it under your "$GITEA_CUSTOM/public/assets/" directory (for instance `$GITEA_CUSTOM/public/assets/impressum.html`) and put a link to it in either `$GITEA_CUSTOM/templates/custom/extra_links.tmpl` or `$GITEA_CUSTOM/templates/custom/extra_links_footer.tmpl`. - -To match the current style, the link should have the class name "item", and you can use `{{AppSubUrl}}` to get the base URL: -`<a class="item" href="{{AppSubUrl}}/assets/impressum.html">Impressum</a>` - -For more information, see [Adding Legal Pages](https://docs.gitea.io/en-us/adding-legal-pages). - -You can add new tabs in the same way, putting them in `extra_tabs.tmpl`. -The exact HTML needed to match the style of other tabs is in the file -`templates/repo/header.tmpl` -([source in GitHub](https://github.com/go-gitea/gitea/blob/main/templates/repo/header.tmpl)) - -### Other additions to the page - -Apart from `extra_links.tmpl` and `extra_tabs.tmpl`, there are other useful templates you can put in your `$GITEA_CUSTOM/templates/custom/` directory: - -- `header.tmpl`, just before the end of the `<head>` tag where you can add custom CSS files for instance. -- `body_outer_pre.tmpl`, right after the start of `<body>`. -- `body_inner_pre.tmpl`, before the top navigation bar, but already inside the main container `<div class="full height">`. -- `body_inner_post.tmpl`, before the end of the main container. -- `body_outer_post.tmpl`, before the bottom `<footer>` element. -- `footer.tmpl`, right before the end of the `<body>` tag, a good place for additional JavaScript. - -#### Example: PlantUML - -You can add [PlantUML](https://plantuml.com/) support to Gitea's markdown by using a PlantUML server. -The data is encoded and sent to the PlantUML server which generates the picture. There is an online -demo server at http://www.plantuml.com/plantuml, but if you (or your users) have sensitive data you -can set up your own [PlantUML server](https://plantuml.com/server) instead. To set up PlantUML rendering, -copy JavaScript files from https://gitea.com/davidsvantesson/plantuml-code-highlight and put them in your -`$GITEA_CUSTOM/public/assets/` folder. Then add the following to `custom/footer.tmpl`: - -```html -<script> - $(async () => { - if (!$('.language-plantuml').length) return; - await Promise.all([ - $.getScript('https://your-gitea-server.com/assets/deflate.js'), - $.getScript('https://your-gitea-server.com/assets/encode.js'), - $.getScript('https://your-gitea-server.com/assets/plantuml_codeblock_parse.js'), - ]); - // Replace call with address to your plantuml server - parsePlantumlCodeBlocks("https://www.plantuml.com/plantuml"); - }); -</script> -``` - -You can then add blocks like the following to your markdown: - -```plantuml -Alice -> Bob: Authentication Request -Bob --> Alice: Authentication Response - -Alice -> Bob: Another authentication Request -Alice <-- Bob: Another authentication Response -``` - -The script will detect tags with `class="language-plantuml"`, but you can change this by providing a second argument to `parsePlantumlCodeBlocks`. - -#### Example: STL Preview - -You can display STL file directly in Gitea by adding: - -```html -<script> - function lS(src) { - return new Promise(function (resolve, reject) { - let s = document.createElement("script"); - s.src = src; - s.addEventListener("load", () => { - resolve(); - }); - document.body.appendChild(s); - }); - } - - if ($('.view-raw>a[href$=".stl" i]').length) { - $("body").append( - '<link href="/assets/Madeleine.js/src/css/Madeleine.css" rel="stylesheet">' - ); - Promise.all([ - lS("/assets/Madeleine.js/src/lib/stats.js"), - lS("/assets/Madeleine.js/src/lib/detector.js"), - lS("/assets/Madeleine.js/src/lib/three.min.js"), - lS("/assets/Madeleine.js/src/Madeleine.js"), - ]).then(function () { - $(".view-raw") - .attr("id", "view-raw") - .attr("style", "padding: 0;margin-bottom: -10px;"); - new Madeleine({ - target: "view-raw", - data: $('.view-raw>a[href$=".stl" i]').attr("href"), - path: "/assets/Madeleine.js/src", - }); - $('.view-raw>a[href$=".stl"]').remove(); - }); - } -</script> -``` - -to the file `templates/custom/footer.tmpl` - -You also need to download the content of the library [Madeleine.js](https://github.com/beige90/Madeleine.js) and place it under `$GITEA_CUSTOM/public/assets/` folder. - -You should end-up with a folder structure similar to: - -``` -$GITEA_CUSTOM/templates --- custom - `-- footer.tmpl - -$GITEA_CUSTOM/public/assets/ --- Madeleine.js - |-- LICENSE - |-- README.md - |-- css - | |-- pygment_trac.css - | `-- stylesheet.css - |-- examples - | |-- ajax.html - | |-- index.html - | `-- upload.html - |-- images - | |-- bg_hr.png - | |-- blacktocat.png - | |-- icon_download.png - | `-- sprite_download.png - |-- models - | |-- dino2.stl - | |-- ducati.stl - | |-- gallardo.stl - | |-- lamp.stl - | |-- octocat.stl - | |-- skull.stl - | `-- treefrog.stl - `-- src - |-- Madeleine.js - |-- css - | `-- Madeleine.css - |-- icons - | |-- logo.png - | |-- madeleine.eot - | |-- madeleine.svg - | |-- madeleine.ttf - | `-- madeleine.woff - `-- lib - |-- MadeleineConverter.js - |-- MadeleineLoader.js - |-- detector.js - |-- stats.js - `-- three.min.js -``` - -Then restart Gitea and open a STL file on your Gitea instance. - -## Customizing Gitea mails - -The `$GITEA_CUSTOM/templates/mail` folder allows changing the body of every mail of Gitea. -Templates to override can be found in the -[`templates/mail`](https://github.com/go-gitea/gitea/tree/main/templates/mail) -directory of Gitea source. -Override by making a copy of the file under `$GITEA_CUSTOM/templates/mail` using a -full path structure matching source. - -Any statement contained inside `{{` and `}}` are Gitea's template -syntax and shouldn't be touched without fully understanding these components. - -## Adding Analytics to Gitea - -Google Analytics, Matomo (previously Piwik), and other analytics services can be added to Gitea. To add the tracking code, refer to the `Other additions to the page` section of this document, and add the JavaScript to the `$GITEA_CUSTOM/templates/custom/header.tmpl` file. - -## Customizing gitignores, labels, licenses, locales, and readmes. - -Place custom files in corresponding sub-folder under `custom/options`. - -**NOTE:** The files should not have a file extension, e.g. `Labels` rather than `Labels.txt` - -### gitignores - -To add custom .gitignore, add a file with existing [.gitignore rules](https://git-scm.com/docs/gitignore) in it to `$GITEA_CUSTOM/options/gitignore` - -## Customizing the git configuration - -Starting with Gitea 1.20, you can customize the git configuration via the `git.config` section. - -### Enabling signed git pushes - -To enable signed git pushes, set these two options: - -```ini -[git.config] -receive.advertisePushOptions = true -receive.certNonceSeed = <randomstring> -``` - -`certNonceSeed` should be set to a random string and be kept secret. - -### Labels - -Starting with Gitea 1.19, you can add a file that follows the [YAML label format](https://github.com/go-gitea/gitea/blob/main/options/label/Advanced.yaml) to `$GITEA_CUSTOM/options/label`: - -```yaml -labels: - - name: "foo/bar" # name of the label that will appear in the dropdown - exclusive: true # whether to use the exclusive namespace for scoped labels. scoped delimiter is / - color: aabbcc # hex colour coding - description: Some label # long description of label intent - ``` - -The [legacy file format](https://github.com/go-gitea/gitea/blob/main/options/label/Default) can still be used following the format below, however we strongly recommend using the newer YAML format instead. - -`#hex-color label name ; label description` - -For more information, see the [labels documentation]({{< relref "doc/usage/labels.en-us.md" >}}). - -### Licenses - -To add a custom license, add a file with the license text to `$GITEA_CUSTOM/options/license` - -### Locales - -Locales are managed via our [Crowdin](https://crowdin.com/project/gitea). -You can override a locale by placing an altered locale file in `$GITEA_CUSTOM/options/locale`. -Gitea's default locale files can be found in the [`options/locale`](https://github.com/go-gitea/gitea/tree/main/options/locale) source folder and these should be used as examples for your changes. - -To add a completely new locale, as well as placing the file in the above location, you will need to add the new lang and name to the `[i18n]` section in your `app.ini`. Keep in mind that Gitea will use those settings as **overrides**, so if you want to keep the other languages as well you will need to copy/paste the default values and add your own to them. - -``` -[i18n] -LANGS = en-US,foo-BAR -NAMES = English,FooBar -``` - -The first locale will be used as the default if user browser's language doesn't match any locale in the list. - -Locales may change between versions, so keeping track of your customized locales is highly encouraged. - -### Readmes - -To add a custom Readme, add a markdown formatted file (without an `.md` extension) to `$GITEA_CUSTOM/options/readme` - -**NOTE:** readme templates support **variable expansion**. -currently there are `{Name}` (name of repository), `{Description}`, `{CloneURL.SSH}`, `{CloneURL.HTTPS}` and `{OwnerName}` - -### Reactions - -To change reaction emoji's you can set allowed reactions at app.ini - -``` -[ui] -REACTIONS = +1, -1, laugh, confused, heart, hooray, eyes -``` - -A full list of supported emoji's is at [emoji list](https://gitea.com/gitea/gitea.com/issues/8) - -## Customizing the look of Gitea - -The default built-in themes are `gitea` (light), `arc-green` (dark), and `auto` (chooses light or dark depending on operating system settings). -The default theme can be changed via `DEFAULT_THEME` in the [ui](https://docs.gitea.io/en-us/config-cheat-sheet/#ui-ui) section of `app.ini`. - -Gitea also has support for user themes, which means every user can select which theme should be used. -The list of themes a user can choose from can be configured with the `THEMES` value in the [ui](https://docs.gitea.io/en-us/config-cheat-sheet/#ui-ui) section of `app.ini`. - -To make a custom theme available to all users: - -1. Add a CSS file to `$GITEA_CUSTOM/public/assets/css/theme-<theme-name>.css`. - The value of `$GITEA_CUSTOM` of your instance can be queried by calling `gitea help` and looking up the value of "CustomPath". -2. Add `<theme-name>` to the comma-separated list of setting `THEMES` in `app.ini` - -Community themes are listed in [gitea/awesome-gitea#themes](https://gitea.com/gitea/awesome-gitea#themes). - -The `arc-green` theme source can be found [here](https://github.com/go-gitea/gitea/blob/main/web_src/css/themes/theme-arc-green.css). - -If your custom theme is considered a dark theme, set the global css variable `--is-dark-theme` to `true`. -This allows Gitea to adjust the Monaco code editor's theme accordingly. - -## Customizing fonts - -Fonts can be customized using CSS variables: - -```css -:root { - --fonts-proportional: /* custom proportional fonts */ !important; - --fonts-monospace: /* custom monospace fonts */ !important; - --fonts-emoji: /* custom emoji fonts */ !important; -} -``` diff --git a/docs/content/doc/administration/customizing-gitea.zh-cn.md b/docs/content/doc/administration/customizing-gitea.zh-cn.md deleted file mode 100644 index 64115ba178..0000000000 --- a/docs/content/doc/administration/customizing-gitea.zh-cn.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -date: "2017-04-15T14:56:00+02:00" -title: "自定义 Gitea 配置" -slug: "customizing-gitea" -weight: 100 -toc: false -draft: false -aliases: - - /zh-cn/customizing-gitea -menu: - sidebar: - parent: "administration" - name: "自定义 Gitea 配置" - weight: 100 - identifier: "customizing-gitea" ---- - -# 自定义 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/#ui-ui) 部分的 `DEFAULT_THEME` 的值来变更至一个可用的 Gitea 外观。 diff --git a/docs/content/doc/administration/email-setup.en-us.md b/docs/content/doc/administration/email-setup.en-us.md deleted file mode 100644 index 92ec95cce4..0000000000 --- a/docs/content/doc/administration/email-setup.en-us.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -date: "2019-10-15T10:10:00+05:00" -title: "Email setup" -slug: "email-setup" -weight: 12 -toc: false -draft: false -aliases: - - /en-us/email-setup -menu: - sidebar: - parent: "administration" - name: "Email setup" - weight: 12 - identifier: "email-setup" ---- - -# Email setup - -**Table of Contents** - -{{< toc >}} - -Gitea has mailer functionality for sending transactional emails (such as registration confirmation). It can be configured to either use Sendmail (or compatible MTAs like Postfix and msmtp) or directly use SMTP server. - -## Using Sendmail - -Use `sendmail` command as mailer. - -Note: For use in the official Gitea Docker image, please configure with the SMTP version (see the following section). - -Note: For Internet-facing sites consult documentation of your MTA for instructions to send emails over TLS. Also set up SPF, DMARC, and DKIM DNS records to make emails sent be accepted as legitimate by various email providers. - -```ini -[mailer] -ENABLED = true -FROM = gitea@mydomain.com -MAILER_TYPE = sendmail -SENDMAIL_PATH = /usr/sbin/sendmail -SENDMAIL_ARGS = "--" ; most "sendmail" programs take options, "--" will prevent an email address being interpreted as an option. -``` - -## Using SMTP - -Directly use SMTP server as relay. This option is useful if you don't want to set up MTA on your instance but you have an account at email provider. - -```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` -``` - -Restart Gitea for the configuration changes to take effect. - -To send a test email to validate the settings, go to Gitea > Site Administration > Configuration > SMTP Mailer Configuration. - -For the full list of options check the [Config Cheat Sheet]({{< relref "doc/administration/config-cheat-sheet.en-us.md" >}}) - -Please note: authentication is only supported when the SMTP server communication is encrypted with TLS or `HOST=localhost`. TLS encryption can be through: - -- STARTTLS (also known as Opportunistic TLS) via port 587. Initial connection is done over cleartext, but then be upgraded over TLS if the server supports it. -- SMTPS connection (SMTP over TLS) via the default port 465. Connection to the server use TLS from the beginning. -- Forced SMTPS connection with `IS_TLS_ENABLED=true`. (These are both known as Implicit TLS.) -This is due to protections imposed by the Go internal libraries against STRIPTLS attacks. - -Note that Implicit TLS is recommended by [RFC8314](https://tools.ietf.org/html/rfc8314#section-3) since 2018. - -### Gmail - -The following configuration should work with GMail's SMTP server: - -```ini -[mailer] -ENABLED = true -HOST = smtp.gmail.com:465 ; Remove this line for 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 -``` - -Note that you'll need to create and use an [App password](https://support.google.com/accounts/answer/185833?hl=en) by enabling 2FA on your Google -account. You won't be able to use your Google account password directly. diff --git a/docs/content/doc/administration/email-setup.zh-cn.md b/docs/content/doc/administration/email-setup.zh-cn.md deleted file mode 100644 index 0bbeebf2f6..0000000000 --- a/docs/content/doc/administration/email-setup.zh-cn.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -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 帐户密码。 diff --git a/docs/content/doc/administration/environment-variables.en-us.md b/docs/content/doc/administration/environment-variables.en-us.md deleted file mode 100644 index 261d1bea5f..0000000000 --- a/docs/content/doc/administration/environment-variables.en-us.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -date: "2017-04-08T11:34:00+02:00" -title: "Environment variables" -slug: "environment-variables" -weight: 10 -toc: false -draft: false -aliases: - - /en-us/environment-variables -menu: - sidebar: - parent: "administration" - name: "Environment variables" - weight: 10 - identifier: "environment-variables" ---- - -# Environment variables - -**Table of Contents** - -{{< toc >}} - -This is an inventory of Gitea environment variables. They change Gitea behaviour. - -Initialize them before Gitea command to be effective, for example: - -```sh -GITEA_CUSTOM=/home/gitea/custom ./gitea web -``` - -## From Go language - -As Gitea is written in Go, it uses some Go variables, such as: - -- `GOOS` -- `GOARCH` -- [`GOPATH`](https://golang.org/cmd/go/#hdr-GOPATH_environment_variable) - -For documentation about each of the variables available, refer to the -[official Go documentation](https://golang.org/cmd/go/#hdr-Environment_variables). - -## Gitea files - -- `GITEA_WORK_DIR`: Absolute path of working directory. -- `GITEA_CUSTOM`: Gitea uses `WorkPath`/custom folder by default. Use this variable to change _custom_ directory. - -## Operating system specifics - -- `USER`: System user that Gitea will run as. Used for some repository access strings. -- `USERNAME`: if no `USER` found, Gitea will use `USERNAME` -- `HOME`: User home directory path. The `USERPROFILE` environment variable is used in Windows. - -### Only on Windows - -- `USERPROFILE`: User home directory path. If empty, uses `HOMEDRIVE` + `HOMEPATH` -- `HOMEDRIVE`: Main drive path used to access the home directory (C:) -- `HOMEPATH`: Home relative path in the given home drive path - -## Miscellaneous - -- `SKIP_MINWINSVC`: If set to 1, do not run as a service on Windows. diff --git a/docs/content/doc/administration/environment-variables.zh-cn.md b/docs/content/doc/administration/environment-variables.zh-cn.md deleted file mode 100644 index cbc9787c35..0000000000 --- a/docs/content/doc/administration/environment-variables.zh-cn.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -date: "2017-04-08T11:34:00+02:00" -title: "环境变量清单" -slug: "environment-variables" -weight: 10 -toc: false -draft: false -aliases: - - /zh-cn/environment-variables -menu: - sidebar: - parent: "administration" - name: "环境变量清单" - weight: 10 - identifier: "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 的形式运行。 diff --git a/docs/content/doc/administration/external-renderers.en-us.md b/docs/content/doc/administration/external-renderers.en-us.md deleted file mode 100644 index 2de72c8343..0000000000 --- a/docs/content/doc/administration/external-renderers.en-us.md +++ /dev/null @@ -1,198 +0,0 @@ ---- -date: "2018-11-23:00:00+02:00" -title: "External renderers" -slug: "external-renderers" -weight: 60 -toc: false -draft: false -aliases: - - /en-us/external-renderers -menu: - sidebar: - parent: "administration" - name: "External renderers" - weight: 60 - identifier: "external-renderers" ---- - -# Custom files rendering configuration - -**Table of Contents** - -{{< toc >}} - -Gitea supports custom file renderings (i.e., Jupyter notebooks, asciidoc, etc.) through external binaries, -it is just a matter of: - -- installing external binaries -- add some configuration to your `app.ini` file -- restart your Gitea instance - -This supports rendering of whole files. If you want to render code blocks in markdown you would need to do something with javascript. See some examples on the [Customizing Gitea](../customizing-gitea) page. - -## Installing external binaries - -In order to get file rendering through external binaries, their associated packages must be installed. -If you're using a Docker image, your `Dockerfile` should contain something along this lines: - -```docker -FROM 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 -# install any other package you need for your external renderers - -RUN pip3 install --upgrade pip -RUN pip3 install -U setuptools -RUN pip3 install jupyter docutils -# add above any other python package you may need to install -``` - -## `app.ini` file configuration - -add one `[markup.XXXXX]` section per external renderer on your custom `app.ini`: - -```ini -[markup.asciidoc] -ENABLED = true -FILE_EXTENSIONS = .adoc,.asciidoc -RENDER_COMMAND = "asciidoctor -s -a showtitle --out-file=- -" -; Input is not a standard input but a file -IS_INPUT_FILE = false - -[markup.jupyter] -ENABLED = true -FILE_EXTENSIONS = .ipynb -RENDER_COMMAND = "jupyter nbconvert --stdin --stdout --to html --template basic" -IS_INPUT_FILE = false - -[markup.restructuredtext] -ENABLED = true -FILE_EXTENSIONS = .rst -RENDER_COMMAND = "timeout 30s pandoc +RTS -M512M -RTS -f rst" -IS_INPUT_FILE = false -``` - -If your external markup relies on additional classes and attributes on the generated HTML elements, you might need to enable custom sanitizer policies. Gitea uses the [`bluemonday`](https://godoc.org/github.com/microcosm-cc/bluemonday) package as our HTML sanitizer. The example below could be used to support server-side [KaTeX](https://katex.org/) rendering output from [`pandoc`](https://pandoc.org/). - -```ini -[markup.sanitizer.TeX] -; Pandoc renders TeX segments as <span>s with the "math" class, optionally -; with "inline" or "display" classes depending on context. -; - note this is different from the built-in math support in our markdown parser which uses <code> -ELEMENT = span -ALLOW_ATTR = class -REGEXP = ^\s*((math(\s+|$)|inline(\s+|$)|display(\s+|$)))+ - -[markup.markdown] -ENABLED = true -FILE_EXTENSIONS = .md,.markdown -RENDER_COMMAND = pandoc -f markdown -t html --katex -``` - -You must define `ELEMENT` and `ALLOW_ATTR` in each section. - -To define multiple entries, add a unique alphanumeric suffix (e.g., `[markup.sanitizer.1]` and `[markup.sanitizer.something]`). - -To apply a sanitisation rules only for a specify external renderer they must use the renderer name, e.g. `[markup.sanitizer.asciidoc.rule-1]`, `[markup.sanitizer.<renderer>.rule-1]`. - -**Note**: If the rule is defined above the renderer ini section or the name does not match a renderer it is applied to every renderer. - -Once your configuration changes have been made, restart Gitea to have changes take effect. - -**Note**: Prior to Gitea 1.12 there was a single `markup.sanitiser` section with keys that were redefined for multiple rules, however, -there were significant problems with this method of configuration necessitating configuration through multiple sections. - -### Example: HTML - -Render HTML files directly: - -```ini -[markup.html] -ENABLED = true -FILE_EXTENSIONS = .html,.htm -RENDER_COMMAND = cat -; Input is not a standard input but a file -IS_INPUT_FILE = true - -[markup.sanitizer.html.1] -ELEMENT = div -ALLOW_ATTR = class - -[markup.sanitizer.html.2] -ELEMENT = a -ALLOW_ATTR = class -``` - -### Example: Office DOCX - -Display Office DOCX files with [`pandoc`](https://pandoc.org/): - -```ini -[markup.docx] -ENABLED = true -FILE_EXTENSIONS = .docx -RENDER_COMMAND = "pandoc --from docx --to html --self-contained --template /path/to/basic.html" - -[markup.sanitizer.docx.img] -ALLOW_DATA_URI_IMAGES = true -``` - -The template file has the following content: - -``` -$body$ -``` - -### Example: Jupyter Notebook - -Display Jupyter Notebook files with [`nbconvert`](https://github.com/jupyter/nbconvert): - -```ini -[markup.jupyter] -ENABLED = true -FILE_EXTENSIONS = .ipynb -RENDER_COMMAND = "jupyter-nbconvert --stdin --stdout --to html --template basic" - -[markup.sanitizer.jupyter.img] -ALLOW_DATA_URI_IMAGES = true -``` - -## Customizing CSS - -The external renderer is specified in the .ini in the format `[markup.XXXXX]` and the HTML supplied by your external renderer will be wrapped in a `<div>` with classes `markup` and `XXXXX`. The `markup` class provides out of the box styling (as does `markdown` if `XXXXX` is `markdown`). Otherwise you can use these classes to specifically target the contents of your rendered HTML. - -And so you could write some CSS: - -```css -.markup.XXXXX html { - font-size: 100%; - overflow-y: scroll; - -webkit-text-size-adjust: 100%; - -ms-text-size-adjust: 100%; -} - -.markup.XXXXX body { - color: #444; - font-family: Georgia, Palatino, 'Palatino Linotype', Times, 'Times New Roman', serif; - font-size: 12px; - line-height: 1.7; - padding: 1em; - margin: auto; - max-width: 42em; - background: #fefefe; -} - -.markup.XXXXX p { - color: orangered; -} -``` - -Add your stylesheet to your custom directory e.g `custom/public/assets/css/my-style-XXXXX.css` and import it using a custom header file `custom/templates/custom/header.tmpl`: - -```html -<link rel="stylesheet" href="{{AppSubUrl}}/assets/css/my-style-XXXXX.css" /> -``` diff --git a/docs/content/doc/administration/external-renderers.zh-cn.md b/docs/content/doc/administration/external-renderers.zh-cn.md deleted file mode 100644 index 26d3fb45d3..0000000000 --- a/docs/content/doc/administration/external-renderers.zh-cn.md +++ /dev/null @@ -1,207 +0,0 @@ ---- -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 样式应用到特定的外部渲染器，使其具有所需的样式效果。 diff --git a/docs/content/doc/administration/fail2ban-setup.en-us.md b/docs/content/doc/administration/fail2ban-setup.en-us.md deleted file mode 100644 index 1638e0dd1f..0000000000 --- a/docs/content/doc/administration/fail2ban-setup.en-us.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -date: "2018-05-11T11:00:00+02:00" -title: "Fail2ban Setup " -slug: "fail2ban-setup" -weight: 16 -toc: false -draft: false -aliases: - - /en-us/fail2ban-setup -menu: - sidebar: - parent: "administration" - name: "Fail2ban setup" - weight: 16 - identifier: "fail2ban-setup" ---- - -# Fail2ban setup to block users after failed login attempts - -**Remember that fail2ban is powerful and can cause lots of issues if you do it incorrectly, so make -sure to test this before relying on it so you don't lock yourself out.** - -Gitea returns an HTTP 200 for bad logins in the web logs, but if you have logging options on in -`app.ini`, then you should be able to go off of `log/gitea.log`, which gives you something like this -on a bad authentication from the web or CLI using SSH or HTTP respectively: - -```log -2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx -``` - -```log -2020/10/15 16:05:09 modules/ssh/ssh.go:143:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx -``` - -(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.) - -```log -2020/10/15 16:05:09 modules/ssh/ssh.go:155:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx -``` - -(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.) - -```log -2020/10/15 16:05:09 modules/ssh/ssh.go:198:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx -``` - -(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.) - -```log -2020/10/15 16:05:09 modules/ssh/ssh.go:213:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx -``` - -(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.) - -```log -2020/10/15 16:05:09 modules/ssh/ssh.go:227:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx -``` - -(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.) - -```log -2020/10/15 16:05:09 modules/ssh/ssh.go:249:sshConnectionFailed() [W] Failed authentication attempt from xxx.xxx.xxx.xxx -``` - -(From 1.15 this new message will available and doesn't have any of the false positive results that above messages from publicKeyHandler do. This will only be logged if the user has completely failed authentication.) - -```log -2020/10/15 16:08:44 ...s/context/context.go:204:HandleText() [E] invalid credentials from xxx.xxx.xxx.xxx -``` - -Add our filter in `/etc/fail2ban/filter.d/gitea.conf`: - -```ini -# gitea.conf -[Definition] -failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST> -ignoreregex = -``` - -Add our jail in `/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 -``` - -If you're using Docker, you'll also need to add an additional jail to handle the **FORWARD** -chain in **iptables**. Configure it in `/etc/fail2ban/jail.d/gitea-docker.conf`: - -```ini -[gitea-docker] -enabled = true -filter = gitea -logpath = /var/lib/gitea/log/gitea.log -maxretry = 10 -findtime = 3600 -bantime = 900 -action = iptables-allports[chain="FORWARD"] -``` - -Then simply run `service fail2ban restart` to apply your changes. You can check to see if -fail2ban has accepted your configuration using `service fail2ban status`. - -Make sure and read up on fail2ban and configure it to your needs, this bans someone -for **15 minutes** (from all ports) when they fail authentication 10 times in an hour. - -If you run Gitea behind a reverse proxy with Nginx (for example with Docker), you need to add -this to your Nginx configuration so that IPs don't show up as 127.0.0.1: - -``` -proxy_set_header X-Real-IP $remote_addr; -``` - -The security options in `app.ini` need to be adjusted to allow the interpretation of the headers -as well as the list of IP addresses and networks that describe trusted proxy servers -(See the [configuration cheat sheet](https://docs.gitea.io/en-us/config-cheat-sheet/#security-security) for more information). - -``` -REVERSE_PROXY_LIMIT = 1 -REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.1/8 ; 172.17.0.0/16 for the docker default network -``` diff --git a/docs/content/doc/administration/fail2ban-setup.zh-cn.md b/docs/content/doc/administration/fail2ban-setup.zh-cn.md deleted file mode 100644 index f4f3cff4ca..0000000000 --- a/docs/content/doc/administration/fail2ban-setup.zh-cn.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -date: "2022-08-01T00:00:00+00:00" -title: "设置 Fail2ban" -slug: "fail2ban-setup" -weight: 16 -toc: false -draft: false -aliases: - - /zh-cn/fail2ban-setup -menu: - sidebar: - parent: "administration" - name: "设置 Fail2ban" - weight: 16 - identifier: "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](https://docs.gitea.io/en-us/config-cheat-sheet/#security-security)） diff --git a/docs/content/doc/administration/git-lfs-support.en-us.md b/docs/content/doc/administration/git-lfs-support.en-us.md deleted file mode 100644 index 884b19896a..0000000000 --- a/docs/content/doc/administration/git-lfs-support.en-us.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -date: "2019-10-06T08:00:00+05:00" -title: "Git LFS setup" -slug: "git-lfs-setup" -weight: 12 -toc: false -draft: false -aliases: - - /en-us/git-lfs-setup -menu: - sidebar: - parent: "administration" - name: "Git LFS setup" - weight: 12 - identifier: "git-lfs-setup" ---- - -# Git Large File Storage setup - -To use Gitea's built-in LFS support, you must update the `app.ini` file: - -```ini -[server] -; Enables git-lfs support. true or false, default is false. -LFS_START_SERVER = true - -[lfs] -; Where your lfs files reside, default is data/lfs. -PATH = /home/gitea/data/lfs -``` - -**Note**: LFS server support needs at least Git v2.1.2 installed on the server diff --git a/docs/content/doc/administration/git-lfs-support.zh-cn.md b/docs/content/doc/administration/git-lfs-support.zh-cn.md deleted file mode 100644 index 247e9a4777..0000000000 --- a/docs/content/doc/administration/git-lfs-support.zh-cn.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -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 以上版本。 diff --git a/docs/content/doc/administration/https-support.en-us.md b/docs/content/doc/administration/https-support.en-us.md deleted file mode 100644 index d59ae2e8ee..0000000000 --- a/docs/content/doc/administration/https-support.en-us.md +++ /dev/null @@ -1,104 +0,0 @@ ---- -date: "2018-06-02T11:00:00+02:00" -title: "HTTPS setup" -slug: "https-setup" -weight: 12 -toc: false -draft: false -aliases: - - /en-us/https-setup -menu: - sidebar: - parent: "administration" - name: "HTTPS setup" - weight: 12 - identifier: "https-setup" ---- - -# HTTPS setup to encrypt connections to Gitea - -**Table of Contents** - -{{< toc >}} - -## Using the built-in server - -Before you enable HTTPS, make sure that you have valid SSL/TLS certificates. -You could use self-generated certificates for evaluation and testing. Please run `gitea cert --host [HOST]` to generate a self signed certificate. - -If you are using Apache or nginx on the server, it's recommended to check the [reverse proxy guide]({{< relref "doc/administration/reverse-proxies.en-us.md" >}}). - -To use Gitea's built-in HTTPS support, you must change your `app.ini` file: - -```ini -[server] -PROTOCOL = https -ROOT_URL = https://git.example.com:3000/ -HTTP_PORT = 3000 -CERT_FILE = cert.pem -KEY_FILE = key.pem -``` - -Note that if your certificate is signed by a third party certificate authority (i.e. not self-signed), then cert.pem should contain the certificate chain. The server certificate must be the first entry in cert.pem, followed by the intermediaries in order (if any). The root certificate does not have to be included because the connecting client must already have it in order to estalbish the trust relationship. -To learn more about the config values, please checkout the [Config Cheat Sheet](../config-cheat-sheet#server-server). - -For the `CERT_FILE` or `KEY_FILE` field, the file path is relative to the `GITEA_CUSTOM` environment variable when it is a relative path. It can be an absolute path as well. - -### Setting up HTTP redirection - -The Gitea server is only able to listen to one port; to redirect HTTP requests to the HTTPS port, you will need to enable the HTTP redirection service: - -```ini -[server] -REDIRECT_OTHER_PORT = true -; Port the redirection service should listen on -PORT_TO_REDIRECT = 3080 -``` - -If you are using Docker, make sure that this port is configured in your `docker-compose.yml` file. - -## Using ACME (Default: Let's Encrypt) - -[ACME](https://tools.ietf.org/html/rfc8555) is a Certificate Authority standard protocol that allows you to automatically request and renew SSL/TLS certificates. [Let's Encrypt](https://letsencrypt.org/) is a free publicly trusted Certificate Authority server using this standard. Only `HTTP-01` and `TLS-ALPN-01` challenges are implemented. In order for ACME challenges to pass and verify your domain ownership, external traffic to the gitea domain on port `80` (`HTTP-01`) or port `443` (`TLS-ALPN-01`) has to be served by the gitea instance. Setting up [HTTP redirection](#setting-up-http-redirection) and port-forwards might be needed for external traffic to route correctly. Normal traffic to port `80` will otherwise be automatically redirected to HTTPS. **You must consent** to the ACME provider's terms of service (default Let's Encrypt's [terms of service](https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf)). - -Minimum setup using the default 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 -``` - -Minimum setup using a [smallstep CA](https://github.com/smallstep/certificates), refer to [their tutorial](https://smallstep.com/docs/tutorials/acme-challenge) for more information. - -```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 -``` - -To learn more about the config values, please checkout the [Config Cheat Sheet](../config-cheat-sheet#server-server). - -## Using a reverse proxy - -Setup up your reverse proxy as shown in the [reverse proxy guide](../reverse-proxies). - -After that, enable HTTPS by following one of these guides: - -- [nginx](https://nginx.org/en/docs/http/configuring_https_servers.html) -- [apache2/httpd](https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html) -- [caddy](https://caddyserver.com/docs/tls) - -Note: Enabling HTTPS only at the proxy level is referred as [TLS Termination Proxy](https://en.wikipedia.org/wiki/TLS_termination_proxy). The proxy server accepts incoming TLS connections, decrypts the contents, and passes the now unencrypted contents to Gitea. This is normally fine as long as both the proxy and Gitea instances are either on the same machine, or on different machines within private network (with the proxy is exposed to outside network). If your Gitea instance is separated from your proxy over a public network, or if you want full end-to-end encryption, you can also [enable HTTPS support directly in Gitea using built-in server](#using-the-built-in-server) and forward the connections over HTTPS instead. diff --git a/docs/content/doc/administration/https-support.zh-cn.md b/docs/content/doc/administration/https-support.zh-cn.md deleted file mode 100644 index c67776b9e6..0000000000 --- a/docs/content/doc/administration/https-support.zh-cn.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -date: "2023-04-09T11:00:00+02:00" -title: "HTTPS配置" -slug: "https-setup" -weight: 12 -toc: false -draft: false -menu: - sidebar: - parent: "administration" - name: "HTTPS setup" - weight: 12 - identifier: "https-setup" ---- - -# HTTPS setup to encrypt connections to Gitea - -**Table of Contents** - -{{< toc >}} - -## 使用内置服务器 - -在启用HTTPS之前，确保您拥有有效的SSL/TLS证书。 -建议在测试和评估情况下使用自签名证书，请运行 `gitea cert --host [HOST]` 以生成自签名证书 - -如果您在服务器上使用阿帕奇（Apache）或Nginx，建议参考 [反向代理指南]({{< relref "doc/administration/reverse-proxies.zh-cn.md" >}})。 - -要使用Gitea内置HTTPS支持，您必须编辑`app.ini`文件。 - -```ini -[server] -PROTOCOL = https -ROOT_URL = https://git.example.com:3000/ -HTTP_PORT = 3000 -CERT_FILE = cert.pem -KEY_FILE = key.pem -``` - -请注意，如果您的证书由第三方证书颁发机构签名（即不是自签名的），则 cert.pem 应包含证书链。服务器证书必须是 cert.pem 中的第一个条目，后跟中介（如果有）。不必包含根证书，因为连接客户端必须已经拥有根证书才能建立信任关系。要了解有关配置值的更多信息，请查看 [配置备忘单](../config-cheat-sheet#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 -``` - -要了解关于配置, 请访问 [配置备忘单](../config-cheat-sheet#server-server)获取更多信息 - -## 使用反向代理服务器 - -按照 [reverse proxy guide](../reverse-proxies) 的规则设置你的反向代理服务器 - -然后，按照下面的向导启用 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 上。 diff --git a/docs/content/doc/administration/logging-config.en-us.md b/docs/content/doc/administration/logging-config.en-us.md deleted file mode 100644 index 857eb19b56..0000000000 --- a/docs/content/doc/administration/logging-config.en-us.md +++ /dev/null @@ -1,295 +0,0 @@ ---- -date: "2019-04-02T17:06:00+01:00" -title: "Logging Configuration" -slug: "logging-config" -weight: 40 -toc: false -draft: false -aliases: - - /en-us/logging-configuration -menu: - sidebar: - parent: "administration" - name: "Logging Configuration" - weight: 40 - identifier: "logging-config" ---- - -# Logging Configuration - -The logging configuration of Gitea mainly consists of 3 types of components: - -- The `[log]` section for general configuration -- `[log.<mode-name>]` sections for the configuration of different log writers to output logs, aka: "writer mode", the mode name is also used as "writer name". -- The `[log]` section can also contain sub-logger configurations following the key schema `logger.<logger-name>.<CONFIG-KEY>` - -There is a fully functional log output by default, so it is not necessary to define one. - -**Table of Contents** - -{{< toc >}} - -## Collecting Logs for Help - -To collect logs for help and issue report, see [Support Options]({{< relref "doc/help/support.en-us.md" >}}). - -## The `[log]` section - -Configuration of logging facilities in Gitea happen in the `[log]` section and its subsections. - -In the top level `[log]` section the following configurations can be placed: - -- `ROOT_PATH`: (Default: **%(GITEA_WORK_DIR)/log**): Base path for log files -- `MODE`: (Default: **console**) List of log outputs to use for the Default logger. -- `LEVEL`: (Default: **Info**) Least severe log events to persist, case-insensitive. Possible values are: `Trace`, `Debug`, `Info`, `Warn`, `Error`, `Fatal`. -- `STACKTRACE_LEVEL`: (Default: **None**) For this and more severe events the stacktrace will be printed upon getting logged. - -And it can contain the following sub-loggers: - -- `logger.router.MODE`: (Default: **,**): List of log outputs to use for the Router logger. -- `logger.access.MODE`: (Default: **\<empty\>**) List of log outputs to use for the Access logger. By default, the access logger is disabled. -- `logger.xorm.MODE`: (Default: **,**) List of log outputs to use for the XORM logger. - -Setting a comma (`,`) to sub-logger's mode means making it use the default global `MODE`. - -## Quick samples - -### Default (empty) Configuration - -The empty configuration is equivalent to default: - -```ini -[log] -ROOT_PATH = %(GITEA_WORK_DIR)/log -MODE = console -LEVEL = Info -STACKTRACE_LEVEL = None -logger.router.MODE = , -logger.xorm.MODE = , -logger.access.MODE = - -; this is the config options of "console" mode (used by MODE=console above) -[log.console] -MODE = console -FLAGS = stdflags -PREFIX = -COLORIZE = true -``` - -This is equivalent to sending all logs to the console, with default Golang log being sent to the console log too. - -This is only a sample, and it is the default, do not need to write it into your configuration file. - -### Disable Router logs and record some access logs to file - -The Router logger is disabled, the access logs (>=Warn) goes into `access.log`: - -```ini -[log] -logger.router.MODE = -logger.access.MODE = access-file - -[log.access-file] -MODE = file -LEVEL = Warn -FILE_NAME = access.log -``` - -### Set different log levels for different modes - -Default logs (>=Warn) goes into `gitea.log`, while Error logs goes into `file-error.log`: - -```ini -[log] -LEVEL = Warn -MODE = file, file-error - -; by default, the "file" mode will record logs to %(log.ROOT_PATH)/gitea.log, so we don't need to set it -; [log.file] - -[log.file-error] -LEVEL = Error -FILE_NAME = file-error.log -``` - -## Log outputs (mode and writer) - -Gitea provides the following log output writers: - -- `console` - Log to `stdout` (or `stderr` if it is set in the config) -- `file` - Log to a file -- `conn` - Log to a socket (network or unix) - -### Common configuration - -Certain configuration is common to all modes of log output: - -- `MODE` is the mode of the log output writer. It will default to the mode name in the ini section. Thus `[log.console]` will default to `MODE = console`. -- `LEVEL` is the lowest level that this output will log. -- `STACKTRACE_LEVEL` is the lowest level that this output will print a stacktrace. -- `COLORIZE` will default to `true` for `console` as described, otherwise it will default to `false`. - -#### `EXPRESSION` - -`EXPRESSION` represents a regular expression that log events must match to be logged by the output writer. -Either the log message, (with colors removed), must match or the `longfilename:linenumber:functionname` must match. -NB: the whole message or string doesn't need to completely match. - -Please note this expression will be run in the writer's goroutine but not the logging event goroutine. - -#### `FLAGS` - -`FLAGS` represents the preceding logging context information that is -printed before each message. It is a comma-separated string set. The order of values does not matter. - -It defaults to `stdflags` (= `date,time,medfile,shortfuncname,levelinitial`) - -Possible values are: - -- `none` or `,` - No flags. -- `date` - the date in the local time zone: `2009/01/23`. -- `time` - the time in the local time zone: `01:23:23`. -- `microseconds` - microsecond resolution: `01:23:23.123123`. Assumes time. -- `longfile` - full file name and line number: `/a/b/c/d.go:23`. -- `shortfile` - final file name element and line number: `d.go:23`. -- `funcname` - function name of the caller: `runtime.Caller()`. -- `shortfuncname` - last part of the function name. Overrides `funcname`. -- `utc` - if date or time is set, use UTC rather than the local time zone. -- `levelinitial` - initial character of the provided level in brackets eg. `[I]` for info. -- `level` - level in brackets `[INFO]`. -- `gopid` - the Goroutine-PID of the context. -- `medfile` - last 20 characters of the filename - equivalent to `shortfile,longfile`. -- `stdflags` - equivalent to `date,time,medfile,shortfuncname,levelinitial`. - -### Console mode - -In this mode the logger will forward log messages to the stdout and -stderr streams attached to the Gitea process. - -For loggers in console mode, `COLORIZE` will default to `true` if not -on windows, or the Windows terminal can be set into ANSI mode or is a -cygwin or Msys pipe. - -Settings: - -- `STDERR`: **false**: Whether the logger should print to `stderr` instead of `stdout`. - -### File mode - -In this mode the logger will save log messages to a file. - -Settings: - -- `FILE_NAME`: The file to write the log events to, relative to `ROOT_PATH`, Default to `%(ROOT_PATH)/gitea.log`. Exception: access log will default to `%(ROOT_PATH)/access.log`. -- `MAX_SIZE_SHIFT`: **28**: Maximum size shift of a single file. 28 represents 256Mb. For details see below. -- `LOG_ROTATE` **true**: Whether to rotate the log files. TODO: if false, will it delete instead on daily rotate, or do nothing?. -- `DAILY_ROTATE`: **true**: Whether to rotate logs daily. -- `MAX_DAYS`: **7**: Delete rotated log files after this number of days. -- `COMPRESS`: **true**: Whether to compress old log files by default with gzip. -- `COMPRESSION_LEVEL`: **-1**: Compression level. For details see below. - -`MAX_SIZE_SHIFT` defines the maximum size of a file by left shifting 1 the given number of times (`1 << x`). -The exact behavior at the time of v1.17.3 can be seen [here](https://github.com/go-gitea/gitea/blob/v1.17.3/modules/setting/log.go#L185). - -The useful values of `COMPRESSION_LEVEL` are from 1 to (and including) 9, where higher numbers mean better compression. -Beware that better compression might come with higher resource usage. -Must be preceded with a `-` sign. - -### Conn mode - -In this mode the logger will send log messages over a network socket. - -Settings: - -- `ADDR`: **:7020**: Sets the address to connect to. -- `PROTOCOL`: **tcp**: Set the protocol, either "tcp", "unix" or "udp". -- `RECONNECT`: **false**: Try to reconnect when connection is lost. -- `RECONNECT_ON_MSG`: **false**: Reconnect host for every single message. - -### The "Router" logger - -The Router logger logs the following message types when Gitea's route handlers work: - -- `started` messages will be logged at TRACE level -- `polling`/`completed` routers will be logged at INFO. Exception: "/assets" static resource requests are also logged at TRACE. -- `slow` routers will be logged at WARN -- `failed` routers will be logged at WARN - -### The "XORM" logger - -To make XORM outputs SQL logs, the `LOG_SQL` in `[database]` section should also be set to `true`. - -### The "Access" logger - -The Access logger is a new logger since Gitea 1.9. It provides a NCSA -Common Log compliant log format. It's highly configurable but caution -should be taken when changing its template. The main benefit of this -logger is that Gitea can now log accesses in a standard log format so -standard tools may be used. - -You can enable this logger using `logger.access.MODE = ...`. - -If desired the format of the Access logger can be changed by changing -the value of the `ACCESS_LOG_TEMPLATE`. - -Please note, the access logger will log at `INFO` level, setting the -`LEVEL` of this logger to `WARN` or above will result in no access logs. - -#### The ACCESS_LOG_TEMPLATE - -This value represents a go template. Its default value is - -```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}}"` -``` - -The template is passed following options: - -- `Ctx` is the `context.Context` -- `Identity` is the `SignedUserName` or `"-"` if the user is not logged in -- `Start` is the start time of the request -- `ResponseWriter` is the `http.ResponseWriter` - -Caution must be taken when changing this template as it runs outside of -the standard panic recovery trap. The template should also be as simple -as it runs for every request. - -## Releasing-and-Reopening, Pausing and Resuming logging - -If you are running on Unix you may wish to release-and-reopen logs in order to use `logrotate` or other tools. -It is possible force Gitea to release and reopen it's logging files and connections by sending `SIGUSR1` to the -running process, or running `gitea manager logging release-and-reopen`. - -Alternatively, you may wish to pause and resume logging - this can be accomplished through the use of the -`gitea manager logging pause` and `gitea manager logging resume` commands. Please note that whilst logging -is paused log events below INFO level will not be stored and only a limited number of events will be stored. -Logging may block, albeit temporarily, slowing Gitea considerably whilst paused - therefore it is -recommended that pausing only done for a very short period of time. - -## Adding and removing logging whilst Gitea is running - -It is possible to add and remove logging whilst Gitea is running using the `gitea manager logging add` and `remove` subcommands. -This functionality can only adjust running log systems and cannot be used to start the access or router loggers if they -were not already initialized. If you wish to start these systems you are advised to adjust the app.ini and (gracefully) restart -the Gitea service. - -The main intention of these commands is to easily add a temporary logger to investigate problems on running systems where a restart -may cause the issue to disappear. - -## Using `logrotate` instead of built-in log rotation - -Gitea includes built-in log rotation, which should be enough for most deployments. However, if you instead want to use the `logrotate` utility: - -- Disable built-in log rotation by setting `LOG_ROTATE` to `false` in your `app.ini`. -- Install `logrotate`. -- Configure `logrotate` to match your deployment requirements, see `man 8 logrotate` for configuration syntax details. - In the `postrotate/endscript` block send Gitea a `USR1` signal via `kill -USR1` or `kill -10` to the `gitea` process itself, - or run `gitea manager logging release-and-reopen` (with the appropriate environment). - Ensure that your configurations apply to all files emitted by Gitea loggers as described in the above sections. -- Always do `logrotate /etc/logrotate.conf --debug` to test your configurations. -- If you are using docker and are running from outside the container you can use - `docker exec -u $OS_USER $CONTAINER_NAME sh -c 'gitea manager logging release-and-reopen'` - or `docker exec $CONTAINER_NAME sh -c '/bin/s6-svc -1 /etc/s6/gitea/'` or send `USR1` directly to the Gitea process itself. - -The next `logrotate` jobs will include your configurations, so no restart is needed. -You can also immediately reload `logrotate` with `logrotate /etc/logrotate.conf --force`. diff --git a/docs/content/doc/administration/logging-config.zh-cn.md b/docs/content/doc/administration/logging-config.zh-cn.md deleted file mode 100644 index 1edf1443cd..0000000000 --- a/docs/content/doc/administration/logging-config.zh-cn.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -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 >}} - -## 收集日志以获取帮助 - -要收集日志以获取帮助和报告问题，请参阅 [需要帮助]({{< relref "doc/help/support.zh-cn.md" >}})。 - -## `[log]` 部分 - -在 Gitea 中，日志设施的配置在 `[log]` 部分及其子部分。 - -在顶层的 `[log]` 部分，可以放置以下配置项： - -- `ROOT_PATH`：（默认值：**%(GITEA_WORK_DIR)/log**）：日志文件的基本路径。 -- `MODE`：（默认值：**console**）：要用于默认日志记录器的日志输出列表。 -- `LEVEL`：（默认值：**Info**）：要持久化的最严重的日志事件，不区分大小写。可能的值为：`Trace`、`Debug`、`Info`、`Warn`、`Error`、`Fatal`。 -- `STACKTRACE_LEVEL`：（默认值：**None**）：对于此类及更严重的事件，将在记录时打印堆栈跟踪。 - -它还可以包含以下子日志记录器： - -- `logger.router.MODE`：（默认值：**,**）：用于路由器日志记录器的日志输出列表。 -- `logger.access.MODE`：（默认值：**\<empty\>**）：用于访问日志记录器的日志输出列表。默认情况下，访问日志记录器被禁用。 -- `logger.xorm.MODE`：（默认值：**,**）：用于 XORM 日志记录器的日志输出列表。 - -将子日志记录器的模式设置为逗号（`,`）表示使用默认的全局 `MODE`。 - -## 快速示例 - -### 默认（空）配置 - -空配置等同于默认配置： - -```ini -[log] -ROOT_PATH = %(GITEA_WORK_DIR)/log -MODE = console -LEVEL = Info -STACKTRACE_LEVEL = None -logger.router.MODE = , -logger.xorm.MODE = , -logger.access.MODE = - -; 这是“控制台”模式的配置选项（由上面的 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`。 diff --git a/docs/content/doc/administration/mail-templates.en-us.md b/docs/content/doc/administration/mail-templates.en-us.md deleted file mode 100644 index 0740ccaa5f..0000000000 --- a/docs/content/doc/administration/mail-templates.en-us.md +++ /dev/null @@ -1,282 +0,0 @@ ---- -date: "2019-10-23T17:00:00-03:00" -title: "Mail templates" -slug: "mail-templates" -weight: 45 -toc: false -draft: false -aliases: - - /en-us/mail-templates -menu: - sidebar: - parent: "administration" - name: "Mail templates" - weight: 45 - identifier: "mail-templates" ---- - -# Mail templates - -**Table of Contents** - -{{< toc >}} - -To craft the e-mail subject and contents for certain operations, Gitea can be customized by using templates. The templates -for these functions are located under the [`custom` directory](https://docs.gitea.io/en-us/customizing-gitea/). -Gitea has an internal template that serves as default in case there's no custom alternative. - -Custom templates are loaded when Gitea starts. Changes made to them are not recognized until Gitea is restarted again. - -## Mail notifications supporting templates - -Currently, the following notification events make use of templates: - -| Action name | Usage | -| ----------- | ------------------------------------------------------------------------------------------------------------ | -| `new` | A new issue or pull request was created. | -| `comment` | A new comment was created in an existing issue or pull request. | -| `close` | An issue or pull request was closed. | -| `reopen` | An issue or pull request was reopened. | -| `review` | The head comment of a review in a pull request. | -| `approve` | The head comment of a approving review for a pull request. | -| `reject` | The head comment of a review requesting changes for a pull request. | -| `code` | A single comment on the code of a pull request. | -| `assigned` | User was assigned to an issue or pull request. | -| `default` | Any action not included in the above categories, or when the corresponding category template is not present. | - -The path for the template of a particular message type is: - -```sh -custom/templates/mail/{action type}/{action name}.tmpl -``` - -Where `{action type}` is one of `issue` or `pull` (for pull requests), and `{action name}` is one of the names listed above. - -For example, the specific template for a mail regarding a comment in a pull request is: - -```sh -custom/templates/mail/pull/comment.tmpl -``` - -However, creating templates for each and every action type/name combination is not required. -A fallback system is used to choose the appropriate template for an event. The _first existing_ -template on this list is used: - -- The specific template for the desired **action type** and **action name**. -- The template for action type `issue` and the desired **action name**. -- The template for the desired **action type**, action name `default`. -- The template for action type `issue`, action name `default`. - -The only mandatory template is action type `issue`, action name `default`, which is already embedded in Gitea -unless it's overridden by the user in the `custom` directory. - -## Template syntax - -Mail templates are UTF-8 encoded text files that need to follow one of the following formats: - -``` -Text and macros for the subject line ------------- -Text and macros for the mail body -``` - -or - -``` -Text and macros for the mail body -``` - -Specifying a _subject_ section is optional (and therefore also the dash line separator). When used, the separator between -_subject_ and _mail body_ templates requires at least three dashes; no other characters are allowed in the separator line. - -_Subject_ and _mail body_ are parsed by [Golang's template engine](https://golang.org/pkg/text/template/) and -are provided with a _metadata context_ assembled for each notification. The context contains the following elements: - -| Name | Type | Available | Usage | -| ------------------ | ---------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `.FallbackSubject` | string | Always | A default subject line. See Below. | -| `.Subject` | string | Only in body | The _subject_, once resolved. | -| `.Body` | string | Always | The message of the issue, pull request or comment, parsed from Markdown into HTML and sanitized. Do not confuse with the _mail body_. | -| `.Link` | string | Always | The address of the originating issue, pull request or comment. | -| `.Issue` | models.Issue | Always | The issue (or pull request) originating the notification. To get data specific to a pull request (e.g. `HasMerged`), `.Issue.PullRequest` can be used, but care should be taken as this field will be `nil` if the issue is _not_ a pull request. | -| `.Comment` | models.Comment | If applicable | If the notification is from a comment added to an issue or pull request, this will contain the information about the comment. | -| `.IsPull` | bool | Always | `true` if the mail notification is associated with a pull request (i.e. `.Issue.PullRequest` is not `nil`). | -| `.Repo` | string | Always | Name of the repository, including owner name (e.g. `mike/stuff`) | -| `.User` | models.User | Always | Owner of the repository from which the event originated. To get the user name (e.g. `mike`),`.User.Name` can be used. | -| `.Doer` | models.User | Always | User that executed the action triggering the notification event. To get the user name (e.g. `rhonda`), `.Doer.Name` can be used. | -| `.IsMention` | bool | Always | `true` if this notification was only generated because the user was mentioned in the comment, while not being subscribed to the source. It will be `false` if the recipient was subscribed to the issue or repository. | -| `.SubjectPrefix` | string | Always | `Re: ` if the notification is about other than issue or pull request creation; otherwise an empty string. | -| `.ActionType` | string | Always | `"issue"` or `"pull"`. Will correspond to the actual _action type_ independently of which template was selected. | -| `.ActionName` | string | Always | It will be one of the action types described above (`new`, `comment`, etc.), and will correspond to the actual _action name_ independently of which template was selected. | -| `.ReviewComments` | []models.Comment | Always | List of code comments in a review. The comment text will be in `.RenderedContent` and the referenced code will be in `.Patch`. | - -All names are case sensitive. - -### The _subject_ part of the template - -The template engine used for the mail _subject_ is golang's [`text/template`](https://golang.org/pkg/text/template/). -Please refer to the linked documentation for details about its syntax. - -The _subject_ is built using the following steps: - -- A template is selected according to the type of notification and to what templates are present. -- The template is parsed and resolved (e.g. `{{.Issue.Index}}` is converted to the number of the issue - or pull request). -- All space-like characters (e.g. `TAB`, `LF`, etc.) are converted to normal spaces. -- All leading, trailing and redundant spaces are removed. -- The string is truncated to its first 256 runes (characters). - -If the end result is an empty string, **or** no subject template was available (i.e. the selected template -did not include a subject part), Gitea's **internal default** will be used. - -The internal default (fallback) subject is the equivalent of: - -```sh -{{.SubjectPrefix}}[{{.Repo}}] {{.Issue.Title}} (#{{.Issue.Index}}) -``` - -For example: `Re: [mike/stuff] New color palette (#38)` - -Gitea's default subject can also be found in the template _metadata_ as `.FallbackSubject` from any of -the two templates, even if a valid subject template is present. - -### The _mail body_ part of the template - -The template engine used for the _mail body_ is golang's [`html/template`](https://golang.org/pkg/html/template/). -Please refer to the linked documentation for details about its syntax. - -The _mail body_ is parsed after the mail subject, so there is an additional _metadata_ field which is -the actual rendered subject, after all considerations. - -The expected result is HTML (including structural elements like`<html>`, `<body>`, etc.). Styling -through `<style>` blocks, `class` and `style` attributes is possible. However, `html/template` -does some [automatic escaping](https://golang.org/pkg/html/template/#hdr-Contexts) that should be considered. - -Attachments (such as images or external style sheets) are not supported. However, other templates can -be referenced too, for example to provide the contents of a `<style>` element in a centralized fashion. -The external template must be placed under `custom/mail` and referenced relative to that directory. -For example, `custom/mail/styles/base.tmpl` can be included using `{{template styles/base}}`. - -The mail is sent with `Content-Type: multipart/alternative`, so the body is sent in both HTML -and text formats. The latter is obtained by stripping the HTML markup. - -## Troubleshooting - -How a mail is rendered is directly dependent on the capabilities of the mail application. Many mail -clients don't even support HTML, so they show the text version included in the generated mail. - -If the template fails to render, it will be noticed only at the moment the mail is sent. -A default subject is used if the subject template fails, and whatever was rendered successfully -from the the _mail body_ is used, disregarding the rest. - -Please check [Gitea's logs](https://docs.gitea.io/en-us/logging-configuration/) for error messages in case of trouble. - -## Example - -`custom/templates/mail/issue/default.tmpl`: - -```html -[{{.Repo}}] @{{.Doer.Name}} -{{if eq .ActionName "new"}} - created -{{else if eq .ActionName "comment"}} - commented on -{{else if eq .ActionName "close"}} - closed -{{else if eq .ActionName "reopen"}} - reopened -{{else}} - updated -{{end}} -{{if eq .ActionType "issue"}} - issue -{{else}} - pull request -{{end}} -#{{.Issue.Index}}: {{.Issue.Title}} ------------- -<!DOCTYPE html> -<html> -<head> - <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> - <title>{{.Subject}}</title> -</head> - -<body> - {{if .IsMention}} - <p> - You are receiving this because @{{.Doer.Name}} mentioned you. - </p> - {{end}} - <p> - <p> - <a href="{{AppUrl}}/{{.Doer.LowerName}}">@{{.Doer.Name}}</a> - {{if not (eq .Doer.FullName "")}} - ({{.Doer.FullName}}) - {{end}} - {{if eq .ActionName "new"}} - created - {{else if eq .ActionName "close"}} - closed - {{else if eq .ActionName "reopen"}} - reopened - {{else}} - updated - {{end}} - <a href="{{.Link}}">{{.Repo}}#{{.Issue.Index}}</a>. - </p> - {{if not (eq .Body "")}} - <h3>Message content:</h3> - <hr> - {{.Body | Str2html}} - {{end}} - </p> - <hr> - <p> - <a href="{{.Link}}">View it on Gitea</a>. - </p> -</body> -</html> -``` - -This template produces something along these lines: - -### Subject - -> [mike/stuff] @rhonda commented on pull request #38: New color palette - -### Mail body - -> [@rhonda](#) (Rhonda Myers) updated [mike/stuff#38](#). -> -> #### Message content: -> -> \_********************************\_******************************** -> -> Mike, I think we should tone down the blues a little. -> \_********************************\_******************************** -> -> [View it on Gitea](#). - -## Advanced - -The template system contains several functions that can be used to further process and format -the messages. Here's a list of some of them: - -| Name | Parameters | Available | Usage | -| ---------------- | ----------- | --------- | --------------------------------------------------------------------------- | -| `AppUrl` | - | Any | Gitea's URL | -| `AppName` | - | Any | Set from `app.ini`, usually "Gitea" | -| `AppDomain` | - | Any | Gitea's host name | -| `EllipsisString` | string, int | Any | Truncates a string to the specified length; adds ellipsis as needed | -| `Str2html` | string | Body only | Sanitizes text by removing any HTML tags from it. | -| `Safe` | string | Body only | Takes the input as HTML; can be used for `.ReviewComments.RenderedContent`. | - -These are _functions_, not metadata, so they have to be used: - -```html -Like this: {{Str2html "Escape<my>text"}} -Or this: {{"Escape<my>text" | Str2html}} -Or this: {{AppUrl}} -But not like this: {{.AppUrl}} -``` diff --git a/docs/content/doc/administration/mail-templates.zh-cn.md b/docs/content/doc/administration/mail-templates.zh-cn.md deleted file mode 100644 index 3b03090099..0000000000 --- a/docs/content/doc/administration/mail-templates.zh-cn.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -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}} -``` diff --git a/docs/content/doc/administration/repo-indexer.en-us.md b/docs/content/doc/administration/repo-indexer.en-us.md deleted file mode 100644 index a1980bc5fe..0000000000 --- a/docs/content/doc/administration/repo-indexer.en-us.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -date: "2019-09-06T01:35:00-03:00" -title: "Repository indexer" -slug: "repo-indexer" -weight: 45 -toc: false -draft: false -aliases: - - /en-us/repo-indexer -menu: - sidebar: - parent: "administration" - name: "Repository indexer" - weight: 45 - identifier: "repo-indexer" ---- - -# Repository indexer - -**Table of Contents** - -{{< toc >}} - -## Setting up the repository indexer - -Gitea can search through the files of the repositories by enabling this function in your [`app.ini`](https://docs.gitea.io/en-us/config-cheat-sheet/): - -```ini -[indexer] -; ... -REPO_INDEXER_ENABLED = true -REPO_INDEXER_PATH = indexers/repos.bleve -MAX_FILE_SIZE = 1048576 -REPO_INDEXER_INCLUDE = -REPO_INDEXER_EXCLUDE = resources/bin/** -``` - -Please bear in mind that indexing the contents can consume a lot of system resources, especially when the index is created for the first time or globally updated (e.g. after upgrading Gitea). - -### Choosing the files for indexing by size - -The `MAX_FILE_SIZE` option will make the indexer skip all files larger than the specified value. - -### Choosing the files for indexing by path - -Gitea applies glob pattern matching from the [`gobwas/glob` library](https://github.com/gobwas/glob) to choose which files will be included in the index. - -Limiting the list of files prevents the indexes from becoming polluted with derived or irrelevant files (e.g. lss, sym, map, etc.), so the search results are more relevant. It can also help reduce the index size. - -`REPO_INDEXER_EXCLUDE_VENDORED` (default: true) excludes vendored files from index. - -`REPO_INDEXER_INCLUDE` (default: empty) is a comma separated list of glob patterns to **include** in the index. An empty list means "_include all files_". -`REPO_INDEXER_EXCLUDE` (default: empty) is a comma separated list of glob patterns to **exclude** from the index. Files that match this list will not be indexed. `REPO_INDEXER_EXCLUDE` takes precedence over `REPO_INDEXER_INCLUDE`. - -Pattern matching works as follows: - -- To match all files with a `.txt` extension no matter what directory, use `**.txt`. -- To match all files with a `.txt` extension _only at the root level of the repository_, use `*.txt`. -- To match all files inside `resources/bin` and below, use `resources/bin/**`. -- To match all files _immediately inside_ `resources/bin`, use `resources/bin/*`. -- To match all files named `Makefile`, use `**Makefile`. -- Matching a directory has no effect; the pattern `resources/bin` will not include/exclude files inside that directory; `resources/bin/**` will. -- All files and patterns are normalized to lower case, so `**Makefile`, `**makefile` and `**MAKEFILE` are equivalent. diff --git a/docs/content/doc/administration/repo-indexer.zh-cn.md b/docs/content/doc/administration/repo-indexer.zh-cn.md deleted file mode 100644 index 621710e36a..0000000000 --- a/docs/content/doc/administration/repo-indexer.zh-cn.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -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` 是等效的。 diff --git a/docs/content/doc/administration/reverse-proxies.en-us.md b/docs/content/doc/administration/reverse-proxies.en-us.md deleted file mode 100644 index 7272eb5aa4..0000000000 --- a/docs/content/doc/administration/reverse-proxies.en-us.md +++ /dev/null @@ -1,385 +0,0 @@ ---- -date: "2018-05-22T11:00:00+00:00" -title: "Reverse Proxies" -slug: "reverse-proxies" -weight: 16 -toc: false -draft: false -aliases: - - /en-us/reverse-proxies -menu: - sidebar: - parent: "administration" - name: "Reverse Proxies" - weight: 16 - identifier: "reverse-proxies" ---- - -# Reverse Proxies - -**Table of Contents** - -{{< toc >}} - -## Nginx - -If you want Nginx to serve your Gitea instance, add the following `server` section to the `http` section of `nginx.conf`: - -``` -server { - listen 80; - server_name git.example.com; - - location / { - client_max_body_size 512M; - 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; - } -} -``` - -### Resolving Error: 413 Request Entity Too Large - -This error indicates nginx is configured to restrict the file upload size, -it affects attachment uploading, form posting, package uploading and LFS pushing, etc. -You can fine tune the `client_max_body_size` option according to [nginx document](http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size). - -## Nginx with a sub-path - -In case you already have a site, and you want Gitea to share the domain name, you can setup Nginx to serve Gitea under a sub-path by adding the following `server` section inside the `http` section of `nginx.conf`: - -``` -server { - listen 80; - server_name git.example.com; - - # Note: Trailing slash - location /gitea/ { - client_max_body_size 512M; - - # make nginx use unescaped URI, keep "%2F" as is - rewrite ^ $request_uri; - rewrite ^/gitea(/.*) $1 break; - proxy_pass http://127.0.0.1:3000$uri; - - # other common HTTP headers, see the "Nginx" config section above - proxy_set_header ... - } -} -``` - -Then you **MUST** set something like `[server] ROOT_URL = http://git.example.com/git/` correctly in your configuration. - -## Nginx and serve static resources directly - -We can tune the performance in splitting requests into categories static and dynamic. - -CSS files, JavaScript files, images and web fonts are static content. -The front page, a repository view or issue list is dynamic content. - -Nginx can serve static resources directly and proxy only the dynamic requests to Gitea. -Nginx is optimized for serving static content, while the proxying of large responses might be the opposite of that -(see [https://serverfault.com/q/587386](https://serverfault.com/q/587386)). - -Download a snapshot of the Gitea source repository to `/path/to/gitea/`. -After this, run `make frontend` in the repository directory to generate the static resources. We are only interested in the `public/` directory for this task, so you can delete the rest. -(You will need to have [Node with npm](https://nodejs.org/en/download/) and `make` installed to generate the static resources) - -Depending on the scale of your user base, you might want to split the traffic to two distinct servers, -or use a cdn for the static files. - -### Single node and single domain - -Set `[server] STATIC_URL_PREFIX = /_/static` in your configuration. - -```apacheconf -server { - listen 80; - server_name git.example.com; - - location /_/static/assets/ { - alias /path/to/gitea/public/; - } - - location / { - proxy_pass http://localhost:3000; - } -} -``` - -### Two nodes and two domains - -Set `[server] STATIC_URL_PREFIX = http://cdn.example.com/gitea` in your configuration. - -```apacheconf -# application server running Gitea -server { - listen 80; - server_name git.example.com; - - location / { - proxy_pass http://localhost:3000; - } -} -``` - -```apacheconf -# static content delivery server -server { - listen 80; - server_name cdn.example.com; - - location /gitea/ { - alias /path/to/gitea/public/; - } - - location / { - return 404; - } -} -``` - -## Apache HTTPD - -If you want Apache HTTPD to serve your Gitea instance, you can add the following to your Apache HTTPD configuration (usually located at `/etc/apache2/httpd.conf` in Ubuntu): - -```apacheconf -<VirtualHost *:80> - ... - ProxyPreserveHost On - ProxyRequests off - AllowEncodedSlashes NoDecode - ProxyPass / http://localhost:3000/ nocanon -</VirtualHost> -``` - -Note: The following Apache HTTPD mods must be enabled: `proxy`, `proxy_http`. - -If you wish to use Let's Encrypt with webroot validation, add the line `ProxyPass /.well-known !` before `ProxyPass` to disable proxying these requests to Gitea. - -## Apache HTTPD with a sub-path - -In case you already have a site, and you want Gitea to share the domain name, you can setup Apache HTTPD to serve Gitea under a sub-path by adding the following to you Apache HTTPD configuration (usually located at `/etc/apache2/httpd.conf` in Ubuntu): - -```apacheconf -<VirtualHost *:80> - ... - <Proxy *> - Order allow,deny - Allow from all - </Proxy> - AllowEncodedSlashes NoDecode - # Note: no trailing slash after either /git or port - ProxyPass /git http://localhost:3000 nocanon -</VirtualHost> -``` - -Then you **MUST** set something like `[server] ROOT_URL = http://git.example.com/git/` correctly in your configuration. - -Note: The following Apache HTTPD mods must be enabled: `proxy`, `proxy_http`. - -## Caddy - -If you want Caddy to serve your Gitea instance, you can add the following server block to your Caddyfile: - -```apacheconf -git.example.com { - reverse_proxy localhost:3000 -} -``` - -## Caddy with a sub-path - -In case you already have a site, and you want Gitea to share the domain name, you can setup Caddy to serve Gitea under a sub-path by adding the following to your server block in your Caddyfile: - -```apacheconf -git.example.com { - route /git/* { - uri strip_prefix /git - reverse_proxy localhost:3000 - } -} -``` - -Then set `[server] ROOT_URL = http://git.example.com/git/` in your configuration. - -## IIS - -If you wish to run Gitea with IIS. You will need to setup IIS with URL Rewrite as reverse proxy. - -1. Setup an empty website in IIS, named let's say, `Gitea Proxy`. -2. Follow the first two steps in [Microsoft's Technical Community Guide to Setup IIS with URL Rewrite](https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222#M343). That is: - -- Install Application Request Routing (ARR for short) either by using the Microsoft Web Platform Installer 5.1 (WebPI) or downloading the extension from [IIS.net](https://www.iis.net/downloads/microsoft/application-request-routing) -- Once the module is installed in IIS, you will see a new Icon in the IIS Administration Console called URL Rewrite. -- Open the IIS Manager Console and click on the `Gitea Proxy` Website from the tree view on the left. Select and double click the URL Rewrite Icon from the middle pane to load the URL Rewrite interface. -- Choose the `Add Rule` action from the right pane of the management console and select the `Reverse Proxy Rule` from the `Inbound and Outbound Rules` category. -- In the Inbound Rules section, set the server name to be the host that Gitea is running on with its port. e.g. if you are running Gitea on the localhost with port 3000, the following should work: `127.0.0.1:3000` -- Enable SSL Offloading -- In the Outbound Rules, ensure `Rewrite the domain names of the links in HTTP response` is set and set the `From:` field as above and the `To:` to your external hostname, say: `git.example.com` -- Now edit the `web.config` for your website to match the following: (changing `127.0.0.1:3000` and `git.example.com` as appropriate) - -```xml -<?xml version="1.0" encoding="UTF-8"?> -<configuration> - <system.web> - <httpRuntime requestPathInvalidCharacters="" /> - </system.web> - <system.webServer> - <security> - <requestFiltering> - <hiddenSegments> - <clear /> - </hiddenSegments> - <denyUrlSequences> - <clear /> - </denyUrlSequences> - <fileExtensions allowUnlisted="true"> - <clear /> - </fileExtensions> - </requestFiltering> - </security> - <rewrite> - <rules useOriginalURLEncoding="false"> - <rule name="ReverseProxyInboundRule1" stopProcessing="true"> - <match url="(.*)" /> - <action type="Rewrite" url="http://127.0.0.1:3000{UNENCODED_URL}" /> - <serverVariables> - <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="HTTP_ACCEPT_ENCODING" /> - <set name="HTTP_ACCEPT_ENCODING" value="" /> - </serverVariables> - </rule> - </rules> - <outboundRules> - <rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1"> - <!-- set the pattern correctly here - if you only want to accept http or https --> - <!-- change the pattern and the action value as appropriate --> - <match filterByTags="A, Form, Img" pattern="^http(s)?://127.0.0.1:3000/(.*)" /> - <action type="Rewrite" value="http{R:1}://git.example.com/{R:2}" /> - </rule> - <rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding"> - <match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" /> - <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" /> - </rule> - <preConditions> - <preCondition name="ResponseIsHtml1"> - <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" /> - </preCondition> - <preCondition name="NeedsRestoringAcceptEncoding"> - <add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" /> - </preCondition> - </preConditions> - </outboundRules> - </rewrite> - <urlCompression doDynamicCompression="true" /> - <handlers> - <clear /> - <add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" /> - </handlers> - <!-- Map all extensions to the same MIME type, so all files can be - downloaded. --> - <staticContent> - <clear /> - <mimeMap fileExtension="*" mimeType="application/octet-stream" /> - </staticContent> - </system.webServer> -</configuration> -``` - -## HAProxy - -If you want HAProxy to serve your Gitea instance, you can add the following to your HAProxy configuration - -add an acl in the frontend section to redirect calls to gitea.example.com to the correct backend - -``` -frontend http-in - ... - acl acl_gitea hdr(host) -i gitea.example.com - use_backend gitea if acl_gitea - ... -``` - -add the previously defined backend section - -``` -backend gitea - server localhost:3000 check -``` - -If you redirect the http content to https, the configuration work the same way, just remember that the connection between HAProxy and Gitea will be done via http so you do not have to enable https in Gitea's configuration. - -## HAProxy with a sub-path - -In case you already have a site, and you want Gitea to share the domain name, you can setup HAProxy to serve Gitea under a sub-path by adding the following to you HAProxy configuration: - -``` -frontend http-in - ... - acl acl_gitea path_beg /gitea - use_backend gitea if acl_gitea - ... -``` - -With that configuration http://example.com/gitea/ will redirect to your Gitea instance. - -then for the backend section - -``` -backend gitea - http-request replace-path /gitea\/?(.*) \/\1 - server localhost:3000 check -``` - -The added http-request will automatically add a trailing slash if needed and internally remove /gitea from the path to allow it to work correctly with Gitea by setting properly http://example.com/gitea as the root. - -Then you **MUST** set something like `[server] ROOT_URL = http://example.com/gitea/` correctly in your configuration. - -## Traefik - -If you want traefik to serve your Gitea instance, you can add the following label section to your `docker-compose.yaml` (Assuming the provider is docker). - -```yaml -gitea: - image: gitea/gitea - ... - labels: - - "traefik.enable=true" - - "traefik.http.routers.gitea.rule=Host(`example.com`)" - - "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000" -``` - -This config assumes that you are handling HTTPS on the traefik side and using HTTP between Gitea and traefik. - -## Traefik with a sub-path - -In case you already have a site, and you want Gitea to share the domain name, you can setup Traefik to serve Gitea under a sub-path by adding the following to your `docker-compose.yaml` (Assuming the provider is docker) : - -```yaml -gitea: - image: gitea/gitea - ... - labels: - - "traefik.enable=true" - - "traefik.http.routers.gitea.rule=Host(`example.com`) && PathPrefix(`/gitea`)" - - "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000" - - "traefik.http.middlewares.gitea-stripprefix.stripprefix.prefixes=/gitea" - - "traefik.http.routers.gitea.middlewares=gitea-stripprefix" -``` - -This config assumes that you are handling HTTPS on the traefik side and using HTTP between Gitea and traefik. - -Then you **MUST** set something like `[server] ROOT_URL = http://example.com/gitea/` correctly in your configuration. - -## General sub-path configuration - -Usually it's not recommended to put Gitea in a sub-path, it's not widely used and may have some issues in rare cases. - -If you really need to do so, to make Gitea works with sub-path (eg: `http://example.com/gitea/`), here are the requirements: - -1. Set `[server] ROOT_URL = http://example.com/gitea/` in your `app.ini` file. -2. Make the reverse-proxy pass `http://example.com/gitea/foo` to `http://gitea-server:3000/foo`. -3. Make sure the reverse-proxy not decode the URI, the request `http://example.com/gitea/a%2Fb` should be passed as `http://gitea-server:3000/a%2Fb`. diff --git a/docs/content/doc/administration/reverse-proxies.zh-cn.md b/docs/content/doc/administration/reverse-proxies.zh-cn.md deleted file mode 100644 index 63c7c24985..0000000000 --- a/docs/content/doc/administration/reverse-proxies.zh-cn.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -date: "2018-05-22T11:00:00+00:00" -title: "反向代理" -slug: "reverse-proxies" -weight: 16 -toc: false -draft: false -aliases: - - /zh-cn/reverse-proxies -menu: - sidebar: - parent: "administration" - name: "反向代理" - weight: 16 - identifier: "reverse-proxies" ---- - -# 反向代理 - -**目录** - -{{< toc >}} - -## 使用 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: 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 进行通信。 diff --git a/docs/content/doc/administration/search-engines-indexation.en-us.md b/docs/content/doc/administration/search-engines-indexation.en-us.md deleted file mode 100644 index 27427531ce..0000000000 --- a/docs/content/doc/administration/search-engines-indexation.en-us.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -date: "2019-12-31T13:55:00+05:00" -title: "Search Engines Indexation" -slug: "search-engines-indexation" -weight: 60 -toc: false -draft: false -aliases: - - /en-us/search-engines-indexation -menu: - sidebar: - parent: "administration" - name: "Search Engines Indexation" - weight: 60 - identifier: "search-engines-indexation" ---- - -# Search engines indexation of your Gitea installation - -By default your Gitea installation will be indexed by search engines. -If you don't want your repository to be visible for search engines read further. - -## Block search engines indexation using robots.txt - -To make Gitea serve a custom `robots.txt` (default: empty 404) for top level installations, -create a file called `robots.txt` in the [`custom` folder or `CustomPath`]({{< relref "doc/administration/customizing-gitea.en-us.md" >}}) - -Examples on how to configure the `robots.txt` can be found at [https://moz.com/learn/seo/robotstxt](https://moz.com/learn/seo/robotstxt). - -```txt -User-agent: * -Disallow: / -``` - -If you installed Gitea in a subdirectory, you will need to create or edit the `robots.txt` in the top level directory. - -```txt -User-agent: * -Disallow: /gitea/ -``` diff --git a/docs/content/doc/administration/search-engines-indexation.zh-cn.md b/docs/content/doc/administration/search-engines-indexation.zh-cn.md deleted file mode 100644 index 4f9d18af70..0000000000 --- a/docs/content/doc/administration/search-engines-indexation.zh-cn.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -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/ -``` diff --git a/docs/content/doc/administration/signing.en-us.md b/docs/content/doc/administration/signing.en-us.md deleted file mode 100644 index de539e34b2..0000000000 --- a/docs/content/doc/administration/signing.en-us.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -date: "2019-08-17T10:20:00+01:00" -title: "GPG Commit Signatures" -slug: "signing" -weight: 50 -toc: false -draft: false -aliases: - - /en-us/signing -menu: - sidebar: - parent: "administration" - name: "GPG Commit Signatures" - weight: 50 - identifier: "signing" ---- - -# GPG Commit Signatures - -**Table of Contents** - -{{< toc >}} - -Gitea will verify GPG commit signatures in the provided tree by -checking if the commits are signed by a key within the Gitea database, -or if the commit matches the default key for Git. - -Keys are not checked to determine if they have expired or revoked. -Keys are also not checked with keyservers. - -A commit will be marked with a grey unlocked icon if no key can be -found to verify it. If a commit is marked with a red unlocked icon, -it is reported to be signed with a key with an id. - -Please note: The signer of a commit does not have to be an author or -committer of a commit. - -This functionality requires Git >= 1.7.9 but for full functionality -this requires Git >= 2.0.0. - -## Automatic Signing - -There are a number of places where Gitea will generate commits itself: - -- Repository Initialisation -- Wiki Changes -- CRUD actions using the editor or the API -- Merges from Pull Requests - -Depending on configuration and server trust you may want Gitea to -sign these commits. - -## Installing and generating a GPG key for Gitea - -It is up to a server administrator to determine how best to install -a signing key. Gitea generates all its commits using the server `git` -command at present - and therefore the server `gpg` will be used for -signing (if configured.) Administrators should review best-practices -for GPG - in particular it is probably advisable to only install a -signing secret subkey without the master signing and certifying secret -key. - -## General Configuration - -Gitea's configuration for signing can be found with the -`[repository.signing]` section of `app.ini`: - -```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` - -The first option to discuss is the `SIGNING_KEY`. There are three main -options: - -- `none` - this prevents Gitea from signing any commits -- `default` - Gitea will default to the key configured within `git config` -- `KEYID` - Gitea will sign commits with the gpg key with the ID - `KEYID`. In this case you should provide a `SIGNING_NAME` and - `SIGNING_EMAIL` to be displayed for this key. - -The `default` option will interrogate `git config` for -`commit.gpgsign` option - if this is set, then it will use the results -of the `user.signingkey`, `user.name` and `user.email` as appropriate. - -Please note: by adjusting Git's `config` file within Gitea's -repositories, `SIGNING_KEY=default` could be used to provide different -signing keys on a per-repository basis. However, this is clearly not an -ideal UI and therefore subject to change. - -**Since 1.17**, Gitea runs git in its own home directory `[git].HOME_PATH` (default to `%(APP_DATA_PATH)/home`) -and uses its own config `{[git].HOME_PATH}/.gitconfig`. -If you have your own customized git config for Gitea, you should set these configs in system git config (aka `/etc/gitconfig`) -or the Gitea internal git config `{[git].HOME_PATH}/.gitconfig`. -Related home files for git command (like `.gnupg`) should also be put in Gitea's git home directory `[git].HOME_PATH`. -If you like to keep the `.gnupg` directory outside of `{[git].HOME_PATH}/`, consider setting the `$GNUPGHOME` environment variable to your preferred location. - -### `INITIAL_COMMIT` - -This option determines whether Gitea should sign the initial commit -when creating a repository. The possible values are: - -- `never`: Never sign -- `pubkey`: Only sign if the user has a public key -- `twofa`: Only sign if the user logs in with two factor authentication -- `always`: Always sign - -Options other than `never` and `always` can be combined as a comma -separated list. The commit will be signed if all selected options are true. - -### `WIKI` - -This options determines if Gitea should sign commits to the Wiki. -The possible values are: - -- `never`: Never sign -- `pubkey`: Only sign if the user has a public key -- `twofa`: Only sign if the user logs in with two-factor authentication -- `parentsigned`: Only sign if the parent commit is signed. -- `always`: Always sign - -Options other than `never` and `always` can be combined as a comma -separated list. The commit will be signed if all selected options are true. - -### `CRUD_ACTIONS` - -This option determines if Gitea should sign commits from the web -editor or API CRUD actions. The possible values are: - -- `never`: Never sign -- `pubkey`: Only sign if the user has a public key -- `twofa`: Only sign if the user logs in with two-factor authentication -- `parentsigned`: Only sign if the parent commit is signed. -- `always`: Always sign - -Options other than `never` and `always` can be combined as a comma -separated list. The change will be signed if all selected options are true. - -### `MERGES` - -This option determines if Gitea should sign merge commits from PRs. -The possible options are: - -- `never`: Never sign -- `pubkey`: Only sign if the user has a public key -- `twofa`: Only sign if the user logs in with two-factor authentication -- `basesigned`: Only sign if the parent commit in the base repo is signed. -- `headsigned`: Only sign if the head commit in the head branch is signed. -- `commitssigned`: Only sign if all the commits in the head branch to the merge point are signed. -- `approved`: Only sign approved merges to a protected branch. -- `always`: Always sign - -Options other than `never` and `always` can be combined as a comma -separated list. The merge will be signed if all selected options are true. - -## Obtaining the Public Key of the Signing Key - -The public key used to sign Gitea's commits can be obtained from the API at: - -```sh -/api/v1/signing-key.gpg -``` - -In cases where there is a repository specific key this can be obtained from: - -```sh -/api/v1/repos/:username/:reponame/signing-key.gpg -``` diff --git a/docs/content/doc/administration/signing.zh-cn.md b/docs/content/doc/administration/signing.zh-cn.md deleted file mode 100644 index 41c3e67811..0000000000 --- a/docs/content/doc/administration/signing.zh-cn.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -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 -``` diff --git a/docs/content/doc/contributing.en-us.md b/docs/content/doc/contributing.en-us.md deleted file mode 100644 index 6cc96d91b2..0000000000 --- a/docs/content/doc/contributing.en-us.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2021-01-22T00:00:00+02:00" -title: "Contributing" -slug: "contributing" -weight: 35 -toc: false -draft: false -menu: - sidebar: - name: "Contributing" - weight: 50 - identifier: "contributing" ---- diff --git a/docs/content/doc/contributing.fr-fr.md b/docs/content/doc/contributing.fr-fr.md deleted file mode 100644 index 3175668329..0000000000 --- a/docs/content/doc/contributing.fr-fr.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2021-01-22T00:00:00+02:00" -title: "Übersetzung" -slug: "contributing" -weight: 35 -toc: false -draft: false -menu: - sidebar: - name: "Übersetzung" - weight: 50 - identifier: "contributing" ---- diff --git a/docs/content/doc/contributing.zh-tw.md b/docs/content/doc/contributing.zh-tw.md deleted file mode 100644 index 73a3f94a7c..0000000000 --- a/docs/content/doc/contributing.zh-tw.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2021-01-22T00:00:00+02:00" -title: "貢獻" -slug: "contributing" -weight: 35 -toc: false -draft: false -menu: - sidebar: - name: "貢獻" - weight: 50 - identifier: "contributing" ---- diff --git a/docs/content/doc/contributing/_index.de-de.md b/docs/content/doc/contributing/_index.de-de.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/contributing/_index.de-de.md +++ /dev/null diff --git a/docs/content/doc/contributing/_index.en-us.md b/docs/content/doc/contributing/_index.en-us.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/contributing/_index.en-us.md +++ /dev/null diff --git a/docs/content/doc/contributing/_index.zh-cn.md b/docs/content/doc/contributing/_index.zh-cn.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/contributing/_index.zh-cn.md +++ /dev/null diff --git a/docs/content/doc/contributing/_index.zh-tw.md b/docs/content/doc/contributing/_index.zh-tw.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/contributing/_index.zh-tw.md +++ /dev/null diff --git a/docs/content/doc/contributing/guidelines-backend.en-us.md b/docs/content/doc/contributing/guidelines-backend.en-us.md deleted file mode 100644 index 283fbdf3ae..0000000000 --- a/docs/content/doc/contributing/guidelines-backend.en-us.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -date: "2021-11-01T23:41:00+08:00" -title: "Guidelines for Backend Development" -slug: "guidelines-backend" -weight: 20 -toc: false -draft: false -aliases: - - /en-us/guidelines-backend -menu: - sidebar: - parent: "contributing" - name: "Guidelines for Backend" - weight: 20 - identifier: "guidelines-backend" ---- - -# Guidelines for Backend Development - -**Table of Contents** - -{{< toc >}} - -## Background - -Gitea uses Golang as the backend programming language. It uses many third-party packages and also write some itself. -For example, Gitea uses [Chi](https://github.com/go-chi/chi) as basic web framework. [Xorm](https://xorm.io) is an ORM framework that is used to interact with the database. -So it's very important to manage these packages. Please take the below guidelines before you start to write backend code. - -## Package Design Guideline - -### Packages List - -To maintain understandable code and avoid circular dependencies it is important to have a good code structure. The Gitea backend is divided into the following parts: - -- `build`: Scripts to help build Gitea. -- `cmd`: All Gitea actual sub commands includes web, doctor, serv, hooks, admin and etc. `web` will start the web service. `serv` and `hooks` will be invoked by Git or OpenSSH. Other sub commands could help to maintain Gitea. -- `tests`: Common test utility functions - - `tests/integration`: Integration tests, to test back-end regressions - - `tests/e2e`: E2e tests, to test front-end and back-end compatibility and visual regressions. -- `models`: Contains the data structures used by xorm to construct database tables. It also contains functions to query and update the database. Dependencies to other Gitea code should be avoided. You can make exceptions in cases such as logging. - - `models/db`: Basic database operations. All other `models/xxx` packages should depend on this package. The `GetEngine` function should only be invoked from `models/`. - - `models/fixtures`: Sample data used in unit tests and integration tests. One `yml` file means one table which will be loaded into database when beginning the tests. - - `models/migrations`: Stores database migrations between versions. PRs that change a database structure **MUST** also have a migration step. -- `modules`: Different modules to handle specific functionality in Gitea. Work in Progress: Some of them should be moved to `services`, in particular those that depend on models because they rely on the database. - - `modules/setting`: Store all system configurations read from ini files and has been referenced by everywhere. But they should be used as function parameters when possible. - - `modules/git`: Package to interactive with `Git` command line or Gogit package. -- `public`: Compiled frontend files (javascript, images, css, etc.) -- `routers`: Handling of server requests. As it uses other Gitea packages to serve the request, other packages (models, modules or services) must not depend on routers. - - `routers/api` Contains routers for `/api/v1` aims to handle RESTful API requests. - - `routers/install` Could only respond when system is in INSTALL mode (INSTALL_LOCK=false). - - `routers/private` will only be invoked by internal sub commands, especially `serv` and `hooks`. - - `routers/web` will handle HTTP requests from web browsers or Git SMART HTTP protocols. -- `services`: Support functions for common routing operations or command executions. Uses `models` and `modules` to handle the requests. -- `templates`: Golang templates for generating the html output. - -### Package Dependencies - -Since Golang doesn't support import cycles, we have to decide the package dependencies carefully. There are some levels between those packages. Below is the ideal package dependencies direction. - -`cmd` -> `routers` -> `services` -> `models` -> `modules` - -From left to right, left packages could depend on right packages, but right packages MUST not depend on left packages. The sub packages on the same level could depend on according this level's rules. - -**NOTICE** - -Why do we need database transactions outside of `models`? And how? -Some actions should allow for rollback when database record insertion/update/deletion failed. -So services must be allowed to create a database transaction. Here is some example, - -```go -// services/repository/repository.go -func CreateXXXX() error { - return db.WithTx(func(ctx context.Context) error { - // do something, if err is returned, it will rollback automatically - if err := issues.UpdateIssue(ctx, repoID); err != nil { - // ... - return err - } - // ... - return nil - }) -} -``` - -You should **not** use `db.GetEngine(ctx)` in `services` directly, but just write a function under `models/`. -If the function will be used in the transaction, just let `context.Context` as the function's first parameter. - -```go -// models/issues/issue.go -func UpdateIssue(ctx context.Context, repoID int64) error { - e := db.GetEngine(ctx) - - // ... -} -``` - -### Package Name - -For the top level package, use a plural as package name, i.e. `services`, `models`, for sub packages, use singular, -i.e. `services/user`, `models/repository`. - -### Import Alias - -Since there are some packages which use the same package name, it is possible that you find packages like `modules/user`, `models/user`, and `services/user`. When these packages are imported in one Go file, it's difficult to know which package we are using and if it's a variable name or an import name. So, we always recommend to use import aliases. To differ from package variables which are commonly in camelCase, just use **snake_case** for import aliases. -i.e. `import user_service "code.gitea.io/gitea/services/user"` - -### Important Gotchas - -- Never write `x.Update(exemplar)` without an explicit `WHERE` clause: - - This will cause all rows in the table to be updated with the non-zero values of the exemplar - including IDs. - - You should usually write `x.ID(id).Update(exemplar)`. -- If during a migration you are inserting into a table using `x.Insert(exemplar)` where the ID is preset: - - You will need to ``SET IDENTITY_INSERT `table` ON`` for the MSSQL variant (the migration will fail otherwise) - - However, you will also need to update the id sequence for postgres - the migration will silently pass here but later insertions will fail: - ``SELECT setval('table_name_id_seq', COALESCE((SELECT MAX(id)+1 FROM `table_name`), 1), false)`` - -### Future Tasks - -Currently, we are creating some refactors to do the following things: - -- Correct that codes which doesn't follow the rules. -- There are too many files in `models`, so we are moving some of them into a sub package `models/xxx`. -- Some `modules` sub packages should be moved to `services` because they depend on `models`. diff --git a/docs/content/doc/contributing/guidelines-backend.zh-cn.md b/docs/content/doc/contributing/guidelines-backend.zh-cn.md deleted file mode 100644 index c94d4305e1..0000000000 --- a/docs/content/doc/contributing/guidelines-backend.zh-cn.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -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`中。 diff --git a/docs/content/doc/contributing/guidelines-frontend.en-us.md b/docs/content/doc/contributing/guidelines-frontend.en-us.md deleted file mode 100644 index fcbd81b26b..0000000000 --- a/docs/content/doc/contributing/guidelines-frontend.en-us.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -date: "2021-10-13T16:00:00+02:00" -title: "Guidelines for Frontend Development" -slug: "guidelines-frontend" -weight: 30 -toc: false -draft: false -aliases: - - /en-us/guidelines-frontend -menu: - sidebar: - parent: "contributing" - name: "Guidelines for Frontend" - weight: 30 - identifier: "guidelines-frontend" ---- - -# Guidelines for Frontend Development - -**Table of Contents** - -{{< toc >}} - -## Background - -Gitea uses [Fomantic-UI](https://fomantic-ui.com/introduction/getting-started.html) (based on [jQuery](https://api.jquery.com)) and [Vue3](https://vuejs.org/) for its frontend. - -The HTML pages are rendered by [Go HTML Template](https://pkg.go.dev/html/template). - -The source files can be found in the following directories: - -* **CSS styles:** `web_src/css/` -* **JavaScript files:** `web_src/js/` -* **Vue components:** `web_src/js/components/` -* **Go HTML templates:** `templates/` - -## General Guidelines - -We recommend [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html) and [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html) - -### Gitea specific guidelines: - -1. Every feature (Fomantic-UI/jQuery module) should be put in separate files/directories. -2. HTML ids and classes should use kebab-case, it's preferred to contain 2-3 feature related keywords. -3. HTML ids and classes used in JavaScript should be unique for the whole project, and should contain 2-3 feature related keywords. We recommend to use the `js-` prefix for classes that are only used in JavaScript. -4. CSS styling for classes provided by frameworks should not be overwritten. Always use new class names with 2-3 feature related keywords to overwrite framework styles. Gitea's helper CSS classes in `helpers.less` could be helpful. -5. The backend can pass complex data to the frontend by using `ctx.PageData["myModuleData"] = map[]{}`, but do not expose whole models to the frontend to avoid leaking sensitive data. -6. Simple pages and SEO-related pages use Go HTML Template render to generate static Fomantic-UI HTML output. Complex pages can use Vue3. -7. Clarify variable types, prefer `elem.disabled = true` instead of `elem.setAttribute('disabled', 'anything')`, prefer `$el.prop('checked', var === 'yes')` instead of `$el.prop('checked', var)`. -8. Use semantic elements, prefer `<button class="ui button">` instead of `<div class="ui button">`. -9. Avoid unnecessary `!important` in CSS, add comments to explain why it's necessary if it can't be avoided. -10. Avoid mixing different events in one event listener, prefer to use individual event listeners for every event. -11. Custom event names are recommended to use `ce-` prefix. -12. Gitea's tailwind-style CSS classes use `gt-` prefix (`gt-relative`), while Gitea's own private framework-level CSS classes use `g-` prefix (`g-modal-confirm`). - -### Accessibility / ARIA - -In history, Gitea heavily uses Fomantic UI which is not an accessibility-friendly framework. -Gitea uses some patches to make Fomantic UI more accessible (see the `aria.js` and `aria.md`), -but there are still many problems which need a lot of work and time to fix. - -### Framework Usage - -Mixing different frameworks together is discouraged, it makes the code difficult to be maintained. -A JavaScript module should follow one major framework and follow the framework's best practice. - -Recommended implementations: - -* Vue + Vanilla JS -* Fomantic-UI (jQuery) -* Vanilla JS - -Discouraged implementations: - -* Vue + Fomantic-UI (jQuery) -* jQuery + Vanilla JS - -To make UI consistent, Vue components can use Fomantic-UI CSS classes. -Although mixing different frameworks is discouraged, -it should also work if the mixing is necessary and the code is well-designed and maintainable. - -### `async` Functions - -Only mark a function as `async` if and only if there are `await` calls -or `Promise` returns inside the function. - -It's not recommended to use `async` event listeners, which may lead to problems. -The reason is that the code after await is executed outside the event dispatch. -Reference: https://github.com/github/eslint-plugin-github/blob/main/docs/rules/async-preventdefault.md - -If an event listener must be `async`, the `e.preventDefault()` should be before any `await`, -it's recommended to put it at the beginning of the function. - -If we want to call an `async` function in a non-async context, -it's recommended to use `const _promise = asyncFoo()` to tell readers -that this is done by purpose, we want to call the async function and ignore the Promise. -Some lint rules and IDEs also have warnings if the returned Promise is not handled. - -### HTML Attributes and `dataset` - -The usage of `dataset` is forbidden, its camel-casing behaviour makes it hard to grep for attributes. -However, there are still some special cases, so the current guideline is: - -* For legacy code: - * `$.data()` should be refactored to `$.attr()`. - * `$.data()` can be used to bind some non-string data to elements in rare cases, but it is highly discouraged. - -* For new code: - * `node.dataset` should not be used, use `node.getAttribute` instead. - * never bind any user data to a DOM node, use a suitable design pattern to describe the relation between node and data. - -### Show/Hide Elements - -* Vue components are recommended to use `v-if` and `v-show` to show/hide elements. -* Go template code should use Gitea's `.gt-hidden` and `showElem()/hideElem()/toggleElem()`, see more details in `.gt-hidden`'s comment. - -### Styles and Attributes in Go HTML Template - -It's recommended to use: - -```html -<div class="gt-name1 gt-name2 {{if .IsFoo}}gt-foo{{end}}" {{if .IsFoo}}data-foo{{end}}></div> -``` - -instead of: - -```html -<div class="gt-name1 gt-name2{{if .IsFoo}} gt-foo{{end}}"{{if .IsFoo}} data-foo{{end}}></div> -``` - -to make the code more readable. - -### Legacy Code - -A lot of legacy code already existed before this document's written. It's recommended to refactor legacy code to follow the guidelines. - -### Vue3 and JSX - -Gitea is using Vue3 now. We decided not to introduce JSX to keep the HTML and the JavaScript code separated. diff --git a/docs/content/doc/contributing/guidelines-frontend.zh-cn.md b/docs/content/doc/contributing/guidelines-frontend.zh-cn.md deleted file mode 100644 index 3a58db0c70..0000000000 --- a/docs/content/doc/contributing/guidelines-frontend.zh-cn.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -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 代码分离。 diff --git a/docs/content/doc/contributing/guidelines-refactoring.en-us.md b/docs/content/doc/contributing/guidelines-refactoring.en-us.md deleted file mode 100644 index dce2845de5..0000000000 --- a/docs/content/doc/contributing/guidelines-refactoring.en-us.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -date: "2023-02-14T00:00:00+00:00" -title: "Guidelines for Refactoring" -slug: "guidelines-refactoring" -weight: 40 -toc: false -draft: false -aliases: - - /en-us/guidelines-refactoring -menu: - sidebar: - parent: "contributing" - name: "Guidelines for Refactoring" - weight: 40 - identifier: "guidelines-refactoring" ---- - -# Guidelines for Refactoring - -**Table of Contents** - -{{< toc >}} - -## Background - -Since the first line of code was written at Feb 12, 2014, Gitea has grown to be a large project. -As a result, the codebase has become larger and larger. The larger the codebase is, the more difficult it is to maintain. -A lot of outdated mechanisms exist, a lot of frameworks are mixed together, some legacy code might cause bugs and block new features. -To make the codebase more maintainable and make Gitea better, developers should keep in mind to use modern mechanisms to refactor the old code. - -This document is a collection of guidelines for refactoring the codebase. - -## Refactoring Suggestions - -* Design more about the future, but not only resolve the current problem. -* Reduce ambiguity, reduce conflicts, improve maintainability. -* Describe the refactoring, for example: - * Why the refactoring is needed. - * How the legacy problems would be solved. - * What's the Pros/Cons of the refactoring. -* Only do necessary changes, keep the old logic as much as possible. -* Introduce some intermediate steps to make the refactoring easier to review, a complete refactoring plan could be done in several PRs. -* If there is any divergence, the TOC(Technical Oversight Committee) should be involved to help to make decisions. -* Add necessary tests to make sure the refactoring is correct. -* Non-bug refactoring is preferred to be done at the beginning of a milestone, it would be easier to find problems before the release. - -## Reviewing & Merging Suggestions - -* A refactoring PR shouldn't be kept open for a long time (usually 7 days), it should be reviewed as soon as possible. -* A refactoring PR should be merged as soon as possible, it should not be blocked by other PRs. -* If there is no objection from TOC, a refactoring PR could be merged after 7 days with one core member's approval (not the author). -* Tolerate some dirty/hacky intermediate steps if the final result is good. -* Tolerate some regression bugs if the refactoring is necessary, fix bugs as soon as possible. diff --git a/docs/content/doc/contributing/guidelines-refactoring.zh-cn.md b/docs/content/doc/contributing/guidelines-refactoring.zh-cn.md deleted file mode 100644 index 9356fbd110..0000000000 --- a/docs/content/doc/contributing/guidelines-refactoring.zh-cn.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -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天后由一名核心成员（非作者）批准后合并。 -* 如果最终结果良好，容忍一些不完美/临时的步骤。 -* 如果重构是必要的，容忍一些回归错误，并尽快修复错误。 diff --git a/docs/content/doc/contributing/localization.de-de.md b/docs/content/doc/contributing/localization.de-de.md deleted file mode 100644 index c4dcb6cafa..0000000000 --- a/docs/content/doc/contributing/localization.de-de.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -date: "2021-01-22T00:00:00+02:00" -title: "Übersetzungs Richtlinien" -slug: "localization" -weight: 70 -toc: false -draft: false -menu: - sidebar: - parent: "contributing" - name: "Übersetzungsrichtlinien" - weight: 70 - identifier: "localization" ---- - -## Allgemeines - -Anrede: Wenig förmlich: - -* "Du"-Form -* Keine "Amtsdeusch"-Umschreibungen, einfach so als ob man den Nutzer direkt persönlich ansprechen würde - -Genauer definiert: - -* "falsch" anstatt "nicht korrekt/inkorrekt" -* Benutzerkonto oder Konto? Oder Account? -* "Wende dich an ..." anstatt "kontaktiere ..." -* In der selben Zeit übersetzen (sonst wird aus "is" "war") -* Richtige Anführungszeichen verwenden. Also `"` statt `''` oder `'` oder \` oder `´` - * `„` für beginnende Anführungszeichen, `“` für schließende Anführungszeichen - -Es gelten Artikel und Worttrennungen aus dem Duden. - -## Formulierungen in Modals und Buttons - -Es sollten die gleichen Formulierungen auf Buttons und Modals verwendet werden. - -Beispiel: Wenn der Button mit `löschen` beschriftet ist, sollte im Modal die Frage lauten `Willst du das wirklich löschen?` und nicht `Willst du das wirklich entfernen?`. Gleiches gilt für Success/Errormeldungen nach der Aktion. - -## Trennungen - -* Pull-Request -* Time-Tracker -* E-Mail-Adresse (siehe Duden) - -## Artikeldefinitionen für Anglizismen - -* _Der_ Commit (m.) -* _Der_ Branch (m.), plural: die Branches -* _Das_ Issue (n.) -* _Der_ Fork (m.) -* _Das_ Repository (n.), plural: die Repositories -* _Der_ Pull-Request (m.) -* _Der_ Token (m.), plural: die Token -* _Das_ Review (n.) -* _Der_ Key (m.) -* _Der_ Committer (m.), plural: die Committer - -## Weiterführende Links - -Diese beiden Links sind sehr empfehlenswert: - -* http://docs.translatehouse.org/projects/localization-guide/en/latest/guide/translation_guidelines_german.html -* https://docs.qgis.org/2.18/en/docs/documentation_guidelines/do_translations.html diff --git a/docs/content/doc/contributing/localization.en-us.md b/docs/content/doc/contributing/localization.en-us.md deleted file mode 100644 index c9591254c7..0000000000 --- a/docs/content/doc/contributing/localization.en-us.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Localization" -slug: "localization" -weight: 70 -toc: false -draft: false -aliases: - - /en-us/localization -menu: - sidebar: - parent: "contributing" - name: "Localization" - weight: 70 - identifier: "localization" ---- - -# Localization - -Gitea's localization happens through our [Crowdin project](https://crowdin.com/project/gitea). - -For changes to an **English** translation, a pull request can be made that changes the appropriate key in -the [english locale](https://github.com/go-gitea/gitea/blob/main/options/locale/locale_en-US.ini). - -For changes to a **non-English** translation, refer to the Crowdin project above. - -## Supported Languages - -Any language listed in the above Crowdin project will be supported as long as 25% or more has been translated. - -After a translation has been accepted, it will be reflected in the main repository after the next Crowdin sync, which is generally after any PR is merged. - -At the time of writing, this means that a changed translation may not appear until the following Gitea release. - -If you use a bleeding edge build, it should appear as soon as you update after the change is synced. - -# How to Contribute - -Different Languages have different translation guidelines. Please visit the respective page for more information. diff --git a/docs/content/doc/contributing/localization.zh-cn.md b/docs/content/doc/contributing/localization.zh-cn.md deleted file mode 100644 index 659a47332c..0000000000 --- a/docs/content/doc/contributing/localization.zh-cn.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "本地化" -slug: "localization" -weight: 70 -toc: false -draft: false -aliases: - - /zh-cn/localization -menu: - sidebar: - parent: "contributing" - name: "本地化" - weight: 70 - identifier: "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 的下一个版本才会出现。 - -如果使用开发版本，则在同步更改内容后，它应该会在更新后立即显示。 diff --git a/docs/content/doc/contributing/localization.zh-tw.md b/docs/content/doc/contributing/localization.zh-tw.md deleted file mode 100644 index 43c678000e..0000000000 --- a/docs/content/doc/contributing/localization.zh-tw.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "在地化" -slug: "localization" -weight: 70 -toc: false -draft: false -aliases: - - /zh-tw/localization -menu: - sidebar: - parent: "contributing" - name: "在地化" - weight: 70 - identifier: "localization" ---- - -# 在地化 - -我們在 [Crowdin 專案](https://crowdin.com/project/gitea)上進行在地化工作。 - -**英語系**的翻譯，可在修改[英文語言檔](https://github.com/go-gitea/gitea/blob/main/options/locale/locale_en-US.ini)後提出合併請求。 - -**非英語系**的翻譯，請前往上述的 Crowdin 專案。 - -## 已支援的語言 - -上述 Crowdin 專案中列出的語言在翻譯超過 25% 後將被支援。 - -翻譯被認可後將在下次 Crowdin 同步後進入到主儲存庫，通常是在任何合併請求被合併之後。 - -這表示更改的翻譯要到下次 Gitea 發佈後才會出現。 - -如果您使用的是最新建置，它將會在同步完成、您更新後出現。 diff --git a/docs/content/doc/contributing/translation.zh-cn.md b/docs/content/doc/contributing/translation.zh-cn.md deleted file mode 100644 index 8082c30bec..0000000000 --- a/docs/content/doc/contributing/translation.zh-cn.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -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/) diff --git a/docs/content/doc/development.en-us.md b/docs/content/doc/development.en-us.md deleted file mode 100644 index e9e8b9c816..0000000000 --- a/docs/content/doc/development.en-us.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Development" -slug: "development" -weight: 40 -toc: false -draft: false -menu: - sidebar: - name: "Development" - weight: 40 - identifier: "development" ---- diff --git a/docs/content/doc/development.zh-cn.md b/docs/content/doc/development.zh-cn.md deleted file mode 100644 index bbdaec4d1d..0000000000 --- a/docs/content/doc/development.zh-cn.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "开发" -slug: "development" -weight: 40 -toc: false -draft: false -menu: - sidebar: - name: "开发" - weight: 40 - identifier: "development" ---- diff --git a/docs/content/doc/development.zh-tw.md b/docs/content/doc/development.zh-tw.md deleted file mode 100644 index a0fbbf219f..0000000000 --- a/docs/content/doc/development.zh-tw.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "開發" -slug: "development" -weight: 40 -toc: false -draft: false -menu: - sidebar: - name: "開發" - weight: 40 - identifier: "development" ---- diff --git a/docs/content/doc/development/_index.en-us.md b/docs/content/doc/development/_index.en-us.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/development/_index.en-us.md +++ /dev/null diff --git a/docs/content/doc/development/_index.zh-cn.md b/docs/content/doc/development/_index.zh-cn.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/development/_index.zh-cn.md +++ /dev/null diff --git a/docs/content/doc/development/_index.zh-tw.md b/docs/content/doc/development/_index.zh-tw.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/development/_index.zh-tw.md +++ /dev/null diff --git a/docs/content/doc/development/api-usage.en-us.md b/docs/content/doc/development/api-usage.en-us.md deleted file mode 100644 index 4f5304ac0e..0000000000 --- a/docs/content/doc/development/api-usage.en-us.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -date: "2018-06-24:00:00+02:00" -title: "API Usage" -slug: "api-usage" -weight: 40 -toc: false -draft: false -aliases: - - /en-us/api-usage -menu: - sidebar: - parent: "development" - name: "API Usage" - weight: 40 - identifier: "api-usage" ---- - -# API Usage - -**Table of Contents** - -{{< toc >}} - -## Enabling/configuring API access - -By default, `ENABLE_SWAGGER` is true, and -`MAX_RESPONSE_ITEMS` is set to 50. See [Config Cheat -Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/) for more -information. - -## Authentication - -Gitea supports these methods of API authentication: - -- HTTP basic authentication -- `token=...` parameter in URL query string -- `access_token=...` parameter in URL query string -- `Authorization: token ...` header in HTTP headers - -All of these methods accept the same API key token type. You can -better understand this by looking at the code -- as of this writing, -Gitea parses queries and headers to find the token in -[modules/auth/auth.go](https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47). - -## Generating and listing API tokens - -A new token can be generated with a `POST` request to -`/users/:name/tokens`. - -Note that `/users/:name/tokens` is a special endpoint and requires you -to authenticate using `BasicAuth` and a password, as follows: - -```sh -$ curl -H "Content-Type: application/json" -d '{"name":"test"}' -u username:password https://gitea.your.host/api/v1/users/<username>/tokens -{"id":1,"name":"test","sha1":"9fcb1158165773dd010fca5f0cf7174316c3e37d","token_last_eight":"16c3e37d"} -``` - -The ``sha1`` (the token) is only returned once and is not stored in -plain-text. It will not be displayed when listing tokens with a `GET` -request; e.g. - -```sh -$ curl --url https://yourusername:password@gitea.your.host/api/v1/users/<username>/tokens -[{"name":"test","sha1":"","token_last_eight:"........":},{"name":"dev","sha1":"","token_last_eight":"........"}] -``` - -To use the API with basic authentication with two factor authentication -enabled, you'll need to send an additional header that contains the one -time password (6 digitrotating token). -An example of the header is `X-Gitea-OTP: 123456` where `123456` -is where you'd place the code from your authenticator. -Here is how the request would look like in curl: - -```sh -$ curl -H "X-Gitea-OTP: 123456" --url https://yourusername:yourpassword@gitea.your.host/api/v1/users/yourusername/tokens -``` - -You can also create an API key token via your Gitea installation's web -interface: `Settings | Applications | Generate New Token`. - -## OAuth2 Provider - -Access tokens obtained from Gitea's [OAuth2 provider](https://docs.gitea.io/en-us/oauth2-provider) are accepted by these methods: - -- `Authorization bearer ...` header in HTTP headers -- `token=...` parameter in URL query string -- `access_token=...` parameter in URL query string - -### More on the `Authorization:` header - -For historical reasons, Gitea needs the word `token` included before -the API key token in an authorization header, like this: - -```sh -Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675 -``` - -In a `curl` command, for instance, this would look like: - -```sh -curl "http://localhost:4000/api/v1/repos/test1/test1/issues" \ - -H "accept: application/json" \ - -H "Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675" \ - -H "Content-Type: application/json" -d "{ \"body\": \"testing\", \"title\": \"test 20\"}" -i -``` - -As mentioned above, the token used is the same one you would use in -the `token=` string in a GET request. - -## Pagination - -The API supports pagination. The `page` and `limit` parameters are used to specify the page number and the number of items per page. As well, the `Link` header is returned with the next, previous, and last page links if there are more than one pages. The `x-total-count` is also returned to indicate the total number of items. - -```sh -curl -v "http://localhost/api/v1/repos/search?limit=1" -... -< link: <http://localhost/api/v1/repos/search?limit=1&page=2>; rel="next",<http://localhost/api/v1/repos/search?limit=1&page=5252>; rel="last" -... -< x-total-count: 5252 -``` - -## API Guide - -API Reference guide is auto-generated by swagger and available on: -`https://gitea.your.host/api/swagger` -or on the -[Gitea demo instance](https://try.gitea.io/api/swagger) - -The OpenAPI document is at: -`https://gitea.your.host/swagger.v1.json` - -## Sudo - -The API allows admin users to sudo API requests as another user. Simply add either a `sudo=` parameter or `Sudo:` request header with the username of the user to sudo. - -## SDKs - -- [Official go-sdk](https://gitea.com/gitea/go-sdk) -- [more](https://gitea.com/gitea/awesome-gitea#user-content-sdk) diff --git a/docs/content/doc/development/api-usage.zh-cn.md b/docs/content/doc/development/api-usage.zh-cn.md deleted file mode 100644 index ceb69b3f0e..0000000000 --- a/docs/content/doc/development/api-usage.zh-cn.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -date: "2018-06-24:00:00+02:00" -title: "API 使用指南" -slug: "api-usage" -weight: 40 -toc: false -draft: false -aliases: - - /zh-cn/api-usage -menu: - sidebar: - parent: "development" - name: "API 使用指南" - weight: 40 - identifier: "api-usage" ---- - -# Gitea 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 即可。 diff --git a/docs/content/doc/development/hacking-on-gitea.en-us.md b/docs/content/doc/development/hacking-on-gitea.en-us.md deleted file mode 100644 index e1efe2ec11..0000000000 --- a/docs/content/doc/development/hacking-on-gitea.en-us.md +++ /dev/null @@ -1,383 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Hacking on Gitea" -slug: "hacking-on-gitea" -weight: 10 -toc: false -draft: false -aliases: - - /en-us/hacking-on-gitea -menu: - sidebar: - parent: "development" - name: "Hacking on Gitea" - weight: 10 - identifier: "hacking-on-gitea" ---- - -# Hacking on Gitea - -**Table of Contents** - -{{< toc >}} - -## Quickstart - -To get a quick working development environment you could use Gitpod. - -[](https://gitpod.io/#https://github.com/go-gitea/gitea) - -## Installing go - -You should [install go](https://golang.org/doc/install) and set up your go -environment correctly. - -Next, [install Node.js with npm](https://nodejs.org/en/download/) which is -required to build the JavaScript and CSS files. The minimum supported Node.js -version is {{< min-node-version >}} and the latest LTS version is recommended. - -**Note**: When executing make tasks that require external tools, like -`make watch-backend`, Gitea will automatically download and build these as -necessary. To be able to use these you must have the `"$GOPATH"/bin` directory -on the executable path. If you don't add the go bin directory to the -executable path you will have to manage this yourself. - -**Note 2**: Go version {{< min-go-version >}} or higher is required. -Gitea uses `gofmt` to format source code. However, the results of -`gofmt` can differ by the version of `go`. Therefore it is -recommended to install the version of Go that our continuous integration is -running. As of last update, the Go version should be {{< go-version >}}. - -To lint the template files, ensure [Python](https://www.python.org/) and -[Poetry](https://python-poetry.org/) are installed. - -## Installing Make - -Gitea makes heavy use of Make to automate tasks and improve development. This -guide covers how to install Make. - -### On Linux - -Install with the package manager. - -On Ubuntu/Debian: - -```bash -sudo apt-get install make -``` - -On Fedora/RHEL/CentOS: - -```bash -sudo yum install make -``` - -### On Windows - -One of these three distributions of Make will run on Windows: - -- [Single binary build](http://www.equation.com/servlet/equation.cmd?fa=make). Copy somewhere and add to `PATH`. - - [32-bits version](http://www.equation.com/ftpdir/make/32/make.exe) - - [64-bits version](http://www.equation.com/ftpdir/make/64/make.exe) -- [MinGW-w64](https://www.mingw-w64.org) / [MSYS2](https://www.msys2.org/). - - MSYS2 is a collection of tools and libraries providing you with an easy-to-use environment for building, installing and running native Windows software, it includes MinGW-w64. - - In MingGW-w64, the binary is called `mingw32-make.exe` instead of `make.exe`. Add the `bin` folder to `PATH`. - - In MSYS2, you can use `make` directly. See [MSYS2 Porting](https://www.msys2.org/wiki/Porting/). - - To compile Gitea with CGO_ENABLED (eg: SQLite3), you might need to use [tdm-gcc](https://jmeubank.github.io/tdm-gcc/) instead of MSYS2 gcc, because MSYS2 gcc headers lack some Windows-only CRT functions like `_beginthread`. -- [Chocolatey package](https://chocolatey.org/packages/make). Run `choco install make` - -**Note**: If you are attempting to build using make with Windows Command Prompt, you may run into issues. The above prompts (Git bash, or MinGW) are recommended, however if you only have command prompt (or potentially PowerShell) you can set environment variables using the [set](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/set_1) command, e.g. `set TAGS=bindata`. - -## Downloading and cloning the Gitea source code - -The recommended method of obtaining the source code is by using `git clone`. - -```bash -git clone https://github.com/go-gitea/gitea -``` - -(Since the advent of go modules, it is no longer necessary to build go projects -from within the `$GOPATH`, hence the `go get` approach is no longer recommended.) - -## Forking Gitea - -Download the main Gitea source code as above. Then, fork the -[Gitea repository](https://github.com/go-gitea/gitea) on GitHub, -and either switch the git remote origin for your fork or add your fork as another remote: - -```bash -# Rename original Gitea origin to upstream -git remote rename origin upstream -git remote add origin "git@github.com:$GITHUB_USERNAME/gitea.git" -git fetch --all --prune -``` - -or: - -```bash -# Add new remote for our fork -git remote add "$FORK_NAME" "git@github.com:$GITHUB_USERNAME/gitea.git" -git fetch --all --prune -``` - -To be able to create pull requests, the forked repository should be added as a remote -to the Gitea sources. Otherwise, changes can't be pushed. - -## Building Gitea (Basic) - -Take a look at our -[instructions]({{< relref "doc/installation/from-source.en-us.md" >}}) -for [building from source]({{< relref "doc/installation/from-source.en-us.md" >}}). - -The simplest recommended way to build from source is: - -```bash -TAGS="bindata sqlite sqlite_unlock_notify" make build -``` - -The `build` target will execute both `frontend` and `backend` sub-targets. If the `bindata` tag is present, the frontend files will be compiled into the binary. It is recommended to leave out the tag when doing frontend development so that changes will be reflected. - -See `make help` for all available `make` targets. Also see [`.drone.yml`](https://github.com/go-gitea/gitea/blob/main/.drone.yml) to see how our continuous integration works. - -## Building continuously - -To run and continuously rebuild when source files change: - -```bash -# for both frontend and backend -make watch - -# or: watch frontend files (html/js/css) only -make watch-frontend - -# or: watch backend files (go) only -make watch-backend -``` - -On macOS, watching all backend source files may hit the default open files limit which can be increased via `ulimit -n 12288` for the current shell or in your shell startup file for all future shells. - -### Formatting, code analysis and spell check - -Our continuous integration will reject PRs that fail the code linters (including format check, code analysis and spell check). - -You should format your code: - -```bash -make fmt -``` - -and lint the source code: - -```bash -# lint both frontend and backend code -make lint -# lint only backend code -make lint-backend -``` - -**Note**: The results of `gofmt` are dependent on the version of `go` present. -You should run the same version of go that is on the continuous integration -server as mentioned above. - -### Working on JS and CSS - -Frontend development should follow [Guidelines for Frontend Development]({{< relref "doc/contributing/guidelines-frontend.en-us.md" >}}) - -To build with frontend resources, either use the `watch-frontend` target mentioned above or just build once: - -```bash -make build && ./gitea -``` - -Before committing, make sure the linters pass: - -```bash -make lint-frontend -``` - -### Configuring local ElasticSearch instance - -Start local ElasticSearch instance using docker: - -```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 -``` - -Configure `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 -``` - -### Building and adding SVGs - -SVG icons are built using the `make svg` target which compiles the icon sources defined in `build/generate-svg.js` into the output directory `public/assets/img/svg`. Custom icons can be added in the `web_src/svg` directory. - -### Building the Logo - -The PNG and SVG versions of the Gitea logo are built from a single SVG source file `assets/logo.svg` using the `TAGS="gitea" make generate-images` target. To run it, Node.js and npm must be available. - -The same process can also be used to generate custom logo PNGs from a SVG source file by updating `assets/logo.svg` and running `make generate-images`. Omitting the `gitea` tag will update only the user-designated logo files. - -### Updating the API - -When creating new API routes or modifying existing API routes, you **MUST** -update and/or create [Swagger](https://swagger.io/docs/specification/2-0/what-is-swagger/) -documentation for these using [go-swagger](https://goswagger.io/) comments. -The structure of these comments is described in the [specification](https://goswagger.io/use/spec.html#annotation-syntax). -If you want more information about the Swagger structure, you can look at the -[Swagger 2.0 Documentation](https://swagger.io/docs/specification/2-0/basic-structure/) -or compare with a previous PR adding a new API endpoint, e.g. [PR #5483](https://github.com/go-gitea/gitea/pull/5843/files#diff-2e0a7b644cf31e1c8ef7d76b444fe3aaR20) - -You should be careful not to break the API for downstream users which depend -on a stable API. In general, this means additions are acceptable, but deletions -or fundamental changes to the API will be rejected. - -Once you have created or changed an API endpoint, please regenerate the Swagger -documentation using: - -```bash -make generate-swagger -``` - -You should validate your generated Swagger file and spell-check it with: - -```bash -make swagger-validate misspell-check -``` - -You should commit the changed swagger JSON file. The continuous integration -server will check that this has been done using: - -```bash -make swagger-check -``` - -**Note**: Please note you should use the Swagger 2.0 documentation, not the -OpenAPI 3 documentation. - -### Creating new configuration options - -When creating new configuration options, it is not enough to add them to the -`modules/setting` files. You should add information to `custom/conf/app.ini` -and to the -[configuration cheat sheet]({{< relref "doc/administration/config-cheat-sheet.en-us.md" >}}) -found in `docs/content/doc/administer/config-cheat-sheet.en-us.md` - -### Changing the logo - -When changing the Gitea logo SVG, you will need to run and commit the results -of: - -```bash -make generate-images -``` - -This will create the necessary Gitea favicon and others. - -### Database Migrations - -If you make breaking changes to any of the database persisted structs in the -`models/` directory, you will need to make a new migration. These can be found -in `models/migrations/`. You can ensure that your migrations work for the main -database types using: - -```bash -make test-sqlite-migration # with SQLite switched for the appropriate database -``` - -## Testing - -There are two types of test run by Gitea: Unit tests and Integration Tests. - -### Unit Tests - -Unit tests are covered by `*_test.go` in `go test` system. -You can set the environment variable `GITEA_UNIT_TESTS_LOG_SQL=1` to display all SQL statements when running the tests in verbose mode (i.e. when `GOTESTFLAGS=-v` is set). - -```bash -TAGS="bindata sqlite sqlite_unlock_notify" make test # Runs the unit tests -``` - -### Integration Tests - -Unit tests will not and cannot completely test Gitea alone. Therefore, we -have written integration tests; however, these are database dependent. - -```bash -TAGS="bindata sqlite sqlite_unlock_notify" make build test-sqlite -``` - -will run the integration tests in an SQLite environment. Integration tests -require `git lfs` to be installed. Other database tests are available but -may need adjustment to the local environment. - -Take a look at [`tests/integration/README.md`](https://github.com/go-gitea/gitea/blob/main/tests/integration/README.md) -for more information and how to run a single test. - -### Testing for a PR - -Our continuous integration will test the code passes its unit tests and that -all supported databases will pass integration test in a Docker environment. -Migration from several recent versions of Gitea will also be tested. - -Please submit your PR with additional tests and integration tests as -appropriate. - -## Documentation for the website - -Documentation for the website is found in `docs/`. If you change this you -can test your changes to ensure that they pass continuous integration using: - -```bash -# from the docs directory within Gitea -make trans-copy clean build -``` - -You will require a copy of [Hugo](https://gohugo.io/) to run this task. Please -note: this may generate a number of untracked Git objects, which will need to -be cleaned up. - -## Visual Studio Code - -A `launch.json` and `tasks.json` are provided within `contrib/ide/vscode` for -Visual Studio Code. Look at -[`contrib/ide/README.md`](https://github.com/go-gitea/gitea/blob/main/contrib/ide/README.md) -for more information. - -## GoLand - -Clicking the `Run Application` arrow on the function `func main()` in `/main.go` -can quickly start a debuggable Gitea instance. - -The `Output Directory` in `Run/Debug Configuration` MUST be set to the -gitea project directory (which contains `main.go` and `go.mod`), -otherwise, the started instance's working directory is a GoLand's temporary directory -and prevents Gitea from loading dynamic resources (eg: templates) in a development environment. - -To run unit tests with SQLite in GoLand, set `-tags sqlite,sqlite_unlock_notify` -in `Go tool arguments` of `Run/Debug Configuration`. - -## Submitting PRs - -Once you're happy with your changes, push them up and open a pull request. It -is recommended that you allow Gitea Managers and Owners to modify your PR -branches as we will need to update it to main before merging and/or may be -able to help fix issues directly. - -Any PR requires two approvals from the Gitea maintainers and needs to pass the -continuous integration. Take a look at our -[`CONTRIBUTING.md`](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md) -document. - -If you need more help pop on to [Discord](https://discord.gg/gitea) #Develop -and chat there. - -That's it! You are ready to hack on Gitea. diff --git a/docs/content/doc/development/hacking-on-gitea.zh-cn.md b/docs/content/doc/development/hacking-on-gitea.zh-cn.md deleted file mode 100644 index 6f0ce6bc0b..0000000000 --- a/docs/content/doc/development/hacking-on-gitea.zh-cn.md +++ /dev/null @@ -1,351 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "玩转 Gitea" -slug: "hacking-on-gitea" -weight: 10 -toc: false -draft: false -aliases: - - /zh-cn/hacking-on-gitea -menu: - sidebar: - parent: "development" - name: "玩转 Gitea" - weight: 10 - identifier: "hacking-on-gitea" ---- - -# Hacking on Gitea - -**目录** - -{{< toc >}} - -## 快速入门 - -要获得快速工作的开发环境，您可以使用 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 版本是 {{< min-node-version >}} -并且推荐使用最新的 LTS 版本。 - -**注意** ：当执行需要外部工具的 make 任务时，比如 -`make watch-backend`，Gitea 会自动下载并构建这些必要的组件。为了能够使用这些，你必须 -将 `"$GOPATH"/bin` 目录加入到可执行路径上。如果你不把go bin目录添加到可执行路径你必须手动 -指定可执行程序路径。 - -**注意2** ：Go版本 {{< min-go-version >}} 或更高版本是必须的。Gitea 使用 `gofmt` 来 -格式化源代码。然而，`gofmt` 的结果可能因 `go` 的版本而有差异。因此推荐安装我们持续集成使用 -的 Go版本。截至上次更新，Go 版本应该是 {{< go-version >}}。 - -## 安装 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（基本） - -看看我们的 -[说明]({{< relref "doc/installation/from-source.zh-cn.md" >}}) -关于如何[从源代码构建]({{< relref "doc/installation/from-source.zh-cn.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]({{< relref "doc/contributing/guidelines-frontend.zh-cn.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` -并到[配置备忘单]({{< relref "doc/administration/config-cheat-sheet.zh-cn.md" >}}) -在 `docs/content/doc/advanced/config-cheat-sheet.zh-cn.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。 diff --git a/docs/content/doc/development/integrations.en-us.md b/docs/content/doc/development/integrations.en-us.md deleted file mode 100644 index bbb50ae71d..0000000000 --- a/docs/content/doc/development/integrations.en-us.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -date: "2019-04-15T17:29:00+08:00" -title: "Integrations" -slug: "integrations" -weight: 65 -toc: false -draft: false -aliases: - - /en-us/integrations -menu: - sidebar: - parent: "development" - name: "Integrations" - weight: 65 - identifier: "integrations" ---- - -# Integrations - -Gitea has a wonderful community of third-party integrations, as well as first-class support in various other -projects. - -We are curating a list over at [awesome-gitea](https://gitea.com/gitea/awesome-gitea) to track these! - -If you are looking for [CI/CD](https://gitea.com/gitea/awesome-gitea#user-content-devops), -an [SDK](https://gitea.com/gitea/awesome-gitea#user-content-sdk), -or even some extra [themes](https://gitea.com/gitea/awesome-gitea#user-content-themes), -you can find them listed in the [awesome-gitea](https://gitea.com/gitea/awesome-gitea) repository! - -## Pre-Fill New File name and contents - -If you'd like to open a new file with a given name and contents, -you can do so with query parameters: - -```txt -GET /{{org}}/{{repo}}/_new/{{filepath}} - ?filename={{filename}} - &value={{content}} -``` - -For example: - -```txt -GET https://git.example.com/johndoe/bliss/_new/articles/ - ?filename=hello-world.md - &value=Hello%2C%20World! -``` diff --git a/docs/content/doc/development/integrations.zh-cn.md b/docs/content/doc/development/integrations.zh-cn.md deleted file mode 100644 index 694a9d5616..0000000000 --- a/docs/content/doc/development/integrations.zh-cn.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -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! -``` diff --git a/docs/content/doc/development/integrations.zh-tw.md b/docs/content/doc/development/integrations.zh-tw.md deleted file mode 100644 index 278a8f41d5..0000000000 --- a/docs/content/doc/development/integrations.zh-tw.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -date: "2019-04-15T17:29:00+08:00" -title: "整合" -slug: "integrations" -weight: 65 -toc: false -draft: false -aliases: - - /zh-tw/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) 或是其它佈景主題，您可以在存儲庫 [awesome-gitea](https://gitea.com/gitea/awesome-gitea) 找到他們。 diff --git a/docs/content/doc/development/migrations.en-us.md b/docs/content/doc/development/migrations.en-us.md deleted file mode 100644 index f411634156..0000000000 --- a/docs/content/doc/development/migrations.en-us.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -date: "2019-04-15T17:29:00+08:00" -title: "Migrations Interfaces" -slug: "migrations-interfaces" -weight: 55 -toc: false -draft: false -aliases: - - /en-us/migrations-interfaces -menu: - sidebar: - parent: "development" - name: "Migrations Interfaces" - weight: 55 - identifier: "migrations-interfaces" ---- - -# Migration Features - -Complete migrations were introduced in Gitea 1.9.0. It defines two interfaces to support migrating -repository data from other Git host platforms to Gitea or, in the future, migrating Gitea data to other Git host platforms. - -Currently, migrations from GitHub, GitLab, and other Gitea instances are implemented. - -First of all, Gitea defines some standard objects in packages [modules/migration](https://github.com/go-gitea/gitea/tree/main/modules/migration). -They are `Repository`, `Milestone`, `Release`, `ReleaseAsset`, `Label`, `Issue`, `Comment`, `PullRequest`, `Reaction`, `Review`, `ReviewComment`. - -## Downloader Interfaces - -To migrate from a new Git host platform, there are two steps to be updated. - -- You should implement a `Downloader` which will be used to get repository information. -- You should implement a `DownloaderFactory` which will be used to detect if the URL matches and create the above `Downloader`. - - You'll need to register the `DownloaderFactory` via `RegisterDownloaderFactory` on `init()`. - -You can find these interfaces in [downloader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/downloader.go). - -## Uploader Interface - -Currently, only a `GiteaLocalUploader` is implemented, so we only save downloaded -data via this `Uploader` to the local Gitea instance. Other uploaders are not supported at this time. - -You can find these interfaces in [uploader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/uploader.go). diff --git a/docs/content/doc/development/migrations.zh-cn.md b/docs/content/doc/development/migrations.zh-cn.md deleted file mode 100644 index 8e3d73417d..0000000000 --- a/docs/content/doc/development/migrations.zh-cn.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -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)中找到这些接口。 diff --git a/docs/content/doc/development/migrations.zh-tw.md b/docs/content/doc/development/migrations.zh-tw.md deleted file mode 100644 index c4171f3fb7..0000000000 --- a/docs/content/doc/development/migrations.zh-tw.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -date: "2019-04-15T17:29:00+08:00" -title: "遷移介面" -slug: "migrations-interfaces" -weight: 55 -toc: false -draft: false -aliases: - - /zh-tw/migrations-interfaces -menu: - sidebar: - parent: "development" - name: "遷移介面" - weight: 55 - identifier: "migrations-interfaces" ---- - -# 遷移功能 - -完整的遷移從 Gitea 1.9.0 開始提供。它定義了兩個介面用來從其它 Git 託管平臺遷移儲存庫資料到 Gitea，未來或許會提供遷移到其它 git 託管平臺。 -目前已實作了從 Github, Gitlab 和其它 Gitea 遷移資料。 - -Gitea 定義了一些基本物件於套件 [modules/migration](https://github.com/go-gitea/gitea/tree/master/modules/migration)。 -分別是 `Repository`, `Milestone`, `Release`, `ReleaseAsset`, `Label`, `Issue`, `Comment`, `PullRequest`, `Reaction`, `Review`, `ReviewComment`。 - -## Downloader 介面 - -從新的 Git 託管平臺遷移，有兩個新的步驟。 - -- 您必須實作一個 `Downloader`，它用來取得儲存庫資訊。 -- 您必須實作一個 `DownloaderFactory`，它用來偵測 URL 是否符合並建立上述的 `Downloader`。 - - 您需要在 `init()` 透過 `RegisterDownloaderFactory` 來註冊 `DownloaderFactory`。 - -您可以在 [downloader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/downloader.go) 中找到這些介面。 - -## Uploader 介面 - -目前只有 `GiteaLocalUploader` 被實作出來，所以我們只能通過 `Uploader` 儲存已下載的資料到本地的 Gitea 實例。 -目前尚未支援其它 Uploader。 - -您可以在 [uploader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/uploader.go) 中找到這些介面。 diff --git a/docs/content/doc/development/oauth2-provider.en-us.md b/docs/content/doc/development/oauth2-provider.en-us.md deleted file mode 100644 index f7a73dcc88..0000000000 --- a/docs/content/doc/development/oauth2-provider.en-us.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -date: "2023-06-01T08:40:00+08:00" -title: "OAuth2 provider" -slug: "oauth2-provider" -weight: 41 -toc: false -draft: false -aliases: - - /en-us/oauth2-provider -menu: - sidebar: - parent: "development" - name: "OAuth2 Provider" - weight: 41 - identifier: "oauth2-provider" ---- - -# OAuth2 provider - -**Table of Contents** - -{{< toc >}} - -Gitea supports acting as an OAuth2 provider to allow third party applications to access its resources with the user's consent. This feature is available since release 1.8.0. - -## Endpoints - -| Endpoint | 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` | - -## Supported OAuth2 Grants - -At the moment Gitea only supports the [**Authorization Code Grant**](https://tools.ietf.org/html/rfc6749#section-1.3.1) standard with additional support of the following extensions: - -- [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) - -To use the Authorization Code Grant as a third party application it is required to register a new application via the "Settings" (`/user/settings/applications`) section of the settings. To test or debug you can use the web-tool https://oauthdebugger.com/. - -## Scopes - -Gitea supports scoped access tokens, which allow users the ability to restrict tokens to operate only on selected url routes. Scopes are grouped by high-level API routes, and further refined to the following: - -- `read`: `GET` routes -- `write`: `POST`, `PUT`, `PATCH`, and `DELETE` routes (in addition to `GET`) - -Gitea token scopes are as follows: - -| Name | Description | -| ---- |------------------------------------------------------------------------------------------------------------------------------------------------------| -| **(no scope)** | Not supported. A scope is required even for public repositories. | -| **activitypub** | `activitypub` API routes: ActivityPub related operations. | -| **read:activitypub** | Grants read access for ActivityPub operations. | -| **write:activitypub** | Grants read/write/delete access for ActivityPub operations. | -| **admin** | `/admin/*` API routes: Site-wide administrative operations (hidden for non-admin accounts). | -| **read:admin** | Grants read access for admin operations, such as getting cron jobs or registered user emails. | -| **write:admin** | Grants read/write/delete access for admin operations, such as running cron jobs or updating user accounts. | -| **issue** | `issues/*`, `labels/*`, `milestones/*` API routes: Issue-related operations. | -| **read:issue** | Grants read access for issues operations, such as getting issue comments, issue attachments, and milestones. | -| **write:issue** | Grants read/write/delete access for issues operations, such as posting or editing an issue comment or attachment, and updating milestones. | -| **misc** | Reserved for future usage. | -| **read:misc** | Reserved for future usage. | -| **write:misc** | Reserved for future usage. | -| **notification** | `notification/*` API routes: user notification operations. | -| **read:notification** | Grants read access to user notifications, such as which notifications users are subscribed to and read new notifications. | -| **write:notification** | Grants read/write/delete access to user notifications, such as marking notifications as read. | -| **organization** | `orgs/*` and `teams/*` API routes: Organization and team management operations. | -| **read:organization** | Grants read access to org and team status, such as listing all orgs a user has visibility to, teams, and team members. | -| **write:organization** | Grants read/write/delete access to org and team status, such as creating and updating teams and updating org settings. | -| **package** | `/packages/*` API routes: Packages operations | -| **read:package** | Grants read access to package operations, such as reading and downloading available packages. | -| **write:package** | Grants read/write/delete access to package operations. Currently the same as `read:package`. | -| **repository** | `/repos/*` API routes except `/repos/issues/*`: Repository file, pull-request, and release operations. | -| **read:repository** | Grants read access to repository operations, such as getting repository files, releases, collaborators. | -| **write:repository** | Grants read/write/delete access to repository operations, such as getting updating repository files, creating pull requests, updating collaborators. | -| **user** | `/user/*` and `/users/*` API routes: User-related operations. | -| **read:user** | Grants read access to user operations, such as getting user repo subscriptions and user settings. | -| **write:user** | Grants read/write/delete access to user operations, such as updating user repo subscriptions, followed users, and user settings. | - -## Client types - -Gitea supports both confidential and public client types, [as defined by RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1). - -For public clients, a redirect URI of a loopback IP address such as `http://127.0.0.1/` allows any port. Avoid using `localhost`, [as recommended by RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252#section-8.3). - -## Examples - -### Confidential client - -**Note:** This example does not use PKCE. - -1. Redirect the user to the authorization endpoint in order to get their consent for accessing the resources: - - ```curl - https://[YOUR-GITEA-URL]/login/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=code&state=STATE - ``` - - The `CLIENT_ID` can be obtained by registering an application in the settings. The `STATE` is a random string that will be sent back to your application after the user authorizes. The `state` parameter is optional, but should be used to prevent CSRF attacks. - -  - - The user will now be asked to authorize your application. If they authorize it, the user will be redirected to the `REDIRECT_URL`, for example: - - ```curl - https://[REDIRECT_URI]?code=RETURNED_CODE&state=STATE - ``` - -2. Using the provided `code` from the redirect, you can request a new application and refresh token. The access token endpoint accepts POST requests with `application/json` and `application/x-www-form-urlencoded` body, for example: - - ```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" - } - ``` - - Response: - - ```json - { - "access_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjowLCJleHAiOjE1NTUxNzk5MTIsImlhdCI6MTU1NTE3NjMxMn0.0-iFsAwBtxuckA0sNZ6QpBQmywVPz129u75vOM7wPJecw5wqGyBkmstfJHAjEOqrAf_V5Z-1QYeCh_Cz4RiKug", - "token_type": "bearer", - "expires_in": 3600, - "refresh_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjoxLCJjbnQiOjEsImV4cCI6MTU1NzgwNDMxMiwiaWF0IjoxNTU1MTc2MzEyfQ.S_HZQBy4q9r5SEzNGNIoFClT43HPNDbUdHH-GYNYYdkRfft6XptJBkUQscZsGxOW975Yk6RbgtGvq1nkEcklOw" - } - ``` - - The `CLIENT_SECRET` is the unique secret code generated for this application. Please note that the secret will only be visible after you created/registered the application with Gitea and cannot be recovered. If you lose the secret, you must regenerate the secret via the application's settings. - - The `REDIRECT_URI` in the `access_token` request must match the `REDIRECT_URI` in the `authorize` request. - -3. Use the `access_token` to make [API requests](https://docs.gitea.io/en-us/api-usage#oauth2) to access the user's resources. - -### Public client (PKCE) - -PKCE (Proof Key for Code Exchange) is an extension to the OAuth flow which allows for a secure credential exchange without the requirement to provide a client secret. - -**Note**: Please ensure you have registered your OAuth application as a public client. - -To achieve this, you have to provide a `code_verifier` for every authorization request. A `code_verifier` has to be a random string with a minimum length of 43 characters and a maximum length of 128 characters. It can contain alphanumeric characters as well as the characters `-`, `.`, `_` and `~`. - -Using this `code_verifier` string, a new one called `code_challenge` is created by using one of two methods: - -- If you have the required functionality on your client, set `code_challenge` to be a URL-safe base64-encoded string of the SHA256 hash of `code_verifier`. In that case, your `code_challenge_method` becomes `S256`. -- If you are unable to do so, you can provide your `code_verifier` as a plain string to `code_challenge`. Then you have to set your `code_challenge_method` as `plain`. - -After you have generated this values, you can continue with your request. - -1. Redirect the user to the authorization endpoint in order to get their consent for accessing the resources: - - ```curl - https://[YOUR-GITEA-URL]/login/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=code&code_challenge_method=CODE_CHALLENGE_METHOD&code_challenge=CODE_CHALLENGE&state=STATE - ``` - - The `CLIENT_ID` can be obtained by registering an application in the settings. The `STATE` is a random string that will be sent back to your application after the user authorizes. The `state` parameter is optional, but should be used to prevent CSRF attacks. - -  - - The user will now be asked to authorize your application. If they authorize it, the user will be redirected to the `REDIRECT_URL`, for example: - - ```curl - https://[REDIRECT_URI]?code=RETURNED_CODE&state=STATE - ``` - -2. Using the provided `code` from the redirect, you can request a new application and refresh token. The access token endpoint accepts POST requests with `application/json` and `application/x-www-form-urlencoded` body, for example: - - ```curl - POST https://[YOUR-GITEA-URL]/login/oauth/access_token - ``` - - ```json - { - "client_id": "YOUR_CLIENT_ID", - "code": "RETURNED_CODE", - "grant_type": "authorization_code", - "redirect_uri": "REDIRECT_URI", - "code_verifier": "CODE_VERIFIER", - } - ``` - - Response: - - ```json - { - "access_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjowLCJleHAiOjE1NTUxNzk5MTIsImlhdCI6MTU1NTE3NjMxMn0.0-iFsAwBtxuckA0sNZ6QpBQmywVPz129u75vOM7wPJecw5wqGyBkmstfJHAjEOqrAf_V5Z-1QYeCh_Cz4RiKug", - "token_type": "bearer", - "expires_in": 3600, - "refresh_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjoxLCJjbnQiOjEsImV4cCI6MTU1NzgwNDMxMiwiaWF0IjoxNTU1MTc2MzEyfQ.S_HZQBy4q9r5SEzNGNIoFClT43HPNDbUdHH-GYNYYdkRfft6XptJBkUQscZsGxOW975Yk6RbgtGvq1nkEcklOw" - } - ``` - - The `REDIRECT_URI` in the `access_token` request must match the `REDIRECT_URI` in the `authorize` request. - -3. Use the `access_token` to make [API requests](https://docs.gitea.io/en-us/api-usage#oauth2) to access the user's resources. diff --git a/docs/content/doc/development/oauth2-provider.zh-cn.md b/docs/content/doc/development/oauth2-provider.zh-cn.md deleted file mode 100644 index 3fbf174efc..0000000000 --- a/docs/content/doc/development/oauth2-provider.zh-cn.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -date: "2019-04-19:44:00+01:00" -title: "OAuth2 提供者" -slug: "oauth2-provider" -weight: 41 -toc: false -draft: false -aliases: - - /zh-cn/oauth2-provider -menu: - sidebar: - parent: "development" - name: "OAuth2 提供者" - weight: 41 - identifier: "oauth2-provider" ---- - -# OAuth2 提供者 - -**目录** - -{{< toc >}} - -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) 以读写用户的资源。 diff --git a/docs/content/doc/development/oauth2-provider.zh-tw.md b/docs/content/doc/development/oauth2-provider.zh-tw.md deleted file mode 100644 index 8d62264abc..0000000000 --- a/docs/content/doc/development/oauth2-provider.zh-tw.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -date: "2019-04-19:44:00+01:00" -title: "OAuth2 提供者" -slug: "oauth2-provider" -weight: 41 -toc: false -draft: false -aliases: - - /zh-tw/oauth2-provider -menu: - sidebar: - parent: "development" - name: "OAuth2 提供者" - weight: 41 - identifier: "oauth2-provider" ---- - -# OAuth2 提供者 - -**目錄** - -{{< toc >}} - -Gitea 支援作為 OAuth2 提供者，能讓第三方程式能在使用者同意下存取 Gitea 的資源。此功能自 1.8.0 版開始提供。 - -## Endpoint - -| Endpoint | URL | -| ---------------------- | --------------------------- | -| Authorization Endpoint | `/login/oauth/authorize` | -| Access Token Endpoint | `/login/oauth/access_token` | - -## 支援的 OAuth2 Grant - -目前 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`)中註冊一個新的應用程式。 - -## Scope - -目前 Gitea 尚未支援 scope （參見 [#4300](https://github.com/go-gitea/gitea/issues/4300)），所有的第三方程式都可獲得該使用者及他所屬的組織中所有資源的存取權。 - -## 範例 - -**備註：** 此範例未使用 PKCE。 - -1. 重新導向使用者到 authorization endpoint 以獲得他同意授權存取資源： - <!-- 1. Redirect to user to the authorization endpoint in order to get their consent for accessing the resources: --> - - ```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 - ``` - -1. 使用重新導向提供的 `code`，您可以要求一個新的應用程式和 Refresh Token。Access Token Endpoint 接受 POST 請求使用 `application/json` 或 `application/x-www-form-urlencoded` 類型的請求內容，例如： - - ```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`。 - -1. 發送 [API requests](https://docs.gitea.io/en-us/api-usage#oauth2) 時使用 `access_token` 以存取使用者的資源。 diff --git a/docs/content/doc/help.en-us.md b/docs/content/doc/help.en-us.md deleted file mode 100644 index 03c9a27818..0000000000 --- a/docs/content/doc/help.en-us.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2017-01-20T15:00:00+08:00" -title: "Help" -slug: "help" -weight: 5 -toc: false -draft: false -menu: - sidebar: - name: "Help" - weight: 100 - identifier: "help" ---- diff --git a/docs/content/doc/help.fr-fr.md b/docs/content/doc/help.fr-fr.md deleted file mode 100644 index 42e01009ce..0000000000 --- a/docs/content/doc/help.fr-fr.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2017-01-20T15:00:00+08:00" -title: "Aide" -slug: "help" -weight: 5 -toc: false -draft: false -menu: - sidebar: - name: "Aide" - weight: 100 - identifier: "help" ---- diff --git a/docs/content/doc/help.zh-cn.md b/docs/content/doc/help.zh-cn.md deleted file mode 100644 index e8c0bd260b..0000000000 --- a/docs/content/doc/help.zh-cn.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2017-01-20T15:00:00+08:00" -title: "帮助" -slug: "help" -weight: 5 -toc: false -draft: false -menu: - sidebar: - name: "帮助" - weight: 100 - identifier: "help" ---- diff --git a/docs/content/doc/help.zh-tw.md b/docs/content/doc/help.zh-tw.md deleted file mode 100644 index 270a4ed8a7..0000000000 --- a/docs/content/doc/help.zh-tw.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2017-01-20T15:00:00+08:00" -title: "幫助" -slug: "help" -weight: 5 -toc: false -draft: false -menu: - sidebar: - name: "幫助" - weight: 100 - identifier: "help" ---- diff --git a/docs/content/doc/help/_index.en-us.md b/docs/content/doc/help/_index.en-us.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/help/_index.en-us.md +++ /dev/null diff --git a/docs/content/doc/help/_index.zh-cn.md b/docs/content/doc/help/_index.zh-cn.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/help/_index.zh-cn.md +++ /dev/null diff --git a/docs/content/doc/help/_index.zh-tw.md b/docs/content/doc/help/_index.zh-tw.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/help/_index.zh-tw.md +++ /dev/null diff --git a/docs/content/doc/help/faq.en-us.md b/docs/content/doc/help/faq.en-us.md deleted file mode 100644 index 5a2cafba49..0000000000 --- a/docs/content/doc/help/faq.en-us.md +++ /dev/null @@ -1,466 +0,0 @@ ---- -date: "2019-04-05T16:00:00+02:00" -title: "FAQ" -slug: "faq" -weight: 5 -toc: false -draft: false -aliases: - - /en-us/faq -menu: - sidebar: - parent: "help" - name: "FAQ" - weight: 5 - identifier: "faq" ---- - -# Frequently Asked Questions <!-- omit in toc --> - -This page contains some common questions and answers. - -For more help resources, check all [Support Options]({{< relref "doc/help/support.en-us.md" >}}). - -**Table of Contents** - -{{< toc >}} - -## Difference between 1.x and 1.x.x downloads, how can I get latest stable release with bug fixes? - -Version 1.20.x will be used for this example. - -On our [downloads page](https://dl.gitea.com/gitea/) you will see a 1.20 directory, as well as directories for 1.20.0, 1.20.1. - -The 1.20 directory is the nightly build, which is built on each merged commit to the [`release/v1.20`](https://github.com/go-gitea/gitea/tree/release/v1.20) branch. - -The 1.20.0 directory is a release build that was created when the [`v1.20.0`](https://github.com/go-gitea/gitea/releases/tag/v1.20.0) tag was created. - -The nightly builds (1.x) downloads will change as commits are merged to their respective branch, they contain the latest changes/fixes before a tag release is built. - -If a bug fix is targeted on 1.20.1 but 1.20.1 is not released yet, you can get the "1.20-nightly" build to get the bug fix. - -## How to migrate from Gogs/GitHub/etc. to Gitea - -To migrate from Gogs to Gitea: - -- [Gogs version 0.9.146 or less]({{< relref "doc/installation/upgrade-from-gogs.en-us.md" >}}) -- [Gogs version 0.11.46.0418](https://github.com/go-gitea/gitea/issues/4286) - -To migrate from GitHub to Gitea, you can use Gitea's built-in migration form. - -In order to migrate items such as issues, pull requests, etc. you will need to input at least your username. - -[Example (requires login)](https://try.gitea.io/repo/migrate) - -To migrate from GitLab to Gitea, you can use this non-affiliated tool: - -https://github.com/loganinak/MigrateGitlabToGogs - -## Where does Gitea store what file - -- _`AppWorkPath`_ - - The `WORK_PATH` option in `app.ini` - - Else the `--work-path` flag - - Else Environment variable `GITEA_WORK_DIR` - - Else a built-in value set at build time - - Else the directory that contains the Gitea binary -- `AppDataPath` (default for database, indexers, etc.) - - `APP_DATA_PATH` from `app.ini` - - Else _`AppWorkPath`_`/data` -- _`CustomPath`_ (custom templates) - - The `--custom-path` flag - - Else Environment variable `GITEA_CUSTOM` - - Else a built-in value set at build time - - Else _`AppWorkPath`_`/custom` -- HomeDir - - Unix: Environment variable `HOME` - - Windows: Environment variable `USERPROFILE`, else environment variables `HOMEDRIVE`+`HOMEPATH` -- RepoRootPath - - `ROOT` in the \[repository] section of `app.ini` if absolute - - Else _`AppWorkPath`_`/ROOT` if `ROOT` in the \[repository] section of `app.ini` if relative - - Default `%(APP_DATA_PATH)/gitea-repositories` -- INI (config file) - - `--config` flag - - A possible built-in value set a build time - - Else _`CustomPath`_`/conf/app.ini` -- SQLite Database - - `PATH` in `database` section of `app.ini` - - Else `%(APP_DATA_PATH)/gitea.db` - -## Not seeing a clone URL or the clone URL being incorrect - -There are a few places that could make this show incorrectly. - -1. If using a reverse proxy, make sure you have followed the correction directions in the [reverse proxy guide]({{< relref "doc/administration/reverse-proxies.en-us.md" >}}) -2. Make sure you have correctly set `ROOT_URL` in the `server` section of your `app.ini` - -If certain clone options aren't showing up (HTTP/S or SSH), the following options can be checked in your `app.ini` - -- `DISABLE_HTTP_GIT`: if set to true, there will be no HTTP/HTTPS link -- `DISABLE_SSH`: if set to true, there will be no SSH link -- `SSH_EXPOSE_ANONYMOUS`: if set to false, SSH links will be hidden for anonymous users - -## File upload fails with: 413 Request Entity Too Large - -This error occurs when the reverse proxy limits the file upload size. - -See the [reverse proxy guide]({{< relref "doc/administration/reverse-proxies.en-us.md" >}}) for a solution with nginx. - -## Custom Templates not loading or working incorrectly - -Gitea's custom templates must be added to the correct location or Gitea will not find and use them. - -The correct path for the template(s) will be relative to the `CustomPath` - -1. To find `CustomPath`, look for Custom File Root Path in Site Administration -> Configuration -2. If you are still unable to find a path, the default can be [calculated above](#where-does-gitea-store-what-file) -3. Once you have figured out the correct custom path, you can refer to the [customizing Gitea]({{< relref "doc/administration/customizing-gitea.en-us.md" >}}) page to add your template to the correct location. - -## Does Gitea have a "GitHub/GitLab pages" feature? - -Gitea doesn't provide a built-in Pages server. You need a dedicated domain to serve static pages to avoid CSRF security risks. - -For simple usage, you can use a reverse proxy to rewrite & serve static contents from Gitea's raw file URLs. - -And there are already available third-party services, like a standalone [pages server](https://codeberg.org/Codeberg/pages-server) or a [caddy plugin](https://github.com/42wim/caddy-gitea), that can provide the required functionality. - -## Active user vs login prohibited user - -In Gitea, an "active" user refers to a user that has activated their account via email. - -A "login prohibited" user is a user that is not allowed to log in to Gitea anymore - -## Setting up logging - -- [Official Docs]({{< relref "doc/administration/logging-config.en-us.md" >}}) - -## What is Swagger? - -[Swagger](https://swagger.io/) is what Gitea uses for its API documentation. - -All Gitea instances have the built-in API and there is no way to disable it completely. -You can, however, disable showing its documentation by setting `ENABLE_SWAGGER` to `false` in the `api` section of your `app.ini`. -For more information, refer to Gitea's [API docs]({{< relref "doc/development/api-usage.en-us.md" >}}). - -You can see the latest API (for example) on <https://try.gitea.io/api/swagger>. - -You can also see an example of the `swagger.json` file at <https://try.gitea.io/swagger.v1.json>. - -## Adjusting your server for public/private use - -### Preventing spammers - -There are multiple things you can combine to prevent spammers. - -1. By whitelisting or blocklisting certain email domains -2. By only whitelisting certain domains with OpenID (see below) -3. Setting `ENABLE_CAPTCHA` to `true` in your `app.ini` and properly configuring `RECAPTCHA_SECRET` and `RECAPTCHA_SITEKEY` -4. Settings `DISABLE_REGISTRATION` to `true` and creating new users via the [CLI]({{< relref "doc/administration/command-line.en-us.md" >}}), [API]({{< relref "doc/development/api-usage.en-us.md" >}}), or Gitea's Admin UI - -### Only allow/block certain email domains - -You can configure `EMAIL_DOMAIN_WHITELIST` or `EMAIL_DOMAIN_BLOCKLIST` in your app.ini under `[service]` - -### Only allow/block certain OpenID providers - -You can configure `WHITELISTED_URIS` or `BLACKLISTED_URIS` under `[openid]` in your `app.ini` - -**NOTE:** whitelisted takes precedence, so if it is non-blank then blacklisted is ignored - -### Issue only users - -The current way to achieve this is to create/modify a user with a max repo creation limit of 0. - -### Restricted users - -Restricted users are limited to a subset of the content based on their organization/team memberships and collaborations, ignoring the public flag on organizations/repos etc.\_\_ - -Example use case: A company runs a Gitea instance that requires login. Most repos are public (accessible/browsable by all co-workers). - -At some point, a customer or third party needs access to a specific repo and only that repo. Making such a customer account restricted and granting any needed access using team membership(s) and/or collaboration(s) is a simple way to achieve that without the need to make everything private. - -### Enable Fail2ban - -Use [Fail2Ban]({{< relref "doc/administration/fail2ban-setup.en-us.md" >}}) to monitor and stop automated login attempts or other malicious behavior based on log patterns - -## How to add/use custom themes - -Gitea supports three official themes right now, `gitea` (light), `arc-green` (dark), and `auto` (automatically switches between the previous two depending on operating system settings). -To add your own theme, currently the only way is to provide a complete theme (not just color overrides) - -As an example, let's say our theme is `arc-blue` (this is a real theme, and can be found [in this issue](https://github.com/go-gitea/gitea/issues/6011)) - -Name the `.css` file `theme-arc-blue.css` and add it to your custom folder in `custom/public/assets/css` - -Allow users to use it by adding `arc-blue` to the list of `THEMES` in your `app.ini` - -## SSHD vs built-in SSH - -SSHD is the built-in SSH server on most Unix systems. - -Gitea also provides its own SSH server, for usage when SSHD is not available. - -## Gitea is running slow - -The most common culprit for this is loading federated avatars. - -This can be turned off by setting `ENABLE_FEDERATED_AVATAR` to `false` in your `app.ini` - -Another option that may need to be changed is setting `DISABLE_GRAVATAR` to `true` in your `app.ini` - -## Can't create repositories/files - -Make sure that Gitea has sufficient permissions to write to its home directory and data directory. - -See [AppDataPath and RepoRootPath](#where-does-gitea-store-what-file) - -**Note for Arch users:** At the time of writing this, there is an issue with the Arch package's systemd file including this line: - -`ReadWritePaths=/etc/gitea/app.ini` - -Which makes all other paths non-writeable to Gitea. - -## Translation is incorrect/how to add more translations - -Our translations are currently crowd-sourced on our [Crowdin project](https://crowdin.com/project/gitea) - -Whether you want to change a translation or add a new one, it will need to be there as all translations are overwritten in our CI via the Crowdin integration. - -## Push Hook / Webhook aren't running - -If you can push but can't see push activities on the home dashboard, or the push doesn't trigger webhook, there are a few possibilities: - -1. The git hooks are out of sync: run "Resynchronize pre-receive, update and post-receive hooks of all repositories" on the site admin panel -2. The git repositories (and hooks) are stored on some filesystems (ex: mounted by NAS) which don't support script execution, make sure the filesystem supports `chmod a+x any-script` -3. If you are using docker, make sure Docker Server (not the client) >= 20.10.6 - -## SSH issues - -If you cannot reach repositories over `ssh`, but `https` works fine, consider looking into the following. - -First, make sure you can access Gitea via SSH. - -`ssh git@myremote.example` - -If the connection is successful, you should receive an error message like the following: - -``` -Hi there, You've successfully authenticated, but Gitea does not provide shell access. -If this is unexpected, please log in with password and setup Gitea under another user. -``` - -If you do not get the above message but still connect, it means your SSH key is **not** being managed by Gitea. This means hooks won't run, among other potential problems. - -If you cannot connect at all, your SSH key may not be configured correctly locally. -This is specific to SSH and not Gitea, so will not be covered here. - -### SSH Common Errors - -``` -Permission denied (publickey). -fatal: Could not read from remote repository. -``` - -This error signifies that the server rejected a log in attempt, check the -following things: - -- On the client: - - Ensure the public and private ssh keys are added to the correct Gitea user. - - Make sure there are no issues in the remote url. In particular, ensure the name of the - Git user (before the `@`) is spelled correctly. - - Ensure public and private ssh keys are correct on client machine. -- On the server: - - Make sure the repository exists and is correctly named. - - Check the permissions of the `.ssh` directory in the system user's home directory. - - Verify that the correct public keys are added to `.ssh/authorized_keys`. - - Try to run `Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys)` on the - Gitea admin panel. - - Read Gitea logs. - - Read /var/log/auth (or similar). - - Check permissions of repositories. - -The following is an example of a missing public SSH key where authentication -succeeded, but some other setting is preventing SSH from reaching the correct -repository. - -``` -fatal: Could not read from remote repository. - -Please make sure you have the correct access rights -and the repository exists. -``` - -In this case, look into the following settings: - -- On the server: - - Make sure that the `git` system user has a usable shell set - - Verify this with `getent passwd git | cut -d: -f7` - - `usermod` or `chsh` can be used to modify this. - - Ensure that the `gitea serv` command in `.ssh/authorized_keys` uses the - correct configuration file. - -## Missing releases after migrating repository with tags - -To migrate an repository _with_ all tags, you need to do two things: - -- Push tags to the repository: - -``` - git push --tags -``` - -- (Re-)sync tags of all repositories within Gitea: - -``` -gitea admin repo-sync-releases -``` - -## LFS Issues - -For issues concerning LFS data upload - -``` -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>' -``` - -Check the value of `LFS_HTTP_AUTH_EXPIRY` in your `app.ini` file. - -By default, your LFS token will expire after 20 minutes. If you have a slow connection or a large file (or both), it may not finish uploading within the time limit. - -You may want to set this value to `60m` or `120m`. - -## How can I create users before starting Gitea - -Gitea provides a sub-command `gitea migrate` to initialize the database, after which you can use the [admin CLI commands]({{< relref "doc/administration/command-line.en-us.md#admin" >}}) to add users like normal. - -## How can I enable password reset - -There is no setting for password resets. It is enabled when a [mail service]({{< relref "doc/administration/email-setup.en-us.md" >}}) is configured, and disabled otherwise. - -## How can a user's password be changed - -- As an **admin**, you can change any user's password (and optionally force them to change it on next login)... - - By navigating to your `Site Administration -> User Accounts` page and editing a user. - - By using the [admin CLI commands]({{< relref "doc/administration/command-line.en-us.md#admin" >}}). - - Keep in mind most commands will also need a [global flag]({{< relref "doc/administration/command-line.en-us.md#global-options" >}}) to point the CLI at the correct configuration. -- As a **user** you can change it... - - In your account `Settings -> Account` page (this method **requires** you to know your current password). - - By using the `Forgot Password` link. - - If the `Forgot Password/Account Recovery` page is disabled, please contact your administrator to configure a [mail service]({{< relref "doc/administration/email-setup.en-us.md" >}}). - -## Why is my markdown broken - -In Gitea version `1.11` we moved to [goldmark](https://github.com/yuin/goldmark) for markdown rendering, which is [CommonMark](https://commonmark.org/) compliant. - -If you have markdown that worked as you expected prior to version `1.11` and after upgrading it's not working anymore, please look through the CommonMark spec to see whether the problem is due to a bug or non-compliant syntax. - -If it is the latter, _usually_ there is a compliant alternative listed in the spec. - -## Upgrade errors with MySQL - -If you are receiving errors on upgrade of Gitea using MySQL that read: - -> `ORM engine initialization failed: migrate: do migrate: Error: 1118: Row size too large...` - -Please run `gitea convert` or run `ALTER TABLE table_name ROW_FORMAT=dynamic;` for each table in the database. - -The underlying problem is that the space allocated for indices by the default row format -is too small. Gitea requires that the `ROWFORMAT` for its tables is `DYNAMIC`. - -If you are receiving an error line containing `Error 1071: Specified key was too long; max key length is 1000 bytes...` -then you are attempting to run Gitea on tables which use the ISAM engine. While this may have worked by chance in previous versions of Gitea, it has never been officially supported and -you must use InnoDB. You should run `ALTER TABLE table_name ENGINE=InnoDB;` for each table in the database. - -If you are using MySQL 5, another possible fix is - -```mysql -SET GLOBAL innodb_file_format=Barracuda; -SET GLOBAL innodb_file_per_table=1; -SET GLOBAL innodb_large_prefix=1; -``` - -## Why Are Emoji Broken On MySQL - -Unfortunately MySQL's `utf8` charset does not completely allow all possible UTF-8 characters, in particular Emoji. -They created a new charset and collation called `utf8mb4` that allows for emoji to be stored but tables which use -the `utf8` charset, and connections which use the `utf8` charset will not use this. - -Please run `gitea convert`, or run `ALTER DATABASE database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;` -for the database_name and run `ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;` -for each table in the database. - -## Why are Emoji displaying only as placeholders or in monochrome - -Gitea requires the system or browser to have one of the supported Emoji fonts installed, which are Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol, Noto Color Emoji and Twemoji Mozilla. Generally, the operating system should already provide one of these fonts, but especially on Linux, it may be necessary to install them manually. - -## Initial logging - -Before Gitea has read the configuration file and set-up its logging it will log a number of things to stdout in order to help debug things if logging does not work. - -You can stop this logging by setting the `--quiet` or `-q` option. Please note this will only stop logging until Gitea has set-up its own logging. - -If you report a bug or issue you MUST give us logs with this information restored. - -You should only set this option once you have completely configured everything. - -## Warnings about struct defaults during database startup - -Sometimes when there are migrations the old columns and default values may be left -unchanged in the database schema. This may lead to warning such as: - -``` -2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync2() [W] Table user Column keep_activity_private db default is , struct default is 0 -``` - -These can safely be ignored, but you are able to stop these warnings by getting Gitea to recreate these tables using: - -``` -gitea doctor recreate-table user -``` - -This will cause Gitea to recreate the user table and copy the old data into the new table -with the defaults set appropriately. - -You can ask Gitea to recreate multiple tables using: - -``` -gitea doctor recreate-table table1 table2 ... -``` - -And if you would like Gitea to recreate all tables simply call: - -``` -gitea doctor recreate-table -``` - -It is highly recommended to back-up your database before running these commands. - -## How to adopt repositories from disk - -- Add your (bare) repositories to the correct spot for your configuration (`repository.ROOT`), ensuring they are in the correct layout `<REPO_ROOT>/[user]/[repo].git`. - - **Note:** the directory names must be lowercase. - - You can also check `<ROOT_URL>/admin/config` for the repository root path. -- Ensure that the user/org exists that you want to adopt repositories for. -- As an admin, go to `<ROOT_URL>/admin/repos/unadopted` and search. - - Users can also be given similar permissions via config [`ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`]({{< relref "doc/administration/config-cheat-sheet.en-us.md#repository" >}}). -- If the above steps are done correctly, you should be able to select repositories to adopt. - - If no repositories are found, enable [debug logging]({{< relref "doc/administration/config-cheat-sheet.en-us.md#repository" >}}) to check for any specific errors. - -## Gitea can't start on NFS - -In most cases, it's caused by broken NFS lock system. You can try to stop Gitea process and -run `flock -n /data-nfs/gitea/queues/LOCK echo 'lock acquired'` to see whether the lock can be acquired immediately. -If the lock can't be acquired, NFS might report some errors like `lockd: cannot monitor node-3, statd: server rpc.statd not responding, timed out` in its server logs. - -Then the NFS lock could be reset by: - -```bash -# /etc/init.d/nfs stop -# rm -rf /var/lib/nfs/sm/* -# /etc/init.d/nfs start -``` diff --git a/docs/content/doc/help/faq.zh-cn.md b/docs/content/doc/help/faq.zh-cn.md deleted file mode 100644 index 6a63b4530e..0000000000 --- a/docs/content/doc/help/faq.zh-cn.md +++ /dev/null @@ -1,472 +0,0 @@ ---- -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/support.zh-cn.md" >}})。 - -**目录** - -{{< toc >}} - -## 1.x和1.x.x下载之间的区别 - -以1.7.x版本为例。 - -**注意：**此示例也适用于Docker镜像！ - -在我们的[下载页面](https://dl.gitea.com/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/support.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" >}})以检查是否有特定错误。 diff --git a/docs/content/doc/help/support.en-us.md b/docs/content/doc/help/support.en-us.md deleted file mode 100644 index 2b285ce6ea..0000000000 --- a/docs/content/doc/help/support.en-us.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -date: "2018-05-21T15:00:00+00:00" -title: "Support Options" -slug: "support" -weight: 20 -toc: false -draft: false -aliases: - - /en-us/seek-help -menu: - sidebar: - parent: "help" - name: "Support Options" - weight: 20 - identifier: "support" ---- - -# Support Options - -- [Paid Commercial Support](https://about.gitea.com/) -- [Discord](https://discord.gg/Gitea) -- [Discourse Forum](https://discourse.gitea.io/) - -**NOTE:** When asking for support, it may be a good idea to have the following available so that the person helping has all the info they need: - -1. Your `app.ini` (with any sensitive data scrubbed as necessary). -2. The Gitea logs, and any other appropriate log files for the situation. - - When using systemd, use `journalctl --lines 1000 --unit gitea` to collect logs. - - When using docker, use `docker logs --tail 1000 <gitea-container>` to collect logs. - - By default, the logs are outputted to console. If you need to collect logs from files, - you could copy the following config into your `app.ini` (remove all other `[log]` sections), - then you can find the `*.log` files in Gitea's log directory (default: `%(GITEA_WORK_DIR)/log`). - - ```ini - ; To show all SQL logs, you can also set LOG_SQL=true in the [database] section - [log] - LEVEL=debug - MODE=console,file - ``` - -3. Any error messages you are seeing. -4. When possible, try to replicate the issue on [try.gitea.io](https://try.gitea.io) and include steps so that others can reproduce the issue. - - This will greatly improve the chance that the root of the issue can be quickly discovered and resolved. -5. If you encounter slow/hanging/deadlock problems, please report the stack trace when the problem occurs. - Go to the "Site Admin" -> "Monitoring" -> "Stacktrace" -> "Download diagnosis report". - -## Bugs - -If you found a bug, please create an [issue on GitHub](https://github.com/go-gitea/gitea/issues). - -## Chinese Support - -Support for the Chinese language is provided at [Our discourse](https://discourse.gitea.io/c/5-category/5) or QQ Group 328432459. diff --git a/docs/content/doc/help/support.zh-cn.md b/docs/content/doc/help/support.zh-cn.md deleted file mode 100644 index 775dfe83bd..0000000000 --- a/docs/content/doc/help/support.zh-cn.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -date: "2017-01-20T15:00:00+08:00" -title: "需要帮助" -slug: "support" -weight: 20 -toc: false -draft: false -aliases: - - /zh-cn/seek-help -menu: - sidebar: - parent: "help" - name: "需要帮助" - weight: 20 - identifier: "support" ---- - -## 需要帮助? - -如果您在使用或者开发过程中遇到问题，请到以下渠道咨询： - -- 到 [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 获得进一步的支持 diff --git a/docs/content/doc/help/support.zh-tw.md b/docs/content/doc/help/support.zh-tw.md deleted file mode 100644 index a9c35eaafb..0000000000 --- a/docs/content/doc/help/support.zh-tw.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -date: "2018-05-21T15:00:00+00:00" -title: "取得協助" -slug: "support" -weight: 20 -toc: false -draft: false -aliases: - - /zh-tw/seek-help -menu: - sidebar: - parent: "help" - name: "取得協助" - weight: 20 - identifier: "support" ---- - -# 取得協助 - -- [Discord 聊天室](https://discord.gg/Gitea) -- [Discourse 討論區](https://discourse.gitea.io/) - -**備註：** 尋求支援時，若能先備妥下列資訊將可讓提供協助的人能快速地分析您的問題： - -1. 您的 `app.ini` (必要時清除掉任何機密資訊) -2. `gitea.log` (以及任何有關的日誌檔案) - - 例：如果錯誤和資料庫相關，提供 `xorm.log` 可能會有幫助 -3. 您看到的任何錯誤訊息 -4. 儘可能地在 [try.gitea.io](https://try.gitea.io) 觸發您的問題並記下步驟，以便其他人能重現那個問題。 - - 這將讓我們更有機會快速地找出問題的根源並解決它。 -5. 堆棧跟踪，[請參考英文文檔](https://docs.gitea.io/en-us/seek-help/) - -## 錯誤回報 - -如果您發現錯誤，請到 [GitHub 的 Issue](https://github.com/go-gitea/gitea/issues) 回報。 diff --git a/docs/content/doc/installation.en-us.md b/docs/content/doc/installation.en-us.md deleted file mode 100644 index 4257521d97..0000000000 --- a/docs/content/doc/installation.en-us.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Installation" -slug: "installation" -weight: 10 -toc: false -draft: false -menu: - sidebar: - name: "Installation" - weight: 10 - identifier: "installation" ---- diff --git a/docs/content/doc/installation.fr-fr.md b/docs/content/doc/installation.fr-fr.md deleted file mode 100644 index 55b48bda3e..0000000000 --- a/docs/content/doc/installation.fr-fr.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2017-08-23T09:00:00+02:00" -title: "Installation" -slug: "installation" -weight: 10 -toc: false -draft: false -menu: - sidebar: - name: "Installation" - weight: 10 - identifier: "installation" ---- diff --git a/docs/content/doc/installation.zh-cn.md b/docs/content/doc/installation.zh-cn.md deleted file mode 100644 index 8f57e0f00c..0000000000 --- a/docs/content/doc/installation.zh-cn.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "安装" -slug: "installation" -weight: 10 -toc: false -draft: false -menu: - sidebar: - name: "安装" - weight: 10 - identifier: "installation" ---- diff --git a/docs/content/doc/installation.zh-tw.md b/docs/content/doc/installation.zh-tw.md deleted file mode 100644 index f955e994ac..0000000000 --- a/docs/content/doc/installation.zh-tw.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "安裝" -slug: "installation" -weight: 10 -toc: false -draft: false -menu: - sidebar: - name: "安裝" - weight: 10 - identifier: "installation" ---- diff --git a/docs/content/doc/installation/_index.en-us.md b/docs/content/doc/installation/_index.en-us.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/installation/_index.en-us.md +++ /dev/null diff --git a/docs/content/doc/installation/_index.fr-fr.md b/docs/content/doc/installation/_index.fr-fr.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/installation/_index.fr-fr.md +++ /dev/null diff --git a/docs/content/doc/installation/_index.zh-cn.md b/docs/content/doc/installation/_index.zh-cn.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/installation/_index.zh-cn.md +++ /dev/null diff --git a/docs/content/doc/installation/_index.zh-tw.md b/docs/content/doc/installation/_index.zh-tw.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/installation/_index.zh-tw.md +++ /dev/null diff --git a/docs/content/doc/installation/comparison.en-us.md b/docs/content/doc/installation/comparison.en-us.md deleted file mode 100644 index 578b00c211..0000000000 --- a/docs/content/doc/installation/comparison.en-us.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -date: "2018-05-07T13:00:00+02:00" -title: "Compared to other Git hosting" -slug: "comparison" -weight: 5 -toc: false -draft: false -aliases: - - /en-us/comparison -menu: - sidebar: - name: "Comparison" - weight: 5 - parent: installation - identifier: "comparison" ---- - -# Gitea compared to other Git hosting options - -**Table of Contents** - -{{< toc >}} - -To help decide if Gitea is suited for your needs, here is how it compares to other Git self hosted options. - -Be warned that we don't regularly check for feature changes in other products, so this list may be outdated. If you find anything that needs to be updated in the table below, please [open an issue](https://github.com/go-gitea/gitea/issues/new/choose). - -_Symbols used in table:_ - -- _✓ - supported_ - -- _⁄ - supported with limited functionality_ - -- _✘ - unsupported_ - -- _⚙️ - supported through third-party software_ - -## General Features - -| Feature | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | -| ------------------------------------------------ | --------------------------------------------------- | ---- | --------- | --------- | --------- | --------- | ------------ | -| Open source and free | ✓ | ✓ | ✘ | ✓ | ✘ | ✘ | ✓ | -| Low RAM/ CPU usage | ✓ | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ | -| Multiple database support | ✓ | ✓ | ✘ | ⁄ | ⁄ | ✓ | ✓ | -| Multiple OS support | ✓ | ✓ | ✘ | ✘ | ✘ | ✘ | ✓ | -| Easy upgrades | ✓ | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | -| Telemetry | **✘** | ✘ | ✓ | ✓ | ✓ | ✓ | ? | -| Third-party render tool support | ✓ | ✘ | ✘ | ✘ | ✘ | ✓ | ? | -| WebAuthn (2FA) | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ? | -| Extensive API | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Built-in Package/Container Registry | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Sync commits to an external repo (push mirror) | ✓ | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | -| Sync commits from an external repo (pull mirror) | ✓ | ✘ | ✘ | ✓ | ✓ | ✘ | ? | -| Light and Dark Theme | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ? | -| Custom Theme Support | ✓ | ✓ | ✘ | ✘ | ✘ | ✓ | ✘ | -| Markdown support | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| CSV support | ✓ | ✘ | ✓ | ✘ | ✘ | ✓ | ? | -| 'GitHub / GitLab pages' | [⚙️][gitea-pages-server], [⚙️][gitea-caddy-plugin] | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Repo-specific wiki (as a repo itself) | ✓ | ✓ | ✓ | ✓ | ✓ | / | ✘ | -| Deploy Tokens | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Repository Tokens with write rights | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| RSS Feeds | ✓ | ✘ | ✓ | ✘ | ✘ | ✘ | ✘ | -| Built-in CI/CD | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Subgroups: groups within groups | [✘](https://github.com/go-gitea/gitea/issues/1872) | ✘ | ✘ | ✓ | ✓ | ✘ | ✓ | -| Interaction with other instances | [/](https://github.com/go-gitea/gitea/issues/18240) | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ | -| Mermaid diagrams in Markdown | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Math syntax in Markdown | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | - -## Code management - -| Feature | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | -| ------------------------------------------- | --------------------------------------------------- | ---- | --------- | --------- | --------- | --------- | ------------ | -| Repository topics | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Repository code search | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Global code search | ✓ | ✘ | ✓ | ✘ | ✓ | ✓ | ✓ | -| Git LFS 2.0 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Group Milestones | [✘](https://github.com/go-gitea/gitea/issues/14622) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | -| Granular user roles (Code, Issues, Wiki, …) | ✓ | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | -| Verified Committer | ⁄ | ✘ | ? | ✓ | ✓ | ✓ | ✘ | -| GPG Signed Commits | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| SSH Signed Commits | ✓ | ✘ | ✓ | ✓ | ✓ | ? | ? | -| Reject unsigned commits | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Migrating repos from other services | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Repository Activity page | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Branch manager | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Create new branches | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Web code editor | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Commit graph | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Template Repositories | ✓ | ✘ | ✓ | ✘ | ✓ | ✓ | ✘ | -| Git Blame | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| Visual comparison of image changes | ✓ | ✘ | ✓ | ? | ? | ? | ? | - -## Issue Tracker - -| Feature | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | -| ----------------------------- | --------------------------------------------------- | ---- | --------- | --------- | --------- | --------- | ------------ | -| Issue tracker | ✓ | ✓ | ✓ | ✓ | ✓ | / | ✘ | -| Issue templates | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Labels | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Time tracking | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Multiple assignees for issues | ✓ | ✘ | ✓ | ✘ | ✓ | ✘ | ✘ | -| Related issues | ✘ | ✘ | ⁄ | ✓ | ✓ | ✘ | ✘ | -| Confidential issues | [✘](https://github.com/go-gitea/gitea/issues/3217) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | -| Comment reactions | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Lock Discussion | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Batch issue handling | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Issue Boards (Kanban) | [/](https://github.com/go-gitea/gitea/issues/14710) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | -| Create branch from issue | [✘](https://github.com/go-gitea/gitea/issues/20226) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | -| Convert comment to new issue | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Issue search | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| Global issue search | [/](https://github.com/go-gitea/gitea/issues/2434) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| Issue dependency | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ | -| Create issue via email | [✘](https://github.com/go-gitea/gitea/issues/6226) | ✘ | ✘ | ✓ | ✓ | ✓ | ✘ | -| Service Desk | [✘](https://github.com/go-gitea/gitea/issues/6219) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | - -## Pull/Merge requests - -| Feature | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | -| ----------------------------------------------- | -------------------------------------------------- | ---- | --------- | --------- | --------- | --------- | ------------ | -| Pull/Merge requests | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Squash merging | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Rebase merging | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Pull/Merge request inline comments | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Pull/Merge request approval | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Pull/Merge require approval | ✓ | ✘ | ✓ | ✘ | ✓ | ✓ | ✓ | -| Pull/Merge multiple reviewers | ✓ | ✓ | ✓ | ✘ | ✓ | ✓ | ✓ | -| Merge conflict resolution | [✘](https://github.com/go-gitea/gitea/issues/9014) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| Restrict push and merge access to certain users | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Revert specific commits | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| Pull/Merge requests templates | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Cherry-picking changes | ✓ | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | -| Download Patch | ✓ | ✘ | ✓ | ✓ | ✓ | / | ✘ | -| Merge queues | ✘ | ✘ | ✓ | ✘ | ✓ | ✘ | ✘ | - -## 3rd-party integrations - -| Feature | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | -| ---------------------------------------------- | ------------------------------------------------ | ---- | --------- | --------- | --------- | --------- | ------------ | -| Webhooks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Git Hooks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| AD / LDAP integration | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Multiple LDAP / AD server support | ✓ | ✓ | ✘ | ✘ | ✓ | ✓ | ✓ | -| LDAP user synchronization | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| SAML 2.0 service provider | [✘](https://github.com/go-gitea/gitea/issues/5512) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| OpenID Connect support | ✓ | ✘ | ✓ | ✓ | ✓ | ? | ✘ | -| OAuth 2.0 integration (external authorization) | ✓ | ✘ | ⁄ | ✓ | ✓ | ? | ✓ | -| Act as OAuth 2.0 provider | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| Two factor authentication (2FA) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | -| Integration with the most common services | ✓ | / | ⁄ | ✓ | ✓ | ⁄ | ✓ | -| Incorporate external CI/CD | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | - -[gitea-caddy-plugin]: https://github.com/42wim/caddy-gitea -[gitea-pages-server]: https://codeberg.org/Codeberg/pages-server diff --git a/docs/content/doc/installation/comparison.zh-cn.md b/docs/content/doc/installation/comparison.zh-cn.md deleted file mode 100644 index 91955ee688..0000000000 --- a/docs/content/doc/installation/comparison.zh-cn.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -date: "2019-02-14T11:51:04+08:00" -title: "对比 Gitea 与其它 Git 托管工具" -slug: "comparison" -weight: 5 -toc: false -draft: false -aliases: - - /zh-cn/comparison -menu: - sidebar: - parent: "installation" - name: "横向对比" - weight: 5 - identifier: "comparison" ---- - -# 对比 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 diff --git a/docs/content/doc/installation/comparison.zh-tw.md b/docs/content/doc/installation/comparison.zh-tw.md deleted file mode 100644 index 042acba8d3..0000000000 --- a/docs/content/doc/installation/comparison.zh-tw.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -date: "2018-05-07T13:00:00+02:00" -title: "比較 Gitea 和其它自託管 Git 服務" -slug: "comparison" -weight: 5 -toc: false -draft: false -aliases: - - /zh-tw/comparison -menu: - sidebar: - parent: "installation" - name: "比較" - weight: 5 - identifier: "comparison" ---- - -# 比較 Gitea 和其它自託管 Git 服務 - -**目錄** - -{{< toc >}} - -為了幫助您判斷 Gitea 是否適合您的需求，這裡列出了它和其它自託管 Git 服務的比較。 - -請注意我們不會經常檢查其它產品的功能異動，所以這份清單可能過期，如果您在下方表格中找到需要更新的資料，請在 [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 驅動的靜態頁面 | [⚙️][gitea-pages-server], [⚙️][gitea-caddy-plugin] | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| Git 驅動的整合 wiki | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | -| 部署 Token | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| 有寫入權限的儲存庫 Token | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✓ | -| 內建 Container Registry | [✘](https://github.com/go-gitea/gitea/issues/2316) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | -| 對外部 Git 鏡像 | ✓ | ✓ | ✘ | ✘ | ✓ | ✓ | ✓ | -| FIDO (2FA) | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| 內建 CI/CD | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| 子群組: 群組中的群組 | ✘ | ✘ | ✘ | ✓ | ✓ | ✘ | ✓ | - -## 程式碼管理 - -| 功能 | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | -| ----------------------------------------- | ------------------------------------------------ | ---- | --------- | --------- | --------- | --------- | ------------ | -| 儲存庫主題描述 | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| 儲存庫程式碼搜尋 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| 全域程式碼搜尋 | ✓ | ✘ | ✓ | ✘ | ✓ | ✓ | ✓ | -| Git LFS 2.0 | ✓ | ✘ | ✓ | ✓ | ✓ | ⁄ | ✓ | -| 群組里程碑 | ✘ | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | -| 精細的使用者權限（程式碼, 問題, Wiki 等） | ✓ | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ | -| 驗證提交者 | ⁄ | ✘ | ? | ✓ | ✓ | ✓ | ✘ | -| GPG 簽署提交 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| 拒絕未經簽署的提交 | [✓](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 | -| -------------------- | -------------------------------------------------- | --------------------------------------------- | --------- | ----------------------------------------------------------------------- | --------- | --------- | ------------ | -| 問題追蹤器 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | -| 問題範本 | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | -| 標籤 | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | -| 時間追蹤 | ✓ | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ | -| 指派問題給多個成員 | ✓ | ✘ | ✓ | ✘ | ✓ | ✘ | ✘ | -| 相關問題 | ✘ | ✘ | ⁄ | [✓](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) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| 問題相依 | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ | -| 從電子郵件建立問題 | [✘](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) | ✓ | ✘ | ✘ | - -## 拉取/合併請求 - -| 功能 | Gitea | Gogs | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | -| -------------------------- | -------------------------------------------------- | ---- | --------- | --------------------------------------------------------------------------------- | --------- | ------------------------------------------------------------------------ | ------------ | -| 拉取/合併請求 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Squash 合併 | ✓ | ✘ | ✓ | [✓](https://docs.gitlab.com/ce/user/project/merge_requests/squash_and_merge.html) | ✓ | ✓ | ✓ | -| Rebase 合併 | ✓ | ✓ | ✓ | ✘ | ⁄ | ✘ | ✓ | -| 拉取/合併請求的行內留言 | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ | -| 拉取/合併請求的核可 | ✓ | ✘ | ⁄ | ✓ | ✓ | ✓ | ✓ | -| 解決合併衝突 | [✘](https://github.com/go-gitea/gitea/issues/5158) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| 限制某些使用者的推送及合併 | ✓ | ✘ | ✓ | ⁄ | ✓ | ✓ | ✓ | -| 還原指定的提交或合併請求 | [✘](https://github.com/go-gitea/gitea/issues/5158) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ | -| 拉取/合併請求範本 | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | -| 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 Hook | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| 整合 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 Connect | ✓ | ✘ | ✓ | ✓ | ✓ | ? | ✘ | -| 整合 OAuth 2.0 (外部驗證) | ✓ | ✘ | ⁄ | ✓ | ✓ | ? | ✓ | -| 成為 OAuth 2.0 提供者 | [✓](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 diff --git a/docs/content/doc/installation/database-preparation.en-us.md b/docs/content/doc/installation/database-preparation.en-us.md deleted file mode 100644 index 4b0d1b5ba8..0000000000 --- a/docs/content/doc/installation/database-preparation.en-us.md +++ /dev/null @@ -1,307 +0,0 @@ ---- -date: "2020-01-16" -title: "Database Preparation" -slug: "database-prep" -weight: 10 -toc: false -draft: false -aliases: - - /en-us/database-prep -menu: - sidebar: - parent: "installation" - name: "Database preparation" - weight: 10 - identifier: "database-prep" ---- - -# Database Preparation - -You need a database to use Gitea. Gitea supports PostgreSQL (>=10), MySQL (>=5.7), SQLite, and MSSQL (>=2008R2 SP3). This page will guide into preparing database. Only PostgreSQL and MySQL will be covered here since those database engines are widely-used in production. If you plan to use SQLite, you can ignore this chapter. - -Database instance can be on same machine as Gitea (local database setup), or on different machine (remote database). - -Note: All steps below requires that the database engine of your choice is installed on your system. For remote database setup, install the server application on database instance and client program on your Gitea server. The client program is used to test connection to the database from Gitea server, while Gitea itself use database driver provided by Go to accomplish the same thing. In addition, make sure you use same engine version for both server and client for some engine features to work. For security reason, protect `root` (MySQL) or `postgres` (PostgreSQL) database superuser with secure password. The steps assumes that you run Linux for both database and Gitea servers. - -**Table of Contents** - -{{< toc >}} - -## MySQL - -1. For remote database setup, you will need to make MySQL listen to your IP address. Edit `bind-address` option on `/etc/mysql/my.cnf` on database instance to: - - ```ini - bind-address = 203.0.113.3 - ``` - -2. On database instance, login to database console as root: - - ``` - mysql -u root -p - ``` - - Enter the password as prompted. - -3. Create database user which will be used by Gitea, authenticated by password. This example uses `'gitea'` as password. Please use a secure password for your instance. - - For local database: - - ```sql - SET old_passwords=0; - CREATE USER 'gitea' IDENTIFIED BY 'gitea'; - ``` - - For remote database: - - ```sql - SET old_passwords=0; - CREATE USER 'gitea'@'192.0.2.10' IDENTIFIED BY 'gitea'; - ``` - - where `192.0.2.10` is the IP address of your Gitea instance. - - Replace username and password above as appropriate. - -4. Create database with UTF-8 charset and collation. Make sure to use `utf8mb4` charset instead of `utf8` as the former supports all Unicode characters (including emojis) beyond _Basic Multilingual Plane_. Also, collation chosen depending on your expected content. When in doubt, use either `unicode_ci` or `general_ci`. - - ```sql - CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'; - ``` - - Replace database name as appropriate. - -5. Grant all privileges on the database to database user created above. - - For local database: - - ```sql - GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'; - FLUSH PRIVILEGES; - ``` - - For remote database: - - ```sql - GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'192.0.2.10'; - FLUSH PRIVILEGES; - ``` - -6. Quit from database console by `exit`. - -7. On your Gitea server, test connection to the database: - - ``` - mysql -u gitea -h 203.0.113.3 -p giteadb - ``` - - where `gitea` is database username, `giteadb` is database name, and `203.0.113.3` is IP address of database instance. Omit `-h` option for local database. - - You should be connected to the database. - -## PostgreSQL - -1. For remote database setup, configure PostgreSQL on database instance to listen to your IP address by editing `listen_addresses` on `postgresql.conf` to: - - ```ini - listen_addresses = 'localhost, 203.0.113.3' - ``` - -2. PostgreSQL uses `md5` challenge-response encryption scheme for password authentication by default. Nowadays this scheme is not considered secure anymore. Use SCRAM-SHA-256 scheme instead by editing the `postgresql.conf` configuration file on the database server to: - - ```ini - password_encryption = scram-sha-256 - ``` - - Restart PostgreSQL to apply the setting. - -3. On the database server, login to the database console as superuser: - - ``` - su -c "psql" - postgres - ``` - -4. Create database user (role in PostgreSQL terms) with login privilege and password. Please use a secure, strong password instead of `'gitea'` below: - - ```sql - CREATE ROLE gitea WITH LOGIN PASSWORD 'gitea'; - ``` - - Replace username and password as appropriate. - -5. Create database with UTF-8 charset and owned by the database user created earlier. Any `libc` collations can be specified with `LC_COLLATE` and `LC_CTYPE` parameter, depending on expected content: - - ```sql - CREATE DATABASE giteadb WITH OWNER gitea TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8'; - ``` - - Replace database name as appropriate. - -6. Allow the database user to access the database created above by adding the following authentication rule to `pg_hba.conf`. - - For local database: - - ```ini - local giteadb gitea scram-sha-256 - ``` - - For remote database: - - ```ini - host giteadb gitea 192.0.2.10/32 scram-sha-256 - ``` - - Replace database name, user, and IP address of Gitea instance with your own. - - Note: rules on `pg_hba.conf` are evaluated sequentially, that is the first matching rule will be used for authentication. Your PostgreSQL installation may come with generic authentication rules that match all users and databases. You may need to place the rules presented here above such generic rules if it is the case. - - Restart PostgreSQL to apply new authentication rules. - -7. On your Gitea server, test connection to the database. - - For local database: - - ``` - psql -U gitea -d giteadb - ``` - - For remote database: - - ``` - psql "postgres://gitea@203.0.113.3/giteadb" - ``` - - where `gitea` is database user, `giteadb` is database name, and `203.0.113.3` is IP address of your database instance. - - You should be prompted to enter password for the database user, and connected to the database. - -## Database Connection over TLS - -If the communication between Gitea and your database instance is performed through a private network, or if Gitea and the database are running on the same server, this section can be omitted since the security between Gitea and the database instance is not critically exposed. If instead the database instance is on a public network, use TLS to encrypt the connection to the database, as it is possible for third-parties to intercept the traffic data. - -### Prerequisites - -- You need two valid TLS certificates, one for the database instance (database server) and one for the Gitea instance (database client). Both certificates must be signed by a trusted CA. -- The database certificate must contain `TLS Web Server Authentication` in the `X509v3 Extended Key Usage` extension attribute, while the client certificate needs `TLS Web Client Authentication` in the corresponding attribute. -- On the database server certificate, one of `Subject Alternative Name` or `Common Name` entries must be the fully-qualified domain name (FQDN) of the database instance (e.g. `db.example.com`). On the database client certificate, one of the entries mentioned above must contain the database username that Gitea will be using to connect. -- You need domain name mappings of both Gitea and database servers to their respective IP addresses. Either set up DNS records for them or add local mappings to `/etc/hosts` (`%WINDIR%\System32\drivers\etc\hosts` in Windows) on each system. This allows the database connections to be performed by domain name instead of IP address. See documentation of your system for details. - -### PostgreSQL - -The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both database client and server authenticate each other by sending their respective certificates to their respective opposite for validation. In other words, the server verifies client certificate, and the client verifies server certificate. - -1. On the server with the database instance, place the following credentials: - - - `/path/to/postgresql.crt`: Database instance certificate - - `/path/to/postgresql.key`: Database instance private key - - `/path/to/root.crt`: CA certificate chain to validate client certificates - -2. Add following options to `postgresql.conf`: - - ```ini - ssl = on - ssl_ca_file = '/path/to/root.crt' - ssl_cert_file = '/path/to/postgresql.crt' - ssl_key_file = '/path/to/postgresql.key' - ssl_min_protocol_version = 'TLSv1.2' - ``` - -3. Adjust credentials ownership and permission, as required by PostgreSQL: - - ``` - chown postgres:postgres /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key - chmod 0600 /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key - ``` - -4. Edit `pg_hba.conf` rule to only allow Gitea database user to connect over SSL, and to require client certificate verification. - - For PostgreSQL 12: - - ```ini - hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=verify-full - ``` - - For PostgreSQL 11 and earlier: - - ```ini - hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=1 - ``` - - Replace database name, user, and IP address of Gitea instance as appropriate. - -5. Restart PostgreSQL to apply configurations above. - -6. On the server running the Gitea instance, place the following credentials under the home directory of the user who runs Gitea (e.g. `git`): - - - `~/.postgresql/postgresql.crt`: Database client certificate - - `~/.postgresql/postgresql.key`: Database client private key - - `~/.postgresql/root.crt`: CA certificate chain to validate server certificate - - Note: Those file names above are hardcoded in PostgreSQL and it is not possible to change them. - -7. Adjust credentials, ownership and permission as required: - - ``` - chown git:git ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt - chown 0600 ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt - ``` - -8. Test the connection to the database: - - ``` - psql "postgres://gitea@example.db/giteadb?sslmode=verify-full" - ``` - - You should be prompted to enter password for the database user, and then be connected to the database. - -### MySQL - -While the MySQL driver used by Gitea also supports two-way TLS, Gitea currently supports only one-way TLS. See issue #10828 for details. - -In one-way TLS, the database client verifies the certificate sent from server during the connection handshake, and the server assumes that the connected client is legitimate, since client certificate verification doesn't take place. - -1. On the database instance, place the following credentials: - - - `/path/to/mysql.crt`: Database instance certificate - - `/path/to/mysql.key`: Database instance key - - `/path/to/ca.crt`: CA certificate chain. This file isn't used on one-way TLS, but is used to validate client certificates on two-way TLS. - -2. Add following options to `my.cnf`: - - ```ini - [mysqld] - ssl-ca = /path/to/ca.crt - ssl-cert = /path/to/mysql.crt - ssl-key = /path/to/mysql.key - tls-version = TLSv1.2,TLSv1.3 - ``` - -3. Adjust credentials ownership and permission: - - ``` - chown mysql:mysql /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key - chmod 0600 /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key - ``` - -4. Restart MySQL to apply the setting. - -5. The database user for Gitea may have been created earlier, but it would authenticate only against the IP addresses of the server running Gitea. To authenticate against its domain name, recreate the user, and this time also set it to require TLS for connecting to the database: - - ```sql - DROP USER 'gitea'@'192.0.2.10'; - CREATE USER 'gitea'@'example.gitea' IDENTIFIED BY 'gitea' REQUIRE SSL; - GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'example.gitea'; - FLUSH PRIVILEGES; - ``` - - Replace database user name, password, and Gitea instance domain as appropriate. - -6. Make sure that the CA certificate chain required to validate the database server certificate is on the system certificate store of both the database and Gitea servers. Consult your system documentation for instructions on adding a CA certificate to the certificate store. - -7. On the server running Gitea, test connection to the database: - - ``` - mysql -u gitea -h example.db -p --ssl - ``` - - You should be connected to the database. diff --git a/docs/content/doc/installation/database-preparation.zh-cn.md b/docs/content/doc/installation/database-preparation.zh-cn.md deleted file mode 100644 index 6c23f8ce5d..0000000000 --- a/docs/content/doc/installation/database-preparation.zh-cn.md +++ /dev/null @@ -1,307 +0,0 @@ ---- -date: "2020-01-16" -title: "数据库准备" -slug: "database-prep" -weight: 10 -toc: false -draft: false -aliases: - - /zh-cn/database-prep -menu: - sidebar: - parent: "installation" - name: "数据库准备" - weight: 10 - identifier: "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。 - -**目录** - -{{< toc >}} - -## 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 - ``` - - 至此应该成功连接到数据库了。 diff --git a/docs/content/doc/installation/from-binary.en-us.md b/docs/content/doc/installation/from-binary.en-us.md deleted file mode 100644 index 4c501aa30e..0000000000 --- a/docs/content/doc/installation/from-binary.en-us.md +++ /dev/null @@ -1,242 +0,0 @@ ---- -date: "2017-06-19T12:00:00+02:00" -title: "Installation from binary" -slug: "install-from-binary" -weight: 15 -toc: false -draft: false -aliases: - - /en-us/install-from-binary -menu: - sidebar: - parent: "installation" - name: "From binary" - weight: 15 - identifier: "install-from-binary" ---- - -# Installation from binary - -All downloads come with SQLite, MySQL and PostgreSQL support, and are built with -embedded assets. This can be different from Gogs. - -**Table of Contents** - -{{< toc >}} - -## Download - -You can find the file matching your platform from the [downloads page](https://dl.gitea.com/gitea/) after navigating to the version you want to download. - -### Choosing the right file - -**For Linux**, you will likely want `linux-amd64`. It's for 64-bit Intel/AMD platforms, but there are other platforms available, including `arm64` (e.g. Raspberry PI 4), `386` (i.e. 32-bit), `arm-5`, and `arm-6`. - -**For Windows**, you will likely want `windows-4.0-amd64`. It's for all modern versions of Windows, but there is also a `386` platform available designed for older, 32-bit versions of Windows. - -*Note: there is also a `gogit-windows` file available that was created to help with some [performance problems](https://github.com/go-gitea/gitea/pull/15482) reported by some Windows users on older systems/versions. You should consider using this file if you're experiencing performance issues, and let us know if it improves performance.* - -**For macOS**, you should choose `darwin-arm64` if your hardware uses Apple Silicon, or `darwin-amd64` for Intel. - -**For FreeBSD**, you should choose `freebsd12-amd64` for 64-bit Intel/AMD platforms. - -### Downloading with wget - -Copy the commands below and replace the URL within the one you wish to download. - -```sh -wget -O gitea https://dl.gitea.com/gitea/{{< version >}}/gitea-{{< version >}}-linux-amd64 -chmod +x gitea -``` - -Note that the above command will download Gitea {{< version >}} for 64-bit Linux. - -## Verify GPG signature - -Gitea signs all binaries with a [GPG key](https://keys.openpgp.org/search?q=teabot%40gitea.io) to prevent against unwanted modification of binaries. -To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the GPG command line tool. - -```sh -gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2 -gpg --verify gitea-{{< version >}}-linux-amd64.asc gitea-{{< version >}}-linux-amd64 -``` - -Look for the text `Good signature from "Teabot <teabot@gitea.io>"` to assert a good binary, -despite warnings like `This key is not certified with a trusted signature!`. - -## Recommended server configuration - -**NOTE:** Many of the following directories can be configured using [Environment Variables]({{< relref "doc/administration/environment-variables.en-us.md" >}}) as well! -Of note, configuring `GITEA_WORK_DIR` will tell Gitea where to base its working directory, as well as ease installation. - -### Prepare environment - -Check that Git is installed on the server. If it is not, install it first. Gitea requires Git version >= 2.0. - -```sh -git --version -``` - -Create a user to run Gitea (e.g. `git`) - -```sh -# On Ubuntu/Debian: -adduser \ - --system \ - --shell /bin/bash \ - --gecos 'Git Version Control' \ - --group \ - --disabled-password \ - --home /home/git \ - git - -# On Fedora/RHEL/CentOS: -groupadd --system git -adduser \ - --system \ - --shell /bin/bash \ - --comment 'Git Version Control' \ - --gid git \ - --home-dir /home/git \ - --create-home \ - git -``` - -### Create required directory structure - -```sh -mkdir -p /var/lib/gitea/{custom,data,log} -chown -R git:git /var/lib/gitea/ -chmod -R 750 /var/lib/gitea/ -mkdir /etc/gitea -chown root:git /etc/gitea -chmod 770 /etc/gitea -``` - -> **NOTE:** `/etc/gitea` is temporarily set with write permissions for user `git` so that the web installer can write the configuration file. After the installation is finished, it is recommended to set permissions to read-only using: -> -> ```sh -> chmod 750 /etc/gitea -> chmod 640 /etc/gitea/app.ini -> ``` - -If you don't want the web installer to be able to write to the config file, it is possible to make the config file read-only for the Gitea user (owner/group `root:git`, mode `0640`) however you will need to edit your config file manually to: - -* Set `INSTALL_LOCK= true`, -* Ensure all database configuration details are set correctly -* Ensure that the `SECRET_KEY` and `INTERNAL_TOKEN` values are set. (You may want to use the `gitea generate secret` to generate these secret keys.) -* Ensure that any other secret keys you need are set. - -See the [command line documentation]({{< relref "doc/administration/command-line.en-us.md" >}}) for information on using `gitea generate secret`. - -### Configure Gitea's working directory - -**NOTE:** If you plan on running Gitea as a Linux service, you can skip this step, as the service file allows you to set `WorkingDirectory`. Otherwise, consider setting this environment variable (semi-)permanently so that Gitea consistently uses the correct working directory. - -```sh -export GITEA_WORK_DIR=/var/lib/gitea/ -``` - -### Copy the Gitea binary to a global location - -```sh -cp gitea /usr/local/bin/gitea -``` - -### Adding bash/zsh autocompletion (from 1.19) - -A script to enable bash-completion can be found at [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete). This can be copied to `/usr/share/bash-completion/completions/gitea` -or sourced within your `.bashrc`. - -Similarly a script for zsh-completion can be found at [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete). This can be copied to `/usr/share/zsh/_gitea` or sourced within your -`.zshrc`. - -YMMV and these scripts may need further improvement. - -## Running Gitea - -After you complete the above steps, you can run Gitea two ways: - -### 1. Creating a service file to start Gitea automatically (recommended) - -See how to create [Linux service]({{< relref "doc/installation/run-as-service-in-ubuntu.en-us.md" >}}) - -### 2. Running from command-line/terminal - -```sh -GITEA_WORK_DIR=/var/lib/gitea/ /usr/local/bin/gitea web -c /etc/gitea/app.ini -``` - -## Updating to a new version - -You can update to a new version of Gitea by stopping Gitea, replacing the binary at `/usr/local/bin/gitea` and restarting the instance. -The binary file name should not be changed during the update to avoid problems in existing repositories. - -It is recommended that you make a [backup]({{< relref "doc/administration/backup-and-restore.en-us.md" >}}) before updating your installation. - -If you have carried out the installation steps as described above, the binary should -have the generic name `gitea`. Do not change this, i.e. to include the version number. - -### 1. Restarting Gitea with systemd (recommended) - -As we explained before, we recommend to use systemd as the service manager. In this case, `systemctl restart gitea` should be fine. - -### 2. Restarting Gitea without systemd - -To restart your Gitea instance, we recommend to use SIGHUP signal. If you know your Gitea PID, use `kill -1 $GITEA_PID`, otherwise you can use `killall -1 gitea`. - -To gracefully stop the Gitea instance, a simple `kill $GITEA_PID` or `killall gitea` is enough. - -**NOTE:** We don't recommend to use the SIGKILL signal (`-9`); you may be forcefully stopping some of Gitea's internal tasks, and it will not gracefully stop (tasks in queues, indexers, etc.) - -See below for troubleshooting instructions to repair broken repositories after -an update of your Gitea version. - -## Troubleshooting - -### Old glibc versions - -Older Linux distributions (such as Debian 7 and CentOS 6) may not be able to load the -Gitea binary, usually producing an error such as `./gitea: /lib/x86_64-linux-gnu/libc.so.6: -version 'GLIBC\_2.14' not found (required by ./gitea)`. This is due to the integrated -SQLite support in the binaries provided by dl.gitea.com. In this situation, it is usually -possible to [install from source]({{< relref "doc/installation/from-source.en-us.md" >}}), without including -SQLite support. - -### Running Gitea on another port - -For errors like `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000: -bind: address already in use`, Gitea needs to be started on another free port. This -is possible using `./gitea web -p $PORT`. It's possible another instance of Gitea -is already running. - -### Running Gitea on Raspbian - -As of v1.8, there is a problem with the arm7 version of Gitea, and it doesn't run on Raspberry Pis and similar devices. - -It is recommended to switch to the arm6 version, which has been tested and shown to work on Raspberry Pis and similar devices. - -<!--- -please remove after fixing the arm7 bug ----> -### Git error after updating to a new version of Gitea - -If during the update, the binary file name has been changed to a new version of Gitea, -Git Hooks in existing repositories will not work any more. In that case, a Git -error will be displayed when pushing to the repository. - -``` -remote: ./hooks/pre-receive.d/gitea: line 2: [...]: No such file or directory -``` - -The `[...]` part of the error message will contain the path to your previous Gitea -binary. - -To solve this, go to the admin options and run the task `Resynchronize pre-receive, -update and post-receive hooks of all repositories` to update all hooks to contain -the new binary path. Please note that this overwrites all Git Hooks, including ones -with customizations made. - -If you aren't using the Gitea built-in SSH server, you will also need to re-write -the authorized key file by running the `Update the '.ssh/authorized_keys' file with -Gitea SSH keys.` task in the admin options. diff --git a/docs/content/doc/installation/from-binary.fr-fr.md b/docs/content/doc/installation/from-binary.fr-fr.md deleted file mode 100644 index f3d3110439..0000000000 --- a/docs/content/doc/installation/from-binary.fr-fr.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -date: "2017-08-23T09:00:00+02:00" -title: "Installation avec le binaire pré-compilé" -slug: "install-from-binary" -weight: 15 -toc: false -draft: false -aliases: - - /fr-fr/install-from-binary -menu: - sidebar: - parent: "installation" - name: "Binaire pré-compilé" - weight: 15 - identifier: "install-from-binary" ---- - -# Installation avec le binaire pré-compilé - -Tous les binaires sont livrés avec le support de SQLite, MySQL et PostgreSQL, et sont construits avec les ressources incorporées. Gardez à l'esprit que cela peut être différent pour les versions antérieures. L'installation basée sur nos binaires est assez simple, il suffit de choisir le fichier correspondant à votre plateforme à partir de la [page de téléchargement](https://dl.gitea.com/gitea). Copiez l'URL et remplacer l'URL dans les commandes suivantes par la nouvelle: - -``` -wget -O gitea https://dl.gitea.com/gitea/{{< version >}}/gitea-{{< version >}}-linux-amd64 -chmod +x gitea -``` - -## Test - -Après avoir suivi les étapes ci-dessus, vous aurez un binaire `gitea` dans votre répertoire de travail. En premier lieu, vous pouvez tester si le binaire fonctionne comme prévu et ensuite vous pouvez le copier vers la destination où vous souhaitez le stocker. Lorsque vous lancez Gitea manuellement à partir de votre CLI, vous pouvez toujours le tuer en appuyant sur `Ctrl + C`. - -``` -./gitea web -``` - -## Dépannage - -### Anciennes version de glibc - -Les anciennes distributions Linux (comme Debian 7 ou CentOS 6) peuvent ne pas être capable d'exécuter le binaire Gitea, résultant généralement une erreur du type ```./gitea: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./gitea)```. Cette erreur est due au driver SQLite que nous intégrons dans le binaire Gitea. Dans le futur, nous fournirons des binaires sans la dépendance pour la bibliothèque glibc. En attendant, vous pouvez mettre à jour votre distribution ou installer Gitea depuis le [code source]({{< relref "doc/installation/from-source.fr-fr.md" >}}). - -### Exécuter Gitea avec un autre port - -Si vous obtenez l'erreur `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000: bind: address already in use`, Gitea à besoin d'utiliser un autre port. Vous pouvez changer le port par défaut en utilisant `./gitea web -p $PORT`. - -## Il manque quelque chose ? - -Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/Gitea), vous obtiendrez des réponses à toute vos questions assez rapidement. diff --git a/docs/content/doc/installation/from-binary.zh-cn.md b/docs/content/doc/installation/from-binary.zh-cn.md deleted file mode 100644 index 85fc473628..0000000000 --- a/docs/content/doc/installation/from-binary.zh-cn.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "使用二进制文件安装" -slug: "install-from-binary" -weight: 15 -toc: false -draft: false -aliases: - - /zh-cn/install-from-binary -menu: - sidebar: - parent: "installation" - name: "使用二进制文件安装" - weight: 15 - identifier: "install-from-binary" ---- - -# 使用二进制文件安装 - -所有打包的二进制程序均包含 SQLite，MySQL 和 PostgreSQL 的数据库连接支持，同时网站的静态资源均已嵌入到可执行程序中，这一点和曾经的 Gogs 有所不同。 - -**目录** - -{{< toc >}} - -## 下载 - -你可以从 [下载页面](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 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 工作的路径。以下路径可以通过 [环境变量]({{< relref "doc/administration/environment-variables.zh-cn.md" >}}) 初始化。 - -### 准备环境 - -检查是否安装 Git。要求 Git 版本 >= 2.0。 - -```sh -git --version -``` - -创建用户（推荐使用名称 `git`） - -```sh -# On Ubuntu/Debian: -adduser \ - --system \ - --shell /bin/bash \ - --gecos 'Git Version Control' \ - --group \ - --disabled-password \ - --home /home/git \ - git - -# On Fedora/RHEL/CentOS: -groupadd --system git -adduser \ - --system \ - --shell /bin/bash \ - --comment 'Git Version Control' \ - --gid git \ - --home-dir /home/git \ - --create-home \ - git -``` - -### 创建工作路径 - -```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` -- 提供所有必要的密钥 - -详情参考 [命令行文档](/zh-cn/command-line/) 中有关 `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 服务]({{< relref "doc/installation/run-as-service-in-ubuntu.zh-cn.md" >}}) - -### 2. 通过命令行终端运行 - -```sh -GITEA_WORK_DIR=/var/lib/gitea/ /usr/local/bin/gitea web -c /etc/gitea/app.ini -``` - -## 升级到最新版本 - -您可以通过停止程序，替换 `/usr/local/bin/gitea` 并重启来更新到新版本。直接替换可执行程序时不要更改或使用新的文件名称，以避免数据出错。 - -建议您在更新之前进行[备份]({{< relref "doc/administration/backup-and-restore.zh-cn.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/#troubleshooting) - -如果从本页中没有找到你需要的内容，请访问 [帮助页面]({{< relref "doc/help/support.zh-cn.md" >}}) diff --git a/docs/content/doc/installation/from-binary.zh-tw.md b/docs/content/doc/installation/from-binary.zh-tw.md deleted file mode 100644 index 78db79775d..0000000000 --- a/docs/content/doc/installation/from-binary.zh-tw.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "執行檔安裝" -slug: "install-from-binary" -weight: 15 -toc: false -draft: false -aliases: - - /zh-tw/install-from-binary -menu: - sidebar: - parent: "installation" - name: "執行檔" - weight: 15 - identifier: "install-from-binary" ---- - -# 從執行檔安裝 - -所有的執行檔皆支援 SQLite, MySQL and PostgreSQL，且所有檔案都已經包在執行檔內，這一點跟之前的版本有所不同。關於執行檔的安裝方式非常簡單，只要從[下載頁面](https://dl.gitea.com/gitea)選擇相對應平台，複製下載連結，使用底下指令就可以完成了: - -``` -wget -O gitea https://dl.gitea.com/gitea/{{< version >}}/gitea-{{< version >}}-linux-amd64 -chmod +x gitea -``` - -## 測試 - -執行完上述步驟，您將會得到 `gita` 執行檔，在複製到遠端伺服器前，您可以先測試看看，在命令列執行完成後，可以透過 `Ctrl + C` 關閉程式。 - -``` -./gitea web -``` - -## 需要協助？ - -如果本頁中無法解決您的問題，請直接到 [Discord server](https://discord.gg/Gitea)，在那邊可以快速得到協助。 diff --git a/docs/content/doc/installation/from-package.en-us.md b/docs/content/doc/installation/from-package.en-us.md deleted file mode 100644 index b427ae9a49..0000000000 --- a/docs/content/doc/installation/from-package.en-us.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Installation from package" -slug: "install-from-package" -weight: 20 -toc: false -draft: false -aliases: - - /en-us/install-from-package -menu: - sidebar: - parent: "installation" - name: "From package" - weight: 20 - identifier: "install-from-package" ---- - -**Table of Contents** - -{{< toc >}} - -# Official packages - -## macOS - -Currently, the only supported method of installation on MacOS is [Homebrew](http://brew.sh/). -Following the [deployment from binary]({{< relref "doc/installation/from-binary.en-us.md" >}}) guide may work, -but is not supported. To install Gitea via `brew`: - -``` -brew tap gitea/tap https://gitea.com/gitea/homebrew-gitea -brew install gitea -``` - -# Unofficial packages - -## Alpine Linux - -Alpine Linux has [Gitea](https://pkgs.alpinelinux.org/packages?name=gitea&branch=edge) in its community repository which follows the latest stable version. - -```sh -apk add gitea -``` - -## Arch Linux - -The rolling release distribution has [Gitea](https://www.archlinux.org/packages/community/x86_64/gitea/) in their official community repository and package updates are provided with new Gitea releases. - -```sh -pacman -S gitea -``` - -## Arch Linux ARM - -Arch Linux ARM provides packages for [aarch64](https://archlinuxarm.org/packages/aarch64/gitea), [armv7h](https://archlinuxarm.org/packages/armv7h/gitea) and [armv6h](https://archlinuxarm.org/packages/armv6h/gitea). - -```sh -pacman -S gitea -``` - -## Gentoo Linux - -The rolling release distribution has [Gitea](https://packages.gentoo.org/packages/www-apps/gitea) in their official community repository and package updates are provided with new Gitea releases. - -```sh -emerge gitea -va -``` - -## Canonical Snap - -There is a [Gitea Snap](https://snapcraft.io/gitea) package which follows the latest stable version. - -```sh -snap install gitea -``` - -## SUSE and openSUSE - -OpenSUSE build service provides packages for [openSUSE and SLE](https://software.opensuse.org/download/package?package=gitea&project=devel%3Atools%3Ascm) -in the Development Software Configuration Management Repository - -## Windows - -There is a [Gitea](https://chocolatey.org/packages/gitea) package for Windows by [Chocolatey](https://chocolatey.org/). - -```sh -choco install gitea -``` - -Or follow the [deployment from binary]({{< relref "doc/installation/from-binary.en-us.md" >}}) guide. - -## FreeBSD - -A FreeBSD port `www/gitea` is available. To install the pre-built binary package: - -``` -pkg install gitea -``` - -For the most up to date version, or to build the port with custom options, -[install it from the port](https://www.freebsd.org/doc/handbook/ports-using.html): - -``` -su - -cd /usr/ports/www/gitea -make install clean -``` - -The port uses the standard FreeBSD file system layout: config files are in `/usr/local/etc/gitea`, -bundled templates, options, plugins and themes are in `/usr/local/share/gitea`, and a start script -is in `/usr/local/etc/rc.d/gitea`. - -To enable Gitea to run as a service, run `sysrc gitea_enable=YES` and start it with `service gitea start`. - -## Others - -Various other third-party packages of Gitea exist. -To see a curated list, head over to [awesome-gitea](https://gitea.com/gitea/awesome-gitea/src/branch/master/README.md#user-content-packages). - -Do you know of an existing package that isn't on the list? Send in a PR to get it added! diff --git a/docs/content/doc/installation/from-package.fr-fr.md b/docs/content/doc/installation/from-package.fr-fr.md deleted file mode 100644 index 0a00cd7f0c..0000000000 --- a/docs/content/doc/installation/from-package.fr-fr.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Installation depuis le gestionnaire de paquets" -slug: "install-from-package" -weight: 20 -toc: false -draft: false -aliases: - - /fr-fr/install-from-package -menu: - sidebar: - parent: "installation" - name: "Gestionnaire de paquets" - weight: 20 - identifier: "install-from-package" ---- - -# Installation depuis le gestionnaire de paquets - -## Linux - -Nous n'avons pas encore publié de paquet pour Linux, nous allons mettre à jour cette page directement lorsque nous commencerons à publier des paquets pour toutes distributions Linux. En attendant, vous devriez suivre les [instructions d'installation]({{< relref "doc/installation/from-binary.fr-fr.md" >}}) avec le binaire pré-compilé. - -## Windows - -Nous n'avons pas encore publié de paquet pour Windows, nous allons mettre à jour cette page directement lorsque nous commencerons à publier des paquets sous la forme de fichiers `MSI` ou via [Chocolatey](https://chocolatey.org/). En attendant, vous devriez suivre les [instructions d'installation]({{< relref "doc/installation/from-binary.fr-fr.md" >}}) avec le binaire pré-compilé. - -## macOS - -Actuellement, nous ne supportons que l'installation via `brew` pour macOS. Si vous n'utilisez pas [Homebrew](http://brew.sh/), vous pouvez suivre les [instructions d'installation]({{< relref "doc/installation/from-binary.fr-fr.md" >}}) avec le binaire pré-compilé. Pour installer Gitea depuis `brew`, utilisez les commandes suivantes : - -``` -brew tap go-gitea/gitea -brew install gitea -``` - -## FreeBSD - -Le portage FreeBSD `www/gitea` est disponible. Vous pouvez également installer le paquet pré-compilé avec la commande suivante: - -``` -pkg install gitea -``` - -Pour une version plus récente, ou pour les instructions de compilations, veuillez consulter la documentation officielle de FreeBSD : [install it from the port](https://www.freebsd.org/doc/handbook/ports-using.html) - -``` -su - -cd /usr/ports/www/gitea -make install clean -``` - -Le port utilise la schéma standard du système de fichiers FreeBSD : Les fichiers de configuration sont localisés dans le répertoire `/usr/local/etc/gitea`, les modèles, options, plugins et thèmes sont localisés dans le répertoire `/usr/local/share/gitea`, et le script de démarrage se situe dans `/usr/local/etc/rc.d/gitea`. - -Pour exécuter Gitea en tant que service, utilisez la commande `sysrc gitea_enable=YES` et la commande `service gitea start` pour démarrer le service. - -## Il manque quelque chose ? - -Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/Gitea), vous obtiendrez des réponses à toute vos questions assez rapidement. diff --git a/docs/content/doc/installation/from-package.zh-cn.md b/docs/content/doc/installation/from-package.zh-cn.md deleted file mode 100644 index 4845dd1153..0000000000 --- a/docs/content/doc/installation/from-package.zh-cn.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "使用包管理器安装" -slug: "install-from-package" -weight: 20 -toc: false -draft: false -aliases: - - /zh-cn/install-from-package -menu: - sidebar: - parent: "installation" - name: "使用包管理器安装" - weight: 20 - identifier: "install-from-package" ---- - -**目录** - -{{< toc >}} - -# 官方包管理器 - -## macOS - -macOS 平台下当前我们仅支持通过 `brew` 来安装。如果你没有安装 [Homebrew](http://brew.sh/)，你也可以查看 [从二进制安装]({{< relref "doc/installation/from-binary.zh-cn.md" >}})。在你安装了 `brew` 之后， 你可以执行以下命令： - -``` -brew tap gitea/tap https://gitea.com/gitea/homebrew-gitea -brew install gitea -``` - -# 非官方包管理器 - -## 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 -``` - -你也可以 [从二进制安装]({{< relref "doc/installation/from-binary.zh-cn.md" >}}) 。 - -## 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 来添加它。 diff --git a/docs/content/doc/installation/from-package.zh-tw.md b/docs/content/doc/installation/from-package.zh-tw.md deleted file mode 100644 index c01653e1d0..0000000000 --- a/docs/content/doc/installation/from-package.zh-tw.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "套件安裝" -slug: "install-from-package" -weight: 20 -toc: false -draft: false -aliases: - - /zh-tw/install-from-package -menu: - sidebar: - parent: "installation" - name: "套件安裝" - weight: 20 - identifier: "install-from-package" ---- - -# 從套件安裝 - -## Linux - -目前尚未發佈任何 Linux 套件，如果我們發佈了，會直接更新此網頁。在這之前請先參考[執行檔安裝]({{< relref "doc/installation/from-binary.zh-tw.md" >}})方式。 - -## Windows - -在 Windows 作業系統你可以透過 [Chocolatey](https://chocolatey.org/) 套件管理器安裝 [Gitea](https://chocolatey.org/packages/gitea) 套件： - -```sh -choco install gitea -``` - -也可以參考[執行檔安裝]({{< relref "doc/installation/from-binary.zh-tw.md" >}})方式。 - -## macOS - -目前我們只支援透過 `brew` 來安裝套件。假如您尚未使用 [Homebrew](http://brew.sh/)，您就必須參考[執行檔安裝]({{< relref "doc/installation/from-binary.zh-tw.md" >}})方式。透過 `brew` 安裝 Gitea，您只需要執行底下指令: - -``` -brew tap go-gitea/gitea -brew install gitea -``` - -## FreeBSD - -下載 FreeBSD port `www/gitea` 套件。你可以安裝 pre-built 執行檔: - -``` -pkg install gitea -``` - -對於最新版本或想要自行編譯特定選項，請使用 [port 安裝](https://www.freebsd.org/doc/handbook/ports-using.html): - -``` -su - -cd /usr/ports/www/gitea -make install clean -``` - -## 需要協助？ - -如果本頁中無法解決您的問題，請直接到 [Discord server](https://discord.gg/Gitea)，在那邊可以快速得到協助。 diff --git a/docs/content/doc/installation/from-source.en-us.md b/docs/content/doc/installation/from-source.en-us.md deleted file mode 100644 index 98179dd55e..0000000000 --- a/docs/content/doc/installation/from-source.en-us.md +++ /dev/null @@ -1,266 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Installation from source" -slug: "install-from-source" -weight: 30 -toc: false -draft: false -aliases: - - /en-us/install-from-source -menu: - sidebar: - parent: "installation" - name: "From source" - weight: 30 - identifier: "install-from-source" ---- - -# Installation from source - -You should [install go](https://golang.org/doc/install) and set up your go -environment correctly. In particular, it is recommended to set the `$GOPATH` -environment variable and to add the go bin directory or directories -`${GOPATH//://bin:}/bin` to the `$PATH`. See the Go wiki entry for -[GOPATH](https://github.com/golang/go/wiki/GOPATH). - -Next, [install Node.js with npm](https://nodejs.org/en/download/) which is -required to build the JavaScript and CSS files. The minimum supported Node.js -version is {{< min-node-version >}} and the latest LTS version is recommended. - -**Note**: When executing make tasks that require external tools, like -`make misspell-check`, Gitea will automatically download and build these as -necessary. To be able to use these, you must have the `"$GOPATH/bin"` directory -on the executable path. If you don't add the go bin directory to the -executable path, you will have to manage this yourself. - -**Note 2**: Go version {{< min-go-version >}} or higher is required. However, it is recommended to -obtain the same version as our continuous integration, see the advice given in -[Hacking on Gitea]({{< relref "doc/development/hacking-on-gitea.en-us.md" >}}) - -**Table of Contents** - -{{< toc >}} - -## Download - -First, we must retrieve the source code. Since, the advent of go modules, the -simplest way of doing this is to use Git directly as we no longer have to have -Gitea built from within the GOPATH. - -```bash -git clone https://github.com/go-gitea/gitea -``` - -(Previous versions of this document recommended using `go get`. This is -no longer necessary.) - -Decide which version of Gitea to build and install. Currently, there are -multiple options to choose from. The `main` branch represents the current -development version. To build with main, skip to the [build section](#build). - -To work with tagged releases, the following commands can be used: - -```bash -git branch -a -git checkout v{{< version >}} -``` - -To validate a Pull Request, first enable the new branch (`xyz` is the PR id; -for example `2663` for [#2663](https://github.com/go-gitea/gitea/pull/2663)): - -```bash -git fetch origin pull/xyz/head:pr-xyz -``` - -To build Gitea from source at a specific tagged release (like v{{< version >}}), list the -available tags and check out the specific tag. - -List available tags with the following. - -```bash -git tag -l -git checkout v{{< version >}} # or git checkout pr-xyz -``` - -## Build - -To build from source, the following programs must be present on the system: - -- `go` {{< min-go-version >}} or higher, see [here](https://golang.org/dl/) -- `node` {{< min-node-version >}} or higher with `npm`, see [here](https://nodejs.org/en/download/) -- `make`, see [here]({{< relref "doc/development/hacking-on-gitea.en-us.md" >}}#installing-make) - -Various [make tasks](https://github.com/go-gitea/gitea/blob/main/Makefile) -are provided to keep the build process as simple as possible. - -Depending on requirements, the following build tags can be included. - -- `bindata`: Build a single monolithic binary, with all assets included. Required for production build. -- `sqlite sqlite_unlock_notify`: Enable support for a - [SQLite3](https://sqlite.org/) database. Suggested only for tiny - installations. -- `pam`: Enable support for PAM (Linux Pluggable Authentication Modules). Can - be used to authenticate local users or extend authentication to methods - available to PAM. -- `gogit`: (EXPERIMENTAL) Use go-git variants of Git commands. - -Bundling all assets (JS/CSS/templates, etc) into the binary. Using the `bindata` build tag is required for -production deployments. You could exclude `bindata` when you are developing/testing Gitea or able to separate the assets correctly. - -To include all assets, use the `bindata` tag: - -```bash -TAGS="bindata" make build -``` - -In the default release build of our continuous integration system, the build -tags are: `TAGS="bindata sqlite sqlite_unlock_notify"`. The simplest -recommended way to build from source is therefore: - -```bash -TAGS="bindata sqlite sqlite_unlock_notify" make build -``` - -The `build` target is split into two sub-targets: - -- `make backend` which requires [Go {{< min-go-version >}}](https://golang.org/dl/) or greater. -- `make frontend` which requires [Node.js {{< min-node-version >}}](https://nodejs.org/en/download/) or greater. - -If pre-built frontend files are present it is possible to only build the backend: - -```bash -TAGS="bindata" make backend -``` - -Webpack source maps are by default enabled in development builds and disabled in production builds. They can be enabled by setting the `ENABLE_SOURCEMAP=true` environment variable. - -## Test - -After following the steps above, a `gitea` binary will be available in the working directory. -It can be tested from this directory or moved to a directory with test data. When Gitea is -launched manually from command line, it can be killed by pressing `Ctrl + C`. - -```bash -./gitea web -``` - -## Changing default paths - -Gitea will search for a number of things from the _`CustomPath`_. By default this is -the `custom/` directory in the current working directory when running Gitea. It will also -look for its configuration file _`CustomConf`_ in `$(CustomPath)/conf/app.ini`, and will use the -current working directory as the relative base path _`AppWorkPath`_ for a number configurable -values. Finally the static files will be served from _`StaticRootPath`_ which defaults to the _`AppWorkPath`_. - -These values, although useful when developing, may conflict with downstream users preferences. - -One option is to use a script file to shadow the `gitea` binary and create an appropriate -environment before running Gitea. However, when building you can change these defaults -using the `LDFLAGS` environment variable for `make`. The appropriate settings are as follows - -- To set the _`CustomPath`_ use `LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=custom-path\""` -- For _`CustomConf`_ you should use `-X \"code.gitea.io/gitea/modules/setting.CustomConf=conf.ini\"` -- For _`AppWorkPath`_ you should use `-X \"code.gitea.io/gitea/modules/setting.AppWorkPath=working-path\"` -- For _`StaticRootPath`_ you should use `-X \"code.gitea.io/gitea/modules/setting.StaticRootPath=static-root-path\"` -- To change the default PID file location use `-X \"code.gitea.io/gitea/cmd.PIDFile=/run/gitea.pid\"` - -Add as many of the strings with their preceding `-X` to the `LDFLAGS` variable and run `make build` -with the appropriate `TAGS` as above. - -Running `gitea help` will allow you to review what the computed settings will be for your `gitea`. - -## Cross Build - -The `go` compiler toolchain supports cross-compiling to different architecture targets that are supported by the toolchain. See [`GOOS` and `GOARCH` environment variable](https://golang.org/doc/install/source#environment) for the list of supported targets. Cross compilation is helpful if you want to build Gitea for less-powerful systems (such as Raspberry Pi). - -To cross build Gitea with build tags (`TAGS`), you also need a C cross compiler which targets the same architecture as selected by the `GOOS` and `GOARCH` variables. For example, to cross build for Linux ARM64 (`GOOS=linux` and `GOARCH=arm64`), you need the `aarch64-unknown-linux-gnu-gcc` cross compiler. This is required because Gitea build tags uses `cgo`'s foreign-function interface (FFI). - -Cross-build Gitea for Linux ARM64, without any tags: - -``` -GOOS=linux GOARCH=arm64 make build -``` - -Cross-build Gitea for Linux ARM64, with recommended build tags: - -``` -CC=aarch64-unknown-linux-gnu-gcc GOOS=linux GOARCH=arm64 TAGS="bindata sqlite sqlite_unlock_notify" make build -``` - -Replace `CC`, `GOOS`, and `GOARCH` as appropriate for your architecture target. - -You will sometimes need to build a static compiled image. To do this you will need to add: - -``` -LDFLAGS="-linkmode external -extldflags '-static' $LDFLAGS" TAGS="netgo osusergo $TAGS" make build -``` - -This can be combined with `CC`, `GOOS`, and `GOARCH` as above. - -### Adding bash/zsh autocompletion (from 1.19) - -A script to enable bash-completion can be found at [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete). This should be altered as appropriate and can be `source` in your `.bashrc` -or copied as `/usr/share/bash-completion/completions/gitea`. - -Similarly, a script for zsh-completion can be found at [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete). This can be copied to `/usr/share/zsh/_gitea` or sourced within your -`.zshrc`. - -YMMV and these scripts may need further improvement. - -## Compile or cross-compile using Linux with Zig - -Follow [Getting Started of Zig](https://ziglang.org/learn/getting-started/#installing-zig) to install zig. - -- Compile (Linux ➝ Linux) - -```sh -CC="zig cc -target x86_64-linux-gnu" \ -CGO_ENABLED=1 \ -CGO_CFLAGS="-O2 -g -pthread" \ -CGO_LDFLAGS="-linkmode=external -v" -GOOS=linux \ -GOARCH=amd64 \ -TAGS="bindata sqlite sqlite_unlock_notify" \ -make build -``` - -- Cross-compile (Linux ➝ Windows) - -```sh -CC="zig cc -target x86_64-windows-gnu" \ -CGO_ENABLED=1 \ -CGO_CFLAGS="-O2 -g -pthread" \ -GOOS=windows \ -GOARCH=amd64 \ -TAGS="bindata sqlite sqlite_unlock_notify" \ -make build -``` - -## Compile or cross-compile with Zig using Windows - -Compile with `GIT BASH`. - -- Compile (Windows ➝ Windows) - -```sh -CC="zig cc -target x86_64-windows-gnu" \ -CGO_ENABLED=1 \ -CGO_CFLAGS="-O2 -g -pthread" \ -GOOS=windows \ -GOARCH=amd64 \ -TAGS="bindata sqlite sqlite_unlock_notify" \ -make build -``` - -- Cross-compile (Windows ➝ Linux) - -```sh -CC="zig cc -target x86_64-linux-gnu" \ -CGO_ENABLED=1 \ -CGO_CFLAGS="-O2 -g -pthread" \ -CGO_LDFLAGS="-linkmode=external -v" -GOOS=linux \ -GOARCH=amd64 \ -TAGS="bindata sqlite sqlite_unlock_notify" \ -make build -``` diff --git a/docs/content/doc/installation/from-source.fr-fr.md b/docs/content/doc/installation/from-source.fr-fr.md deleted file mode 100644 index 6e2ff164f9..0000000000 --- a/docs/content/doc/installation/from-source.fr-fr.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -date: "2017-08-23T09:00:00+02:00" -title: "Installation depuis le code source" -slug: "install-from-source" -weight: 30 -toc: false -draft: false -aliases: - - /fr-fr/install-from-source -menu: - sidebar: - parent: "installation" - name: "Code source" - weight: 30 - identifier: "install-from-source" ---- - -# Installation depuis le code source - -Nous ne couvrirons pas les bases de la configuration de Golang dans ce guide. Si vous ne savez pas comment démarrer un environnement fonctionnel, vous devrez suivre les [instructions d'installation](https://golang.org/doc/install) officielles. - -**Attention**: La version 1.7 ou suppérieur de Go est nécessaire - -## Téléchargement - -Tout d'abord, vous devez récupérer le code source, la manière la plus simple est d'utiliser directement Go. Il suffit d'appeler les commandes suivantes pour récupérer le code source et passer au répertoire de travail. - -``` -go get -d -u code.gitea.io/gitea -cd $GOPATH/src/code.gitea.io/gitea -``` - -Maintenant, il est temps de décider quelle version de Gitea vous souhaitez compiler et installer. Actuellement, ils existent plusieurs options possibles. Si vous voulez compiler notre branche `master`, vous pouvez directement passer à la [section compilation](#compilation), cette branche représente la dernière version en cours de développement et n'a pas vocation à être utiliser en production. - -Si vous souhaitez compiler la dernière version stable, utilisez les étiquettes ou les différentes branches disponibles. Vous pouvez voir les branches disponibles et comment utiliser cette branche avec ces commandes: - -``` -git branch -a -git checkout v{{< version >}} -``` - -Si vous souhaitez valider une demande d'ajout (_Pull request_), vous devez activer cette branche en premier : - -``` -git fetch origin pull/xyz/head:pr-xyz # xyz is PR value -``` - -Enfin, vous pouvez directement utiliser les versions étiquettées (ex : `v{{< version >}}`). Pour utiliser les étiquettes, vous devez lister les étiquettes disponibles et choisir une étiquette spécifique avec les commandes suivantes : - -``` -git tag -l -git checkout v{{< version >}} -git checkout pr-xyz -``` - -## Compilation - -Comme nous regroupons déjà toutes les bibliothèques requises pour compiler Gitea, vous pouvez continuer avec le processus de compilation lui-même. Nous fournissons diverses [tâches Make](https://github.com/go-gitea/gitea/blob/main/Makefile) pour rendre le processus de construction aussi simple que possible. [Voyez ici comment obtenir Make](/fr-fr/hacking-on-gitea/). Selon vos besoins, vous pourrez éventuellement ajouter diverses options de compilation, vous pouvez choisir entre ces options : - -* `bindata`: Intègre toutes les ressources nécessaires à l'exécution d'une instance de Gitea, ce qui rend un déploiement facile car il n'est pas nécessaire de se préoccuper des fichiers supplémentaires. -* `sqlite sqlite_unlock_notify`: Active la prise en charge d'une base de données [SQLite3](https://sqlite.org/), ceci n'est recommandé que pour les petites installations de Gitea. -* `pam`: Active la prise en charge de PAM (mLinux Pluggable Authentication Modules), très utile si vos utilisateurs doivent être authentifiés avec les comptes du système. - -Il est temps de compiler le binaire, nous suggérons d'intégrer les ressources avec l'option de compilation `bindata`: - -``` -TAGS="bindata" make build -``` - -## Test - -Après avoir suivi toutes les étapes, vous devriez avoir le binaire `gitea` dans votre répertoire courant. Dans un premier temps, vous pouvez tester qu'il fonctionne puis, dans un second temps, vous pouvez le copier dans la destination de votre choix. Lorsque vous lancez Gitea manuellement à partir de votre CLI, vous pouvez toujours le tuer en appuyant sur `Ctrl + C`. - -``` -./gitea web -``` - -## Il manque quelque chose ? - -Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/Gitea), vous obtiendrez des réponses à toute vos questions assez rapidement. diff --git a/docs/content/doc/installation/from-source.zh-cn.md b/docs/content/doc/installation/from-source.zh-cn.md deleted file mode 100644 index 5d4ab0c3ae..0000000000 --- a/docs/content/doc/installation/from-source.zh-cn.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "使用源代码安装" -slug: "install-from-source" -weight: 30 -toc: false -draft: false -aliases: - - /zh-cn/install-from-source -menu: - sidebar: - parent: "installation" - name: "使用源代码安装" - weight: 30 - identifier: "install-from-source" ---- - -# 使用源代码安装 - -首先你需要安装Golang，关于Golang的安装，参见[官方文档](https://golang.google.cn/doc/install)。 - -其次你需要[安装Node.js](https://nodejs.org/zh-cn/download/)，Node.js 和 npm 将用于构建 Gitea 前端。 - -**目录** - -{{< toc >}} - -## 下载 - -你需要获取Gitea的源码，最方便的方式是使用 `git` 命令。执行以下命令： - -``` -git clone https://github.com/go-gitea/gitea -cd gitea -``` - -然后你可以选择编译和安装的版本，当前你有多个选择。如果你想编译 `main` 版本，你可以直接跳到 [编译](#编译) 部分，这是我们的开发分支，虽然也很稳定但不建议您在正式产品中使用。 - -如果你想编译最新稳定分支，你可以执行以下命令签出源码： - -```bash -git branch -a -git checkout v{{< version >}} -``` - -最后，你也可以直接使用标签版本如 `v{{< version >}}`。你可以执行以下命令列出可用的版本并选择某个版本签出： - -```bash -git tag -l -git checkout v{{< version >}} -``` - -## 编译 - -要从源代码进行编译，以下依赖程序必须事先安装好： - -- `go` {{< min-go-version >}} 或以上版本, 详见[这里](https://golang.google.cn/doc/install) -- `node` {{< min-node-version >}} 或以上版本，并且安装 `npm`, 详见[这里](https://nodejs.org/zh-cn/download/) -- `make`, 详见[这里](/zh-cn/hacking-on-gitea/) - -各种可用的 [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 -``` - -## 使用Linux与Zig编译或交叉编译 - -按照[Getting Started of Zig](https://ziglang.org/learn/getting-started/#installing-zig)来安装zig。 - -- 编译(Linux ➝ Linux) - -```sh -CC="zig cc -target x86_64-linux-gnu" \ -CGO_ENABLED=1 \ -CGO_CFLAGS="-O2 -g -pthread" \ -CGO_LDFLAGS="-linkmode=external -v" -GOOS=linux \ -GOARCH=amd64 \ -TAGS="bindata sqlite sqlite_unlock_notify" \ -make build -``` - -- 交叉编译(Linux ➝ Windows) - -```sh -CC="zig cc -target x86_64-windows-gnu" \ -CGO_ENABLED=1 \ -CGO_CFLAGS="-O2 -g -pthread" \ -GOOS=windows \ -GOARCH=amd64 \ -TAGS="bindata sqlite sqlite_unlock_notify" \ -make build -``` - -## 使用Windows与Zig编译或交叉编译 - -使用`GIT BASH`编译。 - -- 编译(Windows ➝ Windows) - -```sh -CC="zig cc -target x86_64-windows-gnu" \ -CGO_ENABLED=1 \ -CGO_CFLAGS="-O2 -g -pthread" \ -GOOS=windows \ -GOARCH=amd64 \ -TAGS="bindata sqlite sqlite_unlock_notify" \ -make build -``` - -- 交叉编译(Windows ➝ Linux) - -```sh -CC="zig cc -target x86_64-linux-gnu" \ -CGO_ENABLED=1 \ -CGO_CFLAGS="-O2 -g -pthread" \ -CGO_LDFLAGS="-linkmode=external -v" -GOOS=linux \ -GOARCH=amd64 \ -TAGS="bindata sqlite sqlite_unlock_notify" \ -make build -``` diff --git a/docs/content/doc/installation/from-source.zh-tw.md b/docs/content/doc/installation/from-source.zh-tw.md deleted file mode 100644 index ea34b7e18c..0000000000 --- a/docs/content/doc/installation/from-source.zh-tw.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "原始碼安裝" -slug: "install-from-source" -weight: 30 -toc: false -draft: false -aliases: - - /zh-tw/install-from-source -menu: - sidebar: - parent: "installation" - name: "原始碼安裝" - weight: 30 - identifier: "install-from-source" ---- - -# 從原始碼安裝 - -我們不會在本文教大家如何安裝 Golang 環境。假如您不知道如何設定環境，請直接參考[官方安裝文件](https://golang.org/doc/install)。 - -## 下載 - -首先您必須先下載原始碼，最簡單的方式就是透過 Go 指令下載，請透過底下指令下載原始碼並且切換到工作目錄。 - -``` -go get -d -u code.gitea.io/gitea -cd $GOPATH/src/code.gitea.io/gitea -``` - -現在該決定您要編譯或安裝的 Gitea 版本，您有很多可以選擇。如果您想編譯 `master` 版本，你可以直接跳到[編譯章節](#編譯)，這是我們開發分支，雖然很穩定，但是不建議用在正式環境。 - -假如您想要編譯最新穩定版本，可以執行底下命令切換到正確版本: - -``` -git branch -a -git checkout v{{< version >}} -``` - -最後您也可以直接編譯最新的標籤版本像是 `v{{< version >}}`，假如您想要從原始碼編譯，這方法是最合適的，在編譯標籤版本前，您需要列出當下所有標籤，並且直接切換到標籤版本，請使用底下指令：: - -``` -git tag -l -git checkout v{{< version >}} -``` - -## 編譯 - -完成設定相依性套件環境等工作後，您就可以開始編譯工作了。我們提供了不同的[編譯選項](https://github.com/go-gitea/gitea/blob/main/Makefile) ，讓編譯過程更加簡單。您可以根據需求來調整編譯選項，底下是可用的編譯選項說明： - -* `bindata`: 使用此標籤來嵌入所有 Gitea 相關資源，您不用擔心其他額外檔案，對於部署來說非常方便。 -* `sqlite sqlite_unlock_notify`: 使用此標籤來啟用 [SQLite3](https://sqlite.org/) 資料庫，建議只有少數人時才使用此模式。 -* `pam`: 使用此標籤來啟用 PAM (Linux Pluggable Authentication Modules) 認證，對於系統使用者來說，此方式最方便了。 - -現在您可以開始編譯執行檔了，我們建議使用 `bindata` 編譯選項: - -``` -TAGS="bindata" make build -``` - -**注意**: 因為使用了套件管理工具，我們建議 Go 環境版本為 1.6 或者是更高，這樣不用在 Go 1.5 版本設定全域變數 `GO15VENDOREXPERIMENT`。 - -## 測試 - -完成上述步驟後，您可以在當下目錄發現 `gitea` 執行檔，在複製執行檔到遠端環境之前，您必須透過底下指令執行測試，使用 `Ctrl + C` 則可以關閉當下 gitea 程序。 - -``` -./gitea web -``` - -## 需要協助？ - -如果本頁中無法解決您的問題，請直接到 [Discord server](https://discord.gg/Gitea)，在那邊可以快速得到協助。 diff --git a/docs/content/doc/installation/on-cloud-provider.en-us.md b/docs/content/doc/installation/on-cloud-provider.en-us.md deleted file mode 100644 index bf3bf4c312..0000000000 --- a/docs/content/doc/installation/on-cloud-provider.en-us.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Install on Cloud Provider" -slug: "install-on-cloud-provider" -weight: 90 -toc: false -draft: false -aliases: - - /en-us/install-on-cloud-provider -menu: - sidebar: - parent: "installation" - name: "On cloud provider" - weight: 90 - identifier: "install-on-cloud-provider" ---- - -# Installation on Cloud Provider - -**Table of Contents** - -{{< toc >}} - -## Cloudron - -Gitea is available as a 1-click install on [Cloudron](https://cloudron.io). -Cloudron makes it easy to run apps like Gitea on your server and keep them up-to-date and secure. - -[](https://cloudron.io/button.html?app=io.gitea.cloudronapp) - -The Gitea package is maintained [here](https://git.cloudron.io/cloudron/gitea-app). - -There is a [demo instance](https://my.demo.cloudron.io) (username: cloudron password: cloudron) where -you can experiment with running Gitea. - -## Vultr - -Gitea can be found in [Vultr](https://www.vultr.com)'s marketplace. - -To deploy Gitea to Vultr, have a look at the [Vultr Marketplace](https://www.vultr.com/marketplace/apps/gitea). - -## DigitalOcean - -[DigitalOcean](https://www.digitalocean.com) has Gitea as droplet in their marketplace. - -To deploy Gitea to DigitalOcean, have a look at the [DigitalOcean Marketplace](https://marketplace.digitalocean.com/apps/gitea). - -## Linode - -[Linode](https://www.linode.com/) has Gitea as an app in their marketplace. - -To deploy Gitea to Linode, have a look at the [Linode Marketplace](https://www.linode.com/marketplace/apps/linode/gitea/). - -## alwaysdata - -[alwaysdata](https://www.alwaysdata.com/) has Gitea as an app in their marketplace. - -To deploy Gitea to alwaysdata, have a look at the [alwaysdata Marketplace](https://www.alwaysdata.com/en/marketplace/gitea/). - -## Exoscale - -[Exoscale](https://www.exoscale.com/) provides Gitea managed by [Glasskube](https://glasskube.eu/) in their marketplace. - -Exoscale is a European cloud service provider. - -The package is maintained and update via the open source [Glasskube Kubernetes Operator](https://github.com/glasskube/operator). - -To deploy Gitea to Exoscale, have a look at the [Exoscale Marketplace](https://www.exoscale.com/marketplace/listing/glasskube-gitea/). diff --git a/docs/content/doc/installation/on-cloud-provider.zh-cn.md b/docs/content/doc/installation/on-cloud-provider.zh-cn.md deleted file mode 100644 index 80fbf2d51d..0000000000 --- a/docs/content/doc/installation/on-cloud-provider.zh-cn.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "在云服务器中安装 Gitea" -slug: "install-on-cloud-provider" -weight: 90 -toc: false -draft: false -aliases: - - /zh-cn/install-on-cloud-provider -menu: - sidebar: - parent: "installation" - name: "在云服务器中安装 Gitea" - weight: 90 - identifier: "install-on-cloud-provider" ---- - -# 在云服务器上安装 Gitea - -**Table of Contents** - -{{< toc >}} - -## 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。 - -## Vultr - -Gitea 可以在 [Vultr](https://www.vultr.com) 的市场中被找到。 - -要将 Gitea 部署到 Vultr，请参考 [Vultr Marketplace](https://www.vultr.com/marketplace/apps/gitea). - -## DigitalOcean - -[DigitalOcean](https://www.digitalocean.com) 将 Gitea 作为其市场中的一个 droplet。 - -要将 Gitea 部署到 DigitalOcean, 请参考 [DigitalOcean Marketplace](https://marketplace.digitalocean.com/apps/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/). diff --git a/docs/content/doc/installation/on-kubernetes.en-us.md b/docs/content/doc/installation/on-kubernetes.en-us.md deleted file mode 100644 index 0847a3b852..0000000000 --- a/docs/content/doc/installation/on-kubernetes.en-us.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -date: "2020-03-19T19:27:00+02:00" -title: "Install on Kubernetes" -slug: "install-on-kubernetes" -weight: 80 -toc: false -draft: false -aliases: - - /en-us/install-on-kubernetes -menu: - sidebar: - parent: "installation" - name: "Kubernetes" - weight: 80 - identifier: "install-on-kubernetes" ---- - -# Installation with Helm (on Kubernetes) - -Gitea provides a Helm Chart to allow for installation on kubernetes. - -A non-customized install can be done with: - -``` -helm repo add gitea-charts https://dl.gitea.com/charts/ -helm install gitea gitea-charts/gitea -``` - -If you would like to customize your install, which includes kubernetes ingress, please refer to the complete [Gitea helm chart configuration details](https://gitea.com/gitea/helm-chart/) - -## Health check endpoint - -Gitea comes with a health check endpoint `/api/healthz`, you can configure it in kubernetes like this: - -```yaml - livenessProbe: - httpGet: - path: /api/healthz - port: http - initialDelaySeconds: 200 - timeoutSeconds: 5 - periodSeconds: 10 - successThreshold: 1 - failureThreshold: 10 -``` - -a successful health check response will respond with http code `200`, here's example: - -``` -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" - } - ] - } -} -``` - -for more information, please reference to kubernetes documentation [Define a liveness HTTP request](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request) diff --git a/docs/content/doc/installation/on-kubernetes.zh-cn.md b/docs/content/doc/installation/on-kubernetes.zh-cn.md deleted file mode 100644 index 83647a2eab..0000000000 --- a/docs/content/doc/installation/on-kubernetes.zh-cn.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -date: "2020-03-19T19:27:00+02:00" -title: "在 Kubernetes 中安装 Gitea" -slug: "install-on-kubernetes" -weight: 80 -toc: false -draft: false -aliases: - - /zh-cn/install-on-kubernetes -menu: - sidebar: - parent: "installation" - name: "在 Kubernetes 中安装 Gitea" - weight: 80 - identifier: "install-on-kubernetes" ---- - -# 使用 Helm 在 Kubernetes 云原生环境中安装 Gitea - -Gitea 已经提供了便于在 Kubernetes 云原生环境中安装所需的 Helm Chart - -默认安装指令为： - -```bash -helm repo add gitea https://dl.gitea.com/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`，下面是示例： - -``` -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/) diff --git a/docs/content/doc/installation/on-kubernetes.zh-tw.md b/docs/content/doc/installation/on-kubernetes.zh-tw.md deleted file mode 100644 index 28dfbda81d..0000000000 --- a/docs/content/doc/installation/on-kubernetes.zh-tw.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -date: "2020-03-19T19:27:00+02:00" -title: "在 Kubernetes 安裝" -slug: "install-on-kubernetes" -weight: 80 -toc: false -draft: false -aliases: - - /zh-tw/install-on-kubernetes -menu: - sidebar: - parent: "installation" - name: "Kubernetes" - weight: 80 - identifier: "install-on-kubernetes" ---- - -# 使用 Helm 安裝 (在 Kubernetes) - -Gitea 提供 Helm Chart 用來安裝於 kubernetes。 - -非自訂安裝可使用下列指令： - -``` -helm repo add gitea-charts https://dl.gitea.com/charts/ -helm install gitea gitea-charts/gitea -``` - -若您想自訂安裝（包括使用 kubernetes ingress），請前往完整的 [Gitea helm chart configuration details](https://gitea.com/gitea/helm-chart/) - -## 運行狀況檢查終端節點 - -Gitea 附帶了一個運行狀況檢查端點 `/api/healthz`，你可以像這樣在 kubernetes 中配置它: - -```yaml - livenessProbe: - httpGet: - path: /api/healthz - port: http - initialDelaySeconds: 200 - timeoutSeconds: 5 - periodSeconds: 10 - successThreshold: 1 - failureThreshold: 10 -``` - -成功的運行狀況檢查回應將使用 HTTP 代碼 `200` 進行回應，下面是示例: - -``` -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文檔[定義一個存活態 HTTP請求接口]（https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/） diff --git a/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md b/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md deleted file mode 100644 index 3587dfc01a..0000000000 --- a/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -date: "2017-07-21T12:00:00+02:00" -title: "Run as service in Linux" -slug: "linux-service" -weight: 40 -toc: false -draft: false -aliases: - - /en-us/linux-service -menu: - sidebar: - parent: "installation" - name: "Linux service" - weight: 40 - identifier: "linux-service" ---- - -### Run Gitea as Linux service - -You can run Gitea as service, using either systemd or supervisor. The steps below tested on Ubuntu 16.04, but those should work on any Linux distributions (with little modification). - -#### Using systemd - -Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) to `/etc/systemd/system/gitea.service`, then edit the file with your favorite editor. - -Uncomment any service that needs to be enabled on this host, such as MySQL. - -Change the user, home directory, and other required startup values. Change the -PORT or remove the -p flag if default port is used. - -Enable and start Gitea at boot: - -``` -sudo systemctl enable gitea -sudo systemctl start gitea -``` - -If you have systemd version 220 or later, you can enable and immediately start Gitea at once by: - -``` -sudo systemctl enable gitea --now -``` - -#### Using supervisor - -Install supervisor by running below command in terminal: - -``` -sudo apt install supervisor -``` - -Create a log dir for the supervisor logs: - -``` -# assuming Gitea is installed in /home/git/gitea/ -mkdir /home/git/gitea/log/supervisor -``` - -Append the configuration from the sample -[supervisord config](https://github.com/go-gitea/gitea/blob/main/contrib/supervisor/gitea) to `/etc/supervisor/supervisord.conf`. - -Using your favorite editor, change the user (`git`) and home -(`/home/git`) settings to match the deployment environment. Change the PORT -or remove the -p flag if default port is used. - -Lastly enable and start supervisor at boot: - -``` -sudo systemctl enable supervisor -sudo systemctl start supervisor -``` - -If you have systemd version 220 or later, you can enable and immediately start supervisor by: - -``` -sudo systemctl enable supervisor --now -``` diff --git a/docs/content/doc/installation/run-as-service-in-ubuntu.zh-cn.md b/docs/content/doc/installation/run-as-service-in-ubuntu.zh-cn.md deleted file mode 100644 index 1512a4ab27..0000000000 --- a/docs/content/doc/installation/run-as-service-in-ubuntu.zh-cn.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -date: "2017-07-21T12:00:00+02:00" -title: "在 Linux 中以 service 方式运行" -slug: "linux-service" -weight: 40 -toc: false -draft: false -aliases: - - /zh-cn/linux-service -menu: - sidebar: - parent: "installation" - name: "在Linux中以service方式运行" - weight: 40 - identifier: "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 -``` diff --git a/docs/content/doc/installation/run-as-service-in-ubuntu.zh-tw.md b/docs/content/doc/installation/run-as-service-in-ubuntu.zh-tw.md deleted file mode 100644 index 7465f2253e..0000000000 --- a/docs/content/doc/installation/run-as-service-in-ubuntu.zh-tw.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -date: "2017-07-21T12:00:00+02:00" -title: "在 Linux 中以服務執行" -slug: "linux-service" -weight: 40 -toc: false -draft: false -aliases: - - /zh-tw/linux-service -menu: - sidebar: - parent: "installation" - name: "Linux 服務" - weight: 40 - identifier: "linux-service" ---- - -### 以 Linux 服務執行 Gitea - -您可使用 systemd 或 supervisor 以服務的方式執行 Gitea。下列步驟已在 Ubuntu 16.04 中測試，但它們應該適用於所有的 Linux 發行版（只需要一些小小的調整）。 - -#### 使用 systemd - -複製範例 [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) 到 `/etc/systemd/system/gitea.service` 後用您喜愛的文字編輯器開啟檔案。 - -取消註解任何需要在此系統上啟動的服務像是 MySQL。 - -修改 user, home directory 和其它必要的啟動參數。若預設埠已被占用請修改埠號或移除「-p」旗標。 - -在系統啟動時啟用並執行 Gitea： - -``` -sudo systemctl enable gitea -sudo systemctl start gitea -``` - -若您使用 systemd 220 或更新版本，您能以一行指令啟動並立即執行 Gitea： - -``` -sudo systemctl enable gitea --now -``` - -#### 使用 supervisor - -在終端機使用下列指令安裝 supervisor： - -``` -sudo apt install supervisor -``` - -為 supervisor 建立 log 資料夾： - -``` -# assuming Gitea is installed in /home/git/gitea/ -mkdir /home/git/gitea/log/supervisor -``` - -附加範例 [supervisord config](https://github.com/go-gitea/gitea/blob/main/contrib/supervisor/gitea) 的設定值到 `/etc/supervisor/supervisord.conf`。 - -用您喜愛的文字編輯器修改使用者（git）和家目錄（/home/git）設定以符合部署環境。若預設埠已被占用請修改埠號或移除「-p」旗標。 - -最後設定在系統啟動時啟用並執行 supervisor： - -``` -sudo systemctl enable supervisor -sudo systemctl start supervisor -``` - -若您使用 systemd 220 或更新版本，您能以一行指令啟動並立即執行 supervisor： - -``` -sudo systemctl enable supervisor --now -``` diff --git a/docs/content/doc/installation/upgrade-from-gitea.en-us.md b/docs/content/doc/installation/upgrade-from-gitea.en-us.md deleted file mode 100644 index a6415f7861..0000000000 --- a/docs/content/doc/installation/upgrade-from-gitea.en-us.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -date: "2021-09-02T16:00:00+08:00" -title: "Upgrade from an old Gitea" -slug: "upgrade-from-gitea" -weight: 100 -toc: false -draft: false -aliases: - - /en-us/upgrade-from-gitea -menu: - sidebar: - parent: "installation" - name: "Upgrade From Old Gitea" - weight: 100 - identifier: "upgrade-from-gitea" ---- - -# Upgrade from an old Gitea - -**Table of Contents** - -{{< toc >}} - -To update Gitea, download a newer version, stop the old one, perform a backup, and run the new one. -Every time a Gitea instance starts up, it checks whether a database migration should be run. -If a database migration is required, Gitea will take some time to complete the upgrade and then serve. - -## Check the Changelog for breaking changes - -To make Gitea better, some breaking changes are unavoidable, especially for big milestone releases. -Before upgrade, please read the [Changelog on Gitea blog](https://blog.gitea.io/) -and check whether the breaking changes affect your Gitea instance. - -## Backup for downgrade - -Gitea keeps compatibility for patch versions whose first two fields are the same (`a.b.x` -> `a.b.y`), -these patch versions can be upgraded and downgraded with the same database structure. -Otherwise (`a.b.?` -> `a.c.?`), a newer Gitea version will upgrade the old database -to a new structure that may differ from the old version. - -For example: - -| From | To | Result | -| --- | --- | --- | -| 1.4.0 | 1.4.1 | ✅ | -| 1.4.1 | 1.4.0 | ⚠️ Not recommended, take your own risk! Although it may work if the database structure doesn't change, it's highly recommended to use a backup to downgrade. | -| 1.4.x | 1.5.y | ✅ Database gets upgraded. You can upgrade from 1.4.x to the latest 1.5.y directly. | -| 1.5.y | 1.4.x | ❌ Database already got upgraded and can not be used for an old Gitea, use a backup to downgrade. | - -**Since you can not run an old Gitea with an upgraded database, -a backup should always be made before a database upgrade.** - -If you use Gitea in production, it's always highly recommended to make a backup before upgrade, -even if the upgrade is between patch versions. - -Backup steps: - -* Stop Gitea instance -* Backup database -* Backup Gitea config -* Backup Gitea data files in `APP_DATA_PATH` -* Backup Gitea external storage (eg: S3/MinIO or other storages if used) - -If you are using cloud services or filesystems with snapshot feature, -a snapshot for the Gitea data volume and related object storage is more convenient. - -## Upgrade with Docker - -* `docker pull` the latest Gitea release. -* Stop the running instance, backup data. -* Use `docker` or `docker-compose` to start the newer Gitea Docker container. - -## Upgrade from package - -* Stop the running instance, backup data. -* Use your package manager to upgrade Gitea to the latest version. -* Start the Gitea instance. - -## Upgrade from binary - -* Download the latest Gitea binary to a temporary directory. -* Stop the running instance, backup data. -* Replace the installed Gitea binary with the downloaded one. -* Start the Gitea instance. - -A script automating these steps for a deployment on Linux can be found at [`contrib/upgrade.sh` in Gitea's source tree](https://github.com/go-gitea/gitea/blob/main/contrib/upgrade.sh). - -## Take care about customized templates - -Gitea's template structure and variables may change between releases, if you are using customized templates, -do pay attention if your templates are compatible with the Gitea you are using. - -If the customized templates don't match Gitea version, you may experience: -`50x` server error, page components missing or malfunctioning, strange page layout, ... -Remove or update the incompatible templates and Gitea web will work again. diff --git a/docs/content/doc/installation/upgrade-from-gitea.zh-cn.md b/docs/content/doc/installation/upgrade-from-gitea.zh-cn.md deleted file mode 100644 index 8429ca492e..0000000000 --- a/docs/content/doc/installation/upgrade-from-gitea.zh-cn.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -date: "2021-09-02T16:00:00+08:00" -title: "从旧版 Gitea 升级" -slug: "upgrade-from-gitea" -weight: 100 -toc: false -draft: false -menu: - sidebar: - parent: "installation" - name: "从旧版 Gitea 升级" - weight: 100 - identifier: "upgrade-from-gitea" ---- - -# 从旧版 Gitea 升级 - -**目录** - -{{< toc >}} - -想要升级 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 才可以正常工作。 diff --git a/docs/content/doc/installation/upgrade-from-gogs.en-us.md b/docs/content/doc/installation/upgrade-from-gogs.en-us.md deleted file mode 100644 index fa545ee025..0000000000 --- a/docs/content/doc/installation/upgrade-from-gogs.en-us.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Upgrade from Gogs" -slug: "upgrade-from-gogs" -weight: 101 -toc: false -draft: false -aliases: - - /en-us/upgrade-from-gogs -menu: - sidebar: - parent: "installation" - name: "Upgrade From Gogs" - weight: 101 - identifier: "upgrade-from-gogs" ---- - -# Upgrade from Gogs - -**Table of Contents** - -{{< toc >}} - -Gogs, version 0.9.146 and older, can be easily migrated to Gitea. - -There are some basic steps to follow. On a Linux system run as the Gogs user: - -* Create a Gogs backup with `gogs backup`. This creates `gogs-backup-[timestamp].zip` file - containing all important Gogs data. You would need it if you wanted to move to the `gogs` back later. -* Download the file matching the destination platform from the [downloads page](https://dl.gitea.com/gitea/). - It should be `1.0.x` version. Migrating from `gogs` to any other version is impossible. -* Put the binary at the desired install location. -* Copy `gogs/custom/conf/app.ini` to `gitea/custom/conf/app.ini`. -* Copy custom `templates, public` from `gogs/custom/` to `gitea/custom/`. -* For any other custom folders, such as `gitignore, label, license, locale, readme` in - `gogs/custom/conf`, copy them to `gitea/custom/options`. -* Copy `gogs/data/` to `gitea/data/`. It contains issue attachments and avatars. -* Verify by starting Gitea with `gitea web`. -* Enter Gitea admin panel on the UI, run `Rewrite '.ssh/authorized_keys' file`. -* Launch every major version of the binary ( `1.1.4` → `1.2.3` → `1.3.4` → `1.4.2` → etc ) to migrate database. -* If custom or config path was changed, run `Rewrite all update hook of repositories`. - -## Change gogs specific information - -* Rename `gogs-repositories/` to `gitea-repositories/` -* Rename `gogs-data/` to `gitea-data/` -* In `gitea/custom/conf/app.ini` change: - - FROM: - - ```ini - [database] - PATH = /home/:USER/gogs/data/:DATABASE.db - [attachment] - PATH = /home/:USER/gogs-data/attachments - [picture] - AVATAR_UPLOAD_PATH = /home/:USER/gogs-data/avatars - [log] - ROOT_PATH = /home/:USER/gogs/log - ``` - - TO: - - ```ini - [database] - PATH = /home/:USER/gitea/data/:DATABASE.db - [attachment] - PATH = /home/:USER/gitea-data/attachments - [picture] - AVATAR_UPLOAD_PATH = /home/:USER/gitea-data/avatars - [log] - ROOT_PATH = /home/:USER/gitea/log - ``` - -* Verify by starting Gitea with `gitea web` - -## Upgrading to most recent `gitea` version - -After successful migration from `gogs` to `gitea 1.0.x`, it is possible to upgrade `gitea` to a modern version -in a two steps process. - -Upgrade to [`gitea 1.6.4`](https://dl.gitea.com/gitea/1.6.4/) first. Download the file matching -the destination platform from the [downloads page](https://dl.gitea.com/gitea/1.6.4/) and replace the binary. -Run Gitea at least once and check that everything works as expected. - -Then repeat the procedure, but this time using the [latest release](https://dl.gitea.com/gitea/{{< version >}}/). - -## Upgrading from a more recent version of Gogs - -Upgrading from a more recent version of Gogs (up to `0.11.x`) may also be possible, but will require a bit more work. -See [#4286](https://github.com/go-gitea/gitea/issues/4286), which includes various Gogs `0.11.x` versions. - -Upgrading from Gogs `0.12.x` and above will be increasingly more difficult as the projects diverge further apart in configuration and schema. - -## Troubleshooting - -* If errors are encountered relating to custom templates in the `gitea/custom/templates` - folder, try moving the templates causing the errors away one by one. They may not be - compatible with Gitea or an update. - -## Add Gitea to startup on Unix - -Update the appropriate file from [gitea/contrib](https://github.com/go-gitea/gitea/tree/main/contrib) -with the right environment variables. - -For distros with systemd: - -* Copy the updated script to `/etc/systemd/system/gitea.service` -* Add the service to the startup with: `sudo systemctl enable gitea` -* Disable old gogs startup script: `sudo systemctl disable gogs` - -For distros with SysVinit: - -* Copy the updated script to `/etc/init.d/gitea` -* Add the service to the startup with: `sudo rc-update add gitea` -* Disable old gogs startup script: `sudo rc-update del gogs` diff --git a/docs/content/doc/installation/upgrade-from-gogs.fr-fr.md b/docs/content/doc/installation/upgrade-from-gogs.fr-fr.md deleted file mode 100644 index 9d287d111d..0000000000 --- a/docs/content/doc/installation/upgrade-from-gogs.fr-fr.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -date: "2017-08-23T09:00:00+02:00" -title: "Mise à jour depuis Gogs" -slug: "upgrade-from-gogs" -weight: 101 -toc: false -draft: false -aliases: - - /fr-fr/upgrade-from-gogs -menu: - sidebar: - parent: "installation" - name: "Depuis Gogs" - weight: 101 - identifier: "upgrade-from-gogs" ---- - -# Mise à jour depuis Gogs - -À partir de la version 0.9.146 (schéma de la base de données : version 15) de Gogs, Il est possible de migrer vers Gitea simplement et sans encombre. - -Veuillez suivre les étapes ci-dessous. Sur Unix, toute les commandes s'exécutent en tant que l'utilisateur utilisé pour votre installation de Gogs : - -* Crééer une sauvegarde de Gogs avec la commande `gogs dump`. Le fichier nouvellement créé `gogs-dump-[timestamp].zip` contient toutes les données de votre instance de Gogs. -* Téléchargez le fichier correspondant à votre plateforme à partir de la [page de téléchargements](https://dl.gitea.com/gitea). -* Mettez la binaire dans le répertoire d'installation souhaité. -* Copiez le fichier `gogs/custom/conf/app.ini` vers `gitea/custom/conf/app.ini`. -* Si vous avez personnalisé les répertoires `templates, public` dans `gogs/custom/`, copiez-les vers `gitea/custom/`. -* Si vous avez d'autres répertoires personnalisés comme `gitignore, label, license, locale, readme` dans `gogs/custom/conf` copiez-les vers `gitea/custom/options`. -* Copiez le répertoire `gogs/data/` vers `gitea/data/`. -* Vérifiez votre installation en exécutant Gitea avec la commande `gitea web`. -* Lancez le binaire de version majeure en version majeure ( `1.1.4` → `1.2.3` → `1.3.4` → `1.4.2` → etc ) afin de récupérer les migrations de base de données. -* Connectez vous au panel d'administration de Gitea et exécutez l'action `Rewrite '.ssh/authorized_keys' file`, puis l'action `Rewrite all update hook of repositories` (obligatoire si le chemin menant à votre configuration personnalisée à changé). - -## Modifier les informations spécifiques de gogs - -* Renommez `gogs-repositories/` vers `gitea-repositories/` -* Renommez `gogs-data/` to `gitea-data/` -* Dans votre fichier `gitea/custom/conf/app.ini`, modifiez les éléments suivants: - - DE : - - ```ini - [database] - PATH = /home/:USER/gogs/data/:DATABASE.db - [attachment] - PATH = /home/:USER/gogs-data/attachments - [picture] - AVATAR_UPLOAD_PATH = /home/:USER/gogs-data/avatars - [log] - ROOT_PATH = /home/:USER/gogs/log - ``` - - VERS : - - ```ini - [database] - PATH = /home/:USER/gitea/data/:DATABASE.db - [attachment] - PATH = /home/:USER/gitea-data/attachments - [picture] - AVATAR_UPLOAD_PATH = /home/:USER/gitea-data/avatars - [log] - ROOT_PATH = /home/:USER/gitea/log - ``` - -* Vérifiez votre installation en exécutant Gitea avec la commande `gitea web`. - -## Dépannage - -* Si vous rencontrez des erreurs relatives à des modèles personnalisés dans le dossier `gitea/custom/templates`, essayez de déplacer un par un les modèles provoquant les erreurs. Il est possible qu'ils ne soient pas compatibles avec Gitea. - -## Démarrer automatiquement Gitea (Unix) - -Distributions utilisant systemd: - -* Copiez le script mis à jour vers `/etc/systemd/system/gitea.service` -* Ajoutez le service avec la commande `sudo systemctl enable gitea` -* Désactivez Gogs avec la commande `sudo systemctl disable gogs` - -Distributions utilisant SysVinit: - -* Copiez le script mis à jour vers `/etc/init.d/gitea` -* Ajoutez le service avec la commande `sudo rc-update add gitea` -* Désactivez Gogs avec la commande `sudo rc-update del gogs` diff --git a/docs/content/doc/installation/upgrade-from-gogs.zh-cn.md b/docs/content/doc/installation/upgrade-from-gogs.zh-cn.md deleted file mode 100644 index f537896ca1..0000000000 --- a/docs/content/doc/installation/upgrade-from-gogs.zh-cn.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "从 Gogs 升级" -slug: "upgrade-from-gogs" -weight: 101 -toc: false -draft: false -aliases: - - /zh-cn/upgrade-from-gogs -menu: - sidebar: - parent: "installation" - name: "从 Gogs 升级" - weight: 101 - identifier: "upgrade-from-gogs" ---- - -# 从 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 钩子（用于自定义配置文件被修改）`。 diff --git a/docs/content/doc/installation/upgrade-from-gogs.zh-tw.md b/docs/content/doc/installation/upgrade-from-gogs.zh-tw.md deleted file mode 100644 index 46442845e7..0000000000 --- a/docs/content/doc/installation/upgrade-from-gogs.zh-tw.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "從 Gogs 升級" -slug: "upgrade-from-gogs" -weight: 101 -toc: false -draft: false -aliases: - - /zh-tw/upgrade-from-gogs -menu: - sidebar: - parent: "installation" - name: "從 Gogs 升級" - weight: 101 - identifier: "upgrade-from-gogs" ---- - -# 從 Gogs 升級 - -**目錄** - -{{< toc >}} - -若您正在執行 Gogs 0.9.146 以下版本，您可以很簡單地遷移到 Gitea。 - -請參考下列步驟。在 Linux 系統上請以 Gogs 的使用者身份執行： - -- 使用 `gogs backup` 建立 Gogs 的備份。這會建立檔案 `gogs-backup-[timestamp].zip` 包含所有重要的 Gogs 資料。 - 如果稍後您要恢復到 `gogs` 時會用到它。 -- 從[下載頁](https://dl.gitea.com/gitea/)下載對應您平臺的檔案。請下載 `1.0.x` 版，從 `gogs` 遷移到其它版本是不可行的。 -- 將二進位檔放到適當的安裝位置。 -- 複製 `gogs/custom/conf/app.ini` 到 `gitea/custom/conf/app.ini`。 -- 從 `gogs/custom/` 複製自訂 `templates, public` 到 `gitea/custom/`。 -- `gogs/custom/conf` 中的其它自訂資料夾如： `gitignore, label, license, locale, readme`， - 請複製到 `gitea/custom/options`。 -- 複製 `gogs/data/` 到 `gitea/data/`。它包含了問題附件和大頭貼。 -- 以指令 `gitea web` 啟動 Gitea 驗證上列設定是否正確。 -- 從網頁 UI 進入 Gitea 管理員面板, 執行 `Rewrite '.ssh/authorized_keys' file`。 -- 執行每個主要版本的二進位檔 ( `1.1.4` → `1.2.3` → `1.3.4` → `1.4.2` → 等等 ) 以遷移資料庫。 -- 如果變更了自訂檔、設定檔路徑，請執行 `Rewrite all update hook of repositories`。 - -## 修改指定的 gogs 資訊 - -- 重新命名 `gogs-repositories/` 為 `gitea-repositories/` -- 重新命名 `gogs-data/` 為 `gitea-data/` -- 在 `gitea/custom/conf/app.ini` 中修改： - - 修改前： - - ```ini - [database] - PATH = /home/:USER/gogs/data/:DATABASE.db - [attachment] - PATH = /home/:USER/gogs-data/attachments - [picture] - AVATAR_UPLOAD_PATH = /home/:USER/gogs-data/avatars - [log] - ROOT_PATH = /home/:USER/gogs/log - ``` - - 修改後： - - ```ini - [database] - PATH = /home/:USER/gitea/data/:DATABASE.db - [attachment] - PATH = /home/:USER/gitea-data/attachments - [picture] - AVATAR_UPLOAD_PATH = /home/:USER/gitea-data/avatars - [log] - ROOT_PATH = /home/:USER/gitea/log - ``` - -- 執行 `gitea web` 啟動 Gitea 檢查是否正確執行 - -## 升級到最新版的 `gitea` - -成功從 `gogs` 升級到 `gitea 1.0.x` 後再用 2 個步驟即可升級到最新版的 `gitea`。 - -請先升級到 [`gitea 1.6.4`](https://dl.gitea.com/gitea/1.6.4/)，先從[下載頁](https://dl.gitea.com/gitea/1.6.4/)下載 -您平臺的二進位檔取代既有的。至少執行一次 Gitea 並確認一切符合預期。 - -接著重複上述步驟，但這次請使用[最新發行版本](https://dl.gitea.com/gitea/{{< version >}}/)。 - -## 從更新版本的 Gogs 升級 - -您也可以從更新版本的 Gogs 升級，但需要更多步驟。 -請參考 [#4286](https://github.com/go-gitea/gitea/issues/4286)。 - -## 疑難排解 - -- 如果錯誤和 `gitea/custom/templates` 中 的自訂樣板有關，請試著逐一移除它們。 - 它們可能和 Gitea 或更新不相容。 - -## 在 Unix 啟動時執行 Gitea - -從 [gitea/contrib](https://github.com/go-gitea/gitea/tree/master/contrib) 更新必要的檔案以取得正確的環境變數。 - -使用 systemd 的發行版： - -- 複製新的腳本到 `/etc/systemd/system/gitea.service` -- 啟動系統時執行服務： `sudo systemctl enable gitea` -- 停用舊的 gogs 腳本： `sudo systemctl disable gogs` - -使用 SysVinit 的發行版： - -- 複製新的腳本到 `/etc/init.d/gitea` -- 啟動系統時執行服務： `sudo rc-update add gitea` -- 停用舊的 gogs 腳本： `sudo rc-update del gogs` diff --git a/docs/content/doc/installation/windows-service.en-us.md b/docs/content/doc/installation/windows-service.en-us.md deleted file mode 100644 index d3f5a9abae..0000000000 --- a/docs/content/doc/installation/windows-service.en-us.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -date: "2016-12-21T15:00:00-02:00" -title: "Register as a Windows Service" -slug: "windows-service" -weight: 50 -toc: false -draft: false -aliases: - - /en-us/windows-service -menu: - sidebar: - parent: "installation" - name: "Windows Service" - weight: 50 - identifier: "windows-service" ---- - -# Prerequisites - -The following changes are made in C:\gitea\custom\conf\app.ini: - -``` -RUN_USER = COMPUTERNAME$ -``` - -Sets Gitea to run as the local system user. - -COMPUTERNAME is whatever the response is from `echo %COMPUTERNAME%` on the command line. If the response is `USER-PC` then `RUN_USER = USER-PC$` - -## Use absolute paths - -If you use SQLite3, change the `PATH` to include the full path: - -``` -[database] -PATH = c:/gitea/data/gitea.db -``` - -# Register as a Windows Service - -To register Gitea as a Windows service, open a command prompt (cmd) as an Administrator, -then run the following command: - -``` -sc.exe create gitea start= auto binPath= "\"C:\gitea\gitea.exe\" web --config \"C:\gitea\custom\conf\app.ini\"" -``` - -Do not forget to replace `C:\gitea` with the correct Gitea directory. - -Open "Windows Services", search for the service named "gitea", right-click it and click on -"Run". If everything is OK, Gitea will be reachable on `http://localhost:3000` (or the port -that was configured). - -## Adding startup dependencies - -To add a startup dependency to the Gitea Windows service (eg Mysql, Mariadb), as an Administrator, then run the following command: - -``` -sc.exe config gitea depend= mariadb -``` - -This will ensure that when the Windows machine restarts, the automatic starting of Gitea is postponed until the database is ready and thus mitigate failed startups. - -## Unregister as a service - -To unregister Gitea as a service, open a command prompt (cmd) as an Administrator and run: - -``` -sc.exe delete gitea -``` diff --git a/docs/content/doc/installation/windows-service.fr-fr.md b/docs/content/doc/installation/windows-service.fr-fr.md deleted file mode 100644 index c4e00b04e1..0000000000 --- a/docs/content/doc/installation/windows-service.fr-fr.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -date: "2017-08-23T09:00:00+02:00" -title: "Démarrer en tant que service Windows" -slug: "windows-service" -weight: 50 -toc: false -draft: false -aliases: - - /fr-fr/windows-service -menu: - sidebar: - parent: "installation" - name: "Service Windows" - weight: 50 - identifier: "windows-service" ---- - -# Activer un service Windows - -Pour activer le service Windows Gitea, ouvrez une `cmd` en tant qu'Administrateur puis utilisez la commande suivante : - -``` -sc create gitea start= auto binPath= "\"C:\gitea\gitea.exe\" web --config \"C:\gitea\custom\conf\app.ini\"" -``` - -N'oubliez pas de remplacer `C:\gitea` par le chemin que vous avez utilisé pour votre installation. - -Ensuite, ouvrez "Services Windows", puis recherchez le service `gitea`, faites un clic droit et selectionnez "Run". Si tout fonctionne, vous devriez être capable d'accèder à Gitea à l'URL `http://localhost:3000` (ou sur le port configuré si différent de 3000). - -## Désactiver un service Windows - -Pour désactiver le service Windows Gitea, ouvrez une `cmd` en tant qu'Administrateur puis utilisez la commande suivante : - -``` -sc delete gitea -``` diff --git a/docs/content/doc/installation/windows-service.zh-cn.md b/docs/content/doc/installation/windows-service.zh-cn.md deleted file mode 100644 index 0f2a0f5869..0000000000 --- a/docs/content/doc/installation/windows-service.zh-cn.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -date: "2016-12-21T15:00:00-02:00" -title: "注册为Windows服务" -slug: "windows-service" -weight: 50 -toc: false -draft: false -aliases: - - /zh-cn/windows-service -menu: - sidebar: - parent: "installation" - name: "Windows服务" - weight: 50 - identifier: "windows-service" ---- - -# 注册为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 -``` diff --git a/docs/content/doc/installation/windows-service.zh-tw.md b/docs/content/doc/installation/windows-service.zh-tw.md deleted file mode 100644 index 5764d647fc..0000000000 --- a/docs/content/doc/installation/windows-service.zh-tw.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -date: "2016-12-21T15:00:00-02:00" -title: "註冊為 Windows 服務" -slug: "windows-service" -weight: 50 -toc: false -draft: false -aliases: - - /zh-tw/windows-service -menu: - sidebar: - parent: "installation" - name: "Windows 服務" - weight: 50 - identifier: "windows-service" ---- - -# 事前準備 - -確認您的 C:\gitea\custom\conf\app.ini 中包含： - -``` -RUN_USER = COMPUTERNAME$ -``` - -設定 Gitea 以本地使用者身份執行。 - -請將在命令提示字元（cmd）執行 `echo %COMPUTERNAME%` 的結果輸入 `COMPUTERNAME`。若回應為 `USER-PC`，請輸入 `RUN_USER = USER-PC$` - -## 使用絕對路徑 - -如果您使用 sqlite3，修改 `PATH` 為完整路徑： - -``` -[database] -PATH = c:/gitea/data/gitea.db -``` - -# 註冊為 Windows 服務 - -要註冊為 Windows 服務，請先以系統管理員身份開啟命令提示字元，接著執行下列指令： - -``` -sc.exe create gitea start= auto binPath= "\"C:\gitea\gitea.exe\" web --config \"C:\gitea\custom\conf\app.ini\"" -``` - -別忘記將 `C:\gitea` 取代為您的 Gitea 安裝路徑。 - -開啟 Windows 的「服務」，並且搜尋服務名稱「gitea」，按右鍵選擇「啟動」。在瀏覽器打開 `http://localhost:3000` 就可以成功看到畫面 (如果修改過連接埠，請自行修正，3000 是預設值)。 - -## 刪除服務 - -要刪除 Gitea 服務，請用系統管理員身份開啟命令提示字元，接著執行下列指令： - -``` -sc.exe delete gitea -``` diff --git a/docs/content/doc/installation/with-docker-rootless.en-us.md b/docs/content/doc/installation/with-docker-rootless.en-us.md deleted file mode 100644 index 6c2326b7c9..0000000000 --- a/docs/content/doc/installation/with-docker-rootless.en-us.md +++ /dev/null @@ -1,364 +0,0 @@ ---- -date: "2020-02-09T20:00:00+02:00" -title: "Installation with Docker (rootless)" -slug: "install-with-docker-rootless" -weight: 60 -toc: false -draft: false -aliases: - - /en-us/install-with-docker-rootless -menu: - sidebar: - parent: "installation" - name: "With Docker Rootless" - weight: 60 - identifier: "install-with-docker-rootless" ---- - -# Installation with Docker - -Gitea provides automatically updated Docker images within its Docker Hub organization. It is -possible to always use the latest stable tag or to use another service that handles updating -Docker images. - -The rootless image uses Gitea internal SSH to provide Git protocol and doesn't support OpenSSH. - -This reference setup guides users through the setup based on `docker-compose`, but the installation -of `docker-compose` is out of scope of this documentation. To install `docker-compose` itself, follow -the official [install instructions](https://docs.docker.com/compose/install/). - -## Basics - -The most simple setup just creates a volume and a network and starts the `gitea/gitea:latest-rootless` -image as a service. Since there is no database available, one can be initialized using SQLite3. - -Create a directory for `data` and `config`: - -```sh -mkdir -p gitea/{data,config} -cd gitea -touch docker-compose.yml -``` - -Then paste the following content into a file named `docker-compose.yml`: - -```yaml -version: "2" - -services: - server: - image: gitea/gitea:{{< version >}}-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" -``` - -Note that the volume should be owned by the user/group with the UID/GID specified in the config file. By default Gitea in docker will use uid:1000 gid:1000. If needed you can set ownership on those folders with the command: - -```sh -sudo chown 1000:1000 config/ data/ -``` - -> If you don't give the volume correct permissions, the container may not start. - -For a stable release you could use `:latest-rootless`, `:1-rootless` or specify a certain release like `:{{< version >}}-rootless`, but if you'd like to use the latest development version then `:nightly-rootless` would be an appropriate tag. If you'd like to run the latest commit from a release branch you can use the `:1.x-nightly-rootless` tag, where x is the minor version of Gitea. (e.g. `:1.16-nightly-rootless`) - -## Custom port - -To bind the integrated ssh and the webserver on a different port, adjust -the port section. It's common to just change the host port and keep the ports within -the container like they are. - -```diff -version: "2" - -services: - server: - image: gitea/gitea:{{< version >}}-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 database - -To start Gitea in combination with a MySQL database, apply these changes to the -`docker-compose.yml` file created above. - -```diff -version: "2" - -services: - server: - image: gitea/gitea:{{< version >}}-rootless -+ environment: -+ - GITEA__database__DB_TYPE=mysql -+ - GITEA__database__HOST=db:3306 -+ - GITEA__database__NAME=gitea -+ - GITEA__database__USER=gitea -+ - GITEA__database__PASSWD=gitea - restart: always - volumes: - - ./data:/var/lib/gitea - - ./config:/etc/gitea - - /etc/timezone:/etc/timezone:ro - - /etc/localtime:/etc/localtime:ro - ports: - - "3000:3000" - - "2222:2222" -+ depends_on: -+ - db -+ -+ db: -+ image: mysql:8 -+ restart: always -+ environment: -+ - MYSQL_ROOT_PASSWORD=gitea -+ - MYSQL_USER=gitea -+ - MYSQL_PASSWORD=gitea -+ - MYSQL_DATABASE=gitea -+ volumes: -+ - ./mysql:/var/lib/mysql -``` - -## PostgreSQL database - -To start Gitea in combination with a PostgreSQL database, apply these changes to -the `docker-compose.yml` file created above. - -```diff -version: "2" - -services: - server: - image: gitea/gitea:{{< version >}}-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: postgres:14 -+ restart: always -+ environment: -+ - POSTGRES_USER=gitea -+ - POSTGRES_PASSWORD=gitea -+ - POSTGRES_DB=gitea -+ volumes: -+ - ./postgres:/var/lib/postgresql/data -``` - -## Named volumes - -To use named volumes instead of host volumes, define and use the named volume -within the `docker-compose.yml` configuration. This change will automatically -create the required volume. You don't need to worry about permissions with -named volumes; Docker will deal with that automatically. - -```diff -version: "2" - -+volumes: -+ gitea-data: -+ driver: local -+ gitea-config: -+ driver: local -+ -services: - server: - image: gitea/gitea:{{< version >}}-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 or PostgreSQL containers will need to be created separately. - -## Custom user - -You can choose to use a custom user (following --user flag definition https://docs.docker.com/engine/reference/run/#user). -As an example to clone the host user `git` definition use the command `id -u git` and add it to `docker-compose.yml` file: -Please make sure that the mounted folders are writable by the user. - -```diff -version: "2" - -services: - server: - image: gitea/gitea:{{< version >}}-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" -``` - -## Start - -To start this setup based on `docker-compose`, execute `docker-compose up -d`, -to launch Gitea in the background. Using `docker-compose ps` will show if Gitea -started properly. Logs can be viewed with `docker-compose logs`. - -To shut down the setup, execute `docker-compose down`. This will stop -and kill the containers. The volumes will still exist. - -Notice: if using a non-3000 port on http, change app.ini to match -`LOCAL_ROOT_URL = http://localhost:3000/`. - -## Install - -After starting the Docker setup via `docker-compose`, Gitea should be available using a -favorite browser to finalize the installation. Visit http://server-ip:3000 and follow the -installation wizard. If the database was started with the `docker-compose` setup as -documented above, please note that `db` must be used as the database hostname. - -# Customization - -Customization files described [here](https://docs.gitea.io/en-us/customizing-gitea/) should -be placed in `/var/lib/gitea/custom` directory. If using host volumes, it's quite easy to access these -files; for named volumes, this is done through another container or by direct access at -`/var/lib/docker/volumes/gitea_gitea/_/var_lib_gitea`. The configuration file will be saved at -`/etc/gitea/app.ini` after the installation. - -# Upgrading - -:exclamation::exclamation: **Make sure you have volumed data to somewhere outside Docker container** :exclamation::exclamation: - -To upgrade your installation to the latest release: - -``` -# 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 -``` - -# Upgrading from standard image - -- Backup your setup -- Change volume mountpoint from /data to /var/lib/gitea -- If you used a custom app.ini move it to a new volume mounted to /etc/gitea -- Rename folder (inside volume) gitea to custom -- Edit app.ini if needed - - Set START_SSH_SERVER = true -- Use image gitea/gitea:{{< version >}}-rootless - -## Managing Deployments With Environment Variables - -In addition to the environment variables above, any settings in `app.ini` can be set -or overridden with an environment variable of the form: `GITEA__SECTION_NAME__KEY_NAME`. -These settings are applied each time the docker container starts, and won't be passed into Gitea's sub-processes. -Full information [here](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini). - -These environment variables can be passed to the docker container in `docker-compose.yml`. -The following example will enable a smtp mail server if the required env variables -`GITEA__mailer__FROM`, `GITEA__mailer__HOST`, `GITEA__mailer__PASSWD` are set on the host -or in a `.env` file in the same directory as `docker-compose.yml`. - -The settings can be also set or overridden with the content of a file by defining an environment variable of the form: -`GITEA__section_name__KEY_NAME__FILE` that points to a file. - -```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}""" -``` - -To set required TOKEN and SECRET values, consider using Gitea's built-in [generate utility functions](https://docs.gitea.io/en-us/command-line/#generate). - -# SSH Container Passthrough - -Since SSH is running inside the container, SSH needs to be passed through from the host to the container if SSH support is desired. One option would be to run the container SSH on a non-standard port (or moving the host port to a non-standard port). Another option which might be more straightforward is to forward SSH commands from the host to the container. This setup is explained in the following. - -This guide assumes that you have created a user on the host called `git` with permission to run `docker exec`, and that the Gitea container is called `gitea`. You will need to modify that user's shell to forward the commands to the `sh` executable inside the container, using `docker exec`. - -First, create the file `/usr/local/bin/gitea-shell` on the host, with the following contents: - -```bash -#!/bin/sh -/usr/bin/docker exec -i --env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea sh "$@" -``` - -Note that `gitea` in the docker command above is the name of the container. If you named yours differently, don't forget to change that. - -You should also make sure that you’ve set the permissions of the shell wrapper correctly: - -```bash -sudo chmod +x /usr/local/bin/gitea-shell -``` - -Once the wrapper is in place, you can make it the shell for the `git` user: - -```bash -sudo usermod -s /usr/local/bin/gitea-shell git -``` - -Now that all the SSH commands are forwarded to the container, you need to set up the SSH authentication on the host. This is done by leveraging the [SSH AuthorizedKeysCommand](https://docs.gitea.io/en-us/command-line/#keys) to match the keys against those accepted by Gitea. Add the following block to `/etc/ssh/sshd_config`, on the host: - -```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 -``` - -(From 1.16.0 you will not need to set the `-c /etc/gitea/app.ini` option.) - -All that is left to do is restart the SSH server: - -```bash -sudo systemctl restart sshd -``` - -**Notes** - -This isn't actually using the docker SSH - it is simply using the commands around it. -You could theoretically not run the internal SSH server. diff --git a/docs/content/doc/installation/with-docker-rootless.zh-cn.md b/docs/content/doc/installation/with-docker-rootless.zh-cn.md deleted file mode 100644 index eca2e4381a..0000000000 --- a/docs/content/doc/installation/with-docker-rootless.zh-cn.md +++ /dev/null @@ -1,332 +0,0 @@ ---- -date: "2020-02-09T20:00:00+02:00" -title: "使用 Docker 安装 (rootless)" -slug: "install-with-docker-rootless" -weight: 60 -toc: false -draft: false -aliases: - - /zh-cn/install-with-docker-rootless -menu: - sidebar: - parent: "installation" - name: "使用 Docker 安装 (rootless)" - weight: 60 - identifier: "install-with-docker-rootless" ---- - -# 使用 Docker 安装 - -Gitea 在其 Docker Hub 组织中提供自动更新的 Docker 镜像。您可以始终使用最新的稳定标签，或使用其他处理 Docker 镜像更新的服务。 - -rootless 镜像使用 Gitea 内部 SSH 功能来提供 Git 协议，但不支持 OpenSSH。 - -本参考设置指南将用户引导通过基于 `docker-compose` 的设置。但是，`docker-compose` 的安装超出了本文档的范围。要安装`docker-compose` 本身， 请按照官方的 [安装说明](https://docs.docker.com/compose/install/)进行操作。 - -## 基础设置 - -最简单的设置只需创建一个卷和一个网络，并将 `gitea/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: gitea/gitea:{{< version >}}-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`，或指定特定的版本，如: `{{< version >}}-rootless`。如果您想使用最新的开发版本，则可以使用 `:dev-rootless` 标签。如果您想运行发布分支的最新提交，可以使用 `:1.x-dev-rootless` 标签，其中 x是 Gitea 的次要版本号（例如:`1.16-dev-rootless`）。 - -## 自定义端口 - -要将集成的SSH和Web服务器绑定到不同的端口，请调整端口部分。通常只需更改主机端口并保持容器内的端口不变。 - -```diff -version: "2" - -services: - server: - image: gitea/gitea:{{< version >}}-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: gitea/gitea:{{< version >}}-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: 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: gitea/gitea:{{< version >}}-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: 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: gitea/gitea:{{< version >}}-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: gitea/gitea:{{< version >}}-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` 中。 - -# 升级 - -:exclamation::exclamation: **确保您已将数据卷迁移到 Docker 容器之外的其他位置** :exclamation::exclamation: - -要将安装升级到最新版本，请按照以下步骤操作： - -``` -# 如果在 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` -- 使用镜像 `gitea/gitea:{{< version >}}-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 服务器。 diff --git a/docs/content/doc/installation/with-docker.en-us.md b/docs/content/doc/installation/with-docker.en-us.md deleted file mode 100644 index 5f49876b8a..0000000000 --- a/docs/content/doc/installation/with-docker.en-us.md +++ /dev/null @@ -1,647 +0,0 @@ ---- -date: "2020-03-19T19:27:00+02:00" -title: "Installation with Docker" -slug: "install-with-docker" -weight: 70 -toc: false -draft: false -aliases: - - /en-us/install-with-docker -menu: - sidebar: - parent: "installation" - name: "With Docker" - weight: 70 - identifier: "install-with-docker" ---- - -# Installation with Docker - -Gitea provides automatically updated Docker images within its Docker Hub organization. It is -possible to always use the latest stable tag or to use another service that handles updating -Docker images. - -This reference setup guides users through the setup based on `docker-compose`, but the installation -of `docker-compose` is out of scope of this documentation. To install `docker-compose` itself, follow -the official [install instructions](https://docs.docker.com/compose/install/). - -**Table of Contents** - -{{< toc >}} - -## Basics - -The most simple setup just creates a volume and a network and starts the `gitea/gitea:latest` -image as a service. Since there is no database available, one can be initialized using SQLite3. -Create a directory like `gitea` and paste the following content into a file named `docker-compose.yml`. -Note that the volume should be owned by the user/group with the UID/GID specified in the config file. -If you don't give the volume correct permissions, the container may not start. -For a stable release you can use `:latest`, `:1` or specify a certain release like `:{{< version >}}`, but if you'd like to use the latest development version of Gitea then you could use the `:nightly` tag. If you'd like to run the latest commit from a release branch you can use the `:1.x-nightly` tag, where x is the minor version of Gitea. (e.g. `:1.16-nightly`) - -```yaml -version: "3" - -networks: - gitea: - external: false - -services: - server: - image: gitea/gitea:{{< version >}} - 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" -``` - -## Ports - -To bind the integrated OpenSSH daemon and the webserver on a different port, adjust -the port section. It's common to just change the host port and keep the ports within -the container like they are. - -```diff -version: "3" - -networks: - gitea: - external: false - -services: - server: - image: gitea/gitea:{{< version >}} - 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" -``` - -## Databases - -### MySQL database - -To start Gitea in combination with a MySQL database, apply these changes to the -`docker-compose.yml` file created above. - -```diff -version: "3" - -networks: - gitea: - external: false - -services: - server: - image: gitea/gitea:{{< version >}} - 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: 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 database - -To start Gitea in combination with a PostgreSQL database, apply these changes to -the `docker-compose.yml` file created above. - -```diff -version: "3" - -networks: - gitea: - external: false - -services: - server: - image: gitea/gitea:{{< version >}} - 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: postgres:14 -+ restart: always -+ environment: -+ - POSTGRES_USER=gitea -+ - POSTGRES_PASSWORD=gitea -+ - POSTGRES_DB=gitea -+ networks: -+ - gitea -+ volumes: -+ - ./postgres:/var/lib/postgresql/data -``` - -## Named volumes - -To use named volumes instead of host volumes, define and use the named volume -within the `docker-compose.yml` configuration. This change will automatically -create the required volume. You don't need to worry about permissions with -named volumes; Docker will deal with that automatically. - -```diff -version: "3" - -networks: - gitea: - external: false - -+volumes: -+ gitea: -+ driver: local -+ -services: - server: - image: gitea/gitea:{{< version >}} - 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 or PostgreSQL containers will need to be created separately. - -## Startup - -To start this setup based on `docker-compose`, execute `docker-compose up -d`, -to launch Gitea in the background. Using `docker-compose ps` will show if Gitea -started properly. Logs can be viewed with `docker-compose logs`. - -To shut down the setup, execute `docker-compose down`. This will stop -and kill the containers. The volumes will still exist. - -Notice: if using a non-3000 port on http, change app.ini to match -`LOCAL_ROOT_URL = http://localhost:3000/`. - -## Installation - -After starting the Docker setup via `docker-compose`, Gitea should be available using a -favorite browser to finalize the installation. Visit http://server-ip:3000 and follow the -installation wizard. If the database was started with the `docker-compose` setup as -documented above, please note that `db` must be used as the database hostname. - -## Configure the user inside Gitea using environment variables - -- `USER`: **git**: The username of the user that runs Gitea within the container. -- `USER_UID`: **1000**: The UID (Unix user ID) of the user that runs Gitea within the container. Match this to the UID of the owner of the `/data` volume if using host volumes (this is not necessary with named volumes). -- `USER_GID`: **1000**: The GID (Unix group ID) of the user that runs Gitea within the container. Match this to the GID of the owner of the `/data` volume if using host volumes (this is not necessary with named volumes). - -## Customization - -Customization files described [here](https://docs.gitea.io/en-us/customizing-gitea/) should -be placed in `/data/gitea` directory. If using host volumes, it's quite easy to access these -files; for named volumes, this is done through another container or by direct access at -`/var/lib/docker/volumes/gitea_gitea/_data`. The configuration file will be saved at -`/data/gitea/conf/app.ini` after the installation. - -## Upgrading - -:exclamation::exclamation: **Make sure you have volumed data to somewhere outside Docker container** :exclamation::exclamation: - -To upgrade your installation to the latest release: - -```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 -``` - -## Managing Deployments With Environment Variables - -In addition to the environment variables above, any settings in `app.ini` can be set -or overridden with an environment variable of the form: `GITEA__SECTION_NAME__KEY_NAME`. -These settings are applied each time the docker container starts, and won't be passed into Gitea's sub-processes. -Full information [here](https://github.com/go-gitea/gitea/tree/master/contrib/environment-to-ini). - -These environment variables can be passed to the docker container in `docker-compose.yml`. -The following example will enable an smtp mail server if the required env variables -`GITEA__mailer__FROM`, `GITEA__mailer__HOST`, `GITEA__mailer__PASSWD` are set on the host -or in a `.env` file in the same directory as `docker-compose.yml`. - -The settings can be also set or overridden with the content of a file by defining an environment variable of the form: -`GITEA__section_name__KEY_NAME__FILE` that points to a file. - -```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 will generate new secrets/tokens for every new installation automatically and write them into the app.ini. If you want to set the secrets/tokens manually, you can use the following docker commands to use of Gitea's built-in [generate utility functions](https://docs.gitea.io/en-us/command-line/#generate). Do not lose/change your SECRET_KEY after the installation, otherwise the encrypted data can not be decrypted anymore. - -The following commands will output a new `SECRET_KEY` and `INTERNAL_TOKEN` to `stdout`, which you can then place in your environment variables. - -```bash -docker run -it --rm gitea/gitea:1 gitea generate secret SECRET_KEY -docker run -it --rm gitea/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 Container Passthrough - -Since SSH is running inside the container, SSH needs to be passed through from the host to the container if SSH support is desired. One option would be to run the container SSH on a non-standard port (or moving the host port to a non-standard port). Another option which might be more straightforward is for Gitea users to ssh to a Gitea user on the host which will then relay those connections to the docker. - -### Understanding SSH access to Gitea (without passthrough) - -To understand what needs to happen, you first need to understand what happens without passthrough. So we will try to explain this: - -1. The client adds their SSH public key to Gitea using the webpage. -2. Gitea will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`. -3. This entry has the public key, but also has a `command=` option. It is this command that Gitea uses to match this key to the client user and manages authentication. -4. The client then makes an SSH request to the SSH server using the `git` user, e.g. `git clone git@domain:user/repo.git`. -5. The client will attempt to authenticate with the server, passing one or more public keys one at a time to the server. -6. For each key the client provides, the SSH server will first check its configuration for an `AuthorizedKeysCommand` to see if the public key matches, and then the `git` user's `authorized_keys` file. -7. The first entry that matches will be selected, and assuming this is a Gitea entry, the `command=` will now be executed. -8. The SSH server creates a user session for the `git` user, and using the shell for the `git` user runs the `command=` -9. This runs `gitea serv` which takes over control of the rest of the SSH session and manages gitea authentication & authorization of the git commands. - -Now, for the SSH passthrough to work, we need the host SSH to match the public keys and then run the `gitea serv` on the docker. There are multiple ways of doing this. However, all of these require some information about the docker being passed to the host. - -### SSHing Shim (with authorized_keys) - -In this option, the idea is that the host simply uses the `authorized_keys` that gitea creates but at step 9 the `gitea` command that the host runs is a shim that actually runs ssh to go into the docker and then run the real docker `gitea` itself. - -- To make the forwarding work, the SSH port of the container (22) needs to be mapped to the host port 2222 in `docker-compose.yml` . Since this port does not need to be exposed to the outside world, it can be mapped to the `localhost` of the host machine: - - ```yaml - ports: - # [...] - - "127.0.0.1:2222:22" - ``` - -- Next on the host create the `git` user which shares the same `UID`/ `GID` as the container values `USER_UID`/ `USER_GID`. These values can be set as environment variables in the `docker-compose.yml`: - - ```yaml - environment: - - USER_UID=1000 - - USER_GID=1000 - ``` - -- Mount `/home/git/.ssh` of the host into the container. This ensures that the `authorized_keys` file is shared between the host `git` user and the container `git` user otherwise the SSH authentication cannot work inside the container. - - ```yaml - volumes: - - /home/git/.ssh/:/data/git/.ssh - ``` - -- Now a SSH key pair needs to be created on the host. This key pair will be used to authenticate the `git` user on the host to the container. As an administrative user on the host run: (by administrative user we mean a user that can sudo to root) - - ```bash - sudo -u git ssh-keygen -t rsa -b 4096 -C "Gitea Host Key" - ``` - -- Please note depending on the local version of ssh you may want to consider using `-t ecdsa` here. - -- `/home/git/.ssh/authorized_keys` on the host now needs to be modified. It needs to act in the same way as `authorized_keys` within the Gitea container. Therefore add the public key of the key you created above ("Gitea Host Key") to `~/git/.ssh/authorized_keys`. As an administrative user on the host run: - - ```bash - sudo -u git cat /home/git/.ssh/id_rsa.pub | sudo -u git tee -a /home/git/.ssh/authorized_keys - sudo -u git chmod 600 /home/git/.ssh/authorized_keys - ``` - - Important: The pubkey from the `git` user needs to be added "as is" while all other pubkeys added via the Gitea web interface will be prefixed with `command="/usr [...]`. - - `/home/git/.ssh/authorized_keys` should then look somewhat like - - ```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> - ``` - -- The next step is to create the fake host `gitea` command that will forward commands from the host to the container. The name of this file depends on your version of Gitea: - - - For Gitea v1.16.0+. As an administrative user on the host run: - - ```bash - cat <<"EOF" | sudo tee /usr/local/bin/gitea - #!/bin/sh - ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@" - EOF - sudo chmod +x /usr/local/bin/gitea - ``` - -Here is a detailed explanation what is happening when a SSH request is made: - -1. The client adds their SSH public key to Gitea using the webpage. -2. Gitea in the container will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`. - - However, because `/home/git/.ssh/` on the host is mounted as `/data/git/.ssh` this means that the key has been added to the host `git` user's `authorized_keys` file too. -3. This entry has the public key, but also has a `command=` option. - - This command matches the location of the Gitea binary on the container, but also the location of the shim on the host. -4. The client then makes an SSH request to the host SSH server using the `git` user, e.g. `git clone git@domain:user/repo.git`. -5. The client will attempt to authenticate with the server, passing one or more public keys in turn to the host. -6. For each key the client provides, the host SSH server will first check its configuration for an `AuthorizedKeysCommand` to see if the public key matches, and then the host `git` user's `authorized_keys` file. - - Because `/home/git/.ssh/` on the host is mounted as `/data/git/.ssh` this means that the key they added to the Gitea web will be found -7. The first entry that matches will be selected, and assuming this is a Gitea entry, the `command=` will now be executed. -8. The host SSH server creates a user session for the `git` user, and using the shell for the host `git` user runs the `command=` -9. This means that the host runs the host `/usr/local/bin/gitea` shim that opens an SSH from the host to container passing the rest of the command arguments directly to `/usr/local/bin/gitea` on the container. -10. Meaning that the container `gitea serv` is run, taking over control of the rest of the SSH session and managing gitea authentication & authorization of the git commands. - -**Notes** - -SSH container passthrough using `authorized_keys` will work only if - -- `opensshd` is used in the container -- if `AuthorizedKeysCommand` is _not used_ in combination with `SSH_CREATE_AUTHORIZED_KEYS_FILE=false` to disable authorized files key generation -- `LOCAL_ROOT_URL` is not changed (depending on the changes) - -If you try to run `gitea` on the host, you will attempt to ssh to the container and thence run the `gitea` command there. - -Never add the `Gitea Host Key` as a SSH key to a user on the Gitea interface. - -### SSHing Shell (with authorized_keys) - -In this option, the idea is that the host simply uses the `authorized_keys` that gitea creates but at step 8 above we change the shell that the host runs to ssh directly into the docker and then run the shell there. This means that the `gitea` that is then run is the real docker `gitea`. - -- In this case we setup as per SSHing Shim except instead of creating `/usr/local/bin/gitea` -we create a new shell for the git user. As an administrative user on the host run: - - ```bash - cat <<"EOF" | sudo tee /home/git/ssh-shell - #!/bin/sh - shift - ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $@" - EOF - sudo chmod +x /home/git/ssh-shell - sudo usermod -s /home/git/ssh-shell git - ``` - - Be careful here - if you try to login as the git user in future you will ssh directly to the docker. - -Here is a detailed explanation what is happening when a SSH request is made: - -1. The client adds their SSH public key to Gitea using the webpage. -2. Gitea in the container will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`. - - However, because `/home/git/.ssh/` on the host is mounted as `/data/git/.ssh` this means that the key has been added to the host `git` user's `authorized_keys` file too. -3. This entry has the public key, but also has a `command=` option. - - This command matches the location of the Gitea binary on the container. -4. The client then makes an SSH request to the host SSH server using the `git` user, e.g. `git clone git@domain:user/repo.git`. -5. The client will attempt to authenticate with the server, passing one or more public keys in turn to the host. -6. For each key the client provides, the host SSH server will first check its configuration for an `AuthorizedKeysCommand` to see if the public key matches, and then the host `git` user's `authorized_keys` file. - - Because `/home/git/.ssh/` on the host is mounted as `/data/git/.ssh` this means that the key they added to the Gitea web will be found -7. The first entry that matches will be selected, and assuming this is a Gitea entry, the `command=` will now be executed. -8. The host SSH server creates a user session for the `git` user, and using the shell for the host `git` user runs the `command=` -9. The shell of the host `git` user is now our `ssh-shell` which opens an SSH connection from the host to container, (which opens a shell on the container for the container `git`). -10. The container shell now runs the `command=` option meaning that the container `gitea serv` is run, taking over control of the rest of the SSH session and managing gitea authentication & authorization of the git commands. - -**Notes** - -SSH container passthrough using `authorized_keys` will work only if - -- `opensshd` is used in the container -- if `AuthorizedKeysCommand` is _not used_ in combination with `SSH_CREATE_AUTHORIZED_KEYS_FILE=false` to disable authorized files key generation -- `LOCAL_ROOT_URL` is not changed (depending on the changes) - -If you try to login as the `git` user on the host in future you will ssh directly to the docker. - -Never add the `Gitea Host Key` as a SSH key to a user on the Gitea interface. - -### Docker Shell (with authorized_keys) - -Similar to the above ssh shell technique we can use a shell which simply uses `docker exec`. As an administrative user on the host run: - -```bash -cat <<"EOF" | sudo tee /home/git/docker-shell -#!/bin/sh -/usr/bin/docker exec -i -u git --env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea sh "$@" -EOF -sudo chmod +x /home/git/docker-shell -sudo usermod -s /home/git/docker-shell git -``` - -Here is a detailed explanation what is happening when a SSH request is made: - -1. The client adds their SSH public key to Gitea using the webpage. -2. Gitea in the container will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`. - - However, because `/home/git/.ssh/` on the host is mounted as `/data/git/.ssh` this means that the key has been added to the host `git` user's `authorized_keys` file too. -3. This entry has the public key, but also has a `command=` option. - - This command matches the location of the Gitea binary on the container. -4. The client then makes an SSH request to the host SSH server using the `git` user, e.g. `git clone git@domain:user/repo.git`. -5. The client will attempt to authenticate with the server, passing one or more public keys in turn to the host. -6. For each key the client provides, the host SSH server will first check its configuration for an `AuthorizedKeysCommand` to see if the public key matches, and then the host `git` user's `authorized_keys` file. - - Because `/home/git/.ssh/` on the host is mounted as `/data/git/.ssh` this means that the key they added to the Gitea web will be found -7. The first entry that matches will be selected, and assuming this is a Gitea entry, the `command=` will now be executed. -8. The host SSH server creates a user session for the `git` user, and using the shell for the host `git` user runs the `command=` -9. The shell of the host `git` user is now our `docker-shell` which uses `docker exec` to open a shell for the `git` user on the container. -10. The container shell now runs the `command=` option meaning that the container `gitea serv` is run, taking over control of the rest of the SSH session and managing gitea authentication & authorization of the git commands. - -Note that `gitea` in the docker command above is the name of the container. If you named yours differently, don't forget to change that. The host `git` user also has to have -permission to run `docker exec`. - -**Notes** - -Docker shell passthrough using `authorized_keys` will work only if - -- `opensshd` is used in the container -- if `AuthorizedKeysCommand` is _not used_ in combination with `SSH_CREATE_AUTHORIZED_KEYS_FILE=false` to disable authorized files key generation -- `LOCAL_ROOT_URL` is not changed (depending on the changes) - -If you try to login as the `git` user on the host in future you will `docker exec` directly to the docker. - -A Docker execing shim could be created similarly to above. - -### Docker Shell with AuthorizedKeysCommand - -The AuthorizedKeysCommand route provides another option that does not require many changes to the compose file or the `authorized_keys` - but does require changes to the host `/etc/sshd_config`. - -In this option, the idea is that the host SSH uses an `AuthorizedKeysCommand` instead of relying on sharing the `authorized_keys` file that gitea creates. We continue to use a special shell at step 8 above to exec into the docker and then run the shell there. This means that the `gitea` that is then run is the real docker `gitea`. - -- On the host create a `git` user with permission to run `docker exec`. -- We will again assume that the Gitea container is called `gitea`. -- Modify the `git` user's shell to forward commands to the `sh` executable inside the container using `docker exec`. As an administrative user on the host run: - - ```bash - cat <<"EOF" | sudo tee /home/git/docker-shell - #!/bin/sh - /usr/bin/docker exec -i --env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea sh "$@" - EOF - sudo chmod +x /home/git/docker-shell - sudo usermod -s /home/git/docker-shell git - ``` - -Now all attempts to login as the `git` user on the host will be forwarded to the docker - including the `SSH_ORIGINAL_COMMAND`. We now need to set-up SSH authentication on the host. - -We will do this by leveraging the [SSH AuthorizedKeysCommand](https://docs.gitea.io/en-us/command-line/#keys) to match the keys against those accepted by Gitea. - -Add the following block to `/etc/ssh/sshd_config`, on the host: - -```bash -Match User git - AuthorizedKeysCommandUser git - AuthorizedKeysCommand /usr/bin/docker exec -i gitea /usr/local/bin/gitea keys -c /data/gitea/conf/app.ini -e git -u %u -t %t -k %k -``` - -(From 1.16.0 you will not need to set the `-c /data/gitea/conf/app.ini` option.) - -Finally restart the SSH server. As an administrative user on the host run: - -```bash -sudo systemctl restart sshd -``` - -Here is a detailed explanation what is happening when a SSH request is made: - -1. The client adds their SSH public key to Gitea using the webpage. -2. Gitea in the container will add an entry for this key to its database. -3. The client then makes an SSH request to the host SSH server using the `git` user, e.g. `git clone git@domain:user/repo.git`. -4. The client will attempt to authenticate with the server, passing one or more public keys in turn to the host. -5. For each key the client provides, the host SSH server will checks its configuration for an `AuthorizedKeysCommand`. -6. The host runs the above `AuthorizedKeysCommand`, which execs in to the docker and then runs the `gitea keys` command. -7. Gitea on the docker will look in it's database to see if the public key matches and will return an entry like that of an `authorized_keys` command. -8. This entry has the public key, but also has a `command=` option which matches the location of the Gitea binary on the container. -9. The host SSH server creates a user session for the `git` user, and using the shell for the host `git` user runs the `command=`. -10. The shell of the host `git` user is now our `docker-shell` which uses `docker exec` to open a shell for the `git` user on the container. -11. The container shell now runs the `command=` option meaning that the container `gitea serv` is run, taking over control of the rest of the SSH session and managing gitea authentication & authorization of the git commands. - -**Notes** - -Docker shell passthrough using `AuthorizedKeysCommand` will work only if - -- The host `git` user is allowed to run the `docker exec` command. - -If you try to login as the `git` user on the host in future you will `docker exec` directly to the docker. - -A Docker execing shim could be created similarly to above. - -### SSH Shell with AuthorizedKeysCommand - -Create a key for the host `git` user as above, add it to the docker `/data/git/.ssh/authorized_keys` then finally create and set the `ssh-shell` as above. - -Add the following block to `/etc/ssh/sshd_config`, on the host: - -```bash -Match User git - AuthorizedKeysCommandUser git - AuthorizedKeysCommand /usr/bin/ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 /usr/local/bin/gitea keys -c /data/gitea/conf/app.ini -e git -u %u -t %t -k %k -``` - -(From 1.16.0 you will not need to set the `-c /data/gitea/conf/app.ini` option.) - -Finally restart the SSH server. As an administrative user on the host run: - -```bash -sudo systemctl restart sshd -``` - -Here is a detailed explanation what is happening when a SSH request is made: - -1. The client adds their SSH public key to Gitea using the webpage. -2. Gitea in the container will add an entry for this key to its database. -3. The client then makes an SSH request to the host SSH server using the `git` user, e.g. `git clone git@domain:user/repo.git`. -4. The client will attempt to authenticate with the server, passing one or more public keys in turn to the host. -5. For each key the client provides, the host SSH server will checks its configuration for an `AuthorizedKeysCommand`. -6. The host runs the above `AuthorizedKeysCommand`, which will SSH in to the docker and then run the `gitea keys` command. -7. Gitea on the docker will look in it's database to see if the public key matches and will return an entry like that of an `authorized_keys` command. -8. This entry has the public key, but also has a `command=` option which matches the location of the Gitea binary on the container. -9. The host SSH server creates a user session for the `git` user, and using the shell for the host `git` user runs the `command=`. -10. The shell of the host `git` user is now our `git-shell` which uses SSH to open a shell for the `git` user on the container. -11. The container shell now runs the `command=` option meaning that the container `gitea serv` is run, taking over control of the rest of the SSH session and managing gitea authentication & authorization of the git commands. - -**Notes** - -SSH container passthrough using `AuthorizedKeysCommand` will work only if - -- `opensshd` is running on the container - -If you try to login as the `git` user on the host in future you will `ssh` directly to the docker. - -Never add the `Gitea Host Key` as a SSH key to a user on the Gitea interface. - -SSHing shims could be created similarly to above. diff --git a/docs/content/doc/installation/with-docker.fr-fr.md b/docs/content/doc/installation/with-docker.fr-fr.md deleted file mode 100644 index 362aa5fc67..0000000000 --- a/docs/content/doc/installation/with-docker.fr-fr.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -date: "2017-08-23T09:00:00+02:00" -title: "Installation avec Docker" -slug: "install-with-docker" -weight: 70 -toc: false -draft: false -aliases: - - /fr-fr/install-with-docker -menu: - sidebar: - parent: "installation" - name: "Docker" - weight: 70 - identifier: "install-with-docker" ---- - -# Installation avec Docker - -Nous fournissons des images Docker mises à jour automatiquement via le Docker Hub de notre organisation. C'est à vous, lors devotre déploiement, de vous assurez d'utiliser toujours la dernière version stable ou d'utiliser un autre service qui met à jour l'image Docker pour vous. - -{{< toc >}} - -## Données stockées sur l'hôte - -Tout d'abord, vous devez simplement récupérer l'image Docker avec la commande suivante : - -``` -docker pull gitea/gitea:latest -``` - -Pour garder vos dépôts et certaines autres données persistantes, vous devez créer un répertoire qui contiendra ces données à l'avenir. - -``` -sudo mkdir -p /var/lib/gitea -``` - -Il est temps de démarrer votre instance Docker, c'est un processus assez simple. Vous avez à définir le mappage des ports et le volume à utiliser pour la persistance de vos données : - -``` -docker run -d --name=gitea -p 10022:22 -p 10080:3000 -v /var/lib/gitea:/data gitea/gitea:latest -``` - -Vous devriez avoir une instance fonctionnelle de Gitea. Pour accèder à l'interface web, visitez l'adresse http://hostname:10080 avec votre navigateur web préféré. Si vous voulez clôner un dépôt, vous pouvez le faire avec la commande `git clone ssh://git@hostname:10022/username/repo.git`. - -## Named Volumes - -Ce guide aboutira à une installation avec les données Gitea et PostgreSQL stockées dans des volumes nommés. Cela permet une sauvegarde, une restauration et des mises à niveau en toute simplicité. - -### The Database - -Création du volume nommé pour la base de données : - -``` -$ docker volume create --name gitea-db-data -``` - -Une fois votre volume pret, vous pouvez récupérer l'image Docker de PostgreSQL et créer une instance. Tout comme Gitea, c'est également une image Docker basée sur Alpine Linux, Le montage des données se fera sans aucun problème. - -``` -$ docker pull postgres:alpine -$ docker run -d --name gitea-db \ - -e POSTGRES_PASSWORD=<PASSWORD> \ - -v gitea-db-data:/var/lib/postgresql/data \ - -p 5432:5432 \ - postgres:alpine -``` - -Maintenant que la base de données est démarrée, il faut la configurer. N'oubliez pas le mot de passe que vous avez choisi, vous en aurez besoin lors de l'installation de Gitea. - -``` -$ docker exec -it gitea-db psql -U postgres -psql (9.6.1) -Type "help" for help. - -postgres=# CREATE USER gitea WITH PASSWORD '<PASSWORD>'; -CREATE ROLE -postgres=# CREATE DATABASE gitea OWNER gitea; -CREATE DATABASE -postgres=# \q -$ -``` - -### Gitea - -Premièrement, le volume nommé : - -``` -$ docker volume create --name gitea-data -``` - -Puis l'instance de Gitea : - -``` -$ docker run -d --name gitea \ - --link gitea-db:gitea-db \ - --dns 10.12.10.160 \ - -p 11180:3000 \ - -p 8322:22 \ - -v gitea-data:/data \ - gitea/gitea:latest -``` - -Vous devriez maintenant avoir deux conteneurs Docker pour Gitea et PostgreSQL plus deux volumes nommés Docker. - -# Personnalisation - -Les fichier personnalisés ([voir les instructions](https://docs.gitea.io/en-us/customizing-gitea/)) peuvent être placés dans le répertoire `/data/gitea`. - -Le fichier de configuration sera sauvegardé à l'emplacement suivant : `/data/gitea/conf/app.ini` - -## Il manque quelque chose ? - -Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/Gitea), vous obtiendrez des réponses à toute vos questions assez rapidement. diff --git a/docs/content/doc/installation/with-docker.zh-cn.md b/docs/content/doc/installation/with-docker.zh-cn.md deleted file mode 100644 index 50acc3ffae..0000000000 --- a/docs/content/doc/installation/with-docker.zh-cn.md +++ /dev/null @@ -1,383 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "使用 Docker 安装" -slug: "install-with-docker" -weight: 70 -toc: false -draft: false -aliases: - - /zh-cn/install-with-docker -menu: - sidebar: - parent: "installation" - name: "使用 Docker 安装" - weight: 70 - identifier: "install-with-docker" ---- - -# 使用 Docker 安装 - -Gitea 在其 Docker Hub 组织内提供自动更新的 Docker 镜像。可以始终使用最新的稳定标签或使用其他服务来更新 Docker 镜像。 - -该参考设置指导用户完成基于 `docker-compose` 的设置，但是 `docker-compose` 的安装不在本文档的范围之内。要安装 `docker-compose` 本身，请遵循官方[安装说明](https://docs.docker.com/compose/install/)。 - -{{< toc >}} - -## 基本 - -最简单的设置只是创建一个卷和一个网络，然后将 `gitea/gitea:latest` 镜像作为服务启动。由于没有可用的数据库，因此可以使用 SQLite3 初始化数据库。创建一个类似 `gitea` 的目录，并将以下内容粘贴到名为 `docker-compose.yml` 的文件中。请注意，该卷应由配置文件中指定的 UID/GID 的用户/组拥有。如果您不授予卷正确的权限，则容器可能无法启动。另请注意，标签 `:latest` 将安装当前的开发版本。对于稳定的发行版，您可以使用 `:1` 或指定某个发行版，例如 `{{< version >}}`。 - -```yaml -version: "3" - -networks: - gitea: - external: false - -services: - server: - image: gitea/gitea:{{< version >}} - 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: gitea/gitea:{{< version >}} - 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: gitea/gitea:{{< version >}} - 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: 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: gitea/gitea:{{< version >}} - 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: 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: gitea/gitea:{{< version >}} - 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` 中。 - -## 升级 - -: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 gitea/gitea:1 gitea generate secret SECRET_KEY -docker run -it --rm gitea/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 主机密钥”）的公共密钥添加到 `~/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` 不变 diff --git a/docs/content/doc/installation/with-docker.zh-tw.md b/docs/content/doc/installation/with-docker.zh-tw.md deleted file mode 100644 index fdf5a0101d..0000000000 --- a/docs/content/doc/installation/with-docker.zh-tw.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Docker 安裝" -slug: "install-with-docker" -weight: 70 -toc: false -draft: false -aliases: - - /zh-tw/install-with-docker -menu: - sidebar: - parent: "installation" - name: "Docker 安裝" - weight: 70 - identifier: "install-with-docker" ---- - -# 用 Docker 安裝 - -{{< toc >}} - -我們在 Docker Hub 提供了自動更新的映像檔，它會保持最新穩定版。根據您的部屬環境來使用最新版本或用其他服務來更新 Docker 映像檔。首先您需要下載映像檔： - -``` -docker pull gitea/gitea:latest -``` - -為了儲存您的所有 Git 儲存庫資料，您應該建立一個目錄，用來存放資料的地方。 - -``` -sudo mkdir -p /var/lib/gitea -``` - -現在就可以直接啟動 Docker 容器，這是一個非常簡單的過程，您必須定義啟動連接埠，並且提供上面所建立的資料儲存路徑: - -``` -docker run -d --name=gitea -p 10022:22 -p 10080:3000 -v /var/lib/gitea:/data gitea/gitea:latest -``` - -然後 Gitea 容器已經開始運行，您可以透過個人喜愛的瀏覽器來訪問 http://hostname:10080，假如您想要開始 Clone 儲存庫，可以直接執行 `git clone ssh://git@hostname:10022/username/repo.git` 指令。 - -## 需要協助？ - -如果本頁中無法解決您的問題，請直接到 [Discord server](https://discord.gg/Gitea)，在那邊可以快速得到協助。 diff --git a/docs/content/doc/packages.en-us.md b/docs/content/doc/packages.en-us.md deleted file mode 100644 index e4a87bdebf..0000000000 --- a/docs/content/doc/packages.en-us.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-27T16:00:00+02:00" -title: "Packages" -slug: "packages" -weight: 35 -toc: false -draft: false -menu: - sidebar: - name: "Usage - Packages" - weight: 30 - identifier: "packages" ---- diff --git a/docs/content/doc/search.de-de.md b/docs/content/doc/search.de-de.md deleted file mode 100644 index 29c153171e..0000000000 --- a/docs/content/doc/search.de-de.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2019-11-12T16:00:00+02:00" -title: "Search" -slug: "search" -weight: 1 -toc: false -draft: false -aliases: - - /de-de/help/search -sitemap: - priority : 1 -layout: "search" ---- - - -This file exists solely to respond to /search URL with the related `search` layout template. - -No content shown here is rendered, all content is based in the template layouts/doc/search.html - -Setting a very low sitemap priority will tell search engines this is not important content. diff --git a/docs/content/doc/search.en-us.md b/docs/content/doc/search.en-us.md deleted file mode 100644 index 60a4898c42..0000000000 --- a/docs/content/doc/search.en-us.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2019-11-12T16:00:00+02:00" -title: "Search" -slug: "search" -weight: 1 -toc: false -draft: false -aliases: - - /en-us/help/search -sitemap: - priority : 1 -layout: "search" ---- - - -This file exists solely to respond to /search URL with the related `search` layout template. - -No content shown here is rendered, all content is based in the template layouts/doc/search.html - -Setting a very low sitemap priority will tell search engines this is not important content. diff --git a/docs/content/doc/search.fr-fr.md b/docs/content/doc/search.fr-fr.md deleted file mode 100644 index d3f85c966f..0000000000 --- a/docs/content/doc/search.fr-fr.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2019-11-12T16:00:00+02:00" -title: "Chercher" -slug: "search" -weight: 1 -toc: false -draft: false -aliases: - - /fr-fr/help/search -sitemap: - priority : 1 -layout: "search" ---- - - -This file exists solely to respond to /search URL with the related `search` layout template. - -No content shown here is rendered, all content is based in the template layouts/doc/search.html - -Setting a very low sitemap priority will tell search engines this is not important content. diff --git a/docs/content/doc/search.nl-nl.md b/docs/content/doc/search.nl-nl.md deleted file mode 100644 index 9ca7a34d48..0000000000 --- a/docs/content/doc/search.nl-nl.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2019-11-12T16:00:00+02:00" -title: "Search" -slug: "search" -weight: 1 -toc: false -draft: false -aliases: - - /nl-nl/help/search -sitemap: - priority : 1 -layout: "search" ---- - - -This file exists solely to respond to /search URL with the related `search` layout template. - -No content shown here is rendered, all content is based in the template layouts/doc/search.html - -Setting a very low sitemap priority will tell search engines this is not important content. diff --git a/docs/content/doc/search.pt-br.md b/docs/content/doc/search.pt-br.md deleted file mode 100644 index 0a70026c23..0000000000 --- a/docs/content/doc/search.pt-br.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2019-11-12T16:00:00+02:00" -title: "Search" -slug: "search" -weight: 1 -toc: false -draft: false -aliases: - - /pt-br/help/search -sitemap: - priority : 1 -layout: "search" ---- - - -This file exists solely to respond to /search URL with the related `search` layout template. - -No content shown here is rendered, all content is based in the template layouts/doc/search.html - -Setting a very low sitemap priority will tell search engines this is not important content. diff --git a/docs/content/doc/search.zh-cn.md b/docs/content/doc/search.zh-cn.md deleted file mode 100644 index 50415c259e..0000000000 --- a/docs/content/doc/search.zh-cn.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2019-11-12T16:00:00+02:00" -title: "搜索" -slug: "search" -weight: 1 -toc: false -draft: false -aliases: - - /zh-cn/help/search -sitemap: - priority : 1 -layout: "search" ---- - - -This file exists solely to respond to /search URL with the related `search` layout template. - -No content shown here is rendered, all content is based in the template layouts/doc/search.html - -Setting a very low sitemap priority will tell search engines this is not important content. diff --git a/docs/content/doc/search.zh-tw.md b/docs/content/doc/search.zh-tw.md deleted file mode 100644 index 746cb14c11..0000000000 --- a/docs/content/doc/search.zh-tw.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2019-11-12T16:00:00+02:00" -title: "搜尋" -slug: "search" -weight: 1 -toc: false -draft: false -aliases: - - /zh-tw/help/search -sitemap: - priority : 1 -layout: "search" ---- - - -This file exists solely to respond to /search URL with the related `search` layout template. - -No content shown here is rendered, all content is based in the template layouts/doc/search.html - -Setting a very low sitemap priority will tell search engines this is not important content. diff --git a/docs/content/doc/usage.en-us.md b/docs/content/doc/usage.en-us.md deleted file mode 100644 index 47a4fdc1d7..0000000000 --- a/docs/content/doc/usage.en-us.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-27T16:00:00+02:00" -title: "Usage" -slug: "usage" -weight: 35 -toc: false -draft: false -menu: - sidebar: - name: "Usage" - weight: 30 - identifier: "usage" ---- diff --git a/docs/content/doc/usage.zh-cn.md b/docs/content/doc/usage.zh-cn.md deleted file mode 100644 index 026bef86e9..0000000000 --- a/docs/content/doc/usage.zh-cn.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-27T16:00:00+02:00" -title: "使用指南" -slug: "usage" -weight: 35 -toc: false -draft: false -menu: - sidebar: - name: "使用指南" - weight: 30 - identifier: "usage" ---- diff --git a/docs/content/doc/usage.zh-tw.md b/docs/content/doc/usage.zh-tw.md deleted file mode 100644 index a95e973991..0000000000 --- a/docs/content/doc/usage.zh-tw.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -date: "2016-12-27T16:00:00+02:00" -title: "使用" -slug: "usage" -weight: 35 -toc: false -draft: false -menu: - sidebar: - name: "使用" - weight: 30 - identifier: "usage" ---- diff --git a/docs/content/doc/usage/_index.en-us.md b/docs/content/doc/usage/_index.en-us.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/usage/_index.en-us.md +++ /dev/null diff --git a/docs/content/doc/usage/_index.zh-cn.md b/docs/content/doc/usage/_index.zh-cn.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/usage/_index.zh-cn.md +++ /dev/null diff --git a/docs/content/doc/usage/_index.zh-tw.md b/docs/content/doc/usage/_index.zh-tw.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/usage/_index.zh-tw.md +++ /dev/null diff --git a/docs/content/doc/usage/actions/act-runner.en-us.md b/docs/content/doc/usage/actions/act-runner.en-us.md deleted file mode 100644 index 1f4475508f..0000000000 --- a/docs/content/doc/usage/actions/act-runner.en-us.md +++ /dev/null @@ -1,267 +0,0 @@ ---- -date: "2023-04-27T15:00:00+08:00" -title: "Act Runner" -slug: "act-runner" -weight: 20 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "Act Runner" - weight: 20 - identifier: "actions-runner" ---- - -# Act Runner - -This page will introduce the [act runner](https://gitea.com/gitea/act_runner) in detail, which is the runner of Gitea Actions. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -It is recommended to run jobs in a docker container, so you need to install docker first. -And make sure that the docker daemon is running. - -Other OCI container engines which are compatible with Docker's API should also work, but are untested. - -However, if you are sure that you want to run jobs directly on the host only, then docker is not required. - -## Installation - -There are multiple ways to install the act runner. - -### Download the binary - -You can download the binary from the [release page](https://gitea.com/gitea/act_runner/releases). -However, if you want to use the latest nightly build, you can download it from the [download page](https://dl.gitea.com/act_runner/). - -When you download the binary, please make sure that you have downloaded the correct one for your platform. -You can check it by running the following command: - -```bash -chmod +x act_runner -./act_runner --version -``` - -If you see the version information, it means that you have downloaded the correct binary. - -### Use the docker image - -You can use the docker image from the [docker hub](https://hub.docker.com/r/gitea/act_runner/tags). -Just like the binary, you can use the latest nightly build by using the `nightly` tag, while the `latest` tag is the latest stable release. - -```bash -docker pull gitea/act_runner:latest # for the latest stable release -docker pull gitea/act_runner:nightly # for the latest nightly build -``` - -## Configuration - -Configuration is done via a configuration file. It is optional, and the default configuration will be used when no configuration file is specified. - -You can generate a configuration file by running the following command: - -```bash -./act_runner generate-config -``` - -The default configuration is safe to use without any modification, so you can just use it directly. - -```bash -./act_runner generate-config > config.yaml -./act_runner --config config.yaml [command] -``` - -You could also generate config file with docker: - -```bash -docker run --entrypoint="" --rm -it gitea/act_runner:latest act_runner generate-config > config.yaml -``` - -When you are using the docker image, you can specify the configuration file by using the `CONFIG_FILE` environment variable. Make sure that the file is mounted into the container as a volume: - -```bash -docker run -v $(pwd)/config.yaml:/config.yaml -e CONFIG_FILE=/config.yaml ... -``` - -You may notice the commands above are both incomplete, because it is not the time to run the act runner yet. -Before running the act runner, we need to register it to your Gitea instance first. - -## Registration - -Registration is required before running the act runner, because the runner needs to know where to get jobs from. -And it is also important to Gitea instance to identify the runner. - -### Runner levels - -You can register a runner in different levels, it can be: - -- Instance level: The runner will run jobs for all repositories in the instance. -- Organization level: The runner will run jobs for all repositories in the organization. -- Repository level: The runner will run jobs for the repository it belongs to. - -Note that the repository may still use instance-level or organization-level runners even if it has its own repository-level runners. A future release may provide an option to allow more control over this. - -### Obtain a registration token - -The level of the runner determines where to obtain the registration token. - -- Instance level: The admin settings page, like `<your_gitea.com>/admin/actions/runners`. -- Organization level: The organization settings page, like `<your_gitea.com>/<org>/settings/actions/runners`. -- Repository level: The repository settings page, like `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`. - -If you cannot see the settings page, please make sure that you have the right permissions and that Actions have been enabled. - -The format of the registration token is a random string `D0gvfu2iHfUjNqCYVljVyRV14fISpJxxxxxxxxxx`. - -### Register the runner - -The act runner can be registered by running the following command: - -```bash -./act_runner register -``` - -Alternatively, you can use the `--config` option to specify the configuration file mentioned in the previous section. - -```bash -./act_runner --config config.yaml register -``` - -You will be asked to input the registration information step by step. Includes: - -- The Gitea instance URL, like `https://gitea.com/` or `http://192.168.8.8:3000/`. -- The registration token. -- The runner name, which is optional. If you leave it blank, the hostname will be used. -- The runner labels, which is optional. If you leave it blank, the default labels will be used. - -You may be confused about the runner labels, which will be explained later. - -If you want to register the runner in a non-interactive way, you can use arguments to do it. - -```bash -./act_runner register --no-interactive --instance <instance_url> --token <registration_token> --name <runner_name> --labels <runner_labels> -``` - -When you have registered the runner, you can find a new file named `.runner` in the current directory. -This file stores the registration information. -Please do not edit it manually. -If this file is missing or corrupted, you can simply remove it and register again. - -If you want to store the registration information in another place, you can specify it in the configuration file, -and don't forget to specify the `--config` option. - -### Register the runner with docker - -If you are using the docker image, behaviour will be slightly different. Registration and running are combined into one step in this case, so you need to specify the registration information when running the act runner. - -```bash -docker run \ - -v $(pwd)/config.yaml:/config.yaml \ - -v $(pwd)/data:/data \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -e CONFIG_FILE=/config.yaml \ - -e GITEA_INSTANCE_URL=<instance_url> \ - -e GITEA_RUNNER_REGISTRATION_TOKEN=<registration_token> \ - -e GITEA_RUNNER_NAME=<runner_name> \ - -e GITEA_RUNNER_LABELS=<runner_labels> \ - --name my_runner \ - -d gitea/act_runner:nightly -``` - -You may notice that we have mounted the `/var/run/docker.sock` into the container. -It is because the act runner will run jobs in docker containers, so it needs to communicate with the docker daemon. -As mentioned, you can remove it if you want to run jobs in the host directly. -To be clear, the "host" actually means the container which is running the act runner now, instead of the host machine. - -### Set up the runner using docker compose - -You could also set up the runner using the following `docker-compose.yml`: - -```yml -version: "3.8" -services: - runner: - image: gitea/act_runner:nightly - environment: - CONFIG_FILE: /config.yaml - GITEA_INSTANCE_URL: "${INSTANCE_URL}" - GITEA_RUNNER_REGISTRATION_TOKEN: "${REGISTRATION_TOKEN}" - GITEA_RUNNER_NAME: "${RUNNER_NAME}" - GITEA_RUNNER_LABELS: "${RUNNER_LABELS}" - volumes: - - ./config.yaml:/config.yaml - - ./data:/data - - /var/run/docker.sock:/var/run/docker.sock -``` - -### Configuring cache when starting a Runner using docker image - -If you do not intend to use `actions/cache` in workflow, you can ignore this section. - -If you use `actions/cache` without any additional configuration, it will return the following error: -> Failed to restore: getCacheEntry failed: connect ETIMEDOUT IP:PORT - -The error occurs because the runner container and job container are on different networks, so the job container cannot access the runner container. - -Therefore, it is essential to configure the cache action to ensure its proper functioning. Follow these steps: - -- 1.Obtain the LAN IP address of the host machine where the runner container is running. -- 2.Find an available port number on the host machine where the runner container is running. -- 3.Configure the following settings in the configuration file: - -```yaml -cache: - enabled: true - dir: "" - # Use the LAN IP obtained in step 1 - host: "192.168.8.17" - # Use the port number obtained in step 2 - port: 8088 -``` - -- 4.When starting the container, map the cache port to the host machine: - -```bash -docker run \ - --name gitea-docker-runner \ - -p 8088:8088 \ - -d gitea/act_runner:nightly -``` - -### Labels - -The labels of a runner are used to determine which jobs the runner can run, and how to run them. - -The default labels are `ubuntu-latest:docker://node:16-bullseye,ubuntu-22.04:docker://node:16-bullseye,ubuntu-20.04:docker://node:16-bullseye,ubuntu-18.04:docker://node:16-buster`. -It is a comma-separated list, and each item is a label. - -Let's take `ubuntu-22.04:docker://node:16-bullseye` as an example. -It means that the runner can run jobs with `runs-on: ubuntu-22.04`, and the job will be run in a docker container with the image `node:16-bullseye`. - -If the default image is insufficient for your needs, and you have enough disk space to use a better and bigger one, you can change it to `ubuntu-22.04:docker://<the image you like>`. -You can find more useful images on [act images](https://github.com/nektos/act/blob/master/IMAGES.md). - -If you want to run jobs in the host directly, you can change it to `ubuntu-22.04:host` or just `ubuntu-22.04`, the `:host` is optional. -However, we suggest you to use a special name like `linux_amd64:host` or `windows:host` to avoid misusing it. - -One more thing is that it is recommended to register the runner if you want to change the labels. -It may be annoying to do this, so we may provide a better way to do it in the future. - -## Running - -After you have registered the runner, you can run it by running the following command: - -```bash -./act_runner daemon -# or -./act_runner daemon --config config.yaml -``` - -The runner will fetch jobs from the Gitea instance and run them automatically. - -Since act runner is still in development, it is recommended to check the latest version and upgrade it regularly. diff --git a/docs/content/doc/usage/actions/act-runner.zh-cn.md b/docs/content/doc/usage/actions/act-runner.zh-cn.md deleted file mode 100644 index cc57282900..0000000000 --- a/docs/content/doc/usage/actions/act-runner.zh-cn.md +++ /dev/null @@ -1,263 +0,0 @@ ---- -date: "2023-05-24T15:00:00+08:00" -title: "Act Runner" -slug: "act-runner" -weight: 20 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "Act Runner" - weight: 20 - identifier: "actions-runner" ---- - -# Act Runner - -本页面将详细介绍[Act Runner](https://gitea.com/gitea/act_runner)，这是Gitea Actions的Runner。 - -**目录** - -{{< toc >}} - -## 要求 - -建议在Docker容器中运行Job，因此您需要首先安装Docker。 -并确保Docker守护进程正在运行。 - -其他与Docker API兼容的OCI容器引擎也应该可以正常工作，但尚未经过测试。 - -但是，如果您确定要直接在主机上运行Job，则不需要Docker。 - -## 安装 - -有多种安装Act Runner的方法。 - -### 下载二进制文件 - -您可以从[发布页面](https://gitea.com/gitea/act_runner/releases)下载二进制文件。 -然而，如果您想使用最新的夜间构建版本，可以从[下载页面](https://dl.gitea.com/act_runner/)下载。 - -下载二进制文件时，请确保您已经下载了适用于您的平台的正确版本。 -您可以通过运行以下命令进行检查： - -```bash -chmod +x act_runner -./act_runner --version -``` - -如果看到版本信息，则表示您已经下载了正确的二进制文件。 - -### 使用 Docker 镜像 - -您可以使用[docker hub](https://hub.docker.com/r/gitea/act_runner/tags)上的Docker镜像。 -与二进制文件类似，您可以使用`nightly`标签使用最新的夜间构建版本，而`latest`标签是最新的稳定版本。 - -```bash -docker pull gitea/act_runner:latest # for the latest stable release -docker pull gitea/act_runner:nightly # for the latest nightly build -``` - -## 配置 - -配置通过配置文件进行。它是可选的，当没有指定配置文件时，将使用默认配置。 - -您可以通过运行以下命令生成配置文件： - -```bash -./act_runner generate-config -``` - -默认配置是安全的，可以直接使用。 - -```bash -./act_runner generate-config > config.yaml -./act_runner --config config.yaml [command] -``` - -您亦可以如下使用 docker 创建配置文件： - -```bash -docker run --entrypoint="" --rm -it gitea/act_runner:latest act_runner generate-config > config.yaml -``` - -当使用Docker镜像时，可以使用`CONFIG_FILE`环境变量指定配置文件。确保将文件作为卷挂载到容器中： - -```bash -docker run -v $(pwd)/config.yaml:/config.yaml -e CONFIG_FILE=/config.yaml ... -``` - -您可能注意到上面的命令都是不完整的，因为现在还不是运行Act Runner的时候。 -在运行Act Runner之前，我们需要首先将其注册到您的Gitea实例中。 - -## 注册 - -在运行Act Runner之前，需要进行注册，因为Runner需要知道从哪里获取Job，并且对于Gitea实例来说，识别Runner也很重要。 - -### Runner级别 - -您可以在不同级别上注册Runner，它可以是： - -- 实例级别：Runner将为实例中的所有存储库运行Job。 -- 组织级别：Runner将为组织中的所有存储库运行Job。 -- 存储库级别：Runner将为其所属的存储库运行Job。 - -请注意，即使存储库具有自己的存储库级别Runner，它仍然可以使用实例级别或组织级别Runner。未来的版本可能提供更多对此进行更好控制的选项。 - -### 获取注册令牌 - -Runner级别决定了从哪里获取注册令牌。 - -- 实例级别：管理员设置页面，例如 `<your_gitea.com>/admin/actions/runners`。 -- 组织级别：组织设置页面，例如 `<your_gitea.com>/<org>/settings/actions/runners`。 -- 存储库级别：存储库设置页面，例如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。 - -如果您无法看到设置页面，请确保您具有正确的权限并且已启用 Actions。 - -注册令牌的格式是一个随机字符串 `D0gvfu2iHfUjNqCYVljVyRV14fISpJxxxxxxxxxx`。 - -### 注册Runner - -可以通过运行以下命令来注册Act Runner： - -```bash -./act_runner register -``` - -或者，您可以使用 `--config` 选项来指定前面部分提到的配置文件。 - -```bash -./act_runner --config config.yaml register -``` - -您将逐步输入注册信息，包括： - -- Gitea 实例的 URL，例如 `https://gitea.com/` 或 `http://192.168.8.8:3000/`。 -- 注册令牌。 -- Runner名称（可选）。如果留空，将使用主机名。 -- Runner标签（可选）。如果留空，将使用默认标签。 - -您可能对Runner标签感到困惑，稍后将对其进行解释。 - -如果您想以非交互方式注册Runner，可以使用参数执行以下操作。 - -```bash -./act_runner register --no-interactive --instance <instance_url> --token <registration_token> --name <runner_name> --labels <runner_labels> -``` - -注册Runner后，您可以在当前目录中找到一个名为 `.runner` 的新文件。该文件存储注册信息。 -请不要手动编辑该文件。 -如果此文件丢失或损坏，可以直接删除它并重新注册。 - -如果您想将注册信息存储在其他位置，请在配置文件中指定，并不要忘记指定 `--config` 选项。 - -### 使用Docker注册Runner - -如果您使用的是Docker镜像，注册行为会略有不同。在这种情况下，注册和运行合并为一步，因此您需要在运行Act Runner时指定注册信息。 - -```bash -docker run \ - -v $(pwd)/config.yaml:/config.yaml \ - -v $(pwd)/data:/data \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -e CONFIG_FILE=/config.yaml \ - -e GITEA_INSTANCE_URL=<instance_url> \ - -e GITEA_RUNNER_REGISTRATION_TOKEN=<registration_token> \ - -e GITEA_RUNNER_NAME=<runner_name> \ - -e GITEA_RUNNER_LABELS=<runner_labels> \ - --name my_runner \ - -d gitea/act_runner:nightly -``` - -您可能注意到我们已将`/var/run/docker.sock`挂载到容器中。 -这是因为Act Runner将在Docker容器中运行Job，因此它需要与Docker守护进程进行通信。 -如前所述，如果要在主机上直接运行Job，可以将其移除。 -需要明确的是，这里的 "主机" 实际上指的是当前运行 Act Runner的容器，而不是主机机器本身。 - -### 使用 Docker compose 运行 Runner - -您亦可使用如下的 `docker-compose.yml`: - -```yml -version: "3.8" -services: - runner: - image: gitea/act_runner:nightly - environment: - CONFIG_FILE: /config.yaml - GITEA_INSTANCE_URL: "${INSTANCE_URL}" - GITEA_RUNNER_REGISTRATION_TOKEN: "${REGISTRATION_TOKEN}" - GITEA_RUNNER_NAME: "${RUNNER_NAME}" - GITEA_RUNNER_LABELS: "${RUNNER_LABELS}" - volumes: - - ./config.yaml:/config.yaml - - ./data:/data - - /var/run/docker.sock:/var/run/docker.sock -``` - -### 当您使用 Docker 镜像启动 Runner，如何配置 Cache - -如果你不打算在工作流中使用 `actions/cache`，你可以忽略本段。 - -如果您在使用 `actions/cache` 时没有进行额外的配置，将会返回以下错误信息： -> Failed to restore: getCacheEntry failed: connect ETIMEDOUT IP:PORT - -这个错误的原因是 runner 容器和作业容器位于不同的网络中，因此作业容器无法访问 runner 容器。 -因此，配置 cache 动作以确保其正常运行是非常重要的。请按照以下步骤操作： - -- 1.获取 Runner 容器所在主机的 LAN（本地局域网） IP 地址。 -- 2.获取一个 Runner 容器所在主机的空闲端口号。 -- 3.在配置文件中如下配置： - -```yaml -cache: -enabled: true -dir: "" -# 使用步骤 1. 获取的 LAN IP -host: "192.168.8.17" -# 使用步骤 2. 获取的端口号 -port: 8088 -``` - -- 4.启动容器时, 将 Cache 端口映射至主机。 - -```bash -docker run \ - --name gitea-docker-runner \ - -p 8088:8088 \ - -d gitea/act_runner:nightly -``` - -### 标签 - -Runner的标签用于确定Runner可以运行哪些Job以及如何运行它们。 - -默认标签为`ubuntu-latest:docker://node:16-bullseye,ubuntu-22.04:docker://node:16-bullseye,ubuntu-20.04:docker://node:16-bullseye,ubuntu-18.04:docker://node:16-buster`。 -它们是逗号分隔的列表，每个项目都是一个标签。 - -让我们以 `ubuntu-22.04:docker://node:16-bullseye` 为例。 -它意味着Runner可以运行带有`runs-on: ubuntu-22.04`的Job，并且该Job将在使用`node:16-bullseye`镜像的Docker容器中运行。 - -如果默认镜像无法满足您的需求，并且您有足够的磁盘空间可以使用更好、更大的镜像，您可以将其更改为`ubuntu-22.04:docker://<您喜欢的镜像>`。 -您可以在[act 镜像](https://github.com/nektos/act/blob/master/IMAGES.md)上找到更多有用的镜像。 - -如果您想直接在主机上运行Job，您可以将其更改为`ubuntu-22.04:host`或仅`ubuntu-22.04`，`:host`是可选的。 -然而，我们建议您使用类似`linux_amd64:host`或`windows:host`的特殊名称，以避免误用。 - -还有一点需要注意的是，建议在更改标签时注册Runner。 -这可能会有些麻烦，所以我们可能会在将来提供更好的方法来处理。 - -## 运行 - -注册完Runner后，您可以通过运行以下命令来运行它： - -```bash -./act_runner daemon -# or -./act_runner daemon --config config.yaml -``` - -Runner将从Gitea实例获取Job并自动运行它们。 - -由于Act Runner仍处于开发中，建议定期检查最新版本并进行升级。 diff --git a/docs/content/doc/usage/actions/comparison.en-us.md b/docs/content/doc/usage/actions/comparison.en-us.md deleted file mode 100644 index a8545fba44..0000000000 --- a/docs/content/doc/usage/actions/comparison.en-us.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -date: "2023-04-27T15:00:00+08:00" -title: "Compared to GitHub Actions" -slug: "comparison" -weight: 30 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "Comparison" - weight: 30 - identifier: "actions-comparison" ---- - -# Compared to GitHub Actions - -Even though Gitea Actions is designed to be compatible with GitHub Actions, there are some differences between them. - -**Table of Contents** - -{{< toc >}} - -## Additional features - -### Absolute action URLs - -Gitea Actions supports defining actions via absolute URL, which means that you can use actions from any git repository. -Like `uses: https://github.com/actions/checkout@v3` or `uses: http://your_gitea.com/owner/repo@branch`. - -### Actions written in Go - -Gitea Actions supports writing actions in Go. -See [Creating Go Actions](https://blog.gitea.com/creating-go-actions/). - -## Unsupported workflows syntax - -### `concurrency` - -It's used to run a single job at a time. -See [Using concurrency](https://docs.github.com/en/actions/using-jobs/using-concurrency). - -It's ignored by Gitea Actions now. - -### `run-name` - -The name for workflow runs generated from the workflow. -See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#run-name). - -It's ignored by Gitea Actions now. - -### `permissions` and `jobs.<job_id>.permissions` - -See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions). - -It's ignored by Gitea Actions now. - -### `jobs.<job_id>.timeout-minutes` - -See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes). - -It's ignored by Gitea Actions now. - -### `jobs.<job_id>.continue-on-error` - -See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error). - -It's ignored by Gitea Actions now. - -### `jobs.<job_id>.environment` - -See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment). - -It's ignored by Gitea Actions now. - -### Complex `runs-on` - -See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on). - -Gitea Actions only supports `runs-on: xyz` or `runs-on: [xyz]` now. - -### `workflow_dispatch` - -See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatch). - -It's ignored by Gitea Actions now. - -### `hashFiles` expression - -See [Expressions](https://docs.github.com/en/actions/learn-github-actions/expressions#hashfiles) - -Gitea Actions doesn't support it now, if you use it, the result will always be empty string. - -As a workaround, you can use [go-hashfiles](https://gitea.com/actions/go-hashfiles) instead. - -## Missing features - -### Variables - -See [Variables](https://docs.github.com/en/actions/learn-github-actions/variables). - -It's under development. - -### Problem Matchers - -Problem Matchers are a way to scan the output of actions for a specified regex pattern and surface that information prominently in the UI. -See [Problem matchers](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md). - -It's ignored by Gitea Actions now. - -### Create an error annotation - -See [Creating an annotation for an error](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-creating-an-annotation-for-an-error) - -It's ignored by Gitea Actions now. - -## Missing UI features - -### Pre and Post steps - -Pre and Post steps don't have their own section in the job log user interface. - -## Different behavior - -### Downloading actions - -Gitea Actions doesn't download actions from GitHub by default. -"By default" means that you don't specify the host in the `uses` field, like `uses: actions/checkout@v3`. -As a contrast, `uses: https://github.com/actions/checkout@v3` has specified host. - -The missing host will be filled with `https://gitea.com` if you don't configure it. -That means `uses: actions/checkout@v3` will download the action from [gitea.com/actions/checkout](https://gitea.com/actions/checkout), instead of [github.com/actions/checkout](https://github.com/actions/checkout). - -As mentioned, it's configurable. -If you want your runners to download actions from GitHub or your own Gitea instance by default, you can configure it by setting `[actions].DEFAULT_ACTIONS_URL`. See [Configuration Cheat Sheet]({{< relref "doc/administration/config-cheat-sheet.en-us.md#actions-actions" >}}). - -### Context availability - -Context availability is not checked, so you can use the env context on more places. -See [Context availability](https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability). - -## Known issues - -### `docker/build-push-action@v4` - -See [act_runner#119](https://gitea.com/gitea/act_runner/issues/119#issuecomment-738294). - -`ACTIONS_RUNTIME_TOKEN` is a random string in Gitea Actions, not a JWT. -But the `docker/build-push-action@v4` tries to parse the token as JWT and doesn't handle the error, so the job fails. - -There are two workarounds: - -Set the `ACTIONS_RUNTIME_TOKEN` to empty manually, like: - -``` yml -- name: Build and push - uses: docker/build-push-action@v4 - env: - ACTIONS_RUNTIME_TOKEN: '' - with: -... -``` - -The bug has been fixed in a newer [commit](https://gitea.com/docker/build-push-action/commit/d8823bfaed2a82c6f5d4799a2f8e86173c461aba?style=split&whitespace=show-all#diff-1af9a5bdf96ddff3a2f3427ed520b7005e9564ad), but it has not been released. So you could use the latest version by specifying the branch name, like: - -``` yml -- name: Build and push - uses: docker/build-push-action@master - with: -... -``` diff --git a/docs/content/doc/usage/actions/comparison.zh-cn.md b/docs/content/doc/usage/actions/comparison.zh-cn.md deleted file mode 100644 index 2fc3a23167..0000000000 --- a/docs/content/doc/usage/actions/comparison.zh-cn.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -date: "2023-05-24T15:00:00+08:00" -title: "与GitHub Actions的对比" -slug: "comparison" -weight: 30 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "对比" - weight: 30 - identifier: "actions-comparison" ---- - -# 与GitHub Actions的对比 - -尽管Gitea Actions旨在与GitHub Actions兼容，但它们之间存在一些差异。 - -**目录** - -{{< toc >}} - -## 额外功能 - -### Action URL绝对路径 - -Gitea Actions支持通过URL绝对路径定义actions，这意味着您可以使用来自任何Git存储库的Actions。 -例如，`uses: https://github.com/actions/checkout@v3`或`uses: http://your_gitea.com/owner/repo@branch`。 - -### 使用Go编写Actions - -Gitea Actions支持使用Go编写Actions。 -请参阅[创建Go Actions](https://blog.gitea.com/creating-go-actions/)。 - -## 不支持的工作流语法 - -### `concurrency` - -这是用于一次运行一个Job。 -请参阅[使用并发](https://docs.github.com/zh/actions/using-jobs/using-concurrency)。 - -Gitea Actions目前不支持此功能。 - -### `run-name` - -这是工作流生成的工作流运行的名称。 -请参阅[GitHub Actions 的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#run-name)。 - -Gitea Actions目前不支持此功能。 - -### `permissions`和`jobs.<job_id>.permissions` - -请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#permissions)。 - -Gitea Actions目前不支持此功能。 - -### `jobs.<job_id>.timeout-minutes` - -请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes)。 - -Gitea Actions目前不支持此功能。 - -### `jobs.<job_id>.continue-on-error` - -请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error)。 - -Gitea Actions目前不支持此功能。 - -### `jobs.<job_id>.environment` - -请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment)。 - -Gitea Actions 目前不支持此功能。 - -### 复杂的`runs-on` - -请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on)。 - -Gitea Actions目前只支持`runs-on: xyz`或`runs-on: [xyz]`。 - -### `workflow_dispatch` - -请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatch)。 - -Gitea Actions目前不支持此功能。 - -### `hashFiles`表达式 - -请参阅[表达式](https://docs.github.com/en/actions/learn-github-actions/expressions#hashfiles)。 - -Gitea Actions目前不支持此功能，如果使用它，结果将始终为空字符串。 - -作为解决方法，您可以使用[go-hashfiles](https://gitea.com/actions/go-hashfiles)。 - -## 缺失的功能 - -### 变量 - -请参阅[变量](https://docs.github.com/zh/actions/learn-github-actions/variables)。 - -目前变量功能正在开发中。 - -### 问题匹配器 - -问题匹配器是一种扫描Actions输出以查找指定正则表达式模式并在用户界面中突出显示该信息的方法。 -请参阅[问题匹配器](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md)。 - -Gitea Actions目前不支持此功能。 - -### 为错误创建注释 - -请参阅[为错误创建注释](https://docs.github.com/zh/actions/using-workflows/workflow-commands-for-github-actions#example-creating-an-annotation-for-an-error)。 - -Gitea Actions目前不支持此功能。 - -## 缺失的UI功能 - -### 预处理和后处理步骤 - -预处理和后处理步骤在Job日志用户界面中没有自己的用户界面。 - -## 不一样的行为 - -### 下载Actions - -Gitea Actions默认不从GitHub下载Actions。 -"默认" 意味着您在`uses` 字段中不指定主机，如`uses: actions/checkout@v3`。 -相反，`uses: https://github.com/actions/checkout@v3`是有指定主机的。 - -如果您不进行配置，缺失的主机将填充为`https://gitea.com`。 -这意味着`uses: actions/checkout@v3`将从[gitea.com/actions/checkout](https://gitea.com/actions/checkout)下载该Action，而不是[github.com/actions/checkout](https://github.com/actions/checkout)。 - -正如前面提到的，这是可配置的。 -如果您希望您的运行程序默认从GitHub或您自己的Gitea实例下载动作，您可以通过设置`[actions].DEFAULT_ACTIONS_URL`进行配置。请参阅[配置备忘单]({{< relref "doc/administration/config-cheat-sheet.zh-cn.md#actions-actions" >}})。 - -### 上下文可用性 - -不检查上下文可用性，因此您可以在更多地方使用env上下文。 -请参阅[上下文可用性](https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability)。 - -## 已知问题 - -### `docker/build-push-action@v4` - -请参阅[act_runner#119](https://gitea.com/gitea/act_runner/issues/119#issuecomment-738294)。 - -`ACTIONS_RUNTIME_TOKEN`在Gitea Actions中是一个随机字符串，而不是JWT。 -但是`DOCKER/BUILD-PUSH-ACTION@V4尝试将令牌解析为JWT，并且不处理错误，因此Job失败。 - -有两种解决方法： - -手动将`ACTIONS_RUNTIME_TOKEN`设置为空字符串，例如： - -``` yml -- name: Build and push - uses: docker/build-push-action@v4 - env: - ACTIONS_RUNTIME_TOKEN: '' - with: -... -``` - -该问题已在较新的[提交](https://gitea.com/docker/build-push-action/commit/d8823bfaed2a82c6f5d4799a2f8e86173c461aba?style=split&whitespace=show-all#diff-1af9a5bdf96ddff3a2f3427ed520b7005e9564ad)中修复，但尚未发布。因此，您可以通过指定分支名称来使用最新版本，例如： - -``` yml -- name: Build and push - uses: docker/build-push-action@master - with: -... -``` diff --git a/docs/content/doc/usage/actions/design.en-us.md b/docs/content/doc/usage/actions/design.en-us.md deleted file mode 100644 index c996185fe6..0000000000 --- a/docs/content/doc/usage/actions/design.en-us.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -date: "2023-04-27T15:00:00+08:00" -title: "Design of Gitea Actions" -slug: "design" -weight: 40 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "Design" - weight: 40 - identifier: "actions-design" ---- - -# Design of Gitea Actions - -Gitea Actions has multiple components. This document describes them individually. - -**Table of Contents** - -{{< toc >}} - -## Act - -The [nektos/act](https://github.com/nektos/act) project is an excellent tool that allows you to run your GitHub Actions locally. -We were inspired by this and wondered if it would be possible to run actions for Gitea. - -However, while [nektos/act](https://github.com/nektos/act) is designed as a command line tool, what we actually needed was a Go library with modifications specifically for Gitea. -So we forked it as [gitea/act](https://gitea.com/gitea/act). - -This is a soft fork that will periodically follow the upstream. -Although some custom commits have been added, we will try our best to avoid changing too much of the original code. - -The forked act is just a shim or adapter for Gitea's specific usage. -There are some additional commits that have been made, such as: - -- Outputting execution logs to logger hook so they can be reported to Gitea -- Disabling the GraphQL URL, since Gitea doesn't support it -- Starting a new container for every job instead of reusing to ensure isolation. - -These modifications have no reason to be merged into the upstream. -They don't make sense if the user just wants to run trusted actions locally. - -However, there may be overlaps in the future, such as a required bug fix or new feature needed by both projects. -In these cases, we will contribute the changes back to the upstream repository. - -## Act runner - -Gitea's runner is called act runner because it's based on act. - -Like other CI runners, we designed it as an external part of Gitea, which means it should run on a different server than Gitea. - -To ensure that the runner connects to the correct Gitea instance, we need to register it with a token. -Additionally, the runner will introduce itself to Gitea and declare what kind of jobs it can run by reporting its labels. - -Earlier, we mentioned that `runs-on: ubuntu-latest` in a workflow file means that the job will be run on a runner with the `ubuntu-latest` label. -But how does the runner know to run `ubuntu-latest`? The answer lies in mapping the label to an environment. -That's why when you add custom labels during registration, you will need to input some complex content like `my_custom_label:docker://centos:7`. -This means that the runner can take the job which needs to run on `my_custom_label`, and it will run it via a docker container with the image `centos:7`. - -Docker isn't the only option, though. -The act also supports running jobs directly on the host. -This is achieved through labels like `linux_arm:host`. -This label indicates that the runner can take a job that needs to run on `linux_arm` and run it directly on the host. - -The label's design follows the format `label[:schema[:args]]`. -If the schema is omitted, it defaults to `host`. -So, - -- `my_custom_label:docker://node:18`: Run jobs labeled with `my_custom_label` using the `node:18` Docker image. -- `my_custom_label:host`: Run jobs labeled with `my_custom_label` directly on the host. -- `my_custom_label`: Same as `my_custom_label:host`. -- `my_custom_label:vm:ubuntu-latest`: (Example only, not implemented) Run jobs labeled with `my_custom_label` using a virtual machine with the `ubuntu-latest` ISO. - -## Communication protocol - -As act runner is an independent part of Gitea, we needed a protocol for runners to communicate with the Gitea instance. -However, we did not think it was a good idea to have Gitea listen on a new port. -Instead, we wanted to reuse the HTTP port, which means we needed a protocol that is compatible with HTTP. -We chose to use gRPC over HTTP. - -We use [actions-proto-def](https://gitea.com/gitea/actions-proto-def) and [actions-proto-go](https://gitea.com/gitea/actions-proto-go) to wire them up. -More information about gRPC can be found on [its website](https://grpc.io/). - -## Network architecture - -Let's examine the overall network architecture. -This will help you troubleshoot some problems and explain why it's a bad idea to register a runner with a loopback address of the Gitea instance. - - - -There are four network connections marked in the picture, and the direction of the arrows indicates the direction of establishing the connections. - -### Connection 1, act runner to Gitea instance - -The act runner must be able to connect to Gitea to receive tasks and send back the execution results. - -### Connection 2, job containers to Gitea instance - -The job containers have different network namespaces than the runner, even if they are on the same machine. -They need to connect to Gitea to fetch codes if there is `actions/checkout@v3` in the workflow, for example. -Fetching code is not always necessary to run some jobs, but it is required in most cases. - -If you use a loopback address to register a runner, the runner can connect to Gitea when it is on the same machine. -However, if a job container tries to fetch code from localhost, it will fail because Gitea is not in the same container. - -### Connection 3, act runner to internet - -When you use some actions like `actions/checkout@v3`, the act runner downloads the scripts, not the job containers. -By default, it downloads from [gitea.com](http://gitea.com/), so it requires access to the internet. -It also downloads some docker images from Docker Hub by default, which also requires internet access. - -However, internet access is not strictly necessary. -You can configure your Gitea instance to fetch actions or images from your intranet facilities. - -In fact, your Gitea instance can serve as both the actions marketplace and the image registry. -You can mirror actions repositories from GitHub to your Gitea instance, and use them as normal. -And [Gitea Container Registry](https://docs.gitea.io/en-us/usage/packages/container/) can be used as a Docker image registry. - -### Connection 4, job containers to internet - -When using actions such as `actions/setup-go@v4`, it may be necessary to download resources from the internet to set up the Go language environment in job containers. -Therefore, access to the internet is required for the successful completion of these actions. - -However, it is optional as well. -You can use your own custom actions to avoid relying on internet access, or you can use your packaged Docker image to run jobs with all dependencies installed. - -## Summary - -Using Gitea Actions only requires ensuring that the runner can connect to the Gitea instance. -Internet access is optional, but not having it will require some additional work. -In other words: The runner works best when it can query the internet itself, but you don't need to expose it to the internet (in either direction). - -If you encounter any network issues while using Gitea Actions, hopefully the image above can help you troubleshoot them. diff --git a/docs/content/doc/usage/actions/design.zh-cn.md b/docs/content/doc/usage/actions/design.zh-cn.md deleted file mode 100644 index e1bd1766e7..0000000000 --- a/docs/content/doc/usage/actions/design.zh-cn.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -date: "2023-05-24T15:00:00+08:00" -title: "Gitea Actions设计" -slug: "design" -weight: 40 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "设计" - weight: 40 - identifier: "actions-design" ---- - -# Gitea Actions设计 - -Gitea Actions由多个组件组成。本文档将对它们进行逐个描述。 - -**目录** - -{{< toc >}} - -## Act - -[nektos/act](https://github.com/nektos/act) 项目是一个优秀的工具，允许你在本地运行GitHub Actions。 -我们受到了它的启发，并思考它是否可能为Gitea运行Actions。 - -然而，尽管[nektos/act](https://github.com/nektos/act)被设计为一个命令行工具，但我们实际上需要的是一个专为Gitea修改的Go库。 -因此，我们在[gitea/act](https://gitea.com/gitea/act)基础上进行了分叉。 - -这是一个软分叉，将定期跟进上游。 -虽然添加了一些自定义提交，但我们会尽力避免对原始代码进行太多更改。 - -分叉的 act 只是Gitea特定用途的桥接或适配器。 -还添加了一些额外的提交，例如： - -- 将执行日志输出到日志记录器钩子，以便报告给Gitea -- 禁用 GraphQL URL，因为Gitea不支持它 -- 每个Job启动一个新的容器，而不是重复使用，以确保隔离性。 - -这些修改没有理由合并到上游。 -如果用户只想在本地运行可信的Actions，它们是没有意义的。 - -然而，将来可能会出现重叠，例如两个项目都需要的必要错误修复或新功能。 -在这些情况下，我们将向上游仓库贡献变更。 - -## act runner - -Gitea的Runner被称为act runner，因为它基于act。 - -与其他CIRunner一样，我们将其设计为Gitea的外部部分，这意味着它应该在与Gitea不同的服务器上运行。 - -为了确保Runner连接到正确的Gitea实例，我们需要使用令牌注册它。 -此外，Runner通过声明自己的标签向Gitea报告它可以运行的Job类型。 - -之前，我们提到工作流文件中的 `runs-on: ubuntu-latest` 表示该Job将在具有`ubuntu-latest`标签的Runner上运行。 -但是，Runner如何知道要运行 `ubuntu-latest`？答案在于将标签映射到环境。 -这就是为什么在注册过程中添加自定义标签时，需要输入一些复杂内容，比如`my_custom_label:docker://centos:7`。 -这意味着Runner可以接受需要在`my_custom_label`上运行的Job，并通过使用`centos:7`镜像的Docker容器来运行它。 - -然而，Docker不是唯一的选择。 -act 也支持直接在主机上运行Job。 -这是通过像`linux_arm:host`这样的标签实现的。 -这个标签表示Runner可以接受需要在`linux_arm`上运行的Job，并直接在主机上运行它们。 - -标签的设计遵循格式`label[:schema[:args]]`。 -如果省略了schema，则默认为`host`。 - -因此， - -- `my_custom_label:docker://node:18`：使用`node:18 Docker`镜像运行带有`my_custom_label`标签的Job。 -- `my_custom_label:host`：在主机上直接运行带有`my_custom_label`标签的Job。 -- `my_custom_label`：等同于`my_custom_label:host`。 -- `my_custom_label:vm:ubuntu-latest`：（仅为示例，未实现）使用带有`ubuntu-latest` ISO的虚拟机运行带有`my_custom_label`标签的Job。 - -## 通信协议 - -由于act runner是Gitea的独立部分，我们需要一种协议让Runner与Gitea实例进行通信。 -然而，我们不认为让Gitea监听一个新端口是个好主意。 -相反，我们希望重用HTTP端口，这意味着我们需要一个与HTTP兼容的协议。 -因此，我们选择使用基于HTTP的gRPC。 - -我们使用[actions-proto-def](https://gitea.com/gitea/actions-proto-def) 和 [actions-proto-go](https://gitea.com/gitea/actions-proto-go) 进行连接。 -有关 gRPC 的更多信息，请访问[其官方网站](https://grpc.io/)。 - -## 网络架构 - -让我们来看一下整体的网络架构。 -这将帮助您解决一些问题，并解释为什么使用回环地址注册Runner是个不好的主意。 - - - -图片中标记了四个网络连接，并且箭头的方向表示建立连接的方向。 - -### 连接 1，act runner到Gitea实例 - -act runner 必须能够连接到Gitea以接收任务并发送执行结果回来。 - -### 连接 2，Job容器到Gitea实例 - -即使Job容器位于同一台机器上，它们的网络命名空间与Runner不同。 -举个例子，如果工作流中包含 `actions/checkout@v3`，Job容器需要连接到Gitea来获取代码。 -获取代码并不总是运行某些Job所必需的，但在大多数情况下是必需的。 - -如果您使用回环地址注册Runner，当Runner与Gitea在同一台机器上时，Runner可以连接到Gitea。 -然而，如果Job容器尝试从本地主机获取代码，它将失败，因为Gitea不在同一个容器中。 - -### 连接 3，act runner到互联网 - -当您使用诸如 `actions/checkout@v3` 的一些Actions时，act runner下载的是脚本，而不是Job容器。 -默认情况下，它从[gitea.com](http://gitea.com/)下载，因此需要访问互联网。 -它还默认从Docker Hub下载一些Docker镜像，这也需要互联网访问。 - -然而，互联网访问并不是绝对必需的。 -您可以配置您的Gitea实例从您的内部网络设施中获取 Actions 或镜像。 - -实际上，您的Gitea实例可以同时充当 Actions 市场和镜像注册表。 -您可以将GitHub上的Actions仓库镜像到您的Gitea实例，并将其用作普通Actions。 -而 [Gitea 容器注册表](https://docs.gitea.io/en-us/usage/packages/container/) 可用作Docker镜像注册表。 - -### 连接 4，Job容器到互联网 - -当使用诸如`actions/setup-go@v4`的Actions时，可能需要从互联网下载资源，以设置Job容器中的Go语言环境。 -因此，成功完成这些Actions需要访问互联网。 - -然而，这也是可选的。 -您可以使用自定义的Actions来避免依赖互联网访问，或者可以使用已安装所有依赖项的打包的Docker镜像来运行Job。 - -## 总结 - -使用Gitea Actions只需要确保Runner能够连接到Gitea实例。 -互联网访问是可选的，但如果没有互联网访问，将需要额外的工作。 -换句话说：当Runner能够自行查询互联网时，它的工作效果最好，但您不需要将其暴露给互联网（无论是单向还是双向）。 - -如果您在使用Gitea Actions时遇到任何网络问题，希望上面的图片能够帮助您进行故障排除。 diff --git a/docs/content/doc/usage/actions/faq.en-us.md b/docs/content/doc/usage/actions/faq.en-us.md deleted file mode 100644 index 69a4cf3e89..0000000000 --- a/docs/content/doc/usage/actions/faq.en-us.md +++ /dev/null @@ -1,186 +0,0 @@ ---- -date: "2023-04-27T15:00:00+08:00" -title: "Frequently Asked Questions of Gitea Actions" -slug: "faq" -weight: 100 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "FAQ" - weight: 100 - identifier: "actions-faq" ---- - -# Frequently Asked Questions of Gitea Actions - -This page contains some common questions and answers about Gitea Actions. - -**Table of Contents** - -{{< toc >}} - -## Why is Actions not enabled by default? - -We know it's annoying to enable Actions for the whole instance and each repository one by one, but not everyone likes or needs this feature. -We believe that more work needs to be done to improve Gitea Actions before it deserves any further special treatment. - -## Is it possible to enable Actions for new repositories by default for my own instance? - -Yes, when you enable Actions for the instance, you can choose to enable the `actions` unit for all new repositories by default. - -```ini -[repository] -DEFAULT_REPO_UNITS = ...,repo.actions -``` - -## Should we use `${{ github.xyz }}` or `${{ gitea.xyz }}` in workflow files? - -You can use `github.xyz` and Gitea will work fine. -As mentioned, Gitea Actions is designed to be compatible with GitHub Actions. -However, we recommend using `gitea.xyz` in case Gitea adds something that GitHub does not have to avoid different kinds of secrets in your workflow file (and because you are using this workflow on Gitea, not GitHub). -Still, this is completely optional since both options have the same effect at the moment. - -## Is it possible to register runners for a specific user (not organization)? - -Not yet. -It is technically possible to implement, but we need to discuss whether it is necessary. - -## Where will the runner download scripts when using actions such as `actions/checkout@v3`? - -You may be aware that there are tens of thousands of [marketplace actions](https://github.com/marketplace?type=actions) in GitHub. -However, when you write `uses: actions/checkout@v3`, it actually downloads the scripts from [gitea.com/actions/checkout](http://gitea.com/actions/checkout) by default (not GitHub). -This is a mirror of [github.com/actions/checkout](http://github.com/actions/checkout), but it's impossible to mirror all of them. -That's why you may encounter failures when trying to use some actions that haven't been mirrored. - -The good news is that you can specify the URL prefix to use actions from anywhere. -This is an extra syntax in Gitea Actions. -For example: - -- `uses: https://github.com/xxx/xxx@xxx` -- `uses: https://gitea.com/xxx/xxx@xxx` -- `uses: http://your_gitea_instance.com/xxx@xxx` - -Be careful, the `https://` or `http://` prefix is necessary! - -Alternatively, if you want your runners to download actions from GitHub or your own Gitea instance by default, you can configure it by setting `[actions].DEFAULT_ACTIONS_URL`. -See [Configuration Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions). - -This is one of the differences from GitHub Actions, but it should allow users much more flexibility in how they run Actions. - -## How to limit the permission of the runners? - -Runners have no more permissions than simply connecting to your Gitea instance. -When any runner receives a job to run, it will temporarily gain limited permission to the repository associated with the job. -If you want to give more permissions to the runner, allowing it to access more private repositories or external systems, you can pass [secrets](https://docs.gitea.io/en-us/usage/secrets/) to it. - -Refined permission control to Actions is a complicated job. -In the future, we will add more options to Gitea to make it more configurable, such as allowing more write access to repositories or read access to all repositories in the same organization. - -## How to avoid being hacked? - -There are two types of possible attacks: unknown runner stealing the code or secrets from your repository, or malicious scripts controlling your runner. - -Avoiding the former means not allowing people you don't know to register runners for your repository, organization, or instance. - -The latter is a bit more complicated. -If you're using a private Gitea instance for your company, you may not need to worry about security since you trust your colleagues and can hold them accountable. - -For public instances, things are a little different. -Here's how we do it on [gitea.com](http://gitea.com/): - -- We only register runners for the "gitea" organization, so our runners will not execute jobs from other repositories. -- Our runners always run jobs with isolated containers. While it is possible to do this directly on the host, we choose not to for more security. -- To run actions for fork pull requests, approval is required. See [#22803](https://github.com/go-gitea/gitea/pull/22803). -- If someone registers their own runner for their repository or organization on [gitea.com](http://gitea.com/), we have no objections and will just not use it in our org. However, they should take care to ensure that the runner is not used by other users they do not know. - -## Which operating systems are supported by act runner? - -It works well on Linux, macOS, and Windows. -While other operating systems are theoretically supported, they require further testing. - -One thing to note is that if you choose to run jobs directly on the host instead of in job containers, the environmental differences between operating systems may cause unexpected failures. - -For example, bash is not available on Windows in most cases, while act tries to use bash to run scripts by default. -Therefore, you need to specify `powershell` as the default shell in your workflow file, see [defaults.run](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun). - -```yaml -defaults: - run: - shell: powershell -``` - -## Why choose GitHub Actions? Why not something compatible with GitLab CI/CD? - -[@lunny](https://gitea.com/lunny) has explained this in the [issue to implement actions](https://github.com/go-gitea/gitea/issues/13539). -Furthermore, Actions is not only a CI/CD system but also an automation tool. - -There have also been numerous [marketplace actions](https://github.com/marketplace?type=actions) implemented in the open-source world. -It is exciting to be able to reuse them. - -## What if it runs on multiple labels, such as `runs-on: [label_a, label_b]`? - -This is valid syntax. -It means that it should run on runners that have both the `label_a` **and** `label_b` labels, see [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on). -Unfortunately, act runner does not work this way. -As mentioned, we map labels to environments: - -- `ubuntu` → `ubuntu:22.04` -- `centos` → `centos:8` - -But we need to map label groups to environments instead, like so: - -- `[ubuntu]` → `ubuntu:22.04` -- `[with-gpu]` → `linux:with-gpu` -- `[ubuntu, with-gpu]` → `ubuntu:22.04_with-gpu` - -We also need to re-design how tasks are assigned to runners. -A runner with `ubuntu`, `centos`, or `with-gpu` does not necessarily indicate that it can accept jobs with `[centos, with-gpu]`. -Therefore, the runner should inform the Gitea instance that it can only accept jobs with `[ubuntu]`, `[centos]`, `[with-gpu]`, and `[ubuntu, with-gpu]`. -This is not a technical problem, it was just overlooked in the early design. -See [runtime.go#L65](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L65). - -Currently, the act runner attempts to match everyone in the labels and uses the first match it finds. - -## What is the difference between agent labels and custom labels for a runner? - - - -Agent labels are reported to the Gitea instance by the runner during registration. -Custom labels, on the other hand, are added manually by a Gitea administrator or owners of the organization or repository (depending on the level of the runner). - -However, the design here needs improvement, as it currently has some rough edges. -You can add a custom label such as `centos` to a registered runner, which means the runner will receive jobs with `runs-on: centos`. -However, the runner may not know which environment to use for this label, resulting in it using a default image or leading to a logical dead end. -This default may not match user expectations. -See [runtime.go#L71](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L71). - -In the meantime, we suggest that you re-register your runner if you want to change its labels. - -## Will there be more implementations for Gitea Actions runner? - -Although we would like to provide more options, our limited manpower means that act runner will be the only officially supported runner. -However, both Gitea and act runner are completely open source, so anyone can create a new/better implementation. -We support your choice, no matter how you decide. -In case you fork act runner to create your own version: Please contribute the changes back if you can and if you think your changes will help others as well. - -## What workflow trigger events does Gitea support? - -All events listed in this table are supported events and are compatible with GitHub. -For events supported only by GitHub, see GitHub's [documentation](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows). - -| trigger event | activity types | -|-----------------------------|--------------------------------------------------------------------------------------------------------------------------| -| create | not applicable | -| delete | not applicable | -| fork | not applicable | -| gollum | not applicable | -| push | not applicable | -| issues | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `milestoned`, `demilestoned`, `labeled`, `unlabeled` | -| issue_comment | `created`, `edited`, `deleted` | -| pull_request | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `synchronize`, `labeled`, `unlabeled` | -| pull_request_review | `submitted`, `edited` | -| pull_request_review_comment | `created`, `edited` | -| release | `published`, `edited` | -| registry_package | `published` | diff --git a/docs/content/doc/usage/actions/faq.zh-cn.md b/docs/content/doc/usage/actions/faq.zh-cn.md deleted file mode 100644 index ae6edd06f2..0000000000 --- a/docs/content/doc/usage/actions/faq.zh-cn.md +++ /dev/null @@ -1,186 +0,0 @@ ---- -date: "2023-05-24T15:00:00+08:00" -title: "Gitea Actions常见问题解答" -slug: "faq" -weight: 100 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "常见问题" - weight: 100 - identifier: "actions-faq" ---- - -# Gitea Actions常见问题解答 - -本页面包含一些关于Gitea Actions的常见问题和答案。 - -**目录** - -{{< toc >}} - -## 为什么默认情况下不启用Actions？ - -我们知道为整个实例和每个仓库启用Actions可能很麻烦，但并不是每个人都喜欢或需要此功能。 -在我们认为Gitea Actions值得被特别对待之前，我们认为还需要做更多的工作来改进它。 - -## 是否可以在我的实例中默认启用新仓库的Actions？ - -是的，当您为实例启用Actions时，您可以选择默认启用actions单元以适用于所有新仓库。 - -```ini -[repository] -DEFAULT_REPO_UNITS = ...,repo.actions -``` - -## 在工作流文件中应该使用`${{ github.xyz }}`还是`${{ gitea.xyz }}`？ - -您可以使用`github.xyz`，Gitea将正常工作。 -如前所述，Gitea Actions的设计是与GitHub Actions兼容的。 -然而，我们建议在工作流文件中使用`gitea.xyz`，以防止在工作流文件中出现不同类型的密钥（因为您在Gitea上使用此工作流，而不是GitHub）。 -不过，这完全是可选的，因为目前这两个选项的效果是相同的。 - -## 是否可以为特定用户（而不是组织）注册Runner？ - -目前还不可以。 -从技术上讲是可以实现的，但我们需要讨论是否有必要。 - -## 使用`actions/checkout@v3`等Actions时，Job容器会从何处下载脚本？ - -您可能知道GitHub上有成千上万个[Actions市场](https://github.com/marketplace?type=actions)。 -然而，当您编写`uses: actions/checkout@v3`时，它实际上默认从[gitea.com/actions/checkout](http://gitea.com/actions/checkout)下载脚本（而不是从GitHub下载）。 -这是[github.com/actions/checkout](http://github.com/actions/checkout)的镜像，但无法将它们全部镜像。 -这就是为什么在尝试使用尚未镜像的某些Actions时可能会遇到失败的原因。 - -好消息是，您可以指定要从任何位置使用Actions的URL前缀。 -这是Gitea Actions中的额外语法。 -例如： - -- `uses: https://github.com/xxx/xxx@xxx` -- `uses: https://gitea.com/xxx/xxx@xxx` -- `uses: http://your_gitea_instance.com/xxx@xxx` - -注意，`https://`或`http://`前缀是必需的！ - -另外，如果您希望您的Runner默认从GitHub或您自己的Gitea实例下载Actions，可以通过设置 `[actions].DEFAULT_ACTIONS_URL`进行配置。 -参见[配置速查表](https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions)。 - -这是与GitHub Actions的一个区别，但它应该允许用户以更灵活的方式运行Actions。 - -## 如何限制Runner的权限？ - -Runner仅具有连接到您的Gitea实例的权限。 -当任何Runner接收到要运行的Job时，它将临时获得与Job关联的仓库的有限权限。 -如果您想为Runner提供更多权限，允许它访问更多私有仓库或外部系统，您可以向其传递[密钥](https://docs.gitea.io/en-us/usage/secrets/)。 - -对于 Actions 的细粒度权限控制是一项复杂的工作。 -在未来，我们将添加更多选项以使Gitea更可配置，例如允许对仓库进行更多写访问或对同一组织中的所有仓库进行读访问。 - -## 如何避免被黑客攻击？ - -有两种可能的攻击类型：未知的Runner窃取您的仓库中的代码或密钥，或恶意脚本控制您的Runner。 - -避免前者意味着不允许您不认识的人为您的仓库、组织或实例注册Runner。 - -后者要复杂一些。 -如果您为公司使用私有的Gitea实例，您可能不需要担心安全问题，因为您信任您的同事，并且可以追究他们的责任。 - -对于公共实例，情况略有不同。 -以下是我们在 [gitea.com](http://gitea.com/)上的做法： - -- 我们仅为 "gitea" 组织注册Runner，因此我们的Runner不会执行来自其他仓库的Job。 -- 我们的Runner始终在隔离容器中运行Job。虽然可以直接在主机上进行这样的操作，但出于安全考虑，我们选择不这样做。 -- 对于 fork 的拉取请求，需要获得批准才能运行Actions。参见[#22803](https://github.com/go-gitea/gitea/pull/22803)。 -- 如果有人在[gitea.com](http://gitea.com/)为其仓库或组织注册自己的Runner，我们不会反对，只是不会在我们的组织中使用它。然而，他们应该注意确保该Runner不被他们不认识的其他用户使用。 - -## act runner支持哪些操作系统？ - -它在Linux、macOS和Windows上运行良好。 -虽然理论上支持其他操作系统，但需要进一步测试。 - -需要注意的一点是，如果选择直接在主机上运行Job而不是在Job容器中运行，操作系统之间的环境差异可能会导致意外的失败。 - -例如，在大多数情况下，Windows上没有可用的bash，而act尝试默认使用bash运行脚本。 -因此，您需要在工作流文件中将默认shell指定为`powershell`，参考[defaults.run](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun)。 - -```yaml -defaults: - run: - shell: powershell -``` - -## 为什么选择GitHub Actions？为什么不选择与GitLab CI/CD兼容的工具？ - -[@lunny](https://gitea.com/lunny)在实现Actions的[问题](https://github.com/go-gitea/gitea/issues/13539)中已经解释过这个问题。 -此外，Actions不仅是一个CI/CD 系统，还是一个自动化工具。 - -在开源世界中，已经有许多[市场上的Actions](https://github.com/marketplace?type=actions)实现了。 -能够重用它们是令人兴奋的。 - -## 如果它在多个标签上运行，例如 `runs-on: [label_a, label_b]`，会发生什么？ - -这是有效的语法。 -它意味着它应该在具有`label_a` **和** `label_b`标签的Runner上运行，参考[GitHub Actions的工作流语法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on)。 -不幸的是，act runner 并不支持这种方式。 -如上所述，我们将标签映射到环境： - -- `ubuntu` → `ubuntu:22.04` -- `centos` → `centos:8` - -但我们需要将标签组映射到环境，例如： - -- `[ubuntu]` → `ubuntu:22.04` -- `[with-gpu]` → `linux:with-gpu` -- `[ubuntu, with-gpu]` → `ubuntu:22.04_with-gpu` - -我们还需要重新设计任务分配给Runner的方式。 -具有`ubuntu`、`centos`或`with-gpu`的Runner并不一定表示它可以接受`[centos, with-gpu]`的Job。 -因此，Runner应该通知Gitea实例它只能接受具有 `[ubuntu]`、`[centos]`、`[with-gpu]` 和 `[ubuntu, with-gpu]`的Job。 -这不是一个技术问题，只是在早期设计中被忽视了。 -参见[runtime.go#L65](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L65)。 - -目前，act runner尝试匹配标签中的每一个，并使用找到的第一个匹配项。 - -## 代理标签和自定义标签对于Runner有什么区别？ - - - -代理标签是由Runner在注册过程中向Gitea实例报告的。 -而自定义标签则是由Gitea的管理员或组织或仓库的所有者手动添加的（取决于Runner所属的级别）。 - -然而，目前这方面的设计还有待改进，因为它目前存在一些不完善之处。 -您可以向已注册的Runner添加自定义标签，比如 `centos`，这意味着该Runner将接收具有`runs-on: centos`的Job。 -然而，Runner可能不知道要使用哪个环境来执行该标签，导致它使用默认镜像或导致逻辑死胡同。 -这个默认值可能与用户的期望不符。 -参见[runtime.go#L71](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L71)。 - -与此同时，如果您想更改Runner的标签，我们建议您重新注册Runner。 - -## Gitea Actions runner会有更多的实现吗？ - -虽然我们希望提供更多的选择，但由于我们有限的人力资源，act runner将是唯一受支持的官方Runner。 -然而，无论您如何决定，Gitea 和act runner都是完全开源的，所以任何人都可以创建一个新的/更好的实现。 -我们支持您的选择，无论您如何决定。 -如果您选择分支act runner来创建自己的版本，请在您认为您的更改对其他人也有帮助的情况下贡献这些更改。 - -## Gitea 支持哪些工作流触发事件？ - -表格中列出的所有事件都是支持的，并且与 GitHub 兼容。 -对于仅 GitHub 支持的事件，请参阅 GitHub 的[文档](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows)。 - -| 触发事件 | 活动类型 | -|-----------------------------|--------------------------------------------------------------------------------------------------------------------------| -| create | 不适用 | -| delete | 不适用 | -| fork | 不适用 | -| gollum | 不适用 | -| push | 不适用 | -| issues | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `milestoned`, `demilestoned`, `labeled`, `unlabeled` | -| issue_comment | `created`, `edited`, `deleted` | -| pull_request | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `synchronize`, `labeled`, `unlabeled` | -| pull_request_review | `submitted`, `edited` | -| pull_request_review_comment | `created`, `edited` | -| release | `published`, `edited` | -| registry_package | `published` | diff --git a/docs/content/doc/usage/actions/overview.en-us.md b/docs/content/doc/usage/actions/overview.en-us.md deleted file mode 100644 index e07eca994f..0000000000 --- a/docs/content/doc/usage/actions/overview.en-us.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -date: "2023-04-27T15:00:00+08:00" -title: "Gitea Actions" -slug: "overview" -weight: 1 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "Overview" - weight: 1 - identifier: "actions-overview" ---- - -# Gitea Actions - -Starting with Gitea **1.19**, Gitea Actions are available as a built-in CI/CD solution. - -**Table of Contents** - -{{< toc >}} - -## Name - -It is similar and compatible to [GitHub Actions](https://github.com/features/actions), and its name is inspired by it too. -To avoid confusion, we have clarified the spelling here: - -- "Gitea Actions" (with an "s", both words capitalized) is the name of the Gitea feature. -- "GitHub Actions" is the name of the GitHub feature. -- "Actions" could refer to either of the above, depending on the context. So it refers to "Gitea Actions" in this document. -- "action" or "actions" refer to some scripts/plugins to be used, like "actions/checkout@v3" or "actions/cache@v3". - -## Runners - -Just like other CI/CD solutions, Gitea doesn't run the jobs itself, but delegates the jobs to runners. -The runner of Gitea Actions is called [act runner](https://gitea.com/gitea/act_runner), it is a standalone program and also written in Go. -It is based on a [fork](https://gitea.com/gitea/act) of [nektos/act](http://github.com/nektos/act). - -Because the runner is deployed independently, there could be potential security issues. -To avoid them, please follow two simple rules: - -- Don't use a runner you don't trust for your repository, organization or instance. -- Don't provide a runner to a repository, organization or instance you don't trust. - -For Gitea instances used internally, such as instances used by enterprises or individuals, neither of these two rules is a problem, they are naturally so. -However, for public Gitea instances, such as [gitea.com](https://gitea.com), these two rules should be kept in mind when adding or using runners. - -## Status - -Gitea Actions is still under development, so there may be some bugs and missing features. -And breaking changes may be made before it's stable (v1.20 or later). - -If the situation changes, we will update it here. -So please refer to the content here when you find outdated articles elsewhere. diff --git a/docs/content/doc/usage/actions/overview.zh-cn.md b/docs/content/doc/usage/actions/overview.zh-cn.md deleted file mode 100644 index 2081448151..0000000000 --- a/docs/content/doc/usage/actions/overview.zh-cn.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -date: "2023-05-24T15:00:00+08:00" -title: "Gitea Actions" -slug: "overview" -weight: 1 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "Overview" - weight: 1 - identifier: "actions-overview" ---- - -# Gitea Actions - -从Gitea **1.19**版本开始，Gitea Actions成为了内置的CI/CD解决方案。 - -**目录** - -{{< toc >}} - -## 名称 - -Gitea Actions与[GitHub Actions](https://github.com/features/actions)相似且兼容，它的名称也受到了它的启发。 -为了避免混淆，在这里我们明确了拼写方式： - -- "Gitea Actions"（两个单词都大写且带有"s"）是Gitea功能的名称。 -- "GitHub Actions"是GitHub功能的名称。 -- "Actions"根据上下文的不同可以指代以上任意一个。在本文档中指代的是"Gitea Actions"。 -- "action"或"actions"指代一些要使用的脚本/插件，比如"actions/checkout@v3"或"actions/cache@v3"。 - -## Runner - -和其他CI/CD解决方案一样，Gitea不会自己运行Job，而是将Job委托给Runner。 -Gitea Actions的Runner被称为[act runner](https://gitea.com/gitea/act_runner)，它是一个独立的程序，也是用Go语言编写的。 -它是基于[nektos/act](http://github.com/nektos/act)的一个[分支](https://gitea.com/gitea/act) 。 - -由于Runner是独立部署的，可能存在潜在的安全问题。 -为了避免这些问题，请遵循两个简单的规则： - -- 不要为你的仓库、组织或实例使用你不信任的Runner。 -- 不要为你不信任的仓库、组织或实例提供Runner。 - -对于内部使用的Gitea实例，比如企业或个人使用的实例，这两个规则不是问题，它们自然而然就是如此。 -然而，对于公共的Gitea实例，比如[gitea.com](https://gitea.com)，在添加或使用Runner时应当牢记这两个规则。 - -## 状态 - -Gitea Actions仍然在开发中，因此可能存在一些错误和缺失的功能。 -并且在稳定版本（v1.20或更高版本）之前可能会进行一些重大的更改。 - -如果情况发生变化，我们将在此处进行更新。 -因此，请在其他地方找到过时文章时参考此处的内容。 diff --git a/docs/content/doc/usage/actions/quickstart.en-us.md b/docs/content/doc/usage/actions/quickstart.en-us.md deleted file mode 100644 index 829f1a62c0..0000000000 --- a/docs/content/doc/usage/actions/quickstart.en-us.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -date: "2023-04-27T15:00:00+08:00" -title: "Quick Start" -slug: "quickstart" -weight: 10 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "Quick Start" - weight: 10 - identifier: "actions-quickstart" ---- - -# Quick Start - -This page will guide you through the process of using Gitea Actions. - -**Table of Contents** - -{{< toc >}} - -## Set up Gitea - -First of all, you need a Gitea instance. -You can follow the [documentation]({{< relref "doc/installation/from-package.en-us.md" >}}) to set up a new instance or upgrade your existing one. -It doesn't matter how you install or run Gitea, as long as its version is 1.19.0 or higher. - -Actions are disabled by default, so you need to add the following to the configuration file to enable it: - -```ini -[actions] -ENABLED=true -``` - -If you want to learn more or encounter any problems while configuring it, please refer to the [Configuration Cheat Sheet]({{< relref "doc/administration/config-cheat-sheet.en-us.md#actions-actions" >}}). - -### Set up runner - -Gitea Actions requires [act runner](https://gitea.com/gitea/act_runner) to run the jobs. -In order to avoid consuming too many resources and affecting the Gitea instance, it is recommended to start runners on separate machines from the Gitea instance. - -You can use the [pre-built binaries](http://dl.gitea.com/act_runner) or the [docker images](https://hub.docker.com/r/gitea/act_runner/tags) to set up the runner. - -Before proceeding any further, we suggest running it as a command line with pre-built binaries to ensure that it works with your environment, especially if you are running a runner on your local host. -And it could be easier to debug if something goes wrong. - -The runner can run the jobs in isolated Docker containers, so you need to make sure that the Docker has been installed and Docker daemon is running. -While it is not strictly necessary, because the runner can also run the jobs directly on the host, it depends on how you configure it. -However, it is recommended to use Docker to run the jobs, because it is more secure and easier to manage. - -Before running a runner, you should first register it to your Gitea instance using the following command: - -```bash -./act_runner register --no-interactive --instance <instance> --token <token> -``` - -There are two arguments required, `instance` and `token`. - -`instance` refers to the address of your Gitea instance, like `http://192.168.8.8:3000` or `https://gitea.com`. -The runner and job containers (which are started by the runner to execute jobs) will connect to this address. -This means that it could be different from the `ROOT_URL` of your Gitea instance, which is configured for web access. -It is always a bad idea to use a loopback address such as `127.0.0.1` or `localhost`. -If you are unsure which address to use, the LAN address is usually the right choice. - -`token` is used for authentication and identification, such as `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`. -It is one-time use only and cannot be used to register multiple runners. -You can obtain different levels of 'tokens' from the following places to create the corresponding level of' runners': - -- Instance level: The admin settings page, like `<your_gitea.com>/admin/actions/runners`. -- Organization level: The organization settings page, like `<your_gitea.com>/<org>/settings/actions/runners`. -- Repository level: The repository settings page, like `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`. - - - -After registering, a new file named `.runner` will appear in the current directory. -This file stores the registration information. -Please do not edit it manually. -If this file is missing or corrupted, you can simply remove it and register again. - -Finally, it's time to start the runner: - -```bash -./act_runner daemon -``` - -And you can see the new runner in the management page: - - - -You can find more information by visiting [Act runner]({{< relref "doc/usage/actions/act-runner.en-us.md" >}}). - -### Use Actions - -Even if Actions is enabled for the Gitea instance, repositories still disable Actions by default. - -To enable it, go to the settings page of your repository like `your_gitea.com/<owner>/repo/settings` and enable `Enable Repository Actions`. - - - -The next steps may be rather complicated. -You will need to study [the workflow syntax](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) for Actions and write the workflow files you want. - -However, we can just start from a simple demo: - -```yaml -name: Gitea Actions Demo -run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀 -on: [push] - -jobs: - Explore-Gitea-Actions: - runs-on: ubuntu-latest - steps: - - run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event." - - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!" - - run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}." - - name: Check out repository code - uses: actions/checkout@v3 - - run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner." - - run: echo "🖥️ The workflow is now ready to test your code on the runner." - - name: List files in the repository - run: | - ls ${{ gitea.workspace }} - - run: echo "🍏 This job's status is ${{ job.status }}." -``` - -You can upload it as a file with the extension `.yaml` in the directory `.gitea/workflows/` of the repository, for example `.gitea/workflows/demo.yaml`. -You might notice that this is fairly similar from the [Quickstart for GitHub Actions](https://docs.github.com/en/actions/quickstart). -That is because Gitea Actions is designed to be compatible with GitHub Actions wherever possible. - -Be careful, the demo file contains some emojis. -Please make sure your database supports them, especially when using MySQL. -If the charset is not `utf8mb4`, errors will occur, such as `Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`. -See [Database Preparation]({{< relref "doc/installation/database-preparation.en-us.md#mysql" >}}) for more information. - -Alternatively, you can remove all emojis from the demo file and try again. - -The line `on: [push]` indicates that the workflow will be triggered when you push commits to this repository. -However, when you upload the YAML file, it also pushes a commit, so you should see a new task in the Actions tab. - - - -Great job! You have successfully started working with Actions. diff --git a/docs/content/doc/usage/actions/quickstart.zh-cn.md b/docs/content/doc/usage/actions/quickstart.zh-cn.md deleted file mode 100644 index 1893300b61..0000000000 --- a/docs/content/doc/usage/actions/quickstart.zh-cn.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -date: "2023-05-24T15:00:00+08:00" -title: "快速入门" -slug: "quickstart" -weight: 10 -draft: false -toc: false -menu: - sidebar: - parent: "actions" - name: "快速入门" - weight: 10 - identifier: "actions-quickstart" ---- - -# 快速入门 - -本页面将指导您使用Gitea Actions的过程。 - -**目录** - -{{< toc >}} - -## 设置Gitea - -首先，您需要一个Gitea实例。 -您可以按照[文档]({{< relref "doc/installation/from-package.zh-cn.md" >}}) 来设置一个新实例或升级现有实例。 -无论您如何安装或运行Gitea，只要版本号是1.19.0或更高即可。 - -默认情况下，Actions是禁用的，因此您需要将以下内容添加到配置文件中以启用它： - -```ini -[actions] -ENABLED=true -``` - -如果您想了解更多信息或在配置过程中遇到任何问题，请参考[配置速查表]({{< relref "doc/administration/config-cheat-sheet.zh-cn.md#actions-actions" >}})。 - -### 设置Runner - -Gitea Actions需要[act runner](https://gitea.com/gitea/act_runner) 来运行Job。 -为了避免消耗过多资源并影响Gitea实例，建议您在与Gitea实例分开的机器上启动Runner。 - -您可以使用[预构建的二进制文件](http://dl.gitea.com/act_runner)或[容器镜像](https://hub.docker.com/r/gitea/act_runner/tags)来设置Runner。 - -在进一步操作之前，建议您先使用预构建的二进制文件以命令行方式运行它，以确保它与您的环境兼容，尤其是如果您在本地主机上运行Runner。 -如果出现问题，这样调试起来会更容易。 - -该Runner可以在隔离的Docker容器中运行Job，因此您需要确保已安装Docker并且Docker守护进程正在运行。 -虽然这不是严格必需的，因为Runner也可以直接在主机上运行Job，这取决于您的配置方式。 -然而，建议使用Docker运行Job，因为它更安全且更易于管理。 - -在运行Runner之前，您需要使用以下命令将其注册到Gitea实例中： - -```bash -./act_runner register --no-interactive --instance <instance> --token <token> -``` - -需要两个必需的参数：`instance` 和 `token`。 - -`instance`是您的Gitea实例的地址，如`http://192.168.8.8:3000`或`https://gitea.com`。 -Runner和Job容器（由Runner启动以执行Job）将连接到此地址。 -这意味着它可能与用于Web访问的`ROOT_URL`不同。 -使用回环地址（例如 `127.0.0.1` 或 `localhost`）是一个不好的选择。 -如果不确定使用哪个地址，通常选择局域网地址即可。 - -`token` 用于身份验证和标识，例如 `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`。 -它只能使用一次，并且不能用于注册多个Runner。 -您可以从以下位置获取不同级别的`token`,从而创建出相应级别的`runner` - -- 实例级别：管理员设置页面，例如 `<your_gitea.com>/admin/actions/runners`。 -- 组织级别：组织设置页面，例如 `<your_gitea.com>/<org>/settings/actions/runners`。 -- 存储库级别：存储库设置页面，例如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。 - - - -注册后，当前目录中将出现一个名为 `.runner` 的新文件，该文件存储了注册信息。 -请不要手动编辑该文件。 -如果该文件丢失或损坏，只需删除它然后重新注册即可。 - -最后，是时候启动Runner了： - -```bash -./act_runner daemon -``` - -您可以在管理页面上看到新的Runner： - - - -您可以通过访问[act runner]({{< relref "doc/usage/actions/act-runner.zh-cn.md" >}}) 获取更多信息。 - -### 使用Actions - -即使对于启用了Gitea实例的Actions，存储库仍默认禁用Actions。 - -要启用它，请转到存储库的设置页面，例如`your_gitea.com/<owner>/repo/settings`，然后启用`Enable Repository Actions`。 - - - -接下来的步骤可能相当复杂。 -您需要学习Actions的[工作流语法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)，并编写您想要的工作流文件。 - -不过，我们可以从一个简单的演示开始： - -```yaml -name: Gitea Actions Demo -run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀 -on: [push] - -jobs: - Explore-Gitea-Actions: - runs-on: ubuntu-latest - steps: - - run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event." - - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!" - - run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}." - - name: Check out repository code - uses: actions/checkout@v3 - - run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner." - - run: echo "🖥️ The workflow is now ready to test your code on the runner." - - name: List files in the repository - run: | - ls ${{ gitea.workspace }} - - run: echo "🍏 This job's status is ${{ job.status }}." -``` - -您可以将上述示例上传为一个以`.yaml`扩展名的文件，放在存储库的`.gitea/workflows/`目录中，例如`.gitea/workflows/demo.yaml`。 -您可能会注意到，这与[GitHub Actions的快速入门](https://docs.github.com/en/actions/quickstart)非常相似。 -这是因为Gitea Actions在尽可能兼容GitHub Actions的基础上进行设计。 - -请注意，演示文件中包含一些表情符号。 -请确保您的数据库支持它们，特别是在使用MySQL时。 -如果字符集不是`utf8mb4，将出现错误，例如`Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`。 -有关更多信息，请参阅[数据库准备工作]({{< relref "doc/installation/database-preparation.zh-cn.md#mysql" >}})。 - -或者，您可以从演示文件中删除所有表情符号，然后再尝试一次。 - -`on: [push]` 这一行表示当您向该存储库推送提交时，工作流将被触发。 -然而，当您上传 YAML 文件时，它也会推送一个提交，所以您应该在"Actions"标签中看到一个新的任务。 - - - -做得好！您已成功开始使用Actions。 diff --git a/docs/content/doc/usage/agit-support.en-us.md b/docs/content/doc/usage/agit-support.en-us.md deleted file mode 100644 index 30e2879e89..0000000000 --- a/docs/content/doc/usage/agit-support.en-us.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -date: " 2022-09-01T20:50:42+0000" -title: "Agit Setup" -slug: "agit-setup" -weight: 12 -toc: false -draft: false -aliases: - - /en-us/agit-setup -menu: - sidebar: - parent: "usage" - name: "Agit Setup" - weight: 12 - identifier: "agit-setup" ---- - -# Agit Setup - -In Gitea `1.13`, support for [agit](https://git-repo.info/en/2020/03/agit-flow-and-git-repo/) was added. - -## Creating PRs with Agit - -Agit allows to create PRs while pushing code to the remote repo. \ -This can be done by pushing to the branch followed by a specific refspec (a location identifier known to git). \ -The following example illustrates this: - -```shell -git push origin HEAD:refs/for/master -``` - -The command has the following structure: - -- `HEAD`: The target branch -- `refs/<for|draft|for-review>/<branch>`: The target PR type - - `for`: Create a normal PR with `<branch>` as the target branch - - `draft`/ `for-review`: Currently ignored silently -- `<branch>/<session>`: The target branch to open the PR -- `-o <topic|title|description>`: Options for the PR - - `title`: The PR title - - `topic`: The branch name the PR should be opened for - - `description`: The PR description - - `force-push`: confirm force update the target branch - -Here's another advanced example for creating a new PR targeting `master` with `topic`, `title`, and `description`: - -```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" -``` diff --git a/docs/content/doc/usage/agit-support.zh-cn.md b/docs/content/doc/usage/agit-support.zh-cn.md deleted file mode 100644 index de6eba24b2..0000000000 --- a/docs/content/doc/usage/agit-support.zh-cn.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "Agit 设置" -slug: "agit-setup" -weight: 12 -toc: false -draft: false -aliases: - - /zh-cn/agit-setup -menu: - sidebar: - parent: "usage" - name: "Agit 设置" - weight: 12 - identifier: "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`：确认强制更新目标分支 - -下面是另一个高级示例，用于创建一个以 `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" -``` diff --git a/docs/content/doc/usage/authentication.en-us.md b/docs/content/doc/usage/authentication.en-us.md deleted file mode 100644 index d9648200ef..0000000000 --- a/docs/content/doc/usage/authentication.en-us.md +++ /dev/null @@ -1,352 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Authentication" -slug: "authentication" -weight: 10 -toc: false -draft: false -aliases: - - /en-us/authentication -menu: - sidebar: - parent: "usage" - name: "Authentication" - weight: 10 - identifier: "authentication" ---- - -# Authentication - -{{< toc >}} - -## LDAP (Lightweight Directory Access Protocol) - -Both the LDAP via BindDN and the simple auth LDAP share the following fields: - -- Authorization Name **(required)** - - - A name to assign to the new method of authorization. - -- Host **(required)** - - - The address where the LDAP server can be reached. - - Example: `mydomain.com` - -- Port **(required)** - - - The port to use when connecting to the server. - - Example: `389` for LDAP or `636` for LDAP SSL - -- Enable TLS Encryption (optional) - - - Whether to use TLS when connecting to the LDAP server. - -- Admin Filter (optional) - - - An LDAP filter specifying if a user should be given administrator - privileges. If a user account passes the filter, the user will be - privileged as an administrator. - - Example: `(objectClass=adminAccount)` - - Example for Microsoft Active Directory (AD): `(memberOf=CN=admin-group,OU=example,DC=example,DC=org)` - -- Username attribute (optional) - - - The attribute of the user's LDAP record containing the user name. Given - attribute value will be used for new Gitea account user name after first - successful sign-in. Leave empty to use login name given on sign-in form. - - This is useful when supplied login name is matched against multiple - attributes, but only single specific attribute should be used for Gitea - account name, see "User Filter". - - Example: `uid` - - Example for Microsoft Active Directory (AD): `sAMAccountName` - -- First name attribute (optional) - - - The attribute of the user's LDAP record containing the user's first name. - This will be used to populate their account information. - - Example: `givenName` - -- Surname attribute (optional) - - - The attribute of the user's LDAP record containing the user's surname. - This will be used to populate their account information. - - Example: `sn` - -- E-mail attribute **(required)** - - The attribute of the user's LDAP record containing the user's email - address. This will be used to populate their account information. - - Example: `mail` - -### LDAP via BindDN - -Adds the following fields: - -- Bind DN (optional) - - - The DN to bind to the LDAP server with when searching for the user. This - may be left blank to perform an anonymous search. - - Example: `cn=Search,dc=mydomain,dc=com` - -- Bind Password (optional) - - - The password for the Bind DN specified above, if any. _Note: The password - is stored encrypted with the SECRET_KEY on the server. It is still recommended - to ensure that the Bind DN has as few privileges as possible._ - -- User Search Base **(required)** - - - The LDAP base at which user accounts will be searched for. - - Example: `ou=Users,dc=mydomain,dc=com` - -- User Filter **(required)** - - An LDAP filter declaring how to find the user record that is attempting to - authenticate. The `%[1]s` matching parameter will be substituted with login - name given on sign-in form. - - Example: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))` - - Example for Microsoft Active Directory (AD): `(&(objectCategory=Person)(memberOf=CN=user-group,OU=example,DC=example,DC=org)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))` - - To substitute more than once, `%[1]s` should be used instead, e.g. when - matching supplied login name against multiple attributes such as user - identifier, email or even phone number. - - Example: `(&(objectClass=Person)(|(uid=%[1]s)(mail=%[1]s)(mobile=%[1]s)))` -- Enable user synchronization - - This option enables a periodic task that synchronizes the Gitea users with - the LDAP server. The default period is every 24 hours but that can be - changed in the app.ini file. See the _cron.sync_external_users_ section in - the [sample - app.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) - for detailed comments about that section. The _User Search Base_ and _User - Filter_ settings described above will limit which users can use Gitea and - which users will be synchronized. When initially run the task will create - all LDAP users that match the given settings so take care if working with - large Enterprise LDAP directories. - -### LDAP using simple auth - -Adds the following fields: - -- User DN **(required)** - - - A template to use as the user's DN. The `%s` matching parameter will be - substituted with login name given on sign-in form. - - Example: `cn=%s,ou=Users,dc=mydomain,dc=com` - - Example: `uid=%s,ou=Users,dc=mydomain,dc=com` - -- User Search Base (optional) - - - The LDAP base at which user accounts will be searched for. - - Example: `ou=Users,dc=mydomain,dc=com` - -- User Filter **(required)** - - An LDAP filter declaring when a user should be allowed to log in. The `%[1]s` - matching parameter will be substituted with login name given on sign-in - form. - - Example: `(&(objectClass=posixAccount)(|(cn=%[1]s)(mail=%[1]s)))` - - Example: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))` - -### Verify group membership in LDAP - -Uses the following fields: - -- Group Search Base (optional) - - - The LDAP DN used for groups. - - Example: `ou=group,dc=mydomain,dc=com` - -- Group Name Filter (optional) - - - An LDAP filter declaring how to find valid groups in the above DN. - - Example: `(|(cn=gitea_users)(cn=admins))` - -- User Attribute in Group (optional) - - - Which user LDAP attribute is listed in the group. - - Example: `uid` - -- Group Attribute for User (optional) - - Which group LDAP attribute contains an array above user attribute names. - - Example: `memberUid` - -## PAM (Pluggable Authentication Module) - -This procedure enables PAM authentication. Users may still be added to the -system manually using the user administration. PAM provides a mechanism to -automatically add users to the current database by testing them against PAM -authentication. To work with normal Linux passwords, the user running Gitea -must also have read access to `/etc/shadow` in order to check the validity of -the account when logging in using a public key. - -**Note**: If a user has added SSH public keys into Gitea, the use of these -keys _may_ bypass the login check system. Therefore, if you wish to disable a user who -authenticates with PAM, you _should_ also manually disable the account in Gitea using the -built-in user manager. - -1. Configure and prepare the installation. - - It is recommended that you create an administrative user. - - Deselecting automatic sign-up may also be desired. -1. Once the database has been initialized, log in as the newly created -administrative user. -1. Navigate to the user setting (icon in top-right corner), and select -`Site Administration` -> `Authentication Sources`, and select -`Add Authentication Source`. -1. Fill out the field as follows: - - `Authentication Type` : `PAM` - - `Name` : Any value should be valid here, use "System Authentication" if - you'd like. - - `PAM Service Name` : Select the appropriate file listed under `/etc/pam.d/` - that performs the authentication desired.[^1] - - `PAM Email Domain` : The e-mail suffix to append to user authentication. - For example, if the login system expects a user called `gituser`, and this - field is set to `mail.com`, then Gitea will expect the `user email` field - for an authenticated GIT instance to be `gituser@mail.com`.[^2] - -**Note**: PAM support is added via [build-time flags](https://docs.gitea.io/en-us/install-from-source/#build), -and the official binaries provided do not have this enabled. PAM requires that -the necessary libpam dynamic library be available and the necessary PAM -development headers be accessible to the compiler. - -[^1]: For example, using standard Linux log-in on Debian "Bullseye" use -`common-session-noninteractive` - this value may be valid for other flavors of -Debian including Ubuntu and Mint, consult your distribution's documentation. -[^2]: **This is a required field for PAM**. Be aware: In the above example, the -user will log into the Gitea web interface as `gituser` and not `gituser@mail.com` - -## SMTP (Simple Mail Transfer Protocol) - -This option allows Gitea to log in to an SMTP host as a Gitea user. To -configure this, set the fields below: - -- Authentication Name **(required)** - - - A name to assign to the new method of authorization. - -- SMTP Authentication Type **(required)** - - - Type of authentication to use to connect to SMTP host, PLAIN or LOGIN. - -- Host **(required)** - - - The address where the SMTP host can be reached. - - Example: `smtp.mydomain.com` - -- Port **(required)** - - - The port to use when connecting to the server. - - Example: `587` - -- Allowed Domains - - - Restrict what domains can log in if using a public SMTP host or SMTP host - with multiple domains. - - Example: `gitea.io,mydomain.com,mydomain2.com` - -- Force SMTPS - - - SMTPS will be used by default for connections to port 465, if you wish to use SMTPS - for other ports. Set this value. - - Otherwise if the server provides the `STARTTLS` extension this will be used. - -- Skip TLS Verify - - - Disable TLS verify on authentication. - -- This Authentication Source is Activated - - Enable or disable this authentication source. - -## FreeIPA - -- In order to log in to Gitea using FreeIPA credentials, a bind account needs to - be created for Gitea: - -- On the FreeIPA server, create a `gitea.ldif` file, replacing `dc=example,dc=com` - with your DN, and provide an appropriately secure password: - - ```sh - dn: uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com - changetype: add - objectclass: account - objectclass: simplesecurityobject - uid: gitea - userPassword: secure password - passwordExpirationTime: 20380119031407Z - nsIdleTimeout: 0 - ``` - -- Import the LDIF (change localhost to an IPA server if needed). A prompt for - Directory Manager password will be presented: - - ```sh - ldapmodify -h localhost -p 389 -x -D \ - "cn=Directory Manager" -W -f gitea.ldif - ``` - -- Add an IPA group for gitea_users : - - ```sh - ipa group-add --desc="Gitea Users" gitea_users - ``` - -- Note: For errors about IPA credentials, run `kinit admin` and provide the - domain admin account password. - -- Log in to Gitea as an Administrator and click on "Authentication" under Admin Panel. - Then click `Add New Source` and fill in the details, changing all where appropriate. - -## SPNEGO with SSPI (Kerberos/NTLM, for Windows only) - -Gitea supports SPNEGO single sign-on authentication (the scheme defined by RFC4559) for the web part of the server via the Security Support Provider Interface (SSPI) built in Windows. SSPI works only in Windows environments - when both the server and the clients are running Windows. - -Before activating SSPI single sign-on authentication (SSO) you have to prepare your environment: - -- Create a separate user account in active directory, under which the `gitea.exe` process will be running (eg. `user` under domain `domain.local`): - -- Create a service principal name for the host where `gitea.exe` is running with class `HTTP`: - - - Start `Command Prompt` or `PowerShell` as a privileged domain user (eg. Domain Administrator) - - Run the command below, replacing `host.domain.local` with the fully qualified domain name (FQDN) of the server where the web application will be running, and `domain\user` with the name of the account created in the previous step: - - ```sh - setspn -A HTTP/host.domain.local domain\user - ``` - -- Sign in (_sign out if you were already signed in_) with the user created - -- Make sure that `ROOT_URL` in the `[server]` section of `custom/conf/app.ini` is the fully qualified domain name of the server where the web application will be running - the same you used when creating the service principal name (eg. `host.domain.local`) - -- Start the web server (`gitea.exe web`) - -- Enable SSPI authentication by adding an `SPNEGO with SSPI` authentication source in `Site Administration -> Authentication Sources` - -- Sign in to a client computer in the same domain with any domain user (client computer, different from the server running `gitea.exe`) - -- If you are using Chrome or Edge, add the URL of the web app to the Local intranet sites (`Internet Options -> Security -> Local intranet -> Sites`) - -- Start Chrome or Edge and navigate to the FQDN URL of Gitea (eg. `http://host.domain.local:3000`) - -- Click the `Sign In` button on the dashboard and choose SSPI to be automatically logged in with the same user that is currently logged on to the computer - -- If it does not work, make sure that: - - You are not running the web browser on the same server where Gitea is running. You should be running the web browser on a domain joined computer (client) that is different from the server. If both the client and server are running on the same computer NTLM will be preferred over Kerberos. - - There is only one `HTTP/...` SPN for the host - - The SPN contains only the hostname, without the port - - You have added the URL of the web app to the `Local intranet zone` - - The clocks of the server and client should not differ with more than 5 minutes (depends on group policy) - - `Integrated Windows Authentication` should be enabled in Internet Explorer (under `Advanced settings`) - -## Reverse Proxy - -Gitea supports Reverse Proxy Header authentication, it will read headers as a trusted login user name or user email address. This hasn't been enabled by default, you can enable it with - -```ini -[service] -ENABLE_REVERSE_PROXY_AUTHENTICATION = true -``` - -The default login user name is in the `X-WEBAUTH-USER` header, you can change it via changing `REVERSE_PROXY_AUTHENTICATION_USER` in app.ini. If the user doesn't exist, you can enable automatic registration with `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true`. - -The default login user email is `X-WEBAUTH-EMAIL`, you can change it via changing `REVERSE_PROXY_AUTHENTICATION_EMAIL` in app.ini, this could also be disabled with `ENABLE_REVERSE_PROXY_EMAIL` - -If set `ENABLE_REVERSE_PROXY_FULL_NAME=true`, a user full name expected in `X-WEBAUTH-FULLNAME` will be assigned to the user when auto creating the user. You can also change the header name with `REVERSE_PROXY_AUTHENTICATION_FULL_NAME`. - -You can also limit the reverse proxy's IP address range with `REVERSE_PROXY_TRUSTED_PROXIES` which default value is `127.0.0.0/8,::1/128`. By `REVERSE_PROXY_LIMIT`, you can limit trusted proxies level. - -Notice: Reverse Proxy Auth doesn't support the API. You still need an access token or basic auth to make API requests. diff --git a/docs/content/doc/usage/authentication.zh-cn.md b/docs/content/doc/usage/authentication.zh-cn.md deleted file mode 100644 index bef78ba649..0000000000 --- a/docs/content/doc/usage/authentication.zh-cn.md +++ /dev/null @@ -1,293 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "认证" -slug: "authentication" -weight: 10 -toc: false -draft: false -aliases: - - /zh-cn/authentication -menu: - sidebar: - parent: "usage" - name: "认证" - weight: 10 - identifier: "authentication" ---- - -# 认证 - -## 轻量级目录访问协议（Lightweight Directory Access Protocol，LDAP） - -通过BindDN的LDAP和简单认证方式LDAP共享以下字段: - -- 认证名称 **(必选)** - - - 分配给新授权方法的名称。 - -- 主机名 **(必选)** - - - LDAP 服务的主机地址. - - 例如:`mydomain.com` - -- 端口号 **(必选)** - - - LDAP 服务的端口号. - - 例如: LDAP `389`/ LDAPs `636` - -- 安全协议 (可选) - - 连接LDAP服务器时是否使用TLS协议。 - -- 管理员过滤规则 (可选) - - 一个LDAP过滤器，用于指定哪些用户应该被赋予管理员特权。如果用户帐户符合过滤器条件，则该用户将被授予管理员权限。 - - 示例:`(objectClass=adminAccount)` - - 适用于Microsoft Active Directory（AD）的示例:`memberOf=CN=admin-group,OU=example,DC=example,DC=org` - -- 用户名属性（可选） - - - 用户LDAP记录中包含用户名称的属性。在第一次成功登录后，将使用指定的属性值作为新的Gitea账户用户名。若留空，则使用登录表单上提供的用户名。 - - 当提供的登录名与多个属性匹配时，这一选项非常有用，但是只有一个特定属性应该用于Gitea账户名称，请参阅"用户过滤器"。 - - 示例:uid - - 适用于Microsoft Active Directory（AD）的示例:`sAMAccountName` - -- 名字属性（可选） - - - 用户LDAP记录中包含用户名字的属性。将用于填充他们的账户信息。 - - 示例:givenName -- 姓氏属性（可选） - - 用户LDAP记录中包含用户姓氏的属性。将用于填充他们的账户信息。 - - 示例:`sn` - -- 电子邮件属性 **(必选)** - - 用户LDAP记录中包含用户电子邮件地址的属性。将用于填充他们的账户信息。 - - 示例:`mail` - -### LDAP(via BindDN) - -需要额外设置以下字段: - -- 绑定DN (可选) - - - 搜索用户时绑定到LDAP服务器的DN。这可以留空以执行匿名搜索。 - - 示例: `cn=Search,dc=mydomain,dc=com` - -- 绑定密码 (可选) - - - 上述指定的Bind DN（绑定区别名）的密码，如果有的话。注意：该密码在服务器上使用SECRET_KEY进行加密存储。仍然建议确保Bind DN具有尽可能少的权限。 - -- 用户搜索基准 **(必选)** - - - 这是用于搜索用户帐户的LDAP基础路径. - - 示例: `ou=Users,dc=mydomain,dc=com` - -- 用户过滤规则 **(必选)** - - LDAP 过滤器声明如何查找试图进行身份验证的用户记录 - `%[1]s`匹配参数将替换为登录表单中给出的登录名 - - 示例: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))` - - 示例 for Microsoft Active Directory (AD): `(&(objectCategory=Person)(memberOf=CN=user-group,OU=example,DC=example,DC=org)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))` - - 如需多次替换，应使用 `%[1]s`，例如在将提供的登录名与多个属性（如用户标识符、电子邮件甚至电话号码）进行匹配时。 - - 示例: `(&(objectClass=Person)(|(uid=%[1]s)(mail=%[1]s)(mobile=%[1]s)))` -- 启用用户同步 - - 这个选项启用了一个周期性任务，用于将Gitea用户与LDAP服务器进行同步。默认的同步周期是每24小时， - 但您可以在app.ini文件中进行更改。 - 有关此部分的详细说明，请参阅[sample - app.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) - 的_cron.sync_external_users_ 部分的注释。前面提到的_User Search Base_和_User Filter_ - 设置将限制哪些用户可以使用Gitea以及哪些用户将被同步。 - 在初始运行任务时，将根据给定的设置创建所有与LDAP匹配的用户，因此在使用大型企业LDAP目录时需要小心。 - -### LDAP(simple auth) - -需要额外设置以下字段: - -- 用户DN **(必选)** - - - 用作用户 DN 的模板。匹配参数 `%s` 将替换为登录表单中的登录名。 - - 示例: `cn=%s,ou=Users,dc=mydomain,dc=com` - - 示例: `uid=%s,ou=Users,dc=mydomain,dc=com` - -- 用户搜索基准 (可选) - - - 用户搜索基准声明哪些用户帐户将被搜索. - - 示例: `ou=Users,dc=mydomain,dc=com` - -- 用户过滤规则 **(必选)** - - LDAP 过滤器声明何时允许用户登录 - `%[1]s`匹配参数将替换为登录表单中给出的登录名。 - - 示例: `(&(objectClass=posixAccount)(|(cn=%[1]s)(mail=%[1]s)))` - - 示例: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))` - -### 使用LDAP验证分组成员 - -使用以下字段: - -- 群组搜索基础DN(可选) - - 组使用的 LDAP DN。 - - 示例: `ou=group,dc=mydomain,dc=com` - -- 组名过滤器 (可选) - - - LDAP 过滤器，声明如何在上述 DN 中查找有效组。 - - 示例: `(|(cn=gitea_users)(cn=admins))` - -- 组中的用户属性 (可选) - - - 组中列出了哪个用户的 LDAP 属性。 - - 示例: `uid` - -- 用户组属性 (可选) - - 哪个组的 LDAP 属性包含一个高于用户属性名称的数组。 - - 示例: `memberUid` - -## 可插拔式认证模块(Pluggable Authentication Module,PAM) - -这个过程启用了PAM（Pluggable Authentication Modules）认证。用户仍然可以通过用户管理手动添加到系统中。 -PAM提供了一种机制，通过对用户进行PAM认证来自动将其添加到当前数据库中。为了与普通的Linux密码一起使用， -运行Gitea的用户还必须具有对`/etc/shadow`的读取权限，以便在使用公钥登录时检查账户的有效性。 - -**注意**:如果用户已将SSH公钥添加到Gitea中，使用这些密钥可能会绕过登录检查系统。因此， -如果您希望禁用使用PAM进行身份验证的用户，应该在Gitea中手动禁用该账户，使用内置的用户管理功能。 - -1. 配置和安装准备. - - 建议您创建一个管理用户. - - 建议取消自动注册. -1. 一旦数据库已初始化完成，使用新创建的管理员账户登录. -1. 导航至用户设置（右上角的图标），然后选择 -`Site Administration` -> `Authentication Sources`, 并选择 -`Add Authentication Source`. -1. 填写字段如下: - - 认证类型:`PAM`。 - - 名称:任何有效的值都可以，如果您愿意，可以使用"System Authentication"。 - - PAM服务名称:从/etc/pam.d/目录下选择适用于所需认证的正确文件[^1]。 - - PAM电子邮件域:用户认证时要附加的电子邮件后缀。例如，如果登录系统期望一个名为gituse的用户， - 并且将此字段设置为mail.com，那么Gitea在验证一个GIT实例的用户时将期望user emai字段为gituser@mail.com[^2]。 - -**Note**: PAM 支持通过[build-time flags](https://docs.gitea.io/en-us/install-from-source/#build)添加, -而官方提供的二进制文件通常不会默认启用此功能。PAM需要确保系统上有必要的libpam动态库，并且编译器可以访问必要的PAM开发头文件。 - -[^1]: 例如，在Debian "Bullseye"上使用标准Linux登录，可以使用`common-session-noninteractive`。这个值对于其他版本的Debian， -包括Ubuntu和Mint，可能也是有效的，请查阅您所使用发行版的文档以确认。 - -[^2]: **PAM的必选项** 请注意:在上面的示例中，用户将作为`gituser`而不是`gituser@mail.com`登录到Gitea的Web界面。 - -## 简单邮件传输协议(Simple Mail Transfer Protocol,SMTP) - -此选项允许 Gitea 以 Gitea 用户身份登录 SMTP 主机。请设置以下字段: - -- 身份验证名称 **(必选)** - - 分配给新授权方法的名称 - -- SMTP 验证类型 **(必选)** - - 用于连接 SMTP 主机的验证类型，plain 或 login - -- 主机名 **(必选)** - - - SMTP 服务的主机地址 - - 例如:`smtp.mydomain.com` - -- 端口号 **(必选)** - - - SMTP 服务的端口号 - - 例如: `587` - -- 允许的域名 - - - 如果使用公共 SMTP 主机或有多个域的 SMTP 主机，限制哪些域可以登录 - 限制哪些域可以登录。 - - 示例: `gitea.io,mydomain.com,mydomain2.com` - -- 强制使用 SMTPS - - 默认情况下将使用SMTPS连接到端口465.如果您希望将smtp用于其他端口，自行设置 - - 否则，如果服务器提供' STARTTLS '扩展名，则将使用此扩展名 -- 跳过 TLS 验证 - - 禁用 TLS 验证身份. -- 该认证源处于激活状态 - - 启用或禁用此身份验证源 - -## FreeIPA - -- 要使用 FreeIPA 凭据登录 Gitea，需要为 Gitea 创建一个绑定帐户。 - 创建一个绑定帐户: -- 在FreeIPA服务器上创建一个gitea.ldif文件，并将`dc=example,dc=com`替换为您的`dn`，然后提供一个适当安全的密码。 - - ```sh - dn: uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com - changetype: add - objectclass: account - objectclass: simplesecurityobject - uid: gitea - userPassword: secure password - passwordExpirationTime: 20380119031407Z - nsIdleTimeout: 0 - ``` - -- 导入LDIF文件（如果需要，请将localhost更改为IPA服务器）。系统会提示您输入Directory Manager的密码。: - - ```sh - ldapmodify -h localhost -p 389 -x -D \ - "cn=Directory Manager" -W -f gitea.ldif - ``` - -- 为`gitea_users`添加IPA组: - - ```sh - ipa group-add --desc="Gitea Users" gitea_users - ``` - -- **提示**:对于IPA凭证错误，运行' kinit admin '并提供域管理帐户密码. -- 以管理员身份登录Gitea，点击Admin Panel下的`Authentication`。然后单击`Add New Source`并填写详细信息，更改所有适当的地方。 - -## SPNEGO with SSPI (Kerberos/NTLM, for Windows only) - -Gitea支持通过Windows内置的安全支持提供程序接口（Security Support Provider Interface，SSPI）实现SPNEGO单点登录认证（由RFC4559定义的方案），用于服务器的Web部分。SSPI仅在Windows环境中工作，即当服务器和客户端都在Windows操作系统上运行时。 - -在激活SSPI单点登录认证（SSO）之前，您需要准备您的环境: - -- 在Active Directory中创建一个单独的用户账户，gitea.exe 进程将在该账户下运行（例如，在domain.local域下创建一个名为user的账户: -- 为运行gitea.exe的主机创建一个服务主体名称（Service Principal Name，SPN），其类别为HTTP: - - - 以特权域用户（例如域管理员）的身份启动“命令提示符”或“PowerShell”。 - - 运行下面的命令，将host.domain.local替换为Web应用程序将运行的服务器的完全限定域名（FQDN），将domain\user替换为在前一步中创建的账户名称: - - ```sh - setspn -A HTTP/host.domain.local domain\user - ``` - -在遵循上述步骤之前，请确保您按照以下流程进行操作: - -1. 用之前创建的用户登录（如果已经登录，请先注销）。 -2. 确保在`custom/conf/app.ini`文件的`[server]`部分中，`ROOT_URL`设置为Web应用程序将运行的服务器的完全限定域名（FQDN），与之前创建服务主体名称时使用的一致（例如，`host.domain.local`）。 -3. 启动Web服务器（运行 `gitea.exe web`）。 -4. 在 `Site Administration -> Authentication Sources` 中添加一个 `SPNEGO with SSPI` 认证源，以启用SSPI认证。 -5. 在域中的客户端计算机上，使用任何域用户登录（与运行`gitea.exe`的服务器不同）。 -6. 如果您使用Chrome或Edge浏览器，请将Web应用程序的URL添加到“本地站点”（`Internet选项 -> 安全 -> 本地站点 -> 站点`）。 -7. 启动Chrome或Edge浏览器，导航到Gitea的FQDN URL（例如，`http://host.domain.local:3000`）。 -8. 在控制面板中点击“Sign In”按钮，然后选择SSPI，将会自动使用当前登录到计算机的用户进行登录。 -9. 如果无法正常工作，请确保: - - 您不是在运行`gitea.exe`的同一台服务器上运行Web浏览器。应该在与服务器不同的域加入计算机（客户端）上运行Web浏览器。如果客户端和服务器都在同一台计算机上运行，则NTLM将优先于Kerberos。 - - 主机上只有一个`HTTP/...`的SPN。 - - SPN中只包含主机名，不包含端口号。 - - 将Web应用程序的URL添加到"本地站点"。 - - 服务器和客户端的时钟差异不超过5分钟（取决于组策略）。 - - 在Internet Explorer中启用了"集成Windows身份验证"（在"高级设置"下）。 - -遵循这些步骤，您应该能够成功启用和使用SSPI单点登录认证（SSO）。 - -## 反向代理认证 - -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 来进行认证。 diff --git a/docs/content/doc/usage/authentication.zh-tw.md b/docs/content/doc/usage/authentication.zh-tw.md deleted file mode 100644 index 75959802b1..0000000000 --- a/docs/content/doc/usage/authentication.zh-tw.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "認證" -slug: "authentication" -weight: 10 -toc: false -draft: false -aliases: - - /zh-tw/authentication -menu: - sidebar: - parent: "usage" - name: "認證" - weight: 10 - identifier: "authentication" ---- - -# 認證 - -## TBD diff --git a/docs/content/doc/usage/clone-filter.en-us.md b/docs/content/doc/usage/clone-filter.en-us.md deleted file mode 100644 index 8331c138bf..0000000000 --- a/docs/content/doc/usage/clone-filter.en-us.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -date: "2021-02-02" -title: "Clone filters (partial clone)" -slug: "clone-filters" -weight: 25 -draft: false -toc: false -aliases: - - /en-us/clone-filters -menu: - sidebar: - parent: "usage" - name: "Clone filters" - weight: 25 - identifier: "clone-filters" ---- - -# Clone filters (partial clone) - -Git introduces `--filter` option to `git clone` command, which filters out -large files and objects (such as blobs) to create partial clone of a repo. -Clone filters are especially useful for large repo and/or metered connection, -where full clone (without `--filter`) can be expensive (as all history data -must be downloaded). - -This requires Git version 2.22 or later, both on the Gitea server and on the -client. For clone filters to work properly, make sure that Git version -on the client is at least the same as on the server (or later). Login to -Gitea server as admin and head to Site Administration -> Configuration to -see Git version of the server. - -By default, clone filters are enabled, unless `DISABLE_PARTIAL_CLONE` under -`[git]` is set to `true`. - -See [GitHub blog post: Get up to speed with partial clone](https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/) -for common use cases of clone filters (blobless and treeless clones), and -[GitLab docs for partial clone](https://docs.gitlab.com/ee/topics/git/partial_clone.html) -for more advanced use cases (such as filter by file size and remove -filters to turn partial clone into full clone). diff --git a/docs/content/doc/usage/clone-filter.zh-cn.md b/docs/content/doc/usage/clone-filter.zh-cn.md deleted file mode 100644 index fc174fcb38..0000000000 --- a/docs/content/doc/usage/clone-filter.zh-cn.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "克隆过滤器 (部分克隆)" -slug: "clone-filters" -weight: 25 -draft: false -toc: false -aliases: - - /zh-cn/clone-filters -menu: - sidebar: - parent: "usage" - name: "克隆过滤器" - weight: 25 - identifier: "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) 以获取更高级的用法（例如按文件大小过滤和取消过滤以将部分克隆转换为完全克隆）。 diff --git a/docs/content/doc/usage/code-owners.en-us.md b/docs/content/doc/usage/code-owners.en-us.md deleted file mode 100644 index 94f81eeae1..0000000000 --- a/docs/content/doc/usage/code-owners.en-us.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -date: "2023-05-24T16:00:00+00:00" -title: "Code Owners" -slug: "code-owners" -weight: 30 -toc: false -draft: false -aliases: - - /en-us/code-owners -menu: - sidebar: - parent: "usage" - name: "Code Owners" - weight: 30 - identifier: "code-owners" ---- - -# Code Owners - -Gitea maintains code owner files. It looks for it in the following locations in this order: - -- `./CODEOWNERS` -- `./docs/CODEOWNERS` -- `./.gitea/CODEOWNERS` - -And stops at the first found file. - -File format: `<regexp rule> <@user or @org/team> [@user or @org/team]...` - -Regexp specified in golang Regex format. -Regexp can start with `!` for negative rules - match all files except specified. - -Example file: - -``` -.*\\.go @user1 @user2 # This is comment - -# Comment too -# You can assigning code owning for users or teams -frontend/src/.*\\.js @org1/team1 @org1/team2 @user3 - -# You can use negative pattern -!frontend/src/.* @org1/team3 @user5 - -# You can use power of go regexp -docs/(aws|google|azure)/[^/]*\\.(md|txt) @user8 @org1/team4 -!/assets/.*\\.(bin|exe|msi) @user9 -``` - -### Escaping - -You can escape characters `#`, ` ` (space) and `\` with `\`, like: - -``` -dir/with\#hashtag @user1 -path\ with\ space @user2 -path/with\\backslash @user3 -``` - -Some character (`.+*?()|[]{}^$\`) should be escaped with `\\` inside regexp, like: - -``` -path/\\.with\\.dots -path/with\\+plus -``` diff --git a/docs/content/doc/usage/incoming-email.en-us.md b/docs/content/doc/usage/incoming-email.en-us.md deleted file mode 100644 index 205b3dd8ed..0000000000 --- a/docs/content/doc/usage/incoming-email.en-us.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -date: "2022-12-01T00:00:00+00:00" -title: "Incoming Email" -slug: "incoming-email" -weight: 13 -draft: false -toc: false -aliases: - - /en-us/incoming-email -menu: - sidebar: - parent: "usage" - name: "Incoming Email" - weight: 13 - identifier: "incoming-email" ---- - -# Incoming Email - -Gitea supports the execution of several actions through incoming mails. This page describes how to set this up. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -Handling incoming email messages requires an IMAP-enabled email account. -The recommended strategy is to use [email sub-addressing](https://en.wikipedia.org/wiki/Email_address#Sub-addressing) but a catch-all mailbox does work too. -The receiving email address contains a user/action specific token which tells Gitea which action should be performed. -This token is expected in the `To` and `Delivered-To` header fields. - -Gitea tries to detect automatic responses to skip and the email server should be configured to reduce the incoming noise too (spam, newsletter). - -## Configuration - -To activate the handling of incoming email messages you have to configure the `email.incoming` section in the configuration file. - -The `REPLY_TO_ADDRESS` contains the address an email client will respond to. -This address needs to contain the `%{token}` placeholder which will be replaced with a token describing the user/action. -This placeholder must only appear once in the address and must be in the user part of the address (before the `@`). - -An example using email sub-addressing may look like this: `incoming+%{token}@example.com` - -If a catch-all mailbox is used, the placeholder may be used anywhere in the user part of the address: `incoming+%{token}@example.com`, `incoming_%{token}@example.com`, `%{token}@example.com` - -## Security - -Be careful when choosing the domain used for receiving incoming email. -It's recommended receiving incoming email on a subdomain, such as `incoming.example.com` to prevent potential security problems with other services running on `example.com`. diff --git a/docs/content/doc/usage/incoming-email.zh-cn.md b/docs/content/doc/usage/incoming-email.zh-cn.md deleted file mode 100644 index 335e6aa9e2..0000000000 --- a/docs/content/doc/usage/incoming-email.zh-cn.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "邮件接收" -slug: "incoming-email" -weight: 13 -draft: false -toc: false -aliases: - - /zh-cn/incoming-email -menu: - sidebar: - parent: "usage" - name: "邮件接收" - weight: 13 - identifier: "incoming-email" ---- - -# 邮件接收 - -Gitea 支持通过接收邮件执行多种操作。本页面描述了如何进行设置。 - -**目录** - -{{< toc >}} - -## 要求 - -处理接收的电子邮件需要启用 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` 上的其他服务可能存在的安全问题。 diff --git a/docs/content/doc/usage/issue-pull-request-templates.en-us.md b/docs/content/doc/usage/issue-pull-request-templates.en-us.md deleted file mode 100644 index b48763cf8e..0000000000 --- a/docs/content/doc/usage/issue-pull-request-templates.en-us.md +++ /dev/null @@ -1,309 +0,0 @@ ---- -date: "2018-05-10T16:00:00+02:00" -title: "Issue and Pull Request templates" -slug: "issue-pull-request-templates" -weight: 15 -toc: false -draft: false -aliases: - - /en-us/issue-pull-request-templates -menu: - sidebar: - parent: "usage" - name: "Issue and Pull Request templates" - weight: 15 - identifier: "issue-pull-request-templates" ---- - -# Issue and Pull Request Templates - -**Table of Contents** - -{{< toc >}} - -Some projects have a standard list of questions that users need to answer -when creating an issue or pull request. Gitea supports adding templates to the -main branch of the repository so that they can autopopulate the form when users are -creating issues and pull requests. This will cut down on the initial back and forth -of getting some clarifying details. - -Additionally, the New Issue page URL can be suffixed with `?title=Issue+Title&body=Issue+Text` and the form will be populated with those strings. Those strings will be used instead of the template if there is one. - -## File names - -Possible file names for issue templates: - -- `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` - -Possible file names for issue config: - -- `.gitea/ISSUE_TEMPLATE/config.yaml` -- `.gitea/ISSUE_TEMPLATE/config.yml` -- `.gitea/issue_template/config.yaml` -- `.gitea/issue_template/config.yml` -- `.github/ISSUE_TEMPLATE/config.yaml` -- `.github/ISSUE_TEMPLATE/config.yml` -- `.github/issue_template/config.yaml` -- `.github/issue_template/config.yml` - -Possible file names for PR templates: - -- `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` - -## Directory names - -Alternatively, users can create multiple issue templates inside a special directory and allow users to choose one that more specifically -addresses their problem. - -Possible directory names for issue templates: - -- `ISSUE_TEMPLATE` -- `issue_template` -- `.gitea/ISSUE_TEMPLATE` -- `.gitea/issue_template` -- `.github/ISSUE_TEMPLATE` -- `.github/issue_template` -- `.gitlab/ISSUE_TEMPLATE` -- `.gitlab/issue_template` - -Inside the directory can be multiple markdown (`.md`) or yaml (`.yaml`/`.yml`) issue templates of the form. - -## Syntax for markdown template - -```md ---- - -name: "Template Name" -about: "This template is for testing!" -title: "[TEST] " -ref: "main" -labels: - -- bug -- "help needed" - ---- - -This is the template! -``` - -In the above example, when a user is presented with the list of issues they can submit, this would show as `Template Name` with the description -`This template is for testing!`. When submitting an issue with the above example, the issue title would be pre-populated with -`[TEST] ` while the issue body would be pre-populated with `This is the template!`. The issue would also be assigned two labels, -`bug` and `help needed`, and the issue will have a reference to `main`. - -## Syntax for yaml template - -This example YAML configuration file defines an issue form using several inputs to report a 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 - -You can use a `markdown` element to display Markdown in your form that provides extra context to the user, but is not submitted. - -Attributes: - -| Key | Description | Required | Type | Default | Valid values | -|-------|--------------------------------------------------------------|----------|--------|---------|--------------| -| value | The text that is rendered. Markdown formatting is supported. | Required | String | - | - | - -### Textarea - -You can use a `textarea` element to add a multi-line text field to your form. Contributors can also attach files in `textarea` fields. - -Attributes: - -| Key | Description | Required | Type | Default | Valid values | -|-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------|--------|--------------|---------------------------| -| label | A brief description of the expected user input, which is also displayed in the form. | Required | String | - | - | -| description | A description of the text area to provide context or guidance, which is displayed in the form. | Optional | String | Empty String | - | -| placeholder | A semi-opaque placeholder that renders in the text area when empty. | Optional | String | Empty String | - | -| value | Text that is pre-filled in the text area. | Optional | String | - | - | -| render | If a value is provided, submitted text will be formatted into a codeblock. When this key is provided, the text area will not expand for file attachments or Markdown editing. | Optional | String | - | Languages known to Gitea. | - -Validations: - -| Key | Description | Required | Type | Default | Valid values | -|----------|------------------------------------------------------|----------|---------|---------|--------------| -| required | Prevents form submission until element is completed. | Optional | Boolean | false | - | - -### Input - -You can use an `input` element to add a single-line text field to your form. - -Attributes: - -| Key | Description | Required | Type | Default | Valid values | -|-------------|--------------------------------------------------------------------------------------------|----------|--------|--------------|--------------| -| label | A brief description of the expected user input, which is also displayed in the form. | Required | String | - | - | -| description | A description of the field to provide context or guidance, which is displayed in the form. | Optional | String | Empty String | - | -| placeholder | A semi-transparent placeholder that renders in the field when empty. | Optional | String | Empty String | - | -| value | Text that is pre-filled in the field. | Optional | String | - | - | - -Validations: - -| Key | Description | Required | Type | Default | Valid values | -|-----------|--------------------------------------------------------------------------------------------------|----------|---------|---------|--------------------------------------------------------------------------| -| required | Prevents form submission until element is completed. | Optional | Boolean | false | - | -| is_number | Prevents form submission until element is filled with a number. | Optional | Boolean | false | - | -| regex | Prevents form submission until element is filled with a value that match the regular expression. | Optional | String | - | a [regular expression](https://en.wikipedia.org/wiki/Regular_expression) | - -### Dropdown - -You can use a `dropdown` element to add a dropdown menu in your form. - -Attributes: - -| Key | Description | Required | Type | Default | Valid values | -|-------------|-----------------------------------------------------------------------------------------------------|----------|--------------|--------------|--------------| -| label | A brief description of the expected user input, which is displayed in the form. | Required | String | - | - | -| description | A description of the dropdown to provide extra context or guidance, which is displayed in the form. | Optional | String | Empty String | - | -| multiple | Determines if the user can select more than one option. | Optional | Boolean | false | - | -| options | An array of options the user can choose from. Cannot be empty and all choices must be distinct. | Required | String array | - | - | - -Validations: - -| Key | Description | Required | Type | Default | Valid values | -|----------|------------------------------------------------------|----------|---------|---------|--------------| -| required | Prevents form submission until element is completed. | Optional | Boolean | false | - | - -### Checkboxes - -You can use the `checkboxes` element to add a set of checkboxes to your form. - -Attributes: - -| Key | Description | Required | Type | Default | Valid values | -|-------------|-------------------------------------------------------------------------------------------------------|----------|--------|--------------|--------------| -| label | A brief description of the expected user input, which is displayed in the form. | Required | String | - | - | -| description | A description of the set of checkboxes, which is displayed in the form. Supports Markdown formatting. | Optional | String | Empty String | - | -| options | An array of checkboxes that the user can select. For syntax, see below. | Required | Array | - | - | - -For each value in the options array, you can set the following keys. - -| Key | Description | Required | Type | Default | Options | -|----------|------------------------------------------------------------------------------------------------------------------------------------------|----------|---------|---------|---------| -| label | The identifier for the option, which is displayed in the form. Markdown is supported for bold or italic text formatting, and hyperlinks. | Required | String | - | - | -| required | Prevents form submission until element is completed. | Optional | Boolean | false | - | - -## Syntax for issue config - -This is a example for a issue config file - -```yaml -blank_issues_enabled: true -contact_links: - - name: Gitea - url: https://gitea.io - about: Visit the Gitea Website -``` - -### Possible Options - -| Key | Description | Type | Default | -|----------------------|-------------------------------------------------------------------------------------------------------|--------------------|----------------| -| blank_issues_enabled | If set to false, the User is forced to use a Template | Boolean | true | -| contact_links | Custom Links to show in the Choose Box | Contact Link Array | Empty Array | - -### Contact Link - -| Key | Description | Type | Required | -|----------------------|-------------------------------------------------------------------------------------------------------|---------|----------| -| name | the name of your link | String | true | -| url | The URL of your Link | String | true | -| about | A short description of your Link | String | true | diff --git a/docs/content/doc/usage/issue-pull-request-templates.zh-cn.md b/docs/content/doc/usage/issue-pull-request-templates.zh-cn.md deleted file mode 100644 index fa5b37126f..0000000000 --- a/docs/content/doc/usage/issue-pull-request-templates.zh-cn.md +++ /dev/null @@ -1,298 +0,0 @@ ---- -date: "2022-09-07T16:00:00+08:00" -title: "工单与合并请求模板" -slug: "issue-pull-request-templates" -weight: 15 -toc: true -draft: false -aliases: - - /zh-cn/issue-pull-request-templates -menu: - sidebar: - parent: "usage" - name: "工单与合并请求模板" - weight: 15 - identifier: "issue-pull-request-templates" ---- - -# 从模板创建工单与合并请求 - -开发者可以利用问题模板创建工单与合并请求，其目的在于规范参与者的语言表达。 - -**目录** - -{{< toc >}} - -## 模板介绍 - -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 | - | diff --git a/docs/content/doc/usage/labels.en-us.md b/docs/content/doc/usage/labels.en-us.md deleted file mode 100644 index 8467f7e037..0000000000 --- a/docs/content/doc/usage/labels.en-us.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -date: "2023-03-04T19:00:00+00:00" -title: "Labels" -slug: "labels" -weight: 13 -toc: false -draft: false -aliases: - - /en-us/labels -menu: - sidebar: - parent: "usage" - name: "Labels" - weight: 13 - identifier: "labels" ---- - -# Labels - -You can use labels to classify issues and pull requests and to improve your overview over them. - -## Creating Labels - -For repositories, labels can be created by going to `Issues` and clicking on `Labels`. - -For organizations, you can define organization-wide labels that are shared with all organization repositories, including both already-existing repositories as well as newly created ones. Organization-wide labels can be created in the organization `Settings`. - -Labels have a mandatory name, a mandatory color, an optional description, and must either be exclusive or not (see `Scoped Labels` below). - -When you create a repository, you can ensure certain labels exist by using the `Issue Labels` option. This option lists a number of available label sets that are [configured globally on your instance](../administration/customizing-gitea/#labels). Its contained labels will all be created as well while creating the repository. - -## Scoped Labels - -Scoped labels are used to ensure at most a single label with the same scope is assigned to an issue or pull request. For example, if labels `kind/bug` and `kind/enhancement` have the Exclusive option set, an issue can only be classified as a bug or an enhancement. - -A scoped label must contain `/` in its name (not at either end of the name). The scope of a label is determined based on the **last** `/`, so for example the scope of label `scope/subscope/item` is `scope/subscope`. - -## Filtering by Label - -Issue and pull request lists can be filtered by label. Selecting multiple labels shows issues and pull requests that have all selected labels assigned. - -By holding alt to click the label, issues and pull requests with the chosen label are excluded from the list. diff --git a/docs/content/doc/usage/labels.zh-cn.md b/docs/content/doc/usage/labels.zh-cn.md deleted file mode 100644 index 07dd2bf854..0000000000 --- a/docs/content/doc/usage/labels.zh-cn.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "标签" -slug: "labels" -weight: 13 -toc: false -draft: false -aliases: - - /zh-cn/labels -menu: - sidebar: - parent: "usage" - name: "标签" - weight: 13 - identifier: "labels" ---- - -# 标签 - -您可以使用标签对工单和合并请求进行分类，并提高对它们的概览。 - -## 创建标签 - -对于仓库，可以在 `工单（Issues）` 中点击 `标签（Labels）` 来创建标签。 - -对于组织，您可以定义组织级别的标签，这些标签与所有组织仓库共享，包括已存在的仓库和新创建的仓库。可以在组织的 `设置（Settings）` 中创建组织级别的标签。 - -标签具有必填的名称和颜色，可选的描述，以及必须是独占的或非独占的（见下面的“作用域标签”）。 - -当您创建一个仓库时，可以通过使用 `工单标签（Issue Labels）` 选项来选择标签集。该选项列出了一些在您的实例上 [全局配置的可用标签集](../administration/customizing-gitea/#labels)。在创建仓库时，这些标签也将被创建。 - -## 作用域标签 - -作用域标签用于确保将至多一个具有相同作用域的标签分配给工单或合并请求。例如，如果标签 `kind/bug` 和 `kind/enhancement` 的独占选项被设置，那么工单只能被分类为 bug 或 enhancement 中的一个。 - -作用域标签的名称必须包含 `/`（不能在名称的任一端）。标签的作用域是基于最后一个 `/` 决定的，因此例如标签 `scope/subscope/item` 的作用域是 `scope/subscope`。 - -## 按标签筛选 - -工单和合并请求列表可以按标签进行筛选。选择多个标签将显示具有所有选定标签的工单和合并请求。 - -通过按住 alt 键并单击标签，可以将具有所选标签的工单和合并请求从列表中排除。 diff --git a/docs/content/doc/usage/linked-references.en-us.md b/docs/content/doc/usage/linked-references.en-us.md deleted file mode 100644 index 4e95193015..0000000000 --- a/docs/content/doc/usage/linked-references.en-us.md +++ /dev/null @@ -1,205 +0,0 @@ ---- -date: "2019-11-21T17:00:00-03:00" -title: "Automatically Linked References" -slug: "automatically-linked-references" -weight: 15 -toc: false -draft: false -aliases: - - /en-us/automatically-linked-references -menu: - sidebar: - parent: "usage" - name: "Automatically Linked References" - weight: 15 - identifier: "automatically-linked-references" ---- - -# Automatically Linked References in Issues, Pull Requests and Commit Messages - -**Table of Contents** - -{{< toc >}} - -When an issue, pull request or comment is posted, the text description is parsed -in search for references. These references will be shown as links in the Issue View -and, in some cases, produce certain _actions_. - -Likewise, commit messages are parsed when they are listed, and _actions_ -can be triggered when they are pushed to the main branch. - -To prevent the creation of unintended references, there are certain rules -for them to be recognized. For example, they should not be included inside code -text. They should also be reasonably cleared from their surrounding text -(for example, using spaces). - -## User, Team and Organization Mentions - -When a text in the form `@username` is found and `username` matches the name -of an existing user, a _mention_ reference is created. This will be shown -by changing the text into a link to said user's profile, and possibly create -a notification for the mentioned user depending on whether they have -the necessary permission to access the contents. - -Example: - -> [@John](#), can you give this a look? - -This is also valid for teams and organizations: - -> [@Documenters](#), we need to plan for this. -> [@CoolCompanyInc](#), this issue concerns us all! - -Teams will receive mail notifications when appropriate, but whole organizations won't. - -Commit messages do not produce user notifications. - -## Commits - -Commits can be referenced using their SHA1 hash, or a portion of it of -at least seven characters. They will be shown as a link to the corresponding -commit. - -Example: - -> This bug was introduced in [e59ff077](#) - -## Issues and Pull Requests - -A reference to another issue or pull request can be created using the simple -notation `#1234`, where _1234_ is the number of an issue or pull request -in the same repository. These references will be shown as links to the -referenced content. - -The effect of creating this type of reference is that a _notice_ will be -created in the referenced document, provided the creator of the reference -has reading permissions on it. - -Example: - -> This seems related to [#1234](#) - -Issues and pull requests in other repositories can be referred to as well -using the form `owner/repository#1234`: - -> This seems related to [mike/compiler#1234](#) - -Alternatively, the `!1234` notation can be used as well. Even when in Gitea -a pull request is a form of issue, the `#1234` form will always link to -an issue; if the linked entry happens to be a pull request instead, Gitea -will redirect as appropriate. With the `!1234` notation, a pull request -link will be created, which will be redirected to an issue if required. -However, this distinction could be important if an external tracker is -used, where links to issues and pull requests are not interchangeable. - -## Actionable References in Pull Requests and Commit Messages - -Sometimes a commit or pull request may fix or bring back a problem documented -in a particular issue. Gitea supports closing and reopening the referenced -issues by preceding the reference with a particular _keyword_. Common keywords -include "closes", "fixes", "reopens", etc. This list can be -[customized]({{< ref "doc/administration/config-cheat-sheet.en-us.md" >}}) by the -site administrator. - -Example: - -> This PR _closes_ [#1234](#) - -If the actionable reference is accepted, this will create a notice on the -referenced issue announcing that it will be closed when the referencing PR -is merged. - -For an actionable reference to be accepted, _at least one_ of the following -conditions must be met: - -- The commenter has permissions to close or reopen the issue at the moment - of creating the reference. -- The reference is inside a commit message. -- The reference is posted as part of the pull request description. - -In the last case, the issue will be closed or reopened only if the merger -of the pull request has permissions to do so. - -Additionally, only pull requests and commit messages can create an action, -and only issues can be closed or reopened this way. - -The default _keywords_ are: - -- **Closing**: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved -- **Reopening**: reopen, reopens, reopened - -## Time tracking in Pull Requests and Commit Messages - -When commit or merging of pull request results in automatic closing of issue -it is possible to also add spent time resolving this issue through commit message. - -To specify spent time on resolving issue you need to specify time in format -`@<number><time-unit>` after issue number. In one commit message you can specify -multiple fixed issues and spent time for each of them. - -Supported time units (`<time-unit>`): - -- `m` - minutes -- `h` - hours -- `d` - days (equals to 8 hours) -- `w` - weeks (equals to 5 days) -- `mo` - months (equals to 4 weeks) - -Numbers to specify time (`<number>`) can be also decimal numbers, ex. `@1.5h` would -result in one and half hours. Multiple time units can be combined, ex. `@1h10m` would -mean 1 hour and 10 minutes. - -Example of commit message: - -> Fixed #123 spent @1h, refs #102, fixes #124 @1.5h - -This would result in 1 hour added to issue #123 and 1 and half hours added to issue #124. - -## External Trackers - -Gitea supports the use of external issue trackers, and references to issues -hosted externally can be created in pull requests. However, if the external -tracker uses numbers to identify issues, they will be indistinguishable from -the pull requests hosted in Gitea. To address this, Gitea allows the use of -the `!` marker to identify pull requests. For example: - -> This is issue [#1234](#), and links to the external tracker. -> This is pull request [!1234](#), and links to a pull request in Gitea. - -The `!` and `#` can be used interchangeably for issues and pull request _except_ -for this case, where a distinction is required. If the repository uses external -tracker, commit message for squash merge will use `!` as reference by default. - -## Issues and Pull Requests References Summary - -This table illustrates the different kinds of cross-reference for issues and pull requests. -In the examples, `User1/Repo1` refers to the repository where the reference is used, while -`UserZ/RepoZ` indicates a different repository. - -| Reference in User1/Repo1 | Repo1 issues are external | RepoZ issues are external | Should render | -| --------------------------- | :-----------------------: | :-----------------------: | ------------------------------------------------------- | -| `#1234` | no | - | A link to issue/pull 1234 in `User1/Repo1` | -| `!1234` | no | - | A link to issue/pull 1234 in `User1/Repo1` | -| `#1234` | yes | - | A link to _external issue_ 1234 for `User1/Repo1` | -| `!1234` | yes | - | A link to _PR_ 1234 for `User1/Repo1` | -| `User1/Repo1#1234` | no | - | A link to issue/pull 1234 in `User1/Repo1` | -| `User1/Repo1!1234` | no | - | A link to issue/pull 1234 in `User1/Repo1` | -| `User1/Repo1#1234` | yes | - | A link to _external issue_ 1234 for `User1/Repo1` | -| `User1/Repo1!1234` | yes | - | A link to _PR_ 1234 for `User1/Repo1` | -| `UserZ/RepoZ#1234` | - | no | A link to issue/pull 1234 in `UserZ/RepoZ` | -| `UserZ/RepoZ!1234` | - | no | A link to issue/pull 1234 in `UserZ/RepoZ` | -| `UserZ/RepoZ#1234` | - | yes | A link to _external issue_ 1234 for `UserZ/RepoZ` | -| `UserZ/RepoZ!1234` | - | yes | A link to _PR_ 1234 for `UserZ/RepoZ` | -| **Alphanumeric issue IDs:** | - | - | - | -| `AAA-1234` | yes | - | A link to _external issue_ `AAA-1234` for `User1/Repo1` | -| `!1234` | yes | - | A link to _PR_ 1234 for `User1/Repo1` | -| `User1/Repo1!1234` | yes | - | A link to _PR_ 1234 for `User1/Repo1` | -| _Not supported_ | - | yes | A link to _external issue_ `AAA-1234` for `UserZ/RepoZ` | -| `UserZ/RepoZ!1234` | - | yes | A link to _PR_ 1234 in `UserZ/RepoZ` | - -_The last section is for repositories with external issue trackers that use alphanumeric format._ - -_**-**: not applicable._ - -Note: automatic references between repositories with different types of issues (external vs. internal) are not fully supported -and may render invalid links. diff --git a/docs/content/doc/usage/linked-references.zh-cn.md b/docs/content/doc/usage/linked-references.zh-cn.md deleted file mode 100644 index e565847387..0000000000 --- a/docs/content/doc/usage/linked-references.zh-cn.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "自动链接引用" -slug: "automatically-linked-references" -weight: 15 -toc: false -draft: false -aliases: - - /zh-cn/automatically-linked-references -menu: - sidebar: - parent: "usage" - name: "自动链接引用s" - weight: 15 - identifier: "automatically-linked-references" ---- - -# 在工单、合并请求和提交消息中的自动链接引用 - -**目录** - -{{< toc >}} - -当发布工单、合并请求或评论时，文本描述会被解析以查找引用。这些引用将显示为工单视图中的链接，并且在某些情况下会触发特定的“操作”。 - -类似地，当列出提交消息时，它们也会被解析，并且当它们被推送到主分支时可以触发“操作”。 - -为了防止意外创建引用，对于引用的识别有一定的规则。例如，它们不应该包含在代码文本内部。它们还应该在周围的文本中合理清晰（例如，使用空格）。 - -## 用户、团队和组织提及 - -当找到形式为 `@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”等。这个列表可以由站点管理员进行 [自定义]({{< ref "doc/administration/config-cheat-sheet.zh-cn.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. 内部）的仓库之间的自动引用，可能会导致无效链接。 diff --git a/docs/content/doc/usage/merge-message-templates.en-us.md b/docs/content/doc/usage/merge-message-templates.en-us.md deleted file mode 100644 index 03095a3bbe..0000000000 --- a/docs/content/doc/usage/merge-message-templates.en-us.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -date: "2022-08-31T17:35:40+08:00" -title: "Merge Message templates" -slug: "merge-message-templates" -weight: 15 -toc: false -draft: false -aliases: - - /en-us/merge-message-templates -menu: - sidebar: - parent: "usage" - name: "Merge Message templates" - weight: 15 - identifier: "merge-message-templates" ---- - -# Merge Message templates - -**Table of Contents** - -{{< toc >}} - -## File names - -Possible file names for PR default merge message templates: - -- `.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` - -## Variables - -You can use the following variables enclosed in `${}` inside these templates which follow [os.Expand](https://pkg.go.dev/os#Expand) syntax: - -- BaseRepoOwnerName: Base repository owner name of this pull request -- BaseRepoName: Base repository name of this pull request -- BaseBranch: Base repository target branch name of this pull request -- HeadRepoOwnerName: Head repository owner name of this pull request -- HeadRepoName: Head repository name of this pull request -- HeadBranch: Head repository branch name of this pull request -- PullRequestTitle: Pull request's title -- PullRequestDescription: Pull request's description -- PullRequestPosterName: Pull request's poster name -- PullRequestIndex: Pull request's index number -- PullRequestReference: Pull request's reference char with index number. i.e. #1, !2 -- ClosingIssues: return a string contains all issues which will be closed by this pull request i.e. `close #1, close #2` - -## Rebase - -When rebasing without a merge commit, `REBASE_TEMPLATE.md` modifies the message of the last commit. The following additional variables are available in this template: - -- CommitTitle: Commit's title -- CommitBody: Commits's body text diff --git a/docs/content/doc/usage/merge-message-templates.zh-cn.md b/docs/content/doc/usage/merge-message-templates.zh-cn.md deleted file mode 100644 index 0ec4eee483..0000000000 --- a/docs/content/doc/usage/merge-message-templates.zh-cn.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "合并消息模板" -slug: "merge-message-templates" -weight: 15 -toc: false -draft: false -aliases: - - /zh-cn/merge-message-templates -menu: - sidebar: - parent: "usage" - name: "合并消息模板" - weight: 15 - identifier: "merge-message-templates" ---- - -# 合并消息模板 - -**目录** - -{{< toc >}} - -## 文件名 - -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：提交的正文文本 diff --git a/docs/content/doc/usage/packages/_index.en-us.md b/docs/content/doc/usage/packages/_index.en-us.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/docs/content/doc/usage/packages/_index.en-us.md +++ /dev/null diff --git a/docs/content/doc/usage/packages/alpine.en-us.md b/docs/content/doc/usage/packages/alpine.en-us.md deleted file mode 100644 index f7d2c66586..0000000000 --- a/docs/content/doc/usage/packages/alpine.en-us.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -date: "2023-03-25T00:00:00+00:00" -title: "Alpine Package Registry" -slug: "alpine" -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Alpine" - weight: 4 - identifier: "alpine" ---- - -# Alpine Package Registry - -Publish [Alpine](https://pkgs.alpinelinux.org/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Alpine registry, you need to use a HTTP client like `curl` to upload and a package manager like `apk` to consume packages. - -The following examples use `apk`. - -## Configuring the package registry - -To register the Alpine registry add the url to the list of known apk sources (`/etc/apk/repositories`): - -``` -https://gitea.example.com/api/packages/{owner}/alpine/<branch>/<repository> -``` - -| Placeholder | Description | -| ------------ | ----------- | -| `owner` | The owner of the packages. | -| `branch` | The branch to use. | -| `repository` | The repository to use. | - -If the registry is private, provide credentials in the url. You can use a password or a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}): - -``` -https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/alpine/<branch>/<repository> -``` - -The Alpine registry files are signed with a RSA key which must be known to apk. Download the public key and store it in `/etc/apk/keys/`: - -```shell -curl -JO https://gitea.example.com/api/packages/{owner}/alpine/key -``` - -Afterwards update the local package index: - -```shell -apk update -``` - -## Publish a package - -To publish an Alpine package (`*.apk`), perform a HTTP `PUT` operation with the package content in the request body. - -``` -PUT https://gitea.example.com/api/packages/{owner}/alpine/{branch}/{repository} -``` - -| Parameter | Description | -| ------------ | ----------- | -| `owner` | The owner of the package. | -| `branch` | The branch may match the release version of the OS, ex: `v3.17`. | -| `repository` | The repository can be used [to group packages](https://wiki.alpinelinux.org/wiki/Repositories) or just `main` or similar. | - -Example request using HTTP Basic authentication: - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/file.apk \ - https://gitea.example.com/api/packages/testuser/alpine/v3.17/main -``` - -If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. -You cannot publish a file with the same name twice to a package. You must delete the existing package file first. - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `201 Created` | The package has been published. | -| `400 Bad Request` | The package name, version, branch, repository or architecture are invalid. | -| `409 Conflict` | A package file with the same combination of parameters exist already in the package. | - -## Delete a package - -To delete an Alpine package perform a HTTP `DELETE` operation. This will delete the package version too if there is no file left. - -``` -DELETE https://gitea.example.com/api/packages/{owner}/alpine/{branch}/{repository}/{architecture}/{filename} -``` - -| Parameter | Description | -| -------------- | ----------- | -| `owner` | The owner of the package. | -| `branch` | The branch to use. | -| `repository` | The repository to use. | -| `architecture` | The package architecture. | -| `filename` | The file to delete. - -Example request using HTTP Basic authentication: - -```shell -curl --user your_username:your_token_or_password -X DELETE \ - https://gitea.example.com/api/packages/testuser/alpine/v3.17/main/test-package-1.0.0.apk -``` - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `204 No Content` | Success | -| `404 Not Found` | The package or file was not found. | - -## Install a package - -To install a package from the Alpine registry, execute the following commands: - -```shell -# use latest version -apk add {package_name} -# use specific version -apk add {package_name}={package_version} -``` diff --git a/docs/content/doc/usage/packages/alpine.zh-cn.md b/docs/content/doc/usage/packages/alpine.zh-cn.md deleted file mode 100644 index fd9470525d..0000000000 --- a/docs/content/doc/usage/packages/alpine.zh-cn.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -date: "2023-03-25T00:00:00+00:00" -title: "Alpine 软件包注册表" -slug: "alpine" -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Alpine" - weight: 4 - identifier: "alpine" ---- - -# Alpine 软件包注册表 - -在您的用户或组织中发布 [Alpine](https://pkgs.alpinelinux.org/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 Alpine 注册表，您需要使用像 curl 这样的 HTTP 客户端来上传包，并使用像 apk 这样的包管理器来消费包。 - -以下示例使用 `apk`。 - -## 配置软件包注册表 - -要注册 Alpine 注册表，请将 URL 添加到已知的 apk 源列表中 (`/etc/apk/repositories`): - -``` -https://gitea.example.com/api/packages/{owner}/alpine/<branch>/<repository> -``` - -| 占位符 | 描述 | -| ------------ | -------------- | -| `owner` | 软件包所有者 | -| `branch` | 要使用的分支名 | -| `repository` | 要使用的仓库名 | - -如果注册表是私有的，请在 URL 中提供凭据。您可以使用密码或[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.md#通过-api-认证" >}}): - -``` -https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/alpine/<branch>/<repository> -``` - -Alpine 注册表文件使用 RSA 密钥进行签名，apk 必须知道该密钥。下载公钥并将其存储在 `/etc/apk/keys/` 目录中： - -```shell -curl -JO https://gitea.example.com/api/packages/{owner}/alpine/key -``` - -之后，更新本地软件包索引： - -```shell -apk update -``` - -## 发布软件包 - -要发布一个 Alpine 包（`*.apk`），请执行带有包内容的 HTTP `PUT` 操作，将其放在请求体中。 - -``` -PUT https://gitea.example.com/api/packages/{owner}/alpine/{branch}/{repository} -``` - -| 参数 | 描述 | -| ------------ | --------------------------------------------------------------------------------------------------- | -| `owner` | 包的所有者。 | -| `branch` | 分支可以与操作系统的发行版本匹配，例如：v3.17。 | -| `repository` | 仓库可以用于[分组包](https://wiki.alpinelinux.org/wiki/Repositories) 或者只是 `main` 或类似的名称。 | - -使用 HTTP 基本身份验证的示例请求： - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/file.apk \ - https://gitea.example.com/api/packages/testuser/alpine/v3.17/main -``` - -如果您使用的是双重身份验证或 OAuth，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.md#authentication" >}})代替密码。 -您不能将具有相同名称的文件两次发布到一个包中。您必须首先删除现有的包文件。 - -服务器将以以下的 HTTP 状态码响应： - -| HTTP 状态码 | 含义 | -| ----------------- | ------------------------------------------ | -| `201 Created` | 软件包已发布。 | -| `400 Bad Request` | 软件包的名称、版本、分支、仓库或架构无效。 | -| `409 Conflict` | 具有相同参数组合的包文件已存在于软件包中。 | - -## 删除软件包 - -要删除 Alpine 包，执行 HTTP 的 DELETE 操作。如果没有文件，这将同时删除包版本。 - -``` -DELETE https://gitea.example.com/api/packages/{owner}/alpine/{branch}/{repository}/{architecture}/{filename} -``` - -| 参数 | 描述 | -| -------------- | -------------- | -| `owner` | 软件包的所有者 | -| `branch` | 要使用的分支名 | -| `repository` | 要使用的仓库名 | -| `architecture` | 软件包的架构 | -| `filename` | 要删除的文件名 | - -使用 HTTP 基本身份验证的示例请求： - -```shell -curl --user your_username:your_token_or_password -X DELETE \ - https://gitea.example.com/api/packages/testuser/alpine/v3.17/main/test-package-1.0.0.apk -``` - -服务器将以以下的 HTTP 状态码响应： - -| HTTP 状态码 | 含义 | -| ---------------- | ------------------ | -| `204 No Content` | 成功 | -| `404 Not Found` | 未找到软件包或文件 | - -## 安装软件包 - -要从 Alpine 注册表安装软件包，请执行以下命令： - -```shell -# use latest version -apk add {package_name} -# use specific version -apk add {package_name}={package_version} -``` diff --git a/docs/content/doc/usage/packages/cargo.en-us.md b/docs/content/doc/usage/packages/cargo.en-us.md deleted file mode 100644 index d341eb9f83..0000000000 --- a/docs/content/doc/usage/packages/cargo.en-us.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -date: "2022-11-20T00:00:00+00:00" -title: "Cargo Package Registry" -slug: "cargo" -weight: 5 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Cargo" - weight: 5 - identifier: "cargo" ---- - -# Cargo Package Registry - -Publish [Cargo](https://doc.rust-lang.org/stable/cargo/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Cargo package registry, you need [Rust and Cargo](https://www.rust-lang.org/tools/install). - -Cargo stores information about the available packages in a package index stored in a git repository. -This repository is needed to work with the registry. -The following section describes how to create it. - -## Index Repository - -Cargo stores information about the available packages in a package index stored in a git repository. -In Gitea this repository has the special name `_cargo-index`. -After a package was uploaded, its metadata is automatically written to the index. -The content of this repository should not be manually modified. - -The user or organization package settings page allows to create the index repository along with the configuration file. -If needed this action will rewrite the configuration file. -This can be useful if for example the Gitea instance domain was changed. - -If the case arises where the packages stored in Gitea and the information in the index repository are out of sync, the settings page allows to rebuild the index repository. -This action iterates all packages in the registry and writes their information to the index. -If there are lot of packages this process may take some time. - -## Configuring the package registry - -To register the package registry the Cargo configuration must be updated. -Add the following text to the configuration file located in the current users home directory (for example `~/.cargo/config.toml`): - -``` -[registry] -default = "gitea" - -[registries.gitea] -index = "https://gitea.example.com/{owner}/_cargo-index.git" - -[net] -git-fetch-with-cli = true -``` - -| Parameter | Description | -| --------- | ----------- | -| `owner` | The owner of the package. | - -If the registry is private or you want to publish new packages, you have to configure your credentials. -Add the credentials section to the credentials file located in the current users home directory (for example `~/.cargo/credentials.toml`): - -``` -[registries.gitea] -token = "Bearer {token}" -``` - -| Parameter | Description | -| --------- | ----------- | -| `token` | Your [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) | - -## Publish a package - -Publish a package by running the following command in your project: - -```shell -cargo publish -``` - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Install a package - -To install a package from the package registry, execute the following command: - -```shell -cargo add {package_name} -``` - -| Parameter | Description | -| -------------- | ----------- | -| `package_name` | The package name. | - -## Supported commands - -``` -cargo publish -cargo add -cargo install -cargo yank -cargo unyank -cargo search -``` diff --git a/docs/content/doc/usage/packages/cargo.zh-cn.md b/docs/content/doc/usage/packages/cargo.zh-cn.md deleted file mode 100644 index 2d451716d1..0000000000 --- a/docs/content/doc/usage/packages/cargo.zh-cn.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -date: "2022-11-20T00:00:00+00:00" -title: "Cargo 软件包注册表" -slug: "cargo" -weight: 5 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Cargo" - weight: 5 - identifier: "cargo" ---- - -# Cargo 软件包注册表 - -为您的用户或组织发布 [Cargo](https://doc.rust-lang.org/stable/cargo/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -若要使用 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` | 您的[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.md#通过-api-认证" >}}) | - -## 发布软件包 - -在项目中运行以下命令来发布软件包： - -```shell -cargo publish -``` - -如果已经存在同名和版本的软件包，您将无法发布新的软件包。您必须先删除现有的软件包。 - -## 安装软件包 - -要从软件包注册表安装软件包，请执行以下命令： - -```shell -cargo add {package_name} -``` - -| 参数 | 描述 | -| -------------- | ------------ | -| `package_name` | 软件包名称。 | - -## 支持的命令 - -``` -cargo publish -cargo add -cargo install -cargo yank -cargo unyank -cargo search -``` diff --git a/docs/content/doc/usage/packages/chef.en-us.md b/docs/content/doc/usage/packages/chef.en-us.md deleted file mode 100644 index ee77957551..0000000000 --- a/docs/content/doc/usage/packages/chef.en-us.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -date: "2023-01-20T00:00:00+00:00" -title: "Chef Package Registry" -slug: "chef" -weight: 5 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Chef" - weight: 5 - identifier: "chef" ---- - -# Chef Package Registry - -Publish [Chef](https://chef.io/) cookbooks for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Chef package registry, you have to use [`knife`](https://docs.chef.io/workstation/knife/). - -## Authentication - -The Chef package registry does not use an username:password authentication but signed requests with a private:public key pair. -Visit the package owner settings page to create the necessary key pair. -Only the public key is stored inside Gitea. if you loose access to the private key you must re-generate the key pair. -[Configure `knife`](https://docs.chef.io/workstation/knife_setup/) to use the downloaded private key with your Gitea username as `client_name`. - -## Configure the package registry - -To [configure `knife`](https://docs.chef.io/workstation/knife_setup/) to use the Gitea package registry add the url to the `~/.chef/config.rb` file. - -``` -knife[:supermarket_site] = 'https://gitea.example.com/api/packages/{owner}/chef' -``` - -| Parameter | Description | -| --------- | ----------- | -| `owner` | The owner of the package. | - -## Publish a package - -To publish a Chef package execute the following command: - -```shell -knife supermarket share {package_name} -``` - -| Parameter | Description | -| -------------- | ----------- | -| `package_name` | The package name. | - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Install a package - -To install a package from the package registry, execute the following command: - -```shell -knife supermarket install {package_name} -``` - -Optional you can specify the package version: - -```shell -knife supermarket install {package_name} {package_version} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `package_name` | The package name. | -| `package_version` | The package version. | - -## Delete a package - -If you want to remove a package from the registry, execute the following command: - -```shell -knife supermarket unshare {package_name} -``` - -Optional you can specify the package version: - -```shell -knife supermarket unshare {package_name}/versions/{package_version} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `package_name` | The package name. | -| `package_version` | The package version. | diff --git a/docs/content/doc/usage/packages/chef.zh-cn.md b/docs/content/doc/usage/packages/chef.zh-cn.md deleted file mode 100644 index 939c94b429..0000000000 --- a/docs/content/doc/usage/packages/chef.zh-cn.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -date: "2023-01-20T00:00:00+00:00" -title: "Chef 软件包注册表" -slug: "chef" -weight: 5 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Chef" - weight: 5 - identifier: "chef" ---- - -# Chef Package Registry - -为您的用户或组织发布 [Chef](https://chef.io/) cookbooks。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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` | 软件包版本 | diff --git a/docs/content/doc/usage/packages/composer.en-us.md b/docs/content/doc/usage/packages/composer.en-us.md deleted file mode 100644 index 092518c9f0..0000000000 --- a/docs/content/doc/usage/packages/composer.en-us.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "Composer Package Registry" -slug: "composer" -weight: 10 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Composer" - weight: 10 - identifier: "composer" ---- - -# Composer Package Registry - -Publish [Composer](https://getcomposer.org/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Composer package registry, you can use [Composer](https://getcomposer.org/download/) to consume and a HTTP upload client like `curl` to publish packages. - -## Publish a package - -To publish a Composer package perform a HTTP PUT operation with the package content in the request body. -The package content must be the zipped PHP project with the `composer.json` file. -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -``` -PUT https://gitea.example.com/api/packages/{owner}/composer -``` - -| Parameter | Description | -| ---------- | ----------- | -| `owner` | The owner of the package. | - -If the `composer.json` file does not contain a `version` property, you must provide it as a query parameter: - -``` -PUT https://gitea.example.com/api/packages/{owner}/composer?version={x.y.z} -``` - -Example request using HTTP Basic authentication: - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/project.zip \ - https://gitea.example.com/api/packages/testuser/composer -``` - -Or specify the package version as query parameter: - -```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 -``` - -If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `201 Created` | The package has been published. | -| `400 Bad Request` | The package name and/or version are invalid or a package with the same name and version already exist. | - -## Configuring the package registry - -To register the package registry you need to add it to the Composer `config.json` file (which can usually be found under `<user-home-dir>/.composer/config.json`): - -```json -{ - "repositories": [{ - "type": "composer", - "url": "https://gitea.example.com/api/packages/{owner}/composer" - } - ] -} -``` - -To access the package registry using credentials, you must specify them in the `auth.json` file as follows: - -```json -{ - "http-basic": { - "gitea.example.com": { - "username": "{username}", - "password": "{password}" - } - } -} -``` - -| Parameter | Description | -| ---------- | ----------- | -| `owner` | The owner of the package. | -| `username` | Your Gitea username. | -| `password` | Your Gitea password or a personal access token. | - -## Install a package - -To install a package from the package registry, execute the following command: - -```shell -composer require {package_name} -``` - -Optional you can specify the package version: - -```shell -composer require {package_name}:{package_version} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `package_name` | The package name. | -| `package_version` | The package version. | diff --git a/docs/content/doc/usage/packages/composer.zh-cn.md b/docs/content/doc/usage/packages/composer.zh-cn.md deleted file mode 100644 index de19f71305..0000000000 --- a/docs/content/doc/usage/packages/composer.zh-cn.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "Composer 软件包注册表" -slug: "composer" -weight: 10 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Composer" - weight: 10 - identifier: "composer" ---- - -# Composer 软件包注册表 - -为您的用户或组织发布 [Composer](https://getcomposer.org/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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` | 软件包版本 | diff --git a/docs/content/doc/usage/packages/conan.en-us.md b/docs/content/doc/usage/packages/conan.en-us.md deleted file mode 100644 index 5ca3ca7a26..0000000000 --- a/docs/content/doc/usage/packages/conan.en-us.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "Conan Package Registry" -slug: "conan" -weight: 20 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Conan" - weight: 20 - identifier: "conan" ---- - -# Conan Package Registry - -Publish [Conan](https://conan.io/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Conan package registry, you need to use the [conan](https://conan.io/downloads.html) command line tool to consume and publish packages. - -## Configuring the package registry - -To register the package registry you need to configure a new Conan remote: - -```shell -conan remote add {remote} https://gitea.example.com/api/packages/{owner}/conan -conan user --remote {remote} --password {password} {username} -``` - -| Parameter | Description | -| -----------| ----------- | -| `remote` | The remote name. | -| `username` | Your Gitea username. | -| `password` | Your Gitea password. If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. | -| `owner` | The owner of the package. | - -For example: - -```shell -conan remote add gitea https://gitea.example.com/api/packages/testuser/conan -conan user --remote gitea --password password123 testuser -``` - -## Publish a package - -Publish a Conan package by running the following command: - -```shell -conan upload --remote={remote} {recipe} -``` - -| Parameter | Description | -| ----------| ----------- | -| `remote` | The remote name. | -| `recipe` | The recipe to upload. | - -For example: - -```shell -conan upload --remote=gitea ConanPackage/1.2@gitea/final -``` - -The Gitea Conan package registry has full [revision](https://docs.conan.io/en/latest/versioning/revisions.html) support. - -## Install a package - -To install a Conan package from the package registry, execute the following command: - -```shell -conan install --remote={remote} {recipe} -``` - -| Parameter | Description | -| ----------| ----------- | -| `remote` | The remote name. | -| `recipe` | The recipe to download. | - -For example: - -```shell -conan install --remote=gitea ConanPackage/1.2@gitea/final -``` - -## Supported commands - -``` -conan install -conan get -conan info -conan search -conan upload -conan user -conan download -conan remove -``` diff --git a/docs/content/doc/usage/packages/conan.zh-cn.md b/docs/content/doc/usage/packages/conan.zh-cn.md deleted file mode 100644 index 3d3aa8a298..0000000000 --- a/docs/content/doc/usage/packages/conan.zh-cn.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "Conan 软件包注册表" -slug: "conan" -weight: 20 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Conan" - weight: 20 - identifier: "conan" ---- - -# Conan 软件包注册表 - -为您的用户或组织发布 [Conan](https://conan.io/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 [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，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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 -``` diff --git a/docs/content/doc/usage/packages/conda.en-us.md b/docs/content/doc/usage/packages/conda.en-us.md deleted file mode 100644 index 6178b6237d..0000000000 --- a/docs/content/doc/usage/packages/conda.en-us.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -date: "2022-12-28T00:00:00+00:00" -title: "Conda Package Registry" -slug: "conda" -weight: 25 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Conda" - weight: 25 - identifier: "conda" ---- - -# Conda Package Registry - -Publish [Conda](https://docs.conda.io/en/latest/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Conda package registry, you need to use [conda](https://docs.conda.io/projects/conda/en/stable/user-guide/install/index.html). - -## Configuring the package registry - -To register the package registry and provide credentials, edit your `.condarc` file: - -```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 -``` - -| Placeholder | Description | -| ------------ | ----------- | -| `owner` | The owner of the package. | - -See the [official documentation](https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html) for explanations of the individual settings. - -If you need to provide credentials, you may embed them as part of the channel url (`https://user:password@gitea.example.com/...`). - -## Publish a package - -To publish a package, perform a HTTP PUT operation with the package content in the request body. - -``` -PUT https://gitea.example.com/api/packages/{owner}/conda/{channel}/{filename} -``` - -| Placeholder | Description | -| ------------ | ----------- | -| `owner` | The owner of the package. | -| `channel` | The [channel](https://conda.io/projects/conda/en/latest/user-guide/concepts/channels.html) of the package. (optional) | -| `filename` | The name of the file. | - -Example request using HTTP Basic authentication: - -```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 -``` - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Install a package - -To install a package from the package registry, execute one of the following commands: - -```shell -conda install {package_name} -conda install {package_name}={package_version} -conda install -c {channel} {package_name} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `package_name` | The package name. | -| `package_version` | The package version. | -| `channel` | The channel of the package. (optional) | diff --git a/docs/content/doc/usage/packages/conda.zh-cn.md b/docs/content/doc/usage/packages/conda.zh-cn.md deleted file mode 100644 index 721c2761ca..0000000000 --- a/docs/content/doc/usage/packages/conda.zh-cn.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -date: "2022-12-28T00:00:00+00:00" -title: "Conda 软件包注册表" -slug: "conda" -weight: 25 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Conda" - weight: 25 - identifier: "conda" ---- - -# Conda 软件包注册表 - -为您的用户或组织发布 [Conda](https://docs.conda.io/en/latest/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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` | 软件包的通道（可选） | diff --git a/docs/content/doc/usage/packages/container.en-us.md b/docs/content/doc/usage/packages/container.en-us.md deleted file mode 100644 index 457e6fb1a4..0000000000 --- a/docs/content/doc/usage/packages/container.en-us.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "Container Registry" -slug: "container" -weight: 30 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Container Registry" - weight: 30 - identifier: "container" ---- - -# Container Registry - -Publish [Open Container Initiative](https://opencontainers.org/) compliant images for your user or organization. -The container registry follows the OCI specs and supports all compatible images like [Docker](https://www.docker.com/) and [Helm Charts](https://helm.sh/). - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Container registry, you can use the tools for your specific image type. -The following examples use the `docker` client. - -## Login to the container registry - -To push an image or if the image is in a private registry, you have to authenticate: - -```shell -docker login gitea.example.com -``` - -If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. - -## Image naming convention - -Images must follow this naming convention: - -`{registry}/{owner}/{image}` - -For example, these are all valid image names for the owner `testuser`: - -`gitea.example.com/testuser/myimage` - -`gitea.example.com/testuser/my-image` - -`gitea.example.com/testuser/my/image` - -**NOTE:** The registry only supports case-insensitive tag names. So `image:tag` and `image:Tag` get treated as the same image and tag. - -## Push an image - -Push an image by executing the following command: - -```shell -docker push gitea.example.com/{owner}/{image}:{tag} -``` - -| Parameter | Description | -| ----------| ----------- | -| `owner` | The owner of the image. | -| `image` | The name of the image. | -| `tag` | The tag of the image. | - -For example: - -```shell -docker push gitea.example.com/testuser/myimage:latest -``` - -## Pull an image - -Pull an image by executing the following command: - -```shell -docker pull gitea.example.com/{owner}/{image}:{tag} -``` - -| Parameter | Description | -| ----------| ----------- | -| `owner` | The owner of the image. | -| `image` | The name of the image. | -| `tag` | The tag of the image. | - -For example: - -```shell -docker pull gitea.example.com/testuser/myimage:latest -``` diff --git a/docs/content/doc/usage/packages/container.zh-cn.md b/docs/content/doc/usage/packages/container.zh-cn.md deleted file mode 100644 index d441a81078..0000000000 --- a/docs/content/doc/usage/packages/container.zh-cn.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "容器注册表" -slug: "container" -weight: 30 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "容器" - weight: 30 - identifier: "container" ---- - -# 容器注册表 - -为您的用户或组织发布符合 [Open Container Initiative(OCI)](https://opencontainers.org/) 规范的镜像。 -该容器注册表遵循 OCI 规范，并支持所有兼容的镜像类型，如 [Docker](https://www.docker.com/) 和 [Helm Charts](https://helm.sh/)。 - -**目录** - -{{< toc >}} - -## 目录 - -要使用容器注册表，您可以使用适用于特定镜像类型的工具。 -以下示例使用 `docker` 客户端。 - -## 登录容器注册表 - -要推送镜像或者如果镜像位于私有注册表中，您需要进行身份验证： - -```shell -docker login gitea.example.com -``` - -如果您使用的是 2FA 或 OAuth，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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 -``` diff --git a/docs/content/doc/usage/packages/cran.en-us.md b/docs/content/doc/usage/packages/cran.en-us.md deleted file mode 100644 index fafe49429b..0000000000 --- a/docs/content/doc/usage/packages/cran.en-us.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -date: "2023-01-01T00:00:00+00:00" -title: "CRAN Package Registry" -slug: "cran" -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "CRAN" - weight: 35 - identifier: "cran" ---- - -# CRAN Package Registry - -Publish [R](https://www.r-project.org/) packages to a [CRAN](https://cran.r-project.org/)-like registry for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the CRAN package registry, you need to install [R](https://cran.r-project.org/). - -## Configuring the package registry - -To register the package registry you need to add it to `Rprofile.site`, either on the system-level, user-level (`~/.Rprofile`) or project-level: - -``` -options("repos" = c(getOption("repos"), c(gitea="https://gitea.example.com/api/packages/{owner}/cran"))) -``` - -| Parameter | Description | -| --------- | ----------- | -| `owner` | The owner of the package. | - -If you need to provide credentials, you may embed them as part of the url (`https://user:password@gitea.example.com/...`). - -## Publish a package - -To publish a R package, perform a HTTP `PUT` operation with the package content in the request body. - -Source packages: - -``` -PUT https://gitea.example.com/api/packages/{owner}/cran/src -``` - -| Parameter | Description | -| --------- | ----------- | -| `owner` | The owner of the package. | - -Binary packages: - -``` -PUT https://gitea.example.com/api/packages/{owner}/cran/bin?platform={platform}&rversion={rversion} -``` - -| Parameter | Description | -| ---------- | ----------- | -| `owner` | The owner of the package. | -| `platform` | The name of the platform. | -| `rversion` | The R version of the binary. | - -For example: - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/package.zip \ - https://gitea.example.com/api/packages/testuser/cran/bin?platform=windows&rversion=4.2 -``` - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Install a package - -To install a R package from the package registry, execute the following command: - -```shell -install.packages("{package_name}") -``` - -| Parameter | Description | -| -------------- | ----------- | -| `package_name` | The package name. | - -For example: - -```shell -install.packages("testpackage") -``` diff --git a/docs/content/doc/usage/packages/cran.zh-cn.md b/docs/content/doc/usage/packages/cran.zh-cn.md deleted file mode 100644 index fec9a56feb..0000000000 --- a/docs/content/doc/usage/packages/cran.zh-cn.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -date: "2023-01-01T00:00:00+00:00" -title: "CRAN 软件包注册表" -slug: "cran" -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "CRAN" - weight: 35 - identifier: "cran" ---- - -# CRAN 软件包注册表 - -将 [R](https://www.r-project.org/) 软件包发布到您的用户或组织的类似 [CRAN](https://cran.r-project.org/) 的注册表。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用CRAN软件包注册表，您需要安装 [R](https://cran.r-project.org/)。 - -## 配置软件包注册表 - -要注册软件包注册表，您需要将其添加到 `Rprofile.site` 文件中，可以是系统级别、用户级别 `~/.Rprofile` 或项目级别： - -``` -options("repos" = c(getOption("repos"), c(gitea="https://gitea.example.com/api/packages/{owner}/cran"))) -``` - -| 参数 | 描述 | -| ------- | -------------- | -| `owner` | 软件包的所有者 | - -如果需要提供凭据，可以将它们嵌入到URL(`https://user:password@gitea.example.com/...`)中。 - -## 发布软件包 - -要发布 R 软件包，请执行带有软件包内容的 HTTP `PUT` 操作。 - -源代码软件包： - -``` -PUT https://gitea.example.com/api/packages/{owner}/cran/src -``` - -| 参数 | 描述 | -| ------- | -------------- | -| `owner` | 软件包的所有者 | - -二进制软件包： - -``` -PUT https://gitea.example.com/api/packages/{owner}/cran/bin?platform={platform}&rversion={rversion} -``` - -| 参数 | 描述 | -| ---------- | -------------- | -| `owner` | 软件包的所有者 | -| `platform` | 平台的名称 | -| `rversion` | 二进制的R版本 | - -例如： - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/package.zip \ - https://gitea.example.com/api/packages/testuser/cran/bin?platform=windows&rversion=4.2 -``` - -如果同名和版本的软件包已存在，则无法发布软件包。您必须首先删除现有的软件包。 - -## 安装软件包 - -要从软件包注册表中安装R软件包，请执行以下命令： - -```shell -install.packages("{package_name}") -``` - -| 参数 | 描述 | -| -------------- | ----------------- | -| `package_name` | The package name. | - -例如： - -```shell -install.packages("testpackage") -``` diff --git a/docs/content/doc/usage/packages/debian.en-us.md b/docs/content/doc/usage/packages/debian.en-us.md deleted file mode 100644 index 239fd8c174..0000000000 --- a/docs/content/doc/usage/packages/debian.en-us.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -date: "2023-01-07T00:00:00+00:00" -title: "Debian Package Registry" -slug: "debian" -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Debian" - weight: 35 - identifier: "debian" ---- - -# Debian Package Registry - -Publish [Debian](https://www.debian.org/distrib/packages) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Debian registry, you need to use a HTTP client like `curl` to upload and a package manager like `apt` to consume packages. - -The following examples use `apt`. - -## Configuring the package registry - -To register the Debian registry add the url to the list of known apt sources: - -```shell -echo "deb https://gitea.example.com/api/packages/{owner}/debian {distribution} {component}" | sudo tee -a /etc/apt/sources.list.d/gitea.list -``` - -| Placeholder | Description | -| -------------- | ----------- | -| `owner` | The owner of the package. | -| `distribution` | The distribution to use. | -| `component` | The component to use. | - -If the registry is private, provide credentials in the url. You can use a password or a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}): - -```shell -echo "deb https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/debian {distribution} {component}" | sudo tee -a /etc/apt/sources.list.d/gitea.list -``` - -The Debian registry files are signed with a PGP key which must be known to apt: - -```shell -sudo curl https://gitea.example.com/api/packages/{owner}/debian/repository.key -o /etc/apt/trusted.gpg.d/gitea-{owner}.asc -``` - -Afterwards update the local package index: - -```shell -apt update -``` - -## Publish a package - -To publish a Debian package (`*.deb`), perform a HTTP `PUT` operation with the package content in the request body. - -``` -PUT https://gitea.example.com/api/packages/{owner}/debian/pool/{distribution}/{component}/upload -``` - -| Parameter | Description | -| -------------- | ----------- | -| `owner` | The owner of the package. | -| `distribution` | The distribution may match the release name of the OS, ex: `bionic`. | -| `component` | The component can be used to group packages or just `main` or similar. | - -Example request using HTTP Basic authentication: - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/file.deb \ - https://gitea.example.com/api/packages/testuser/debian/pool/bionic/main/upload -``` - -If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. -You cannot publish a file with the same name twice to a package. You must delete the existing package version first. - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `201 Created` | The package has been published. | -| `400 Bad Request` | The package name, version, distribution, component or architecture are invalid. | -| `409 Conflict` | A package file with the same combination of parameters exists already. | - -## Delete a package - -To delete a Debian package perform a HTTP `DELETE` operation. This will delete the package version too if there is no file left. - -``` -DELETE https://gitea.example.com/api/packages/{owner}/debian/pool/{distribution}/{component}/{package_name}/{package_version}/{architecture} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | -| `package_version` | The package version. | -| `distribution` | The package distribution. | -| `component` | The package component. | -| `architecture` | The package architecture. | - -Example request using HTTP Basic authentication: - -```shell -curl --user your_username:your_token_or_password -X DELETE \ - https://gitea.example.com/api/packages/testuser/debian/pools/bionic/main/test-package/1.0.0/amd64 -``` - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `204 No Content` | Success | -| `404 Not Found` | The package or file was not found. | - -## Install a package - -To install a package from the Debian registry, execute the following commands: - -```shell -# use latest version -apt install {package_name} -# use specific version -apt install {package_name}={package_version} -``` diff --git a/docs/content/doc/usage/packages/debian.zh-cn.md b/docs/content/doc/usage/packages/debian.zh-cn.md deleted file mode 100644 index 57b8a9e4ae..0000000000 --- a/docs/content/doc/usage/packages/debian.zh-cn.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -date: "2023-01-07T00:00:00+00:00" -title: "Debian 软件包注册表" -slug: "debian" -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Debian" - weight: 35 - identifier: "debian" ---- - -# Debian 软件包注册表 - -为您的用户或组织发布 [Debian](https://www.debian.org/distrib/packages) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 Debian 注册表，您需要使用类似于 `curl` 的 HTTP 客户端进行上传，并使用类似于 `apt` 的软件包管理器消费软件包。 - -以下示例使用 `apt`。 - -## 配置软件包注册表 - -要注册 Debian 注册表，请将 URL 添加到已知 `apt` 源列表中： - -```shell -echo "deb https://gitea.example.com/api/packages/{owner}/debian {distribution} {component}" | sudo tee -a /etc/apt/sources.list.d/gitea.list -``` - -| 占位符 | 描述 | -| -------------- | -------------- | -| `owner` | 软件包的所有者 | -| `distribution` | 要使用的发行版 | -| `component` | 要使用的组件 | - -如果注册表是私有的，请在 URL 中提供凭据。您可以使用密码或[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.md#通过-api-认证" >}})： - -```shell -echo "deb https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/debian {distribution} {component}" | sudo tee -a /etc/apt/sources.list.d/gitea.list -``` - -Debian 注册表文件使用 PGP 密钥进行签名，`apt` 必须知道该密钥： - -```shell -sudo curl https://gitea.example.com/api/packages/{owner}/debian/repository.key -o /etc/apt/trusted.gpg.d/gitea-{owner}.asc -``` - -然后更新本地软件包索引： - -```shell -apt update -``` - -## 发布软件包 - -要发布一个 Debian 软件包（`*.deb`），执行 HTTP `PUT` 操作，并将软件包内容放入请求主体中。 - -``` -PUT https://gitea.example.com/api/packages/{owner}/debian/pool/{distribution}/{component}/upload -``` - -| 参数 | 描述 | -| -------------- | ----------------------------------------------------- | -| `owner` | 软件包的所有者 | -| `distribution` | 发行版，可能与操作系统的发行版名称匹配，例如 `bionic` | -| `component` | 组件，可用于分组软件包，或仅为 `main` 或类似的组件。 | - -使用 HTTP 基本身份验证的示例请求： - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/file.deb \ - https://gitea.example.com/api/packages/testuser/debian/pool/bionic/main/upload -``` - -如果您使用 2FA 或 OAuth，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.md#通过-api-认证" >}})替代密码。 -您无法向软件包中多次发布具有相同名称的文件。您必须首先删除现有的软件包版本。 - -服务器将使用以下 HTTP 状态代码进行响应。 - -| HTTP 状态码 | 意义 | -| ----------------- | ---------------------------------------- | -| `201 Created` | 软件包已发布 | -| `400 Bad Request` | 软件包名称、版本、发行版、组件或架构无效 | -| `409 Conflict` | 具有相同参数组合的软件包文件已经存在 | - -## 删除软件包 - -要删除 Debian 软件包，请执行 HTTP `DELETE` 操作。如果没有文件留下，这将同时删除软件包版本。 - -``` -DELETE https://gitea.example.com/api/packages/{owner}/debian/pool/{distribution}/{component}/{package_name}/{package_version}/{architecture} -``` - -| 参数 | 描述 | -| ----------------- | -------------- | -| `owner` | 软件包的所有者 | -| `package_name` | 软件包名称 | -| `package_version` | 软件包版本 | -| `distribution` | 软件包发行版 | -| `component` | 软件包组件 | -| `architecture` | 软件包架构 | - -使用 HTTP 基本身份验证的示例请求： - -```shell -curl --user your_username:your_token_or_password -X DELETE \ - https://gitea.example.com/api/packages/testuser/debian/pools/bionic/main/test-package/1.0.0/amd64 -``` - -服务器将使用以下 HTTP 状态代码进行响应。 - -| HTTP 状态码 | 含义 | -| ---------------- | ------------------ | -| `204 No Content` | 成功 | -| `404 Not Found` | 找不到软件包或文件 | - -## 安装软件包 - -要从 Debian 注册表安装软件包，请执行以下命令: - -```shell -# use latest version -apt install {package_name} -# use specific version -apt install {package_name}={package_version} -``` diff --git a/docs/content/doc/usage/packages/generic.en-us.md b/docs/content/doc/usage/packages/generic.en-us.md deleted file mode 100644 index 9ff8930722..0000000000 --- a/docs/content/doc/usage/packages/generic.en-us.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "Generic Package Registry" -slug: "generic" -weight: 40 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Generic" - weight: 40 - identifier: "generic" ---- - -# Generic Package Registry - -Publish generic files, like release binaries or other output, for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Authenticate to the package registry - -To authenticate to the Package Registry, you need to provide [custom HTTP headers or use HTTP Basic authentication]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}). - -## Publish a package - -To publish a generic package perform a HTTP PUT operation with the package content in the request body. -You cannot publish a file with the same name twice to a package. You must delete the existing package version first. - -``` -PUT https://gitea.example.com/api/packages/{owner}/generic/{package_name}/{package_version}/{file_name} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. It can contain only lowercase letters (`a-z`), uppercase letter (`A-Z`), numbers (`0-9`), dots (`.`), hyphens (`-`), pluses (`+`), or underscores (`_`). | -| `package_version` | The package version, a non-empty string without trailing or leading whitespaces. | -| `file_name` | The filename. It can contain only lowercase letters (`a-z`), uppercase letter (`A-Z`), numbers (`0-9`), dots (`.`), hyphens (`-`), pluses (`+`), or underscores (`_`). | - -Example request using HTTP Basic authentication: - -```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 -``` - -If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `201 Created` | The package has been published. | -| `400 Bad Request` | The package name and/or version and/or file name are invalid. | -| `409 Conflict` | A file with the same name exist already in the package. | - -## Download a package - -To download a generic package perform a HTTP GET operation. - -``` -GET https://gitea.example.com/api/packages/{owner}/generic/{package_name}/{package_version}/{file_name} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | -| `package_version` | The package version. | -| `file_name` | The filename. | - -The file content is served in the response body. The response content type is `application/octet-stream`. - -Example request using HTTP Basic authentication: - -```shell -curl --user your_username:your_token_or_password \ - https://gitea.example.com/api/packages/testuser/generic/test_package/1.0.0/file.bin -``` - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `200 OK` | Success | -| `404 Not Found` | The package or file was not found. | - -## Delete a package - -To delete a generic package perform a HTTP DELETE operation. This will delete all files of this version. - -``` -DELETE https://gitea.example.com/api/packages/{owner}/generic/{package_name}/{package_version} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | -| `package_version` | The package version. | - -Example request using HTTP Basic authentication: - -```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 Status Code | Meaning | -| ----------------- | ------- | -| `204 No Content` | Success | -| `404 Not Found` | The package was not found. | - -## Delete a package file - -To delete a file of a generic package perform a HTTP DELETE operation. This will delete the package version too if there is no file left. - -``` -DELETE https://gitea.example.com/api/packages/{owner}/generic/{package_name}/{package_version}/{filename} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | -| `package_version` | The package version. | -| `filename` | The filename. | - -Example request using HTTP Basic authentication: - -```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 -``` - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `204 No Content` | Success | -| `404 Not Found` | The package or file was not found. | diff --git a/docs/content/doc/usage/packages/generic.zh-cn.md b/docs/content/doc/usage/packages/generic.zh-cn.md deleted file mode 100644 index ce5cdcb7ae..0000000000 --- a/docs/content/doc/usage/packages/generic.zh-cn.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "通用软件包注册表" -slug: "generic" -weight: 40 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "通用" - weight: 40 - identifier: "generic" ---- - -# 通用软件包注册表 - -发布通用文件，如发布二进制文件或其他输出，供您的用户或组织使用。 - -**目录** - -{{< toc >}} - -## 身份验证软件包注册表 - -要身份验证软件包注册表，您需要提供[自定义 HTTP 头或使用 HTTP 基本身份验证]({{< relref "doc/development/api-usage.zh-cn.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，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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` | 找不到软件包或文件 | diff --git a/docs/content/doc/usage/packages/go.en-us.md b/docs/content/doc/usage/packages/go.en-us.md deleted file mode 100644 index 04452c3516..0000000000 --- a/docs/content/doc/usage/packages/go.en-us.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -date: "2023-05-10T00:00:00+00:00" -title: "Go Package Registry" -slug: "go" -weight: 45 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Go" - weight: 45 - identifier: "go" ---- - -# Go Package Registry - -Publish Go packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Publish a package - -To publish a Go package perform a HTTP `PUT` operation with the package content in the request body. -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. -The package must follow the [documented structure](https://go.dev/ref/mod#zip-files). - -``` -PUT https://gitea.example.com/api/packages/{owner}/go/upload -``` - -| Parameter | Description | -| --------- | ----------- | -| `owner` | The owner of the package. | - -To authenticate to the package registry, you need to provide [custom HTTP headers or use HTTP Basic authentication]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}): - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/file.zip \ - https://gitea.example.com/api/packages/testuser/go/upload -``` - -If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `201 Created` | The package has been published. | -| `400 Bad Request` | The package is invalid. | -| `409 Conflict` | A package with the same name exist already. | - -## Install a package - -To install a Go package instruct Go to use the package registry as proxy: - -```shell -# use latest version -GOPROXY=https://gitea.example.com/api/packages/{owner}/go go install {package_name} -# or -GOPROXY=https://gitea.example.com/api/packages/{owner}/go go install {package_name}@latest -# use specific version -GOPROXY=https://gitea.example.com/api/packages/{owner}/go go install {package_name}@{package_version} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | -| `package_version` | The package version. | - -If the owner of the packages is private you need to [provide credentials](https://go.dev/ref/mod#private-module-proxy-auth). - -More information about the `GOPROXY` environment variable and how to protect against data leaks can be found in [the documentation](https://go.dev/ref/mod#private-modules). diff --git a/docs/content/doc/usage/packages/go.zh-cn.md b/docs/content/doc/usage/packages/go.zh-cn.md deleted file mode 100644 index 069a6991fb..0000000000 --- a/docs/content/doc/usage/packages/go.zh-cn.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -date: "2023-05-10T00:00:00+00:00" -title: "Go 软件包注册表" -slug: "go" -weight: 45 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Go" - weight: 45 - identifier: "go" ---- - -# Go 软件包注册表 - -为您的用户或组织发布 Go 软件包。 - -**目录** - -{{< toc >}} - -## 发布软件包 - -要发布 Go 软件包，请执行 HTTP `PUT` 操作，并将软件包内容放入请求主体中。 -如果已经存在相同名称和版本的软件包，您无法发布软件包。您必须首先删除现有的软件包。 -该软件包必须遵循[文档中的结构](https://go.dev/ref/mod#zip-files)。 - -``` -PUT https://gitea.example.com/api/packages/{owner}/go/upload -``` - -| 参数 | 描述 | -| ------- | -------------- | -| `owner` | 软件包的所有者 | - -要身份验证到软件包注册表，您需要提供[自定义 HTTP 头或使用 HTTP 基本身份验证]({{< relref "doc/development/api-usage.zh-cn.md#通过-api-认证" >}})： - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/file.zip \ - https://gitea.example.com/api/packages/testuser/go/upload -``` - -如果您使用的是 2FA 或 OAuth，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.md#通过-api-认证" >}})替代密码进行身份验证。 - -服务器将使用以下 HTTP 状态代码进行响应。 - -| HTTP 状态码 | 含义 | -| ----------------- | -------------------------- | -| `201 Created` | 软件包已发布 | -| `400 Bad Request` | 软件包无效 | -| `409 Conflict` | 具有相同名称的软件包已存在 | - -## 安装软件包 - -要安装Go软件包，请指示Go使用软件包注册表作为代理： - -```shell -# 使用最新版本 -GOPROXY=https://gitea.example.com/api/packages/{owner}/go go install {package_name} -# 或者 -GOPROXY=https://gitea.example.com/api/packages/{owner}/go go install {package_name}@latest -# 使用特定版本 -GOPROXY=https://gitea.example.com/api/packages/{owner}/go go install {package_name}@{package_version} -``` - -| 参数 | 描述 | -| ----------------- | -------------- | -| `owner` | 软件包的所有者 | -| `package_name` | 软件包名称 | -| `package_version` | 软件包版本 | - -如果软件包的所有者是私有的，则需要[提供凭据](https://go.dev/ref/mod#private-module-proxy-auth)。 - -有关 `GOPROXY` 环境变量的更多信息以及如何防止数据泄漏的信息，请[参阅文档](https://go.dev/ref/mod#private-modules)。 diff --git a/docs/content/doc/usage/packages/helm.en-us.md b/docs/content/doc/usage/packages/helm.en-us.md deleted file mode 100644 index 1db1e8758b..0000000000 --- a/docs/content/doc/usage/packages/helm.en-us.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -date: "2022-04-14T00:00:00+00:00" -title: "Helm Chart Registry" -slug: "helm" -weight: 50 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Helm" - weight: 50 - identifier: "helm" ---- - -# Helm Chart Registry - -Publish [Helm](https://helm.sh/) charts for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Helm Chart registry use a simple HTTP client like `curl` or the [`helm cm-push`](https://github.com/chartmuseum/helm-push/) plugin. - -## Publish a package - -Publish a package by running the following command: - -```shell -curl --user {username}:{password} -X POST --upload-file ./{chart_file}.tgz https://gitea.example.com/api/packages/{owner}/helm/api/charts -``` - -or with the `helm cm-push` plugin: - -```shell -helm repo add --username {username} --password {password} {repo} https://gitea.example.com/api/packages/{owner}/helm -helm cm-push ./{chart_file}.tgz {repo} -``` - -| Parameter | Description | -| ------------ | ----------- | -| `username` | Your Gitea username. | -| `password` | Your Gitea password. If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. | -| `repo` | The name for the repository. | -| `chart_file` | The Helm Chart archive. | -| `owner` | The owner of the package. | - -## Install a package - -To install a Helm char from the registry, execute the following command: - -```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} -``` - -| Parameter | Description | -| ---------- | ----------- | -| `username` | Your Gitea username. | -| `password` | Your Gitea password or a personal access token. | -| `repo` | The name for the repository. | -| `owner` | The owner of the package. | -| `name` | The local name. | -| `chart` | The name Helm Chart. | diff --git a/docs/content/doc/usage/packages/helm.zh-cn.md b/docs/content/doc/usage/packages/helm.zh-cn.md deleted file mode 100644 index 337170bc26..0000000000 --- a/docs/content/doc/usage/packages/helm.zh-cn.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -date: "2022-04-14T00:00:00+00:00" -title: "Helm Chart 注册表" -slug: "helm" -weight: 50 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Helm" - weight: 50 - identifier: "helm" ---- - -# Helm Chart 注册表 - -为您的用户或组织发布 [Helm](https://helm.sh/) charts。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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的名称 | diff --git a/docs/content/doc/usage/packages/maven.en-us.md b/docs/content/doc/usage/packages/maven.en-us.md deleted file mode 100644 index 85b37fe464..0000000000 --- a/docs/content/doc/usage/packages/maven.en-us.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "Maven Package Registry" -slug: "maven" -weight: 60 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Maven" - weight: 60 - identifier: "maven" ---- - -# Maven Package Registry - -Publish [Maven](https://maven.apache.org) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Maven package registry, you can use [Maven](https://maven.apache.org/install.html) or [Gradle](https://gradle.org/install/). -The following examples use `Maven` and `Gradle Groovy`. - -## Configuring the package registry - -To register the package registry you first need to add your access token to the [`settings.xml`](https://maven.apache.org/settings.html) file: - -```xml -<settings> - <servers> - <server> - <id>gitea</id> - <configuration> - <httpHeaders> - <property> - <name>Authorization</name> - <value>token {access_token}</value> - </property> - </httpHeaders> - </configuration> - </server> - </servers> -</settings> -``` - -Afterwards add the following sections to your project `pom.xml` file: - -```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> -``` - -| Parameter | Description | -| -------------- | ----------- | -| `access_token` | Your [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}). | -| `owner` | The owner of the package. | - -### Gradle variant - -When you plan to add some packages from Gitea instance in your project, you should add it in repositories section: - -```groovy -repositories { - // other repositories - maven { url "https://gitea.example.com/api/packages/{owner}/maven" } -} -``` - -In Groovy gradle you may include next script in your publishing part: - -```groovy -publishing { - // other settings of publication - 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) - } - } - } -} -``` - -## Publish a package - -To publish a package simply run: - -```shell -mvn deploy -``` - -Or call `gradle` with task `publishAllPublicationsToGiteaRepository` in case you are using gradle: - -```groovy -./gradlew publishAllPublicationsToGiteaRepository -``` - -If you want to publish a prebuild package to the registry, you can use [`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 -``` - -| Parameter | Description | -| -------------- | ----------- | -| `owner` | The owner of the package. | - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Install a package - -To install a Maven package from the package registry, add a new dependency to your project `pom.xml` file: - -```xml -<dependency> - <groupId>com.test.package</groupId> - <artifactId>test_project</artifactId> - <version>1.0.0</version> -</dependency> -``` - -And analog in gradle groovy: - -```groovy -implementation "com.test.package:test_project:1.0.0" -``` - -Afterwards run: - -```shell -mvn install -``` - -## Supported commands - -``` -mvn install -mvn deploy -mvn dependency:get: -``` diff --git a/docs/content/doc/usage/packages/maven.zh-cn.md b/docs/content/doc/usage/packages/maven.zh-cn.md deleted file mode 100644 index 833bb81507..0000000000 --- a/docs/content/doc/usage/packages/maven.zh-cn.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "Maven 软件包注册表" -slug: "maven" -weight: 60 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Maven" - weight: 60 - identifier: "maven" ---- - -# Maven 软件包注册表 - -为您的用户或组织发布 [Maven](https://maven.apache.org) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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` | 您的[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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: -``` diff --git a/docs/content/doc/usage/packages/npm.en-us.md b/docs/content/doc/usage/packages/npm.en-us.md deleted file mode 100644 index 58edcd02a4..0000000000 --- a/docs/content/doc/usage/packages/npm.en-us.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "npm Package Registry" -slug: "npm" -weight: 70 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "npm" - weight: 70 - identifier: "npm" ---- - -# npm Package Registry - -Publish [npm](https://www.npmjs.com/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the npm package registry, you need [Node.js](https://nodejs.org/en/download/) coupled with a package manager such as [Yarn](https://classic.yarnpkg.com/en/docs/install) or [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm/) itself. - -The registry supports [scoped](https://docs.npmjs.com/misc/scope/) and unscoped packages. - -The following examples use the `npm` tool with the scope `@test`. - -## Configuring the package registry - -To register the package registry you need to configure a new package source. - -```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}" -``` - -| Parameter | Description | -| ------------ | ----------- | -| `scope` | The scope of the packages. | -| `owner` | The owner of the package. | -| `token` | Your [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}). | - -For example: - -```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" -``` - -or without scope: - -```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" -``` - -## Publish a package - -Publish a package by running the following command in your project: - -```shell -npm publish -``` - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Unpublish a package - -Delete a package by running the following command: - -```shell -npm unpublish {package_name}[@{package_version}] -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `package_name` | The package name. | -| `package_version` | The package version. | - -For example: - -```shell -npm unpublish @test/test_package -npm unpublish @test/test_package@1.0.0 -``` - -## Install a package - -To install a package from the package registry, execute the following command: - -```shell -npm install {package_name} -``` - -| Parameter | Description | -| -------------- | ----------- | -| `package_name` | The package name. | - -For example: - -```shell -npm install @test/test_package -``` - -## Tag a package - -The registry supports [version tags](https://docs.npmjs.com/adding-dist-tags-to-packages/) which can be managed by `npm dist-tag`: - -```shell -npm dist-tag add {package_name}@{version} {tag} -``` - -| Parameter | Description | -| -------------- | ----------- | -| `package_name` | The package name. | -| `version` | The version of the package. | -| `tag` | The tag name. | - -For example: - -```shell -npm dist-tag add test_package@1.0.2 release -``` - -The tag name must not be a valid version. All tag names which are parsable as a version are rejected. - -## Search packages - -The registry supports [searching](https://docs.npmjs.com/cli/v7/commands/npm-search/) but does not support special search qualifiers like `author:gitea`. - -## Supported commands - -``` -npm install -npm ci -npm publish -npm unpublish -npm dist-tag -npm view -npm search -``` diff --git a/docs/content/doc/usage/packages/npm.zh-cn.md b/docs/content/doc/usage/packages/npm.zh-cn.md deleted file mode 100644 index 4863b2582b..0000000000 --- a/docs/content/doc/usage/packages/npm.zh-cn.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "npm 软件包注册表" -slug: "npm" -weight: 70 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "npm" - weight: 70 - identifier: "npm" ---- - -# npm Package Registry - -为您的用户或组织发布 [npm](https://www.npmjs.com/) 包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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` | 您的[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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 -``` diff --git a/docs/content/doc/usage/packages/nuget.en-us.md b/docs/content/doc/usage/packages/nuget.en-us.md deleted file mode 100644 index ccda2cc49c..0000000000 --- a/docs/content/doc/usage/packages/nuget.en-us.md +++ /dev/null @@ -1,119 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "NuGet Package Registry" -slug: "nuget" -weight: 80 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "NuGet" - weight: 80 - identifier: "nuget" ---- - -# NuGet Package Registry - -Publish [NuGet](https://www.nuget.org/) packages for your user or organization. The package registry supports the V2 and V3 API protocol and you can work with [NuGet Symbol Packages](https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg) too. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the NuGet package registry, you can use command-line interface tools as well as NuGet features in various IDEs like Visual Studio. -More information about NuGet clients can be found in [the official documentation](https://docs.microsoft.com/en-us/nuget/install-nuget-client-tools). -The following examples use the `dotnet nuget` tool. - -## Configuring the package registry - -To register the package registry you need to configure a new NuGet feed source: - -```shell -dotnet nuget add source --name {source_name} --username {username} --password {password} https://gitea.example.com/api/packages/{owner}/nuget/index.json -``` - -| Parameter | Description | -| ------------- | ----------- | -| `source_name` | The desired source name. | -| `username` | Your Gitea username. | -| `password` | Your Gitea password. If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. | -| `owner` | The owner of the package. | - -For example: - -```shell -dotnet nuget add source --name gitea --username testuser --password password123 https://gitea.example.com/api/packages/testuser/nuget/index.json -``` - -You can add the source without credentials and use the [`--api-key`](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-push) parameter when publishing packages. In this case you need to provide a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}). - -## Publish a package - -Publish a package by running the following command: - -```shell -dotnet nuget push --source {source_name} {package_file} -``` - -| Parameter | Description | -| -------------- | ----------- | -| `source_name` | The desired source name. | -| `package_file` | Path to the package `.nupkg` file. | - -For example: - -```shell -dotnet nuget push --source gitea test_package.1.0.0.nupkg -``` - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -### Symbol Packages - -The NuGet package registry has build support for a symbol server. The PDB files embedded in a symbol package (`.snupkg`) can get requested by clients. -To do so, register the NuGet package registry as symbol source: - -``` -https://gitea.example.com/api/packages/{owner}/nuget/symbols -``` - -| Parameter | Description | -| --------- | ----------- | -| `owner` | The owner of the package registry. | - -For example: - -``` -https://gitea.example.com/api/packages/testuser/nuget/symbols -``` - -## Install a package - -To install a NuGet package from the package registry, execute the following command: - -```shell -dotnet add package --source {source_name} --version {package_version} {package_name} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `source_name` | The desired source name. | -| `package_name` | The package name. | -| `package_version` | The package version. | - -For example: - -```shell -dotnet add package --source gitea --version 1.0.0 test_package -``` - -## Supported commands - -``` -dotnet add -dotnet nuget push -dotnet nuget delete -``` diff --git a/docs/content/doc/usage/packages/nuget.zh-cn.md b/docs/content/doc/usage/packages/nuget.zh-cn.md deleted file mode 100644 index 14205545b5..0000000000 --- a/docs/content/doc/usage/packages/nuget.zh-cn.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "NuGet 软件包注册表" -slug: "nuget" -weight: 80 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "NuGet" - weight: 80 - identifier: "nuget" ---- - -# NuGet 软件包注册表 - -发布适用于您的用户或组织的 [NuGet](https://www.nuget.org/) 软件包。软件包注册表支持 V2 和 V3 API 协议，并且您还可以使用 [NuGet 符号软件包](https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg)。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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参数。在这种情况下，您需要提供[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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 -``` diff --git a/docs/content/doc/usage/packages/overview.en-us.md b/docs/content/doc/usage/packages/overview.en-us.md deleted file mode 100644 index bf33ea627d..0000000000 --- a/docs/content/doc/usage/packages/overview.en-us.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "Package Registry" -slug: "overview" -weight: 1 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Overview" - weight: 1 - identifier: "packages-overview" ---- - -# Package Registry - -Starting with Gitea **1.17**, the Package Registry can be used as a public or private registry for common package managers. - -**Table of Contents** - -{{< toc >}} - -## Supported package managers - -The following package managers are currently supported: - -| Name | Language | Package client | -| ---- | -------- | -------------- | -| [Alpine]({{< relref "doc/usage/packages/alpine.en-us.md" >}}) | - | `apk` | -| [Cargo]({{< relref "doc/usage/packages/cargo.en-us.md" >}}) | Rust | `cargo` | -| [Chef]({{< relref "doc/usage/packages/chef.en-us.md" >}}) | - | `knife` | -| [Composer]({{< relref "doc/usage/packages/composer.en-us.md" >}}) | PHP | `composer` | -| [Conan]({{< relref "doc/usage/packages/conan.en-us.md" >}}) | C++ | `conan` | -| [Conda]({{< relref "doc/usage/packages/conda.en-us.md" >}}) | - | `conda` | -| [Container]({{< relref "doc/usage/packages/container.en-us.md" >}}) | - | any OCI compliant client | -| [CRAN]({{< relref "doc/usage/packages/cran.en-us.md" >}}) | R | - | -| [Debian]({{< relref "doc/usage/packages/debian.en-us.md" >}}) | - | `apt` | -| [Generic]({{< relref "doc/usage/packages/generic.en-us.md" >}}) | - | any HTTP client | -| [Go]({{< relref "doc/usage/packages/go.en-us.md" >}}) | Go | `go` | -| [Helm]({{< relref "doc/usage/packages/helm.en-us.md" >}}) | - | any HTTP client, `cm-push` | -| [Maven]({{< relref "doc/usage/packages/maven.en-us.md" >}}) | Java | `mvn`, `gradle` | -| [npm]({{< relref "doc/usage/packages/npm.en-us.md" >}}) | JavaScript | `npm`, `yarn`, `pnpm` | -| [NuGet]({{< relref "doc/usage/packages/nuget.en-us.md" >}}) | .NET | `nuget` | -| [Pub]({{< relref "doc/usage/packages/pub.en-us.md" >}}) | Dart | `dart`, `flutter` | -| [PyPI]({{< relref "doc/usage/packages/pypi.en-us.md" >}}) | Python | `pip`, `twine` | -| [RPM]({{< relref "doc/usage/packages/rpm.en-us.md" >}}) | - | `yum`, `dnf`, `zypper` | -| [RubyGems]({{< relref "doc/usage/packages/rubygems.en-us.md" >}}) | Ruby | `gem`, `Bundler` | -| [Swift]({{< relref "doc/usage/packages/rubygems.en-us.md" >}}) | Swift | `swift` | -| [Vagrant]({{< relref "doc/usage/packages/vagrant.en-us.md" >}}) | - | `vagrant` | - -**The following paragraphs only apply if Packages are not globally disabled!** - -## Repository-Packages - -A package always belongs to an owner (a user or organisation), not a repository. -To link an (already uploaded) package to a repository, open the settings page -on that package and choose a repository to link this package to. -The entire package will be linked, not just a single version. - -Linking a package results in showing that package in the repository's package list, -and shows a link to the repository on the package site (as well as a link to the repository issues). - -## Access Restrictions - -| Package owner type | User | Organization | -|--------------------|------|--------------| -| **read** access | public, if user is public too; otherwise for this user only | public, if org is public, otherwise for org members only | -| **write** access | owner only | org members with admin or write access to the org | - -N.B.: These access restrictions are [subject to change](https://github.com/go-gitea/gitea/issues/19270), where more finegrained control will be added via a dedicated organization team permission. - -## Create or upload a package - -Depending on the type of package, use the respective package-manager for that. Check out the sub-page of a specific package manager for instructions. - -## View packages - -You can view the packages of a repository on the repository page. - -1. Go to the repository. -1. Go to **Packages** in the navigation bar. - -To view more details about a package, select the name of the package. - -## Download a package - -To download a package from your repository: - -1. Go to **Packages** in the navigation bar. -1. Select the name of the package to view the details. -1. In the **Assets** section, select the name of the package file you want to download. - -## Delete a package - -You cannot edit a package after you have published it in the Package Registry. Instead, you -must delete and recreate it. - -To delete a package from your repository: - -1. Go to **Packages** in the navigation bar. -1. Select the name of the package to view the details. -1. Click **Delete package** to permanently delete the package. - -## Disable the Package Registry - -The Package Registry is automatically enabled. To disable it for a single repository: - -1. Go to **Settings** in the navigation bar. -1. Disable **Enable Repository Packages Registry**. - -Previously published packages are not deleted by disabling the Package Registry. diff --git a/docs/content/doc/usage/packages/overview.zh-cn.md b/docs/content/doc/usage/packages/overview.zh-cn.md deleted file mode 100644 index 9d24a733fd..0000000000 --- a/docs/content/doc/usage/packages/overview.zh-cn.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "软件包注册表" -slug: "overview" -weight: 1 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Overview" - weight: 1 - identifier: "packages-overview" ---- - -# 软件包注册表 - -从Gitea **1.17**版本开始，软件包注册表可以用作常见软件包管理器的公共或私有注册表。 - -**目录** - -{{< toc >}} - -## 支持的软件包管理器 - -目前支持以下软件包管理器： - -| Name | Language | Package client | -| ------------------------------------------------------------------- | ---------- | ------------------------- | -| [Alpine]({{< relref "doc/usage/packages/alpine.zh-cn.md" >}}) | - | `apk` | -| [Cargo]({{< relref "doc/usage/packages/cargo.zh-cn.md" >}}) | Rust | `cargo` | -| [Chef]({{< relref "doc/usage/packages/chef.zh-cn.md" >}}) | - | `knife` | -| [Composer]({{< relref "doc/usage/packages/composer.zh-cn.md" >}}) | PHP | `composer` | -| [Conan]({{< relref "doc/usage/packages/conan.zh-cn.md" >}}) | C++ | `conan` | -| [Conda]({{< relref "doc/usage/packages/conda.zh-cn.md" >}}) | - | `conda` | -| [Container]({{< relref "doc/usage/packages/container.zh-cn.md" >}}) | - | 任何符合OCI规范的客户端 | -| [CRAN]({{< relref "doc/usage/packages/cran.zh-cn.md" >}}) | R | - | -| [Debian]({{< relref "doc/usage/packages/debian.zh-cn.md" >}}) | - | `apt` | -| [Generic]({{< relref "doc/usage/packages/generic.zh-cn.md" >}}) | - | 任何HTTP客户端 | -| [Go]({{< relref "doc/usage/packages/go.zh-cn.md" >}}) | Go | `go` | -| [Helm]({{< relref "doc/usage/packages/helm.zh-cn.md" >}}) | - | 任何HTTP客户端, `cm-push` | -| [Maven]({{< relref "doc/usage/packages/maven.zh-cn.md" >}}) | Java | `mvn`, `gradle` | -| [npm]({{< relref "doc/usage/packages/npm.zh-cn.md" >}}) | JavaScript | `npm`, `yarn`, `pnpm` | -| [NuGet]({{< relref "doc/usage/packages/nuget.zh-cn.md" >}}) | .NET | `nuget` | -| [Pub]({{< relref "doc/usage/packages/pub.zh-cn.md" >}}) | Dart | `dart`, `flutter` | -| [PyPI]({{< relref "doc/usage/packages/pypi.zh-cn.md" >}}) | Python | `pip`, `twine` | -| [RPM]({{< relref "doc/usage/packages/rpm.zh-cn.md" >}}) | - | `yum`, `dnf`, `zypper` | -| [RubyGems]({{< relref "doc/usage/packages/rubygems.zh-cn.md" >}}) | Ruby | `gem`, `Bundler` | -| [Swift]({{< relref "doc/usage/packages/rubygems.zh-cn.md" >}}) | Swift | `swift` | -| [Vagrant]({{< relref "doc/usage/packages/vagrant.zh-cn.md" >}}) | - | `vagrant` | - -**以下段落仅适用于未全局禁用软件包的情况！** - -## 仓库 x 软件包 - -软件包始终属于所有者（用户或组织），而不是仓库。 -要将（已上传的）软件包链接到仓库，请打开该软件包的设置页面，并选择要将此软件包链接到的仓库。 -将链接到整个软件包，而不仅是单个版本。 - -链接软件包将导致在仓库的软件包列表中显示该软件包，并在软件包页面上显示到仓库的链接（以及到仓库工单的链接）。 - -## 访问限制 - -| 软件包所有者类型 | 用户 | 组织 | -| ---------------- | ---------------------------------------- | ------------------------------------------ | -| **读取** 访问 | 公开，如果用户也是公开的；否则仅限此用户 | 公开，如果组织是公开的，否则仅限组织成员 | -| **写入** 访问 | 仅软件包所有者 | 具有组织中的管理员或写入访问权限的组织成员 | - -注意：这些访问限制可能会[变化](https://github.com/go-gitea/gitea/issues/19270)，将通过专门的组织团队权限添加更细粒度的控制。 - -## 创建或上传软件包 - -根据软件包类型，使用相应的软件包管理器。请查看特定软件包管理器的子页面以获取说明。 - -## 查看软件包 - -您可以在仓库页面上查看仓库的软件包。 - -1. 转到仓库主页。 -2. 在导航栏中选择**软件包** - -要查看有关软件包的更多详细信息，请选择软件包的名称。 - -## 下载软件包 - -要从仓库下载软件包： - -1. 在导航栏中选择**软件包** -2. 选择软件包的名称以查看详细信息。 -3. 在 **Assets** 部分，选择要下载的软件包文件的名称。 - -## 删除软件包 - -在将软件包发布到软件包注册表后，您无法编辑软件包。相反，您必须删除并重新创建它。 - -要从仓库中删除软件包： - -1. 在导航栏中选择**软件包** -2. 选择软件包的名称以查看详细信息。 -3. 单击**删除软件包**以永久删除软件包。 - -## 禁用软件包注册表 - -包注册表已自动启用。要在单个存储库中禁用它： - -1. 在导航栏中选择**设置**。 -2. 禁用**启用仓库软件包注册表**. - -禁用软件包注册表不会删除先前发布的软件包。 diff --git a/docs/content/doc/usage/packages/pub.en-us.md b/docs/content/doc/usage/packages/pub.en-us.md deleted file mode 100644 index 823984d54d..0000000000 --- a/docs/content/doc/usage/packages/pub.en-us.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -date: "2022-07-31T00:00:00+00:00" -title: "Pub Package Registry" -slug: "pub" -weight: 90 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Pub" - weight: 90 - identifier: "pub" ---- - -# Pub Package Registry - -Publish [Pub](https://dart.dev/guides/packages) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Pub package registry, you need to use the tools [dart](https://dart.dev/tools/dart-tool) and/or [flutter](https://docs.flutter.dev/reference/flutter-cli). - -The following examples use dart. - -## Configuring the package registry - -To register the package registry and provide credentials, execute: - -```shell -dart pub token add https://gitea.example.com/api/packages/{owner}/pub -``` - -| Placeholder | Description | -| ------------ | ----------- | -| `owner` | The owner of the package. | - -You need to provide your [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}). - -## Publish a package - -To publish a package, edit the `pubspec.yaml` and add the following line: - -```yaml -publish_to: https://gitea.example.com/api/packages/{owner}/pub -``` - -| Placeholder | Description | -| ------------ | ----------- | -| `owner` | The owner of the package. | - -Now you can publish the package by running the following command: - -```shell -dart pub publish -``` - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Install a package - -To install a Pub package from the package registry, execute the following command: - -```shell -dart pub add {package_name} --hosted-url=https://gitea.example.com/api/packages/{owner}/pub/ -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | - -For example: - -```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/ -``` diff --git a/docs/content/doc/usage/packages/pub.zh-cn.md b/docs/content/doc/usage/packages/pub.zh-cn.md deleted file mode 100644 index 9941a57089..0000000000 --- a/docs/content/doc/usage/packages/pub.zh-cn.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -date: "2022-07-31T00:00:00+00:00" -title: "Pub 软件包注册表" -slug: "pub" -weight: 90 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Pub" - weight: 90 - identifier: "pub" ---- - -# Pub 软件包注册表 - -为您的用户或组织发布 [Pub](https://dart.dev/guides/packages) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用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` | 软件包的所有者 | - -您需要提供您的[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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/ -``` diff --git a/docs/content/doc/usage/packages/pypi.en-us.md b/docs/content/doc/usage/packages/pypi.en-us.md deleted file mode 100644 index 822e3ab97c..0000000000 --- a/docs/content/doc/usage/packages/pypi.en-us.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "PyPI Package Registry" -slug: "pypi" -weight: 100 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "PyPI" - weight: 100 - identifier: "pypi" ---- - -# PyPI Package Registry - -Publish [PyPI](https://pypi.org/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the PyPI package registry, you need to use the tools [pip](https://pypi.org/project/pip/) to consume and [twine](https://pypi.org/project/twine/) to publish packages. - -## Configuring the package registry - -To register the package registry you need to edit your local `~/.pypirc` file. Add - -```ini -[distutils] -index-servers = gitea - -[gitea] -repository = https://gitea.example.com/api/packages/{owner}/pypi -username = {username} -password = {password} -``` - -| Placeholder | Description | -| ------------ | ----------- | -| `owner` | The owner of the package. | -| `username` | Your Gitea username. | -| `password` | Your Gitea password. If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. | - -## Publish a package - -Publish a package by running the following command: - -```shell -python3 -m twine upload --repository gitea /path/to/files/* -``` - -The package files have the extensions `.tar.gz` and `.whl`. - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Install a package - -To install a PyPI package from the package registry, execute the following command: - -```shell -pip install --index-url https://{username}:{password}@gitea.example.com/api/packages/{owner}/pypi/simple --no-deps {package_name} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `username` | Your Gitea username. | -| `password` | Your Gitea password or a personal access token. | -| `owner` | The owner of the package. | -| `package_name` | The package name. | - -For example: - -```shell -pip install --index-url https://testuser:password123@gitea.example.com/api/packages/testuser/pypi/simple --no-deps test_package -``` - -You can use `--extra-index-url` instead of `--index-url` but that makes you vulnerable to dependency confusion attacks because `pip` checks the official PyPi repository for the package before it checks the specified custom repository. Read the `pip` docs for more information. - -## Supported commands - -``` -pip install -twine upload -``` diff --git a/docs/content/doc/usage/packages/pypi.zh-cn.md b/docs/content/doc/usage/packages/pypi.zh-cn.md deleted file mode 100644 index 555fc4db43..0000000000 --- a/docs/content/doc/usage/packages/pypi.zh-cn.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "PyPI 软件包注册表" -slug: "pypi" -weight: 100 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "PyPI" - weight: 100 - identifier: "pypi" ---- - -# PyPI 软件包注册表 - -为您的用户或组织发布 [PyPI](https://pypi.org/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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 -``` diff --git a/docs/content/doc/usage/packages/rpm.en-us.md b/docs/content/doc/usage/packages/rpm.en-us.md deleted file mode 100644 index 7a258f5c03..0000000000 --- a/docs/content/doc/usage/packages/rpm.en-us.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -date: "2023-03-08T00:00:00+00:00" -title: "RPM Package Registry" -slug: "rpm" -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "RPM" - weight: 105 - identifier: "rpm" ---- - -# RPM Package Registry - -Publish [RPM](https://rpm.org/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the RPM registry, you need to use a package manager like `yum`, `dnf` or `zypper` to consume packages. - -The following examples use `dnf`. - -## Configuring the package registry - -To register the RPM registry add the url to the list of known apt sources: - -```shell -dnf config-manager --add-repo https://gitea.example.com/api/packages/{owner}/rpm.repo -``` - -| Placeholder | Description | -| ----------- | ----------- | -| `owner` | The owner of the package. | - -If the registry is private, provide credentials in the url. You can use a password or a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}): - -```shell -dnf config-manager --add-repo https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/rpm.repo -``` - -You have to add the credentials to the urls in the `rpm.repo` file in `/etc/yum.repos.d` too. - -## Publish a package - -To publish a RPM package (`*.rpm`), perform a HTTP PUT operation with the package content in the request body. - -``` -PUT https://gitea.example.com/api/packages/{owner}/rpm/upload -``` - -| Parameter | Description | -| --------- | ----------- | -| `owner` | The owner of the package. | - -Example request using HTTP Basic authentication: - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/file.rpm \ - https://gitea.example.com/api/packages/testuser/rpm/upload -``` - -If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. -You cannot publish a file with the same name twice to a package. You must delete the existing package version first. - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `201 Created` | The package has been published. | -| `400 Bad Request` | The package is invalid. | -| `409 Conflict` | A package file with the same combination of parameters exist already in the package. | - -## Delete a package - -To delete an RPM package perform a HTTP DELETE operation. This will delete the package version too if there is no file left. - -``` -DELETE https://gitea.example.com/api/packages/{owner}/rpm/{package_name}/{package_version}/{architecture} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | -| `package_version` | The package version. | -| `architecture` | The package architecture. | - -Example request using HTTP Basic authentication: - -```shell -curl --user your_username:your_token_or_password -X DELETE \ - https://gitea.example.com/api/packages/testuser/rpm/test-package/1.0.0/x86_64 -``` - -The server responds with the following HTTP Status codes. - -| HTTP Status Code | Meaning | -| ----------------- | ------- | -| `204 No Content` | Success | -| `404 Not Found` | The package or file was not found. | - -## Install a package - -To install a package from the RPM registry, execute the following commands: - -```shell -# use latest version -dnf install {package_name} -# use specific version -dnf install {package_name}-{package_version}.{architecture} -``` diff --git a/docs/content/doc/usage/packages/rpm.zh-cn.md b/docs/content/doc/usage/packages/rpm.zh-cn.md deleted file mode 100644 index f76273e5a8..0000000000 --- a/docs/content/doc/usage/packages/rpm.zh-cn.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -date: "2023-03-08T00:00:00+00:00" -title: "RPM 软件包注册表" -slug: "packages/rpm" -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "RPM" - weight: 105 - identifier: "rpm" ---- - -# RPM 软件包注册表 - -为您的用户或组织发布 [RPM](https://rpm.org/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用RPM注册表，您需要使用像 `yum`, `dnf` 或 `zypper` 这样的软件包管理器来消费软件包。 - -以下示例使用 `dnf`。 - -## 配置软件包注册表 - -要注册RPM注册表，请将 URL 添加到已知 `apt` 源列表中： - -```shell -dnf config-manager --add-repo https://gitea.example.com/api/packages/{owner}/rpm.repo -``` - -| 占位符 | 描述 | -| ------- | -------------- | -| `owner` | 软件包的所有者 | - -如果注册表是私有的，请在URL中提供凭据。您可以使用密码或[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.md#通过-api-认证" >}})： - -```shell -dnf config-manager --add-repo https://{username}:{your_password_or_token}@gitea.example.com/api/packages/{owner}/rpm.repo -``` - -您还必须将凭据添加到 `/etc/yum.repos.d` 中的 `rpm.repo` 文件中的URL中。 - -## 发布软件包 - -要发布RPM软件包（`*.rpm`），请执行带有软件包内容的 HTTP `PUT` 操作。 - -``` -PUT https://gitea.example.com/api/packages/{owner}/rpm/upload -``` - -| 参数 | 描述 | -| ------- | -------------- | -| `owner` | 软件包的所有者 | - -使用HTTP基本身份验证的示例请求： - -```shell -curl --user your_username:your_password_or_token \ - --upload-file path/to/file.rpm \ - https://gitea.example.com/api/packages/testuser/rpm/upload -``` - -如果您使用 2FA 或 OAuth，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.md#通过-api-认证" >}})替代密码。您无法将具有相同名称的文件两次发布到软件包中。您必须先删除现有的软件包版本。 - -服务器将以以下HTTP状态码响应。 - -| HTTP 状态码 | 含义 | -| ----------------- | ------------------------------------------------ | -| `201 Created` | 软件包已发布 | -| `400 Bad Request` | 软件包无效 | -| `409 Conflict` | 具有相同参数组合的软件包文件已经存在于该软件包中 | - -## 删除软件包 - -要删除 RPM 软件包，请执行 HTTP `DELETE` 操作。如果没有文件剩余，这也将删除软件包版本。 - -``` -DELETE https://gitea.example.com/api/packages/{owner}/rpm/{package_name}/{package_version}/{architecture} -``` - -| 参数 | 描述 | -| ----------------- | -------------- | -| `owner` | 软件包的所有者 | -| `package_name` | 软件包名称 | -| `package_version` | 软件包版本 | -| `architecture` | 软件包架构 | - -使用HTTP基本身份验证的示例请求： - -```shell -curl --user your_username:your_token_or_password -X DELETE \ - https://gitea.example.com/api/packages/testuser/rpm/test-package/1.0.0/x86_64 -``` - -服务器将以以下HTTP状态码响应： - -| HTTP 状态码 | 含义 | -| ---------------- | ------------------ | -| `204 No Content` | 成功 | -| `404 Not Found` | 未找到软件包或文件 | - -## 安装软件包 - -要从RPM注册表安装软件包，请执行以下命令： - -```shell -# use latest version -dnf install {package_name} -# use specific version -dnf install {package_name}-{package_version}.{architecture} -``` diff --git a/docs/content/doc/usage/packages/rubygems.en-us.md b/docs/content/doc/usage/packages/rubygems.en-us.md deleted file mode 100644 index 5cfebfc84a..0000000000 --- a/docs/content/doc/usage/packages/rubygems.en-us.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "RubyGems Package Registry" -slug: "rubygems" -weight: 110 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "RubyGems" - weight: 110 - identifier: "rubygems" ---- - -# RubyGems Package Registry - -Publish [RubyGems](https://guides.rubygems.org/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the RubyGems package registry, you need to use the [gem](https://guides.rubygems.org/command-reference/) command line tool to consume and publish packages. - -## Configuring the package registry - -To register the package registry edit the `~/.gem/credentials` file and add: - -```ini ---- -https://gitea.example.com/api/packages/{owner}/rubygems: Bearer {token} -``` - -| Parameter | Description | -| ------------- | ----------- | -| `owner` | The owner of the package. | -| `token` | Your [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}). | - -For example: - -``` ---- -https://gitea.example.com/api/packages/testuser/rubygems: Bearer 3bd626f84b01cd26b873931eace1e430a5773cc4 -``` - -## Publish a package - -Publish a package by running the following command: - -```shell -gem push --host {host} {package_file} -``` - -| Parameter | Description | -| -------------- | ----------- | -| `host` | URL to the package registry. | -| `package_file` | Path to the package `.gem` file. | - -For example: - -```shell -gem push --host https://gitea.example.com/api/packages/testuser/rubygems test_package-1.0.0.gem -``` - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Install a package - -To install a package from the package registry you can use [Bundler](https://bundler.io) or `gem`. - -### Bundler - -Add a new `source` block to your `Gemfile`: - -``` -source "https://gitea.example.com/api/packages/{owner}/rubygems" do - gem "{package_name}" -end -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | - -For example: - -``` -source "https://gitea.example.com/api/packages/testuser/rubygems" do - gem "test_package" -end -``` - -Afterwards run the following command: - -```shell -bundle install -``` - -### gem - -Execute the following command: - -```shell -gem install --host https://gitea.example.com/api/packages/{owner}/rubygems {package_name} -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | - -For example: - -```shell -gem install --host https://gitea.example.com/api/packages/testuser/rubygems test_package -``` - -## Supported commands - -``` -gem install -bundle install -gem push -``` diff --git a/docs/content/doc/usage/packages/rubygems.zh-cn.md b/docs/content/doc/usage/packages/rubygems.zh-cn.md deleted file mode 100644 index f3416c239e..0000000000 --- a/docs/content/doc/usage/packages/rubygems.zh-cn.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -date: "2021-07-20T00:00:00+00:00" -title: "RubyGems 软件包注册表" -slug: "rubygems" -weight: 110 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "RubyGems" - weight: 110 - identifier: "rubygems" ---- - -# RubyGems 软件包注册表 - -为您的用户或组织发布 [RubyGems](https://guides.rubygems.org/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用RubyGems软件包注册表，您需要使用 [gem](https://guides.rubygems.org/command-reference/) 命令行工具来消费和发布软件包。 - -## 配置软件包注册表 - -要注册软件包注册表，请编辑 `~/.gem/credentials` 文件并添加： - -```ini ---- -https://gitea.example.com/api/packages/{owner}/rubygems: Bearer {token} -``` - -| 参数 | 描述 | -| ------- | ------------------------------------------------------------------------------------- | -| `owner` | 软件包的所有者 | -| `token` | 您的[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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 -``` diff --git a/docs/content/doc/usage/packages/storage.en-us.md b/docs/content/doc/usage/packages/storage.en-us.md deleted file mode 100644 index bf500f3bc1..0000000000 --- a/docs/content/doc/usage/packages/storage.en-us.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -date: "2022-11-01T00:00:00+00:00" -title: "Storage" -slug: "storage" -weight: 5 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Storage" - weight: 2 - identifier: "storage" ---- - -# Storage - -This document describes the storage of the package registry and how it can be managed. - -**Table of Contents** - -{{< toc >}} - -## Deduplication - -The package registry has a build-in deduplication of uploaded blobs. -If two identical files are uploaded only one blob is saved on the filesystem. -This ensures no space is wasted for duplicated files. - -If two packages are uploaded with identical files, both packages will display the same size but on the filesystem they require only half of the size. -Whenever a package gets deleted, only the references to the underlying blobs are removed. -The blobs get not removed at this moment, so they still require space on the filesystem. -When a new package gets uploaded the existing blobs may get referenced again. - -These unreferenced blobs get deleted by a [clean up job]({{< relref "doc/administration/config-cheat-sheet.en-us.md#cron---cleanup-expired-packages-croncleanup_packages" >}}). -The config setting `OLDER_THAN` configures how long unreferenced blobs are kept before they get deleted. - -## Cleanup Rules - -Package registries can become large over time without cleanup. -It's recommended to delete unnecessary packages and set up cleanup rules to automatically manage the package registry usage. -Every package owner (user or organization) manages the cleanup rules which are applied to their packages. - -|Setting|Description| -|-|-| -|Enabled|Turn the cleanup rule on or off.| -|Type|Every rule manages a specific package type.| -|Apply pattern to full package name|If enabled, the patterns below are applied to the full package name (`package/version`). Otherwise only the version (`version`) is used.| -|Keep the most recent|How many versions to *always* keep for each package.| -|Keep versions matching|The regex pattern that determines which versions to keep. An empty pattern keeps no version while `.+` keeps all versions. The container registry will always keep the `latest` version even if not configured.| -|Remove versions older than|Remove only versions older than the selected days.| -|Remove versions matching|The regex pattern that determines which versions to remove. An empty pattern or `.+` leads to the removal of every package if no other setting tells otherwise.| - -Every cleanup rule can show a preview of the affected packages. -This can be used to check if the cleanup rules is proper configured. - -### Regex examples - -Regex patterns are automatically surrounded with `\A` and `\z` anchors. -Do not include any `\A`, `\z`, `^` or `$` token in the regex patterns as they are not necessary. -The patterns are case-insensitive which matches the behaviour of the package registry in Gitea. - -|Pattern|Description| -|-|-| -|`.*`|Match every possible version.| -|`v.+`|Match versions that start with `v`.| -|`release`|Match only the version `release`.| -|`release.*`|Match versions that are either named or start with `release`.| -|`.+-temp-.+`|Match versions that contain `-temp-`.| -|`v.+\|release`|Match versions that either start with `v` or are named `release`.| -|`package/v.+\|other/release`|Match versions of the package `package` that start with `v` or the version `release` of the package `other`. This needs the setting *Apply pattern to full package name* enabled.| - -### How the cleanup rules work - -The cleanup rules are part of the [clean up job]({{< relref "doc/administration/config-cheat-sheet.en-us.md#cron---cleanup-expired-packages-croncleanup_packages" >}}) and run periodically. - -The cleanup rule: - -1. Collects all packages of the package type for the owners registry. -2. For every package it collects all versions. -3. Excludes from the list the # versions based on the *Keep the most recent* value. -4. Excludes from the list any versions matching the *Keep versions matching* value. -5. Excludes from the list the versions more recent than the *Remove versions older than* value. -6. Excludes from the list any versions not matching the *Remove versions matching* value. -7. Deletes the remaining versions. diff --git a/docs/content/doc/usage/packages/storage.zh-cn.md b/docs/content/doc/usage/packages/storage.zh-cn.md deleted file mode 100644 index 7845f40cf8..0000000000 --- a/docs/content/doc/usage/packages/storage.zh-cn.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -date: "2022-11-01T00:00:00+00:00" -title: "存储" -slug: "storage" -weight: 5 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Storage" - weight: 2 - identifier: "storage" ---- - -# 存储 - -本文档描述了软件包注册表的存储方式以及如何管理存储。 - -**目录** - -{{< toc >}} - -## 去重 - -软件包注册表具有内置的去重功能，可以对上传的 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. 删除剩余的版本。 diff --git a/docs/content/doc/usage/packages/swift.en-us.md b/docs/content/doc/usage/packages/swift.en-us.md deleted file mode 100644 index 6d4d0f24b4..0000000000 --- a/docs/content/doc/usage/packages/swift.en-us.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -date: "2023-01-10T00:00:00+00:00" -title: "Swift Package Registry" -slug: "swift" -weight: 95 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Swift" - weight: 95 - identifier: "swift" ---- - -# Swift Package Registry - -Publish [Swift](https://www.swift.org/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Swift package registry, you need to use [swift](https://www.swift.org/getting-started/) to consume and a HTTP client (like `curl`) to publish packages. - -## Configuring the package registry - -To register the package registry and provide credentials, execute: - -```shell -swift package-registry set https://gitea.example.com/api/packages/{owner}/swift -login {username} -password {password} -``` - -| Placeholder | Description | -| ------------ | ----------- | -| `owner` | The owner of the package. | -| `username` | Your Gitea username. | -| `password` | Your Gitea password. If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. | - -The login is optional and only needed if the package registry is private. - -## Publish a package - -First you have to pack the contents of your package: - -```shell -swift package archive-source -``` - -To publish the package perform a HTTP PUT request with the package content in the request body. - -```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} -``` - -| Placeholder | Description | -| ----------- | ----------- | -| `username` | Your Gitea username. | -| `password` | Your Gitea password. If you are using 2FA or OAuth use a [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) instead of the password. | -| `owner` | The owner of the package. | -| `scope` | The package scope. | -| `name` | The package name. | -| `version` | The package version. | -| `metadata` | (Optional) The metadata of the package. JSON encoded subset of https://schema.org/SoftwareSourceCode | - -You cannot publish a package if a package of the same name and version already exists. You must delete the existing package first. - -## Install a package - -To install a Swift package from the package registry, add it in the `Package.swift` file dependencies list: - -``` -dependencies: [ - .package(id: "{scope}.{name}", from:"{version}") -] -``` - -| Parameter | Description | -| ----------- | ----------- | -| `scope` | The package scope. | -| `name` | The package name. | -| `version` | The package version. | - -Afterwards execute the following command to install it: - -```shell -swift package resolve -``` diff --git a/docs/content/doc/usage/packages/swift.zh-cn.md b/docs/content/doc/usage/packages/swift.zh-cn.md deleted file mode 100644 index 9c627416ad..0000000000 --- a/docs/content/doc/usage/packages/swift.zh-cn.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -date: "2023-01-10T00:00:00+00:00" -title: "Swift 软件包注册表" -slug: "swift" -weight: 95 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Swift" - weight: 95 - identifier: "swift" ---- - -# Swift 软件包注册表 - -为您的用户或组织发布 [Swift](https://www.swift.org/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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，请使用[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.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 -``` diff --git a/docs/content/doc/usage/packages/vagrant.en-us.md b/docs/content/doc/usage/packages/vagrant.en-us.md deleted file mode 100644 index 583bbc199b..0000000000 --- a/docs/content/doc/usage/packages/vagrant.en-us.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -date: "2022-08-23T00:00:00+00:00" -title: "Vagrant Package Registry" -slug: "vagrant" -weight: 120 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Vagrant" - weight: 120 - identifier: "vagrant" ---- - -# Vagrant Package Registry - -Publish [Vagrant](https://www.vagrantup.com/) packages for your user or organization. - -**Table of Contents** - -{{< toc >}} - -## Requirements - -To work with the Vagrant package registry, you need [Vagrant](https://www.vagrantup.com/downloads) and a tool to make HTTP requests like `curl`. - -## Publish a package - -Publish a Vagrant box by performing a HTTP PUT request to the registry: - -``` -PUT https://gitea.example.com/api/packages/{owner}/vagrant/{package_name}/{package_version}/{provider}.box -``` - -| Parameter | Description | -| ----------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | -| `package_version` | The package version, semver compatible. | -| `provider` | One of the [supported provider names](https://www.vagrantup.com/docs/providers). | - -Example for uploading a 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 -``` - -You cannot publish a box if a box of the same name, version and provider already exists. You must delete the existing package first. - -## Install a package - -To install a box from the package registry, execute the following command: - -```shell -vagrant box add "https://gitea.example.com/api/packages/{owner}/vagrant/{package_name}" -``` - -| Parameter | Description | -| -------------- | ----------- | -| `owner` | The owner of the package. | -| `package_name` | The package name. | - -For example: - -```shell -vagrant box add "https://gitea.example.com/api/packages/testuser/vagrant/test_system" -``` - -This will install the latest version of the package. To add a specific version, use the `--box-version` parameter. -If the registry is private you can pass your [personal access token]({{< relref "doc/development/api-usage.en-us.md#authentication" >}}) in the `VAGRANT_CLOUD_TOKEN` environment variable. - -## Supported commands - -``` -vagrant box add -``` diff --git a/docs/content/doc/usage/packages/vagrant.zh-cn.md b/docs/content/doc/usage/packages/vagrant.zh-cn.md deleted file mode 100644 index ddcec9e4c9..0000000000 --- a/docs/content/doc/usage/packages/vagrant.zh-cn.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -date: "2022-08-23T00:00:00+00:00" -title: "Vagrant 软件包注册表" -slug: "vagrant" -weight: 120 -draft: false -toc: false -menu: - sidebar: - parent: "packages" - name: "Vagrant" - weight: 120 - identifier: "vagrant" ---- - -# Vagrant 软件包注册表 - -为您的用户或组织发布 [Vagrant](https://www.vagrantup.com/) 软件包。 - -**目录** - -{{< toc >}} - -## 要求 - -要使用 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` 参数。 -如果注册表是私有的，您可以将您的[个人访问令牌]({{< relref "doc/development/api-usage.zh-cn.md#通过-api-认证" >}})传递给 `VAGRANT_CLOUD_TOKEN` 环境变量。 - -## 支持的命令 - -``` -vagrant box add -``` diff --git a/docs/content/doc/usage/permissions.en-us.md b/docs/content/doc/usage/permissions.en-us.md deleted file mode 100644 index 655c67de86..0000000000 --- a/docs/content/doc/usage/permissions.en-us.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -date: "2021-12-13:10:10+08:00" -title: "Permissions" -slug: "permissions" -weight: 14 -toc: false -draft: false -aliases: - - /en-us/permissions -menu: - sidebar: - parent: "usage" - name: "Permissions" - weight: 14 - identifier: "permissions" ---- - -# Permissions - -**Table of Contents** - -{{< toc >}} - -Gitea supports permissions for repository so that you can give different access for different people. At first, we need to know about `Unit`. - -## Unit - -In Gitea, we call a sub module of a repository `Unit`. Now we have following possible units. - -| Name | Description | Permissions | -| --------------- | ---------------------------------------------------- | ----------- | -| Code | Access source code, files, commits and branches. | Read Write | -| Issues | Organize bug reports, tasks and milestones. | Read Write | -| PullRequests | Enable pull requests and code reviews. | Read Write | -| Releases | Track project versions and downloads. | Read Write | -| Wiki | Write and share documentation with collaborators. | Read Write | -| ExternalWiki | Link to an external wiki | Read | -| ExternalTracker | Link to an external issue tracker | Read | -| Projects | The URL to the template repository | Read Write | -| Packages | Packages which linked to this repository | Read Write | -| Actions | Review actions logs or restart/cacnel pipelines | Read Write | -| Settings | Manage the repository | Admin | - -With different permissions, people could do different things with these units. - -| Name | Read | Write | Admin | -| --------------- | ------------------------------------------------- | ---------------------------- | ------------------------- | -| Code | View code trees, files, commits, branches and etc. | Push codes. | - | -| Issues | View issues and create new issues. | Add labels, assign, close | - | -| PullRequests | View pull requests and create new pull requests. | Add labels, assign, close | - | -| Releases | View releases and download files. | Create/Edit releases | - | -| Wiki | View wiki pages. Clone the wiki repository. | Create/Edit wiki pages, push | - | -| ExternalWiki | Link to an external wiki | - | - | -| ExternalTracker | Link to an external issue tracker | - | - | -| Projects | View the boards | Change issues across boards | - | -| Packages | View the packages | Upload/Delete packages | - | -| Actions | View the Actions logs | Approve / Cancel / Restart | - | -| Settings | - | - | Manage the repository | - -And there are some differences for permissions between individual repositories and organization repositories. - -## Individual Repository - -For individual repositories, the creators are the only owners of repositories and have no limit to change anything of this -repository or delete it. Repositories owners could add collaborators to help maintain the repositories. Collaborators could have `Read`, `Write` and `Admin` permissions. - -For a private repository, the experience is similar to visiting an anonymous public repository. You have access to all the available content within the repository, including the ability to clone the code, create issues, respond to issue comments, submit pull requests, and more. If you have 'Write' permission, you can push code to specific branches of the repository, provided it's permitted by the branch protection rules. Additionally, you can make changes to the wiki pages. With 'Admin' permission, you have the ability to modify the repository's settings. - -But you cannot delete or transfer this repository if you are not that repository's owner. - -## Organization Repository - -For individual repositories, the owner is the user who created it. For organization repositories, the owners are the members of the owner team on this organization. All the permissions depends on the team permission settings. - -### Owner Team - -The owner team will be created when the organization is created, and the creator will become the first member of the owner team. The owner team cannot be deleted and there is at least one member. - -### Admin Team - -When creating teams, there are two types of teams. One is the admin team, another is the general team. An admin team can be created to manage some of the repositories, whose members can do anything with these repositories. Only members of the owner or admin team can create a new team. - -### General Team - -A general team in an organization has unit permissions settings. It can have members and repositories scope. - -- A team could access all the repositories in this organization or special repositories. -- A team could also be allowed to create new repositories or not. - -The General team can be created to do the operations allowed by their permissions. One member could join multiple teams. diff --git a/docs/content/doc/usage/permissions.zh-cn.md b/docs/content/doc/usage/permissions.zh-cn.md deleted file mode 100644 index 3163633589..0000000000 --- a/docs/content/doc/usage/permissions.zh-cn.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "权限" -slug: "permissions" -weight: 14 -toc: false -draft: false -aliases: - - /zh-cn/permissions -menu: - sidebar: - parent: "usage" - name: "权限" - weight: 14 - identifier: "permissions" ---- - -# 权限 - -**目录** - -{{< toc >}} - -Gitea 支持对仓库进行权限管理，这样您就可以为不同的人员提供不同的访问权限。首先，我们需要了解 `单元（Unit）`。 - -## 单元（Unit） - -在 Gitea 中，我们将仓库的子模块称为 `单元（Unit）`。现在我们有以下几个单元。 - -| 名称 | 描述 | 权限 | -| ----------------- | --------------------------------------------------- | ------------ | -| 代码 | 访问源代码、文件、提交和分支。 | 读取 写入 | -| 工单 | 组织缺陷报告、任务和里程碑。 | 读取 写入 | -| 合并请求 | 启用合并请求和代码审核。 | 读取 写入 | -| 发布 | 跟踪项目版本和下载。 | 读取 写入 | -| 维基 | 与协作者编写和共享文档。 | 读取 写入 | -| 外部维基 | 链接到外部维基。 | 读取 | -| 外部工单跟踪器 | 链接到外部工单跟踪器。 | 读取 | -| 项目 | 模板仓库的 URL。 | 读取 写入 | -| 设置 | 管理仓库。 | 管理员 | - -通过不同的权限，用户可以在这些单元上执行不同的操作。 - -| 名称 | 读取 | 写入 | 管理员 | -| ----------------- | -------------------------------------------------- | ------------------------------ | ------------------------- | -| 代码 | 查看代码树、文件、提交、分支等。 | 推送代码。 | - | -| 工单 | 查看工单并创建新工单。 | 添加标签、分配、关闭工单。 | - | -| 合并请求 | 查看合并请求并创建新合并请求。 | 添加标签、分配、关闭合并请求。 | - | -| 发布 | 查看发布和下载文件。 | 创建/编辑发布。 | - | -| 维基 | 查看维基页面。克隆维基仓库。 | 创建/编辑维基页面，推送更改。 | - | -| 外部维基 | 链接到外部维基。 | - | - | -| 外部工单跟踪器 | 链接到外部工单跟踪器。 | - | - | -| 项目 | 查看面板。 | 在面板之间移动工单。 | - | -| 设置 | - | - | 管理仓库 | - -个人仓库和组织仓库之间的权限存在一些差异。 - -## 个人仓库 - -对于个人仓库，创建者是仓库的唯一所有者，对于该仓库的任何更改或删除没有限制。仓库所有者可以添加协作者来帮助维护仓库。协作者可以拥有 `读取（Read）`、`写入（Write）` 和 `管理员（Admin）` 权限。 - -## 组织仓库 - -与个人仓库不同，组织仓库的所有者是组织的所有者团队。 - -### 团队 - -组织中的一个团队具有单元权限设置。它可以拥有成员和仓库的范围。团队可以访问组织中的所有仓库或者由所有者团队授权访问的特定仓库。团队也可以被允许创建新的仓库。 - -所有者团队（Owners）将在创建组织时自动创建，并且创建者将成为所有者团队的第一个成员。 -组织的每个成员必须至少属于一个团队。所有者团队不能被删除，只有所有者团队的成员可以创建新的团队。可以创建一个管理员团队来管理某些仓库，该团队的成员可以对这些仓库进行任何操作。可以由所有者团队创建一个生成团队来执行其权限允许的操作。 diff --git a/docs/content/doc/usage/profile-readme.en-us.md b/docs/content/doc/usage/profile-readme.en-us.md deleted file mode 100644 index a290eadbb1..0000000000 --- a/docs/content/doc/usage/profile-readme.en-us.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2023-03-02T21:00:00+05:00" -title: "Profile READMEs" -slug: "profile-readme" -weight: 12 -toc: false -draft: false -menu: - sidebar: - parent: "usage" - name: "Profile READMEs" - weight: 12 - identifier: "profile-readme" ---- - -# Profile READMEs - -To display a markdown file in your Gitea profile page, simply make a repository named ".profile" and edit the README.md file inside. Gitea will automatically pull this file in and display it above your repositories. - -Note. You are welcome to make this repository private. Doing so will hide your source files from public viewing and allow you to privitize certain files. However, the README.md file will be the only file present on your profile. If you wish to have an entirely private .profile repository, remove or rename the README.md file. diff --git a/docs/content/doc/usage/profile-readme.zh-cn.md b/docs/content/doc/usage/profile-readme.zh-cn.md deleted file mode 100644 index a253fcaf24..0000000000 --- a/docs/content/doc/usage/profile-readme.zh-cn.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "个人资料 README" -slug: "profile-readme" -weight: 12 -toc: false -draft: false -menu: - sidebar: - parent: "usage" - name: "个人资料 README" - weight: 12 - identifier: "profile-readme" ---- - -# 个人资料 README - -要在您的 Gitea 个人资料页面显示一个 Markdown 文件，只需创建一个名为 ".profile" 的仓库，并编辑其中的 README.md 文件。Gitea 将自动获取该文件并在您的仓库上方显示。 - -注意：您可以将此仓库设为私有。这样可以隐藏您的源文件，使其对公众不可见，并允许您将某些文件设为私有。但是，README.md 文件将是您个人资料上唯一存在的文件。如果您希望完全私有化 .profile 仓库，则需删除或重命名 README.md 文件。 diff --git a/docs/content/doc/usage/protected-tags.en-us.md b/docs/content/doc/usage/protected-tags.en-us.md deleted file mode 100644 index c5e763659d..0000000000 --- a/docs/content/doc/usage/protected-tags.en-us.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -date: "2021-05-14T00:00:00-00:00" -title: "Protected tags" -slug: "protected-tags" -weight: 45 -toc: false -draft: false -aliases: - - /en-us/protected-tags -menu: - sidebar: - parent: "usage" - name: "Protected tags" - weight: 45 - identifier: "protected-tags" ---- - -# Protected tags - -Protected tags allow control over who has permission to create or update Git tags. Each rule allows you to match either an individual tag name, or use an appropriate pattern to control multiple tags at once. - -**Table of Contents** - -{{< toc >}} - -## Setting up protected tags - -To protect a tag, you need to follow these steps: - -1. Go to the repository’s **Settings** > **Tags** page. -1. Type a pattern to match a name. You can use a single name, a [glob pattern](https://pkg.go.dev/github.com/gobwas/glob#Compile) or a regular expression. -1. Choose the allowed users and/or teams. If you leave these fields empty no one is allowed to create or modify this tag. -1. Select **Save** to save the configuration. - -## Pattern protected tags - -The pattern uses [glob](https://pkg.go.dev/github.com/gobwas/glob#Compile) or regular expressions to match a tag name. For regular expressions you need to enclose the pattern in slashes. - -Examples: - -| Type | Pattern Protected Tag | Possible Matching Tags | -| ----- | ------------------------ | --------------------------------------- | -| Glob | `v*` | `v`, `v-1`, `version2` | -| Glob | `v[0-9]` | `v0`, `v1` up to `v9` | -| Glob | `*-release` | `2.1-release`, `final-release` | -| Glob | `gitea` | only `gitea` | -| Glob | `*gitea*` | `gitea`, `2.1-gitea`, `1_gitea-release` | -| Glob | `{v,rel}-*` | `v-`, `v-1`, `v-final`, `rel-`, `rel-x` | -| Glob | `*` | matches all possible tag names | -| Regex | `/\Av/` | `v`, `v-1`, `version2` | -| Regex | `/\Av[0-9]\z/` | `v0`, `v1` up to `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/` | only `gitea` | -| Regex | `/^gitea$/` | only `gitea` | -| Regex | `/\A(v\|rel)-/` | `v-`, `v-1`, `v-final`, `rel-`, `rel-x` | -| Regex | `/.+/` | matches all possible tag names | diff --git a/docs/content/doc/usage/protected-tags.zh-cn.md b/docs/content/doc/usage/protected-tags.zh-cn.md deleted file mode 100644 index 7d43462d32..0000000000 --- a/docs/content/doc/usage/protected-tags.zh-cn.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "受保护的标签" -slug: "protected-tags" -weight: 45 -toc: false -draft: false -aliases: - - /zh-cn/protected-tags -menu: - sidebar: - parent: "usage" - name: "受保护的标签" - weight: 45 - identifier: "protected-tags" ---- - -# 受保护的标签 - -受保护的标签允许控制谁有权限创建或更新 Git 标签。每个规则可以匹配单个标签名称，或者使用适当的模式来同时控制多个标签。 - -**目录** - -{{< toc >}} - -## 设置受保护的标签 - -要保护一个标签，你需要按照以下步骤进行操作： - -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 | `/.+/` | 匹配所有可能的标签名称 | diff --git a/docs/content/doc/usage/pull-request.en-us.md b/docs/content/doc/usage/pull-request.en-us.md deleted file mode 100644 index f9f4b38555..0000000000 --- a/docs/content/doc/usage/pull-request.en-us.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -date: "2018-06-01T19:00:00+02:00" -title: "Pull Request" -slug: "pull-request" -weight: 13 -toc: false -draft: false -aliases: - - /en-us/pull-request -menu: - sidebar: - parent: "usage" - name: "Pull Request" - weight: 13 - identifier: "pull-request" ---- - -# Pull Request - -A Pull Request (PR) is a way to propose changes to a repository. -It is a request to merge one branch into another, accompanied by a description of the changes that were made. -Pull Requests are commonly used as a way for contributors to propose changes and for maintainers to review and merge those changes. - -## Creating a pull request - -To create a PR, you'll need to follow these steps: - -1. **Fork the repository** - If you don't have permission to make changes to the repository directly, you'll need to fork the repository to your own account. -This creates a copy of the repository that you can make changes to. - -2. **Create a branch (optional)** - Create a new branch on your forked repository that contains the changes you want to propose. -Give the branch a descriptive name that indicates what the changes are for. - -3. **Make your changes** - Make the changes you want, commit, and push them to your forked repository. - -4. **Create the PR** - Go to the original repository and go to the "Pull Requests" tab. Click the "New Pull Request" button and select your new branch as the source branch. -Enter a descriptive title and description for your Pull Request and click "Create Pull Request". - -## Reviewing a pull request - -When a PR is created, it triggers a review process. The maintainers of the repository are notified of the PR and can review the changes that were made. -They can leave comments, request changes, or approve the changes. - -If the maintainers request changes, you'll need to make those changes in your branch and push the changes to your forked repository. -The PR will be updated automatically with the new changes. - -If the maintainers approve the changes, they can merge the PR into the repository. - -## Closing a pull request - -If you decide that you no longer want to merge a PR, you can close it. -To close a PR, go to the open PR and click the "Close Pull Request" button. This will close the PR without merging it. - -## "Work In Progress" pull requests - -Marking a pull request as being a work in progress will prevent that pull request from being accidentally merged. -To mark a pull request as being a work in progress, you must prefix its title by `WIP:` or `[WIP]` (case insensitive). -Those values are configurable in your `app.ini` file: - -```ini -[repository.pull-request] -WORK_IN_PROGRESS_PREFIXES=WIP:,[WIP] -``` - -The first value of the list will be used in helpers. - -## Pull Request Templates - -You can find more information about pull request templates at the page [Issue and Pull Request templates](issue-pull-request-templates). diff --git a/docs/content/doc/usage/pull-request.zh-cn.md b/docs/content/doc/usage/pull-request.zh-cn.md deleted file mode 100644 index baf57787c8..0000000000 --- a/docs/content/doc/usage/pull-request.zh-cn.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -date: "2018-06-01T19:00:00+02:00" -title: "合并请求" -slug: "pull-request" -weight: 13 -toc: false -draft: false -aliases: - - /zh-cn/pull-request -menu: - sidebar: - parent: "usage" - name: "Pull Request" - weight: 13 - identifier: "pull-request" ---- - -# 合并请求 - -## 在`合并请求`中使用“Work In Progress”标记 - -您可以通过在一个进行中的 pull request 的标题上添加前缀 `WIP:` 或者 `[WIP]`（此处大小写敏感）来防止它被意外合并，具体的前缀设置可以在配置文件 `app.ini` 中找到： - -``` -[repository.pull-request] -WORK_IN_PROGRESS_PREFIXES=WIP:,[WIP] -``` - -列表的第一个值将用于 helpers 程序。 - -## 合并请求模板 - -有关合并请求模板的更多信息请您移步 : [工单与合并请求模板](issue-pull-request-templates) diff --git a/docs/content/doc/usage/pull-request.zh-tw.md b/docs/content/doc/usage/pull-request.zh-tw.md deleted file mode 100644 index 9bbfa87863..0000000000 --- a/docs/content/doc/usage/pull-request.zh-tw.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -date: "2018-06-01T19:00:00+02:00" -title: "合併請求" -slug: "pull-request" -weight: 13 -toc: false -draft: false -aliases: - - /zh-tw/pull-request -menu: - sidebar: - parent: "usage" - name: "合併請求" - weight: 13 - identifier: "pull-request" ---- - -# 合併請求 - -## 「還在進行中（WIP）」的合併請求 - -將合併請求標記為還在進行中（Work In Progress, WIP）可避免意外地被合併。 -要將合併請求標記為還在進行中請在標題中使用 `WIP:` 或 `[WIP]` 前綴（不分大小寫）。這些值可在您的 `app.ini` 中設定： - -```ini -[repository.pull-request] -WORK_IN_PROGRESS_PREFIXES=WIP:,[WIP] -``` - -網頁提示會使用第一個值作為範例。 - -## 合併請求範本 - -您可以在[問題與合併請求範本](issue-pull-request-templates)找到更多關於合併請求範本的資訊。 diff --git a/docs/content/doc/usage/push.en-us.md b/docs/content/doc/usage/push.en-us.md deleted file mode 100644 index 45190d88ca..0000000000 --- a/docs/content/doc/usage/push.en-us.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -date: "2020-07-06T16:00:00+02:00" -title: "Push" -slug: "push" -weight: 15 -toc: false -draft: false -aliases: - - /en-us/push-to-create - - /en-us/push-options -menu: - sidebar: - parent: "usage" - name: "Push" - weight: 15 - identifier: "push" ---- - -**Table of Contents** - -{{< toc >}} - -There are some additional features when pushing commits to Gitea server. - -# Open PR through Push - -When you push commits to a non-default branch for the first time, -you will receive a link you can click on to visit the compare page of your branch compared to your main branch. -From there, it's easy to create a pull request, even if you want to target another branch. - - - -# Push Options - -In Gitea `1.13`, support for some [push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt) -were added. - -## Supported Options - -- `repo.private` (true|false) - Change the repository's visibility. - - This is particularly useful when combined with push-to-create. - -- `repo.template` (true|false) - Change whether the repository is a template. - -Example of changing a repository's visibility to public: - -```shell -git push -o repo.private=false -u origin main -``` - -# Push To Create - -Push to create is a feature that allows you to push to a repository that does not exist yet in Gitea. This is useful for automation and for allowing users to create repositories without having to go through the web interface. This feature is disabled by default. - -## Enabling Push To Create - -In the `app.ini` file, set `ENABLE_PUSH_CREATE_USER` to `true` and `ENABLE_PUSH_CREATE_ORG` to `true` if you want to allow users to create repositories in their own user account and in organizations they are a member of respectively. Restart Gitea for the changes to take effect. You can read more about these two options in the [Configuration Cheat Sheet]({{< relref "doc/administration/config-cheat-sheet.en-us.md#repository-repository" >}}). - -## Using Push To Create - -Assuming you have a git repository in the current directory, you can push to a repository that does not exist yet in Gitea by running the following command: - -```shell -# Add the remote you want to push to -git remote add origin git@{domain}:{username}/{repo name that does not exist yet}.git - -# push to the remote -git push -u origin main -``` - -This assumes you are using an SSH remote, but you can also use HTTPS remotes as well. - -Push-to-create will default to the visibility defined by `DEFAULT_PUSH_CREATE_PRIVATE` in `app.ini`. diff --git a/docs/content/doc/usage/push.zh-cn.md b/docs/content/doc/usage/push.zh-cn.md deleted file mode 100644 index a12e1b5349..0000000000 --- a/docs/content/doc/usage/push.zh-cn.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "推送" -slug: "push" -weight: 15 -toc: false -draft: false -aliases: - - /zh-cn/push-to-create - - /zh-cn/push-options -menu: - sidebar: - parent: "usage" - name: "推送" - weight: 15 - identifier: "push" ---- - -**目录** - -{{< toc >}} - -在将提交推送到 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 以使更改生效。您可以在 [配置速查表]({{< relref "doc/administration/config-cheat-sheet.zh-cn.md#repository-repository" >}}) 中了解有关这两个选项的更多信息。 - -## 使用推送创建 - -假设您在当前目录中有一个 git 仓库，您可以通过运行以下命令将提交推送到在 Gitea 中尚不存在的仓库： - -```shell -# 添加要推送到的远程仓库 -git remote add origin git@{domain}:{username}/{尚不存在的仓库名称}.git - -# 推送到远程仓库 -git push -u origin main -``` - -这假设您使用的是 SSH 远程，但您也可以使用 HTTPS 远程。 - -推送创建将默认使用 `app.ini` 中定义的可见性 `DEFAULT_PUSH_CREATE_PRIVATE`。 diff --git a/docs/content/doc/usage/push.zh-tw.md b/docs/content/doc/usage/push.zh-tw.md deleted file mode 100644 index 5fe5052c11..0000000000 --- a/docs/content/doc/usage/push.zh-tw.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -date: "2020-07-06T16:00:00+02:00" -title: "使用: Push" -slug: "push" -weight: 15 -toc: false -draft: false -aliases: - - /zh-tw/push-options -menu: - sidebar: - parent: "usage" - name: "Push" - weight: 15 - identifier: "push" ---- - -**Table of Contents** - -{{< toc >}} - -There are some additional features when pushing commits to Gitea server. - -# Push Merge Hint - -When you pushing commits to a non-default branch, you will get an information from -Gitea which is a link, you can click the link and go to a compare page. It's a quick -way to create a pull request or a code review yourself in the Gitea UI. - - - -# Push Options - -Gitea 從 `1.13` 版開始支援某些 [push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt) -。 - -## 支援的 Options - -- `repo.private` (true|false) - 修改儲存庫的可見性。 - - 與 push-to-create 一起使用時特別有用。 - -- `repo.template` (true|false) - 修改儲存庫是否為範本儲存庫。 - -以下範例修改儲存庫的可見性為公開： - -```shell -git push -o repo.private=false -u origin main -``` - -# Push To Create - -Push to create is a feature that allows you to push to a repository that does not exist yet in Gitea. This is useful for automation and for allowing users to create repositories without having to go through the web interface. This feature is disabled by default. - -## Enabling Push To Create - -In the `app.ini` file, set `ENABLE_PUSH_CREATE_USER` to `true` and `ENABLE_PUSH_CREATE_ORG` to `true` if you want to allow users to create repositories in their own user account and in organizations they are a member of respectively. Restart Gitea for the changes to take effect. You can read more about these two options in the [Configuration Cheat Sheet]({{< relref "doc/administration/config-cheat-sheet.zh-tw.md#repository-repository" >}}). - -## Using Push To Create - -Assuming you have a git repository in the current directory, you can push to a repository that does not exist yet in Gitea by running the following command: - -```shell -# Add the remote you want to push to -git remote add origin git@{domain}:{username}/{repo name that does not exist yet}.git - -# push to the remote -git push -u origin main -``` - -This assumes you are using an SSH remote, but you can also use HTTPS remotes as well. diff --git a/docs/content/doc/usage/repo-mirror.en-us.md b/docs/content/doc/usage/repo-mirror.en-us.md deleted file mode 100644 index 157b6c124e..0000000000 --- a/docs/content/doc/usage/repo-mirror.en-us.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -date: "2021-05-13T00:00:00-00:00" -title: "Repository Mirror" -slug: "repo-mirror" -weight: 45 -toc: false -draft: false -aliases: - - /en-us/repo-mirror -menu: - sidebar: - parent: "usage" - name: "Repository Mirror" - weight: 45 - identifier: "repo-mirror" ---- - -# Repository Mirror - -Repository mirroring allows for the mirroring of repositories to and from external sources. You can use it to mirror branches, tags, and commits between repositories. - -**Table of Contents** - -{{< toc >}} - -## Use cases - -The following are some possible use cases for repository mirroring: - -- You migrated to Gitea but still need to keep your project in another source. In that case, you can simply set it up to mirror to Gitea (pull) and all the essential history of commits, tags, and branches are available in your Gitea instance. -- You have old projects in another source that you don’t use actively anymore, but don’t want to remove for archiving purposes. In that case, you can create a push mirror so that your active Gitea repository can push its changes to the old location. - -## Pulling from a remote repository - -For an existing remote repository, you can set up pull mirroring as follows: - -1. Select **New Migration** in the **Create...** menu on the top right. -2. Select the remote repository service. -3. Enter a repository URL. -4. If the repository needs authentication fill in your authentication information. -5. Check the box **This repository will be a mirror**. -6. Select **Migrate repository** to save the configuration. - -The repository now gets mirrored periodically from the remote repository. You can force a sync by selecting **Synchronize Now** in the repository settings. - -:exclamation::exclamation: **NOTE:** You can only set up pull mirroring for repos that don't exist yet on your instance. Once the repo is created, you can't convert it into a pull mirror anymore. :exclamation::exclamation: - -## Pushing to a remote repository - -For an existing repository, you can set up push mirroring as follows: - -1. In your repository, go to **Settings** > **Repository**, and then the **Mirror Settings** section. -2. Enter a repository URL. -3. If the repository needs authentication expand the **Authorization** section and fill in your authentication information. Note that the requested **password** can also be your access token. -4. Select **Add Push Mirror** to save the configuration. - -The repository now gets mirrored periodically to the remote repository. You can force a sync by selecting **Synchronize Now**. In case of an error a message displayed to help you resolve it. - -:exclamation::exclamation: **NOTE:** This will force push to the remote repository. This will overwrite any changes in the remote repository! :exclamation::exclamation: - -### Setting up a push mirror from Gitea to GitHub - -To set up a mirror from Gitea to GitHub, you need to follow these steps: - -1. Create a [GitHub personal access token](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) with the *public_repo* box checked. -2. Create a repository with that name on GitHub. Unlike Gitea, GitHub does not support creating repositories by pushing to the remote. You can also use an existing remote repo if it has the same commit history as your Gitea repo. -3. In the settings of your Gitea repo, fill in the **Git Remote Repository URL**: `https://github.com/<your_github_group>/<your_github_project>.git`. -4. Fill in the **Authorization** fields with your GitHub username and the personal access token as **Password**. -5. (Optional, available on Gitea 1.18+) Select `Sync when new commits are pushed` so that the mirror will be updated as well as soon as there are changes. You can also disable the periodic sync if you like. -6. Select **Add Push Mirror** to save the configuration. - -The repository pushes shortly thereafter. To force a push, select the **Synchronize Now** button. - -### Setting up a push mirror from Gitea to GitLab - -To set up a mirror from Gitea to GitLab, you need to follow these steps: - -1. Create a [GitLab personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) with *write_repository* scope. -2. Fill in the **Git Remote Repository URL**: `https://<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`. -3. Fill in the **Authorization** fields with `oauth2` as **Username** and your GitLab personal access token as **Password**. -4. Select **Add Push Mirror** to save the configuration. - -The repository pushes shortly thereafter. To force a push, select the **Synchronize Now** button. - -### Setting up a push mirror from Gitea to Bitbucket - -To set up a mirror from Gitea to Bitbucket, you need to follow these steps: - -1. Create a [Bitbucket app password](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/) with the *Repository Write* box checked. -2. Fill in the **Git Remote Repository URL**: `https://bitbucket.org/<your_bitbucket_group_or_name>/<your_bitbucket_project>.git`. -3. Fill in the **Authorization** fields with your Bitbucket username and the app password as **Password**. -4. Select **Add Push Mirror** to save the configuration. - -The repository pushes shortly thereafter. To force a push, select the **Synchronize Now** button. - -### Mirror an existing ssh repository - -Currently gitea supports no ssh push mirrors. You can work around this by adding a `post-receive` hook to your gitea repository that pushes manually. - -1. Make sure the user running gitea has access to the git repo you are trying to mirror to from shell. -2. On the Webinterface at the repository settings > git hooks add a post-receive hook for the mirror. I.e. - -``` -#!/usr/bin/env bash -git push --mirror --quiet git@github.com:username/repository.git &>/dev/null & -echo "GitHub mirror initiated .." -``` diff --git a/docs/content/doc/usage/repo-mirror.zh-cn.md b/docs/content/doc/usage/repo-mirror.zh-cn.md deleted file mode 100644 index d327338bad..0000000000 --- a/docs/content/doc/usage/repo-mirror.zh-cn.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "仓库镜像" -slug: "repo-mirror" -weight: 45 -toc: false -draft: false -aliases: - - /zh-cn/repo-mirror -menu: - sidebar: - parent: "usage" - name: "仓库镜像" - weight: 45 - identifier: "repo-mirror" ---- - -# 仓库镜像 - -仓库镜像允许将仓库与外部源之间进行镜像。您可以使用它在仓库之间镜像分支、标签和提交。 - -**目录** - -{{< toc >}} - -## 使用场景 - -以下是一些仓库镜像的可能使用场景： - -- 您迁移到了 Gitea，但仍需要在其他源中保留您的项目。在这种情况下，您可以简单地设置它以进行镜像到 Gitea（拉取），这样您的 Gitea 实例中就可以获取到所有必要的提交历史、标签和分支。 -- 您在其他源中有一些旧项目，您不再主动使用，但出于归档目的不想删除。在这种情况下，您可以创建一个推送镜像，以便您的活跃的 Gitea 仓库可以将其更改推送到旧位置。 - -## 从远程仓库拉取 - -对于现有的远程仓库，您可以按照以下步骤设置拉取镜像： - -1. 在右上角的“创建...”菜单中选择“迁移外部仓库”。 -2. 选择远程仓库服务。 -3. 输入仓库的 URL。 -4. 如果仓库需要身份验证，请填写您的身份验证信息。 -5. 选中“该仓库将是一个镜像”复选框。 -6. 选择“迁移仓库”以保存配置。 - -现在，该仓库会定期从远程仓库进行镜像。您可以通过在仓库设置中选择“立即同步”来强制进行同步。 - -:exclamation::exclamation: **注意：**您只能为尚不存在于您的实例上的仓库设置拉取镜像。一旦仓库创建成功，您就无法再将其转换为拉取镜像。:exclamation::exclamation: - -## 推送到远程仓库 - -对于现有的仓库，您可以按照以下步骤设置推送镜像： - -1. 在仓库中，转到**设置** > **仓库**，然后进入**镜像设置**部分。 -2. 输入一个仓库的 URL。 -3. 如果仓库需要身份验证，请展开**授权**部分并填写您的身份验证信息。请注意，所请求的**密码**也可以是您的访问令牌。 -4. 选择**添加推送镜像**以保存配置。 - -该仓库现在会定期镜像到远程仓库。您可以通过选择**立即同步**来强制同步。如果出现错误，会显示一条消息帮助您解决问题。 - -: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. 选择**添加推送镜像**以保存配置。 - -仓库会很快进行推送。要强制推送，请选择**立即同步**按钮。 diff --git a/docs/content/doc/usage/secrets.en-us.md b/docs/content/doc/usage/secrets.en-us.md deleted file mode 100644 index c82628f50c..0000000000 --- a/docs/content/doc/usage/secrets.en-us.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -date: "2022-12-19T21:26:00+08:00" -title: "Secrets" -slug: "secrets" -weight: 50 -draft: false -toc: false -aliases: - - /en-us/secrets -menu: - sidebar: - parent: "usage" - name: "Secrets" - weight: 50 - identifier: "usage-secrets" ---- - -# Secrets - -Secrets allow you to store sensitive information in your user, organization or repository. -Secrets are available on Gitea 1.19+ and are only visible in 1.20+ when ACTIONS are enabled. - -# Naming your secrets - -The following rules apply to secret names: - -- Secret names can only contain alphanumeric characters (`[a-z]`, `[A-Z]`, `[0-9]`) or underscores (`_`). Spaces are not allowed. - -- Secret names must not start with the `GITHUB_` and `GITEA_` prefix. - -- Secret names must not start with a number. - -- Secret names are not case-sensitive. - -- Secret names must be unique at the level they are created at. - -For example, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level. - -If a secret with the same name exists at multiple levels, the secret at the lowest level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence. diff --git a/docs/content/doc/usage/secrets.zh-cn.md b/docs/content/doc/usage/secrets.zh-cn.md deleted file mode 100644 index 534fc52eeb..0000000000 --- a/docs/content/doc/usage/secrets.zh-cn.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "密钥管理" -slug: "secrets" -weight: 50 -draft: false -toc: false -aliases: - - /zh-cn/secrets -menu: - sidebar: - parent: "usage" - name: "密钥管理" - weight: 50 - identifier: "usage-secrets" ---- - -# 密钥管理 - -密钥管理允许您在用户、组织或仓库中存储敏感信息。 -密钥管理在 Gitea 1.19+ 版本中可用。 - -# 设置密钥名称 - -以下规则适用于密钥名称： - -- 密钥名称只能包含字母数字字符 (`[a-z]`, `[A-Z]`, `[0-9]`) 或下划线 (`_`)。不允许使用空格。 - -- 密钥名称不能以 `GITHUB_` 和 `GITEA_` 前缀开头。 - -- 密钥名称不能以数字开头。 - -- 密钥名称不区分大小写。 - -- 密钥名称在创建它们的级别上必须是唯一的。 - -例如，对于在仓库级别创建的密钥，它在该仓库中必须具有唯一的名称；对于在组织级别创建的密钥，它在该级别上必须具有唯一的名称。 - -如果在多个级别上存在具有相同名称的密钥，则最低级别的密钥优先生效。例如，如果组织级别的密钥与仓库级别的密钥具有相同的名称，则仓库级别的密钥将优先生效。 diff --git a/docs/content/doc/usage/template-repositories.en-us.md b/docs/content/doc/usage/template-repositories.en-us.md deleted file mode 100644 index 5687861b8c..0000000000 --- a/docs/content/doc/usage/template-repositories.en-us.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -date: "2019-11-28:00:00+02:00" -title: "Template Repositories" -slug: "template-repositories" -weight: 14 -toc: false -draft: false -aliases: - - /en-us/template-repositories -menu: - sidebar: - parent: "usage" - name: "Template Repositories" - weight: 14 - identifier: "template-repositories" ---- - -# Template Repositories - -**Table of Contents** - -{{< toc >}} - -Gitea `1.11.0` and above includes template repositories, and one feature implemented with them is auto-expansion of specific variables within your template files. - -To tell Gitea which files to expand, you must include a `template` file inside the `.gitea` directory of the template repository. - -Gitea uses [gobwas/glob](https://github.com/gobwas/glob) for its glob syntax. It closely resembles a traditional `.gitignore`, however there may be slight differences. - -## Example `.gitea/template` file - -All paths are relative to the base of the repository - -```gitignore -# All .go files, anywhere in the repository -**.go - -# All text files in the text directory -text/*.txt - -# A specific file -a/b/c/d.json - -# Batch files in both upper or lower case can be matched -**.[bB][aA][tT] -``` - -**NOTE:** The `template` file will be removed from the `.gitea` directory when a repository is generated from the template. - -## Variable Expansion - -In any file matched by the above globs, certain variables will be expanded. - -Matching filenames and paths can also be expanded, and are conservatively sanitized to support cross-platform filesystems. - -All variables must be of the form `$VAR` or `${VAR}`. To escape an expansion, use a double `$$`, such as `$$VAR` or `$${VAR}` - -| Variable | Expands To | Transformable | -| -------------------- | --------------------------------------------------- | ------------- | -| REPO_NAME | The name of the generated repository | ✓ | -| TEMPLATE_NAME | The name of the template repository | ✓ | -| REPO_DESCRIPTION | The description of the generated repository | ✘ | -| TEMPLATE_DESCRIPTION | The description of the template repository | ✘ | -| REPO_OWNER | The owner of the generated repository | ✓ | -| TEMPLATE_OWNER | The owner of the template repository | ✓ | -| REPO_LINK | The URL to the generated repository | ✘ | -| TEMPLATE_LINK | The URL to the template repository | ✘ | -| REPO_HTTPS_URL | The HTTP(S) clone link for the generated repository | ✘ | -| TEMPLATE_HTTPS_URL | The HTTP(S) clone link for the template repository | ✘ | -| REPO_SSH_URL | The SSH clone link for the generated repository | ✘ | -| TEMPLATE_SSH_URL | The SSH clone link for the template repository | ✘ | - -## Transformers :robot: - -Gitea `1.12.0` adds a few transformers to some of the applicable variables above. - -For example, to get `REPO_NAME` in `PASCAL`-case, your template would use `${REPO_NAME_PASCAL}` - -Feeding `go-sdk` to the available transformers yields... - -| Transformer | Effect | -| ----------- | ------ | -| SNAKE | go_sdk | -| KEBAB | go-sdk | -| CAMEL | goSdk | -| PASCAL | GoSdk | -| LOWER | go-sdk | -| UPPER | GO-SDK | -| TITLE | Go-Sdk | diff --git a/docs/content/doc/usage/template-repositories.zh-cn.md b/docs/content/doc/usage/template-repositories.zh-cn.md deleted file mode 100644 index f8dfe1064d..0000000000 --- a/docs/content/doc/usage/template-repositories.zh-cn.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -date: "2023-05-23T09:00:00+08:00" -title: "模板仓库" -slug: "template-repositories" -weight: 14 -toc: false -draft: false -aliases: - - /zh-cn/template-repositories -menu: - sidebar: - parent: "usage" - name: "模板仓库" - weight: 14 - identifier: "template-repositories" ---- - -# 模板仓库 - -**目录** - -{{< toc >}} - -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 | diff --git a/docs/content/doc/usage/webhooks.en-us.md b/docs/content/doc/usage/webhooks.en-us.md deleted file mode 100644 index 24cd48c919..0000000000 --- a/docs/content/doc/usage/webhooks.en-us.md +++ /dev/null @@ -1,196 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Webhooks" -slug: "webhooks" -weight: 30 -toc: false -draft: false -aliases: - - /en-us/webhooks -menu: - sidebar: - parent: "usage" - name: "Webhooks" - weight: 30 - identifier: "webhooks" ---- - -# Webhooks - -Gitea supports webhooks for repository events. This can be configured in the settings -page `/:username/:reponame/settings/hooks` by a repository admin. Webhooks can also be configured on a per-organization and whole system basis. -All event pushes are POST requests. The methods currently supported are: - -- Gitea (can also be a GET request) -- Gogs -- Slack -- Discord -- Dingtalk -- Telegram -- Microsoft Teams -- Feishu -- Wechatwork -- Packagist - -### Event information - -**WARNING**: The `secret` field in the payload is deprecated as of Gitea 1.13.0 and will be removed in 1.14.0: https://github.com/go-gitea/gitea/issues/11755 - -The following is an example of event information that will be sent by Gitea to -a Payload URL: - -``` -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" - } -} -``` - -### Example - -This is an example of how to use webhooks to run a php script upon push requests to the repository. -In your repository Settings, under Webhooks, Setup a Gitea webhook as follows: - -- Target URL: http://mydomain.com/webhook.php -- HTTP Method: POST -- POST Content Type: application/json -- Secret: 123 -- Trigger On: Push Events -- Active: Checked - -Now on your server create the php file webhook.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 -``` - -There is a Test Delivery button in the webhook settings that allows to test the configuration as well as a list of the most Recent Deliveries. - -### Authorization header - -**With 1.19**, Gitea hooks can be configured to send an [authorization header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) to the webhook target. diff --git a/docs/content/doc/usage/webhooks.zh-cn.md b/docs/content/doc/usage/webhooks.zh-cn.md deleted file mode 100644 index 412dad251b..0000000000 --- a/docs/content/doc/usage/webhooks.zh-cn.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Webhooks" -slug: "webhooks" -weight: 30 -toc: false -draft: false -aliases: - - /zh-cn/webhooks -menu: - sidebar: - parent: "usage" - name: "Webhooks" - weight: 30 - identifier: "webhooks" ---- - -# 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的事件信息示例： - -``` -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 - -$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)。 diff --git a/docs/content/doc/usage/webhooks.zh-tw.md b/docs/content/doc/usage/webhooks.zh-tw.md deleted file mode 100644 index ca5991354a..0000000000 --- a/docs/content/doc/usage/webhooks.zh-tw.md +++ /dev/null @@ -1,190 +0,0 @@ ---- -date: "2016-12-01T16:00:00+02:00" -title: "Webhook" -slug: "webhooks" -weight: 30 -toc: false -draft: false -aliases: - - /zh-tw/webhooks -menu: - sidebar: - parent: "usage" - name: "Webhook" - weight: 30 - identifier: "webhooks" ---- - -# Webhook - -Gitea 的儲存庫事件支援 web hook。這可以有儲存庫管理員在設定頁 `/:username/:reponame/settings/hooks` 中調整。Webhook 也可以按照組織調整或按照全系統調整。 -所有的事件推送都是 POST 請求。此方法目前被下列服務支援： - -- Gitea (也可以是 GET 請求) -- Gogs -- Slack -- Discord -- Dingtalk -- Telegram -- Microsoft Teams -- Feishu -- Wechatwork -- Packagist - -### 事件資訊 - -**警告**： Payload 中的 `secret` 欄位已經在 Gitea 1.13.0 棄用，並且將在 1.14.0 移除： https://github.com/go-gitea/gitea/issues/11755 - -下面是一個將由 Gitea 發送到 Payload URL 的事件資訊的範例： - -``` -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" - } -} -``` - -### 範例 - -此範例示範在發生推送事件時，如何使用 webhook 觸發 php 程式。 -使用下列參數在您的儲存庫設定 Webhook 中建立一個 Gitea webhook： - -- 目標 URL： http://mydomain.com/webhook.php -- HTTP 請求方法：POST -- POST Content Type：application/json -- Secret：123 -- 觸發條件：推送事件 -- 啟用：勾選 - -現在請到您的伺服器上建立 webhook.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 設定中有一個傳送測試資料按鈕，它可讓你測試您的設定並將結果顯示於最近傳送記錄。 |