mirror of
https://gitea.com/gitea/docs.git
synced 2026-09-17 19:55:34 +00:00
Fix broken links (#1)
- Always use a relative markdown link so that we can jump even if we edit it in local env or read it in code hosting server. Reviewed-on: https://gitea.com/gitea/docs/pulls/1
This commit is contained in:
@@ -19,7 +19,7 @@ menu:
|
||||
|
||||
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](administration/customizing-gitea.md)).
|
||||
inside the `custom` directory (see [Customizing Gitea](../administration/customizing-gitea.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.
|
||||
@@ -85,7 +85,7 @@ 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](administration/customizing-gitea.md) for details.
|
||||
Gitea normally starts. See [Customizing Gitea](../administration/customizing-gitea.md) for details.
|
||||
|
||||
The `--overwrite` flag allows any existing files in the destination directory to be overwritten.
|
||||
|
||||
|
||||
@@ -762,7 +762,7 @@ and
|
||||
- `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](administration/email-setup.md) for more information.
|
||||
- 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](../administration/email-setup.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.
|
||||
|
||||
@@ -36,7 +36,7 @@ Application settings can be found in file `CustomConf` which is by default,
|
||||
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](administration/config-cheat-sheet.md)
|
||||
- [Quick Cheat Sheet](../administration/config-cheat-sheet.md)
|
||||
- [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`
|
||||
@@ -44,7 +44,7 @@ environment variable; this can be used to override the default path to something
|
||||
`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](administration/environment-variables.md)
|
||||
- [List of Environment Variables](../administration/environment-variables.md)
|
||||
|
||||
:::note
|
||||
Gitea must perform a full restart to see configuration changes.
|
||||
@@ -89,7 +89,7 @@ directory at the top of this document).
|
||||
Every single page of Gitea can be changed. Dynamic content is generated using [go templates](https://pkg.go.dev/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](administration/cmd-embedded.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).
|
||||
To obtain any embedded file (including templates), the [`gitea embedded` tool](../administration/cmd-embedded.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.
|
||||
@@ -110,7 +110,7 @@ just place it under your "$GITEA_CUSTOM/public/assets/" directory (for instance
|
||||
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](administration/adding-legal-pages.md).
|
||||
For more information, see [Adding Legal Pages](../administration/adding-legal-pages.md).
|
||||
|
||||
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
|
||||
@@ -378,10 +378,10 @@ A full list of supported emoji's is at [emoji list](https://gitea.com/gitea/gite
|
||||
|
||||
The built-in themes are `gitea-light`, `gitea-dark`, and `gitea-auto` (which automatically adapts to OS settings).
|
||||
|
||||
The default theme can be changed via `DEFAULT_THEME` in the [ui](administration/config-cheat-sheet.md#ui-ui) section of `app.ini`.
|
||||
The default theme can be changed via `DEFAULT_THEME` in the [ui](../administration/config-cheat-sheet.md#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](administration/config-cheat-sheet.md#ui-ui) section of `app.ini`.
|
||||
The list of themes a user can choose from can be configured with the `THEMES` value in the [ui](../administration/config-cheat-sheet.md#ui-ui) section of `app.ini`.
|
||||
|
||||
To make a custom theme available to all users:
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@ 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](administration/config-cheat-sheet.md)
|
||||
For the full list of options check the [Config Cheat Sheet](../administration/config-cheat-sheet.md)
|
||||
|
||||
Please note: authentication is only supported when the SMTP server communication is encrypted with TLS or `HOST=localhost`. TLS encryption can be through:
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ it is just a matter of:
|
||||
- add some configuration to your `app.ini` file
|
||||
- restart your Gitea instance
|
||||
|
||||
This supports rendering of whole files. If you want to render code blocks in markdown you would need to do something with javascript. See some examples on the [Customizing Gitea](administration/customizing-gitea.md) page.
|
||||
This supports rendering of whole files. If you want to render code blocks in markdown you would need to do something with javascript. See some examples on the [Customizing Gitea](../administration/customizing-gitea.md) page.
|
||||
|
||||
## Installing external binaries
|
||||
|
||||
|
||||
@@ -119,7 +119,7 @@ proxy_set_header X-Real-IP $remote_addr;
|
||||
|
||||
The security options in `app.ini` need to be adjusted to allow the interpretation of the headers
|
||||
as well as the list of IP addresses and networks that describe trusted proxy servers
|
||||
(See the [configuration cheat sheet](administration/config-cheat-sheet.md#security-security) for more information).
|
||||
(See the [configuration cheat sheet](../administration/config-cheat-sheet.md#security-security) for more information).
|
||||
|
||||
```
|
||||
REVERSE_PROXY_LIMIT = 1
|
||||
|
||||
@@ -22,7 +22,7 @@ menu:
|
||||
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](administration/reverse-proxies.md).
|
||||
If you are using Apache or nginx on the server, it's recommended to check the [reverse proxy guide](../administration/reverse-proxies.md).
|
||||
|
||||
To use Gitea's built-in HTTPS support, you must change your `app.ini` file:
|
||||
|
||||
@@ -36,7 +36,7 @@ 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 establish the trust relationship.
|
||||
To learn more about the config values, please checkout the [Config Cheat Sheet](administration/config-cheat-sheet.md#server-server).
|
||||
To learn more about the config values, please checkout the [Config Cheat Sheet](../administration/config-cheat-sheet.md#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.
|
||||
|
||||
@@ -85,11 +85,11 @@ ACME_DIRECTORY=https
|
||||
ACME_EMAIL=email@example.com
|
||||
```
|
||||
|
||||
To learn more about the config values, please checkout the [Config Cheat Sheet](administration/config-cheat-sheet.md#server-server).
|
||||
To learn more about the config values, please checkout the [Config Cheat Sheet](../administration/config-cheat-sheet.md#server-server).
|
||||
|
||||
## Using a reverse proxy
|
||||
|
||||
Setup up your reverse proxy as shown in the [reverse proxy guide](administration/reverse-proxies.md).
|
||||
Setup up your reverse proxy as shown in the [reverse proxy guide](../administration/reverse-proxies.md).
|
||||
|
||||
After that, enable HTTPS by following one of these guides:
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ menu:
|
||||
# Mail templates
|
||||
|
||||
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](administration/customizing-gitea.md).
|
||||
for these functions are located under the [`custom` directory](../administration/customizing-gitea.md).
|
||||
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.
|
||||
@@ -165,7 +165,7 @@ If the template fails to render, it will be noticed only at the moment the mail
|
||||
A default subject is used if the subject template fails, and whatever was rendered successfully
|
||||
from the _mail body_ is used, disregarding the rest.
|
||||
|
||||
Please check [Gitea's logs](administration/logging-config.md) for error messages in case of trouble.
|
||||
Please check [Gitea's logs](../administration/logging-config.md) for error messages in case of trouble.
|
||||
|
||||
## Example
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ Better code search support could be achieved by setting up the repository indexe
|
||||
|
||||
## Setting up the repository indexer
|
||||
|
||||
Gitea can search through the files of the repositories by enabling this function in your [`app.ini`](administration/config-cheat-sheet.md):
|
||||
Gitea can search through the files of the repositories by enabling this function in your [`app.ini`](../administration/config-cheat-sheet.md):
|
||||
|
||||
```ini
|
||||
[indexer]
|
||||
|
||||
@@ -23,7 +23,7 @@ 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 with path `public/robots.txt` in the [`custom` folder or `CustomPath`](administration/customizing-gitea.md)
|
||||
create a file with path `public/robots.txt` in the [`custom` folder or `CustomPath`](../administration/customizing-gitea.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).
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ menu:
|
||||
|
||||
## Enabling/configuring API access
|
||||
|
||||
By default, `ENABLE_SWAGGER` is true, and `MAX_RESPONSE_ITEMS` is set to 50. See [Config Cheat Sheet](administration/config-cheat-sheet.md) for more information.
|
||||
By default, `ENABLE_SWAGGER` is true, and `MAX_RESPONSE_ITEMS` is set to 50. See [Config Cheat Sheet](../administration/config-cheat-sheet.md) for more information.
|
||||
|
||||
## Authentication
|
||||
|
||||
|
||||
@@ -271,7 +271,7 @@ Please note you should use the Swagger 2.0 documentation, not the OpenAPI 3 docu
|
||||
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](administration/config-cheat-sheet.md)
|
||||
[configuration cheat sheet](../administration/config-cheat-sheet.md)
|
||||
found in `docs/content/doc/administer/config-cheat-sheet.en-us.md`
|
||||
|
||||
### Changing the logo
|
||||
|
||||
@@ -86,7 +86,7 @@ https://github.com/loganinak/MigrateGitlabToGogs
|
||||
|
||||
There are a few places that could make this show incorrectly.
|
||||
|
||||
1. If using a reverse proxy, make sure you have followed the correction directions in the [reverse proxy guide](administration/reverse-proxies.md)
|
||||
1. If using a reverse proxy, make sure you have followed the correction directions in the [reverse proxy guide](../administration/reverse-proxies.md)
|
||||
2. Make sure you have correctly set `ROOT_URL` in the `server` section of your `app.ini`
|
||||
|
||||
If certain clone options aren't showing up (HTTP/S or SSH), the following options can be checked in your `app.ini`
|
||||
@@ -99,7 +99,7 @@ If certain clone options aren't showing up (HTTP/S or SSH), the following option
|
||||
|
||||
This error occurs when the reverse proxy limits the file upload size.
|
||||
|
||||
See the [reverse proxy guide](administration/reverse-proxies.md) for a solution with nginx.
|
||||
See the [reverse proxy guide](../administration/reverse-proxies.md) for a solution with nginx.
|
||||
|
||||
## Custom Templates not loading or working incorrectly
|
||||
|
||||
@@ -109,7 +109,7 @@ The correct path for the template(s) will be relative to the `CustomPath`
|
||||
|
||||
1. To find `CustomPath`, look for Custom File Root Path in Site Administration -> Configuration
|
||||
2. If you are still unable to find a path, the default can be [calculated above](#where-does-gitea-store-what-file)
|
||||
3. Once you have figured out the correct custom path, you can refer to the [customizing Gitea](administration/customizing-gitea.md) page to add your template to the correct location.
|
||||
3. Once you have figured out the correct custom path, you can refer to the [customizing Gitea](../administration/customizing-gitea.md) page to add your template to the correct location.
|
||||
|
||||
## Does Gitea have a "GitHub/GitLab pages" feature?
|
||||
|
||||
@@ -127,7 +127,7 @@ A "login prohibited" user is a user that is not allowed to log in to Gitea anymo
|
||||
|
||||
## Setting up logging
|
||||
|
||||
- [Official Docs](administration/logging-config.md)
|
||||
- [Official Docs](../administration/logging-config.md)
|
||||
|
||||
## What is Swagger?
|
||||
|
||||
@@ -150,7 +150,7 @@ There are multiple things you can combine to prevent spammers.
|
||||
1. By whitelisting or blocklisting certain email domains
|
||||
2. By only whitelisting certain domains with OpenID (see below)
|
||||
3. Setting `ENABLE_CAPTCHA` to `true` in your `app.ini` and properly configuring `RECAPTCHA_SECRET` and `RECAPTCHA_SITEKEY`
|
||||
4. Settings `DISABLE_REGISTRATION` to `true` and creating new users via the [CLI](administration/command-line.md), [API](development/api-usage.md), or Gitea's Admin UI
|
||||
4. Settings `DISABLE_REGISTRATION` to `true` and creating new users via the [CLI](../administration/command-line.md), [API](development/api-usage.md), or Gitea's Admin UI
|
||||
|
||||
### Only allow/block certain email domains
|
||||
|
||||
@@ -178,7 +178,7 @@ At some point, a customer or third party needs access to a specific repo and onl
|
||||
|
||||
### Enable Fail2ban
|
||||
|
||||
Use [Fail2Ban](administration/fail2ban-setup.md) to monitor and stop automated login attempts or other malicious behavior based on log patterns
|
||||
Use [Fail2Ban](../administration/fail2ban-setup.md) to monitor and stop automated login attempts or other malicious behavior based on log patterns
|
||||
|
||||
## SSHD vs built-in SSH
|
||||
|
||||
@@ -322,24 +322,24 @@ 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](administration/command-line.md#admin) to add users like normal.
|
||||
Gitea provides a sub-command `gitea migrate` to initialize the database, after which you can use the [admin CLI commands](../administration/command-line.md#admin) to add users like normal.
|
||||
|
||||
## How can I enable password reset
|
||||
|
||||
There is no setting for password resets. It is enabled when a [mail service](administration/email-setup.md) is configured, and disabled otherwise.
|
||||
There is no setting for password resets. It is enabled when a [mail service](../administration/email-setup.md) is configured, and disabled otherwise.
|
||||
|
||||
## How can a user's password be changed
|
||||
|
||||
- As an **admin**, you can change any user's password (and optionally force them to change it on next login)...
|
||||
- By navigating to your `Site Administration -> User Accounts` page and editing a user.
|
||||
- By using the [admin CLI commands](administration/command-line.md#admin).
|
||||
- By using the [admin CLI commands](../administration/command-line.md#admin).
|
||||
|
||||
Keep in mind most commands will also need a [global flag](administration/command-line.md#global-options) to point the CLI at the correct configuration.
|
||||
Keep in mind most commands will also need a [global flag](../administration/command-line.md#global-options) to point the CLI at the correct configuration.
|
||||
- As a **user** you can change it...
|
||||
- In your account `Settings -> Account` page (this method **requires** you to know your current password).
|
||||
- By using the `Forgot Password` link.
|
||||
|
||||
If the `Forgot Password/Account Recovery` page is disabled, please contact your administrator to configure a [mail service](administration/email-setup.md).
|
||||
If the `Forgot Password/Account Recovery` page is disabled, please contact your administrator to configure a [mail service](../administration/email-setup.md).
|
||||
|
||||
## Why is my markdown broken
|
||||
|
||||
@@ -417,9 +417,9 @@ It is highly recommended to back-up your database before running these commands.
|
||||
- You can also check `<ROOT_URL>/admin/config` for the repository root path.
|
||||
- Ensure that the user/org exists that you want to adopt repositories for.
|
||||
- As an admin, go to `<ROOT_URL>/admin/repos/unadopted` and search.
|
||||
- Users can also be given similar permissions via config [`ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`](administration/config-cheat-sheet.md#repository).
|
||||
- Users can also be given similar permissions via config [`ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`](../administration/config-cheat-sheet.md#repository-repository).
|
||||
- If the above steps are done correctly, you should be able to select repositories to adopt.
|
||||
- If no repositories are found, enable [debug logging](administration/config-cheat-sheet.md#repository) to check for any specific errors.
|
||||
- If no repositories are found, enable [debug logging](../administration/config-cheat-sheet.md#repository-repository) to check for any specific errors.
|
||||
|
||||
## Gitea can't start on NFS
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ blog post to read about the justification for a fork.
|
||||
|
||||
:::warning
|
||||
|
||||
Gitea has never sent commits to upstream or cherry-pick commits from upstream. So Gitea is totally not compatible with Gogs. No any gurantee it can work if you upgrade from Gogs to Gitea. The recommands method is to migrate repositories from Gogs to Gitea.
|
||||
Gitea has never sent commits to upstream or cherry-pick commits from upstream. So Gitea is totally not compatible with Gogs. No any gurantee it can work if you upgrade from Gogs to Gitea. The recommanded method is to migrate repositories from Gogs to Gitea.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -88,7 +88,7 @@ _Symbols used in table:_
|
||||
| Visual comparison of image changes | ✓ | ✘ | ✓ | ? | ? | ? | ✘ | ✘ |
|
||||
|
||||
- Gitea has builtin repository-level code search
|
||||
- Better code search support could be achieved by [using a repository indexer](administration/repo-indexer.md)
|
||||
- Better code search support could be achieved by [using a repository indexer](../administration/repo-indexer.md)
|
||||
|
||||
## Issue Tracker
|
||||
|
||||
|
||||
@@ -63,7 +63,7 @@ despite warnings like `This key is not certified with a trusted signature!`.
|
||||
## Recommended server configuration
|
||||
|
||||
:::note
|
||||
Many of the following directories can be configured using [Environment Variables](administration/environment-variables.md) as well!
|
||||
Many of the following directories can be configured using [Environment Variables](../administration/environment-variables.md) as well!
|
||||
Of note, configuring `GITEA_WORK_DIR` will tell Gitea where to base its working directory, as well as ease installation.
|
||||
:::
|
||||
|
||||
@@ -127,7 +127,7 @@ If you don't want the web installer to be able to write to the config file, it i
|
||||
* Ensure that the `SECRET_KEY` and `INTERNAL_TOKEN` values are set. (You may want to use the `gitea generate secret` to generate these secret keys.)
|
||||
* Ensure that any other secret keys you need are set.
|
||||
|
||||
See the [command line documentation](administration/command-line.md) for information on using `gitea generate secret`.
|
||||
See the [command line documentation](../administration/command-line.md) for information on using `gitea generate secret`.
|
||||
|
||||
### Configure Gitea's working directory
|
||||
|
||||
@@ -174,7 +174,7 @@ GITEA_WORK_DIR=/var/lib/gitea/ /usr/local/bin/gitea web -c /etc/gitea/app.ini
|
||||
You can update to a new version of Gitea by stopping Gitea, replacing the binary at `/usr/local/bin/gitea` and restarting the instance.
|
||||
The binary file name should not be changed during the update to avoid problems in existing repositories.
|
||||
|
||||
It is recommended that you make a [backup](administration/backup-and-restore.md) before updating your installation.
|
||||
It is recommended that you make a [backup](../administration/backup-and-restore.md) before updating your installation.
|
||||
|
||||
If you have carried out the installation steps as described above, the binary should
|
||||
have the generic name `gitea`. Do not change this, i.e. to include the version number.
|
||||
|
||||
@@ -256,7 +256,7 @@ documented above, please note that `db` must be used as the database hostname.
|
||||
|
||||
## Customization
|
||||
|
||||
Customization files described [here](administration/customizing-gitea.md) should
|
||||
Customization files described [here](../administration/customizing-gitea.md) 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
|
||||
@@ -317,7 +317,7 @@ services:
|
||||
- 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](administration/command-line.md#generate).
|
||||
To set required TOKEN and SECRET values, consider using Gitea's built-in [generate utility functions](../administration/command-line.md#generate).
|
||||
|
||||
# SSH Container Passthrough
|
||||
|
||||
@@ -346,7 +346,7 @@ Once the wrapper is in place, you can make it the shell for the `git` user:
|
||||
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](administration/command-line.md#keys) to match the keys against those accepted by Gitea. Add the following block to `/etc/ssh/sshd_config`, on the host:
|
||||
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](../administration/command-line.md#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
|
||||
|
||||
@@ -263,7 +263,7 @@ documented above, please note that `db` must be used as the database hostname.
|
||||
|
||||
## Customization
|
||||
|
||||
Customization files described [here](administration/customizing-gitea.md) should
|
||||
Customization files described [here](../administration/customizing-gitea.md) 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
|
||||
@@ -314,7 +314,7 @@ services:
|
||||
- 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](administration/command-line.md#generate). Do not lose/change your SECRET_KEY after the installation, otherwise the encrypted data can not be decrypted anymore.
|
||||
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](../administration/command-line.md#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.
|
||||
|
||||
@@ -558,7 +558,7 @@ In this option, the idea is that the host SSH uses an `AuthorizedKeysCommand` in
|
||||
|
||||
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](administration/command-line.md#keys) to match the keys against those accepted by Gitea.
|
||||
We will do this by leveraging the [SSH AuthorizedKeysCommand](../administration/command-line.md#keys) to match the keys against those accepted by Gitea.
|
||||
|
||||
Add the following block to `/etc/ssh/sshd_config`, on the host:
|
||||
|
||||
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
date: "2019-11-12T16:00:00+02:00"
|
||||
title: "Search"
|
||||
slug: "search"
|
||||
sidebar_position: 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.
|
||||
@@ -114,7 +114,7 @@ If you cannot see the settings page, please make sure that you have the right pe
|
||||
|
||||
The format of the registration token is a random string `D0gvfu2iHfUjNqCYVljVyRV14fISpJxxxxxxxxxx`.
|
||||
|
||||
A registration token can also be obtained from the gitea [command-line interface](administration/command-line.md#actions-generate-runner-token):
|
||||
A registration token can also be obtained from the gitea [command-line interface](../../administration/command-line.md#actions-generate-runner-token):
|
||||
|
||||
```
|
||||
gitea --config /etc/gitea/app.ini actions generate-runner-token
|
||||
|
||||
@@ -136,7 +136,7 @@ If you want to download an action from another git hoster, you can use an absolu
|
||||
If your Gitea instance is in an intranet or a restricted area, you can set the URL to `self` to only download actions from your own instance by default.
|
||||
Of course, you can still use absolute URLs in workflows.
|
||||
|
||||
More details about the `[actions].DEFAULT_ACTIONS_URL` configuration can be found in the [Configuration Cheat Sheet](administration/config-cheat-sheet.md#actions-actions)。
|
||||
More details about the `[actions].DEFAULT_ACTIONS_URL` configuration can be found in the [Configuration Cheat Sheet](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
|
||||
### Context availability
|
||||
|
||||
|
||||
@@ -62,7 +62,7 @@ This is one of the differences from GitHub Actions which supports actions script
|
||||
But it should allow users much more flexibility in how they run Actions.
|
||||
|
||||
Alternatively, if you want your runners to download actions from your own Gitea instance by default, you can configure it by setting `[actions].DEFAULT_ACTIONS_URL`.
|
||||
See [Configuration Cheat Sheet](administration/config-cheat-sheet.md#actions-actions).
|
||||
See [Configuration Cheat Sheet](../../administration/config-cheat-sheet.md#actions-actions).
|
||||
|
||||
## How to limit the permission of the runners?
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Since 1.21.0, Actions are enabled by default. If you are using versions before 1
|
||||
ENABLED=true
|
||||
```
|
||||
|
||||
If you want to learn more or encounter any problems while configuring it, please refer to the [Configuration Cheat Sheet](administration/config-cheat-sheet.md#actions-actions).
|
||||
If you want to learn more or encounter any problems while configuring it, please refer to the [Configuration Cheat Sheet](../../administration/config-cheat-sheet.md#actions-actions).
|
||||
|
||||
### Set up runner
|
||||
|
||||
@@ -129,7 +129,7 @@ That is because Gitea Actions is designed to be compatible with GitHub Actions
|
||||
Be careful, the demo file contains some emojis.
|
||||
Please make sure your database supports them, especially when using MySQL.
|
||||
If the charset is not `utf8mb4`, errors will occur, such as `Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`.
|
||||
See [Database Preparation](installation/database-preparation.md#mysql) for more information.
|
||||
See [Database Preparation](../../installation/database-preparation.md#mysqlmariadb) for more information.
|
||||
|
||||
Alternatively, you can remove all emojis from the demo file and try again.
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ 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](administration/config-cheat-sheet.md) by the
|
||||
[customized](../administration/config-cheat-sheet.md) by the
|
||||
site administrator.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -28,7 +28,7 @@ Whenever a package gets deleted, only the references to the underlying blobs are
|
||||
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](administration/config-cheat-sheet.md#cron---cleanup-expired-packages-croncleanup_packages).
|
||||
These unreferenced blobs get deleted by a [clean up job](../../administration/config-cheat-sheet.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
|
||||
@@ -68,7 +68,7 @@ The patterns are case-insensitive which matches the behaviour of the package reg
|
||||
|
||||
### How the cleanup rules work
|
||||
|
||||
The cleanup rules are part of the [clean up job](administration/config-cheat-sheet.md#cron---cleanup-expired-packages-croncleanup_packages) and run periodically.
|
||||
The cleanup rules are part of the [clean up job](../../administration/config-cheat-sheet.md#cron---cleanup-expired-packages-croncleanup_packages) and run periodically.
|
||||
|
||||
The cleanup rule:
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ Push to create is a feature that allows you to push to a repository that does no
|
||||
|
||||
## 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](administration/config-cheat-sheet.md#repository-repository).
|
||||
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](../administration/config-cheat-sheet.md#repository-repository).
|
||||
|
||||
## Using Push To Create
|
||||
|
||||
|
||||
Reference in New Issue
Block a user