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:
Lunny Xiao
2024-06-14 05:53:15 +00:00
parent b4dddf8804
commit 9a8396aa29
219 changed files with 487 additions and 644 deletions
@@ -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: