mirror of
https://codeberg.org/forgejo/docs.git
synced 2025-04-26 21:50:47 +03:00
Fix minor issues in most admin pages
This commit is contained in:
Aivaras
parent
27a68a1f61
commit
e9f8fbe8c6
13 changed files with 81 additions and 73 deletions
|
|
@ -118,8 +118,8 @@ See the user documentation for `jobs.<job_id>.container` for more information.
|
|||
|
||||
Label examples:
|
||||
|
||||
- `node20:docker://node:20-bookworm` == `node20:docker://docker.io/node:20-bookworm` defines `node20` to be the `node:20-bookworm` image from hub.docker.com
|
||||
- `docker:docker://data.forgejo.org/oci/alpine:3.20` defines `docker` to be the `alpine:3.20` image from https://data.forgejo.org/oci/-/packages/container/alpine/3.20
|
||||
- `node20:docker://node:20-bookworm` == `node20:docker://docker.io/node:20-bookworm` defines `node20` to be the `node:20-bookworm` image from hub.docker.com.
|
||||
- `docker:docker://data.forgejo.org/oci/alpine:3.20` defines `docker` to be the `alpine:3.20` image from https://data.forgejo.org/oci/-/packages/container/alpine/3.20.
|
||||
|
||||
### LXC
|
||||
|
||||
|
|
@ -134,8 +134,8 @@ The runner will execute all the steps, as root, within a [LXC container](https:/
|
|||
|
||||
Label examples:
|
||||
|
||||
- `bookworm:lxc://debian:bookworm:lxc docker` defines `bookworm` to be an LXC container running Debian GNU/Linux bookworm. It has the necessary capabilities to run a nested LXC container and a docker engine.
|
||||
- `bookworm:lxc://debian:bookworm` defines `bookworm` to be an LXC container running Debian GNU/Linux bookworm. It has the necessary capabilities to run a nested LXC container, kvm virtual machines and a docker engine.
|
||||
- `bookworm:lxc://debian:bookworm:lxc docker` defines `bookworm` to be an LXC container running Debian GNU/Linux bookworm. It has the necessary capabilities to run a nested LXC container and a Docker engine.
|
||||
- `bookworm:lxc://debian:bookworm` defines `bookworm` to be an LXC container running Debian GNU/Linux bookworm. It has the necessary capabilities to run a nested LXC container, KVM virtual machines and a Docker engine.
|
||||
|
||||
### Host
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ If a label specifies `host` as its `label type`, the runner will execute all the
|
|||
|
||||
Label example:
|
||||
|
||||
- `self-hosted:host://-self-hosted` defines `self-hosted` to be a shell
|
||||
- `self-hosted:host://-self-hosted` defines `self-hosted` to be a shell.
|
||||
|
||||
### Special labels
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Some settings are provided to customize the look and feel of the Forgejo user in
|
|||
This includes the default theme, the name of your Forgejo instance, as well as the description that appears in Forgejo's homepage. A complete list of those settings can be found in the config cheat sheet:
|
||||
|
||||
- In the [UI section](../config-cheat-sheet/#ui-ui) and below.
|
||||
- The `APP_NAME` setting in the [Overall section](../config-cheat-sheet/#overall-default)
|
||||
- The `APP_NAME` setting in the [Overall section](../config-cheat-sheet/#overall-default).
|
||||
|
||||
They are documented and supported to be backward compatible between versions.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Database instance can be on same machine as Forgejo (local database setup), or o
|
|||
|
||||
## SQLite
|
||||
|
||||
Forgejo distributes binaries that come with SQLite support and you don't need to install additional dependencies on your system.
|
||||
Forgejo distributes binaries that come with SQLite support, meaning you don't have to install additional dependencies on your system.
|
||||
|
||||
> **Note:** If you build Forgejo from source, build with `make TAGS="sqlite sqlite_unlock_notify" build` to include SQLite support.
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ DB_TYPE = sqlite3
|
|||
PATH = data/forgejo.db
|
||||
```
|
||||
|
||||
If you want to maximize performance, you might want to take a look at the `[database].SQLITE_JOURNAL_MODE` setting and consider using the [WAL mode](https://www.sqlite.org/wal.html).
|
||||
If you want to maximize performance, you might want to take a look at the `[database].SQLITE_JOURNAL_MODE` setting, and consider using the [WAL mode](https://www.sqlite.org/wal.html).
|
||||
|
||||
## MySQL/MariaDB
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ If you want to maximize performance, you might want to take a look at the `[data
|
|||
|
||||
Replace database name as appropriate.
|
||||
|
||||
**Using an accent- and case sensitive collation such as `utf8mb4_bin` is important**, because Forgejo often relies on these sensitivities, and if those assumptions are broken, that may lead to internal server errors or other unexpected results.
|
||||
**Using an accent and case sensitive collation such as `utf8mb4_bin` is important**, because Forgejo often relies on these sensitivities, and if those assumptions are broken, that may lead to internal server errors or other unexpected results.
|
||||
|
||||
6. Grant all privileges on the database to the database user created above.
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ If you want to maximize performance, you might want to take a look at the `[data
|
|||
|
||||
8. Optional: On your Forgejo server, test connection to the database (requires that you have a client library installed. The client is not necessary for Forgejo itself):
|
||||
|
||||
```
|
||||
```shell
|
||||
mysql -u forgejo -h 203.0.113.3 -p forgejodb
|
||||
```
|
||||
|
||||
|
|
@ -117,7 +117,7 @@ If you want to maximize performance, you might want to take a look at the `[data
|
|||
|
||||
2. Protect the `root` user with a secure password or disable the login.
|
||||
|
||||
3. If you use a PostgreSQL version lower than 14, the `md5` challenge-response encryption scheme for password authentication is used 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:
|
||||
3. If you use a PostgreSQL version lower than 14, the `md5` challenge-response encryption scheme for password authentication is used by default. Nowadays this scheme is not considered secure anymore. Use the SCRAM-SHA-256 scheme instead by editing the `postgresql.conf` configuration file on the database server to:
|
||||
|
||||
```ini
|
||||
password_encryption = scram-sha-256
|
||||
|
|
@ -127,11 +127,11 @@ If you want to maximize performance, you might want to take a look at the `[data
|
|||
|
||||
4. On the database server, login to the database console as superuser:
|
||||
|
||||
```
|
||||
```shell
|
||||
su -c "psql" - postgres
|
||||
```
|
||||
|
||||
5. Create database user (role in PostgreSQL terms) with login privilege and password. _Please use a secure, strong password instead of `'passw0rd'` below:_
|
||||
5. Create database user (role in PostgreSQL terms) with login privilege and password. **Please use a secure, strong password instead of `'passw0rd'` below:**
|
||||
|
||||
```sql
|
||||
CREATE ROLE forgejo WITH LOGIN PASSWORD 'passw0rd';
|
||||
|
|
@ -173,13 +173,13 @@ If you want to maximize performance, you might want to take a look at the `[data
|
|||
|
||||
For local database:
|
||||
|
||||
```
|
||||
```shell
|
||||
psql -U forgejo -d forgejodb -h localhost
|
||||
```
|
||||
|
||||
For remote database:
|
||||
|
||||
```
|
||||
```shell
|
||||
psql "postgres://forgejo@203.0.113.3/forgejodb"
|
||||
```
|
||||
|
||||
|
|
@ -220,7 +220,7 @@ The PostgreSQL driver used by Forgejo supports two-way TLS. In two-way TLS, both
|
|||
|
||||
3. Adjust credentials ownership and permission, as required by PostgreSQL:
|
||||
|
||||
```
|
||||
```shell
|
||||
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
|
||||
```
|
||||
|
|
@ -253,14 +253,14 @@ The PostgreSQL driver used by Forgejo supports two-way TLS. In two-way TLS, both
|
|||
|
||||
7. Adjust credentials, ownership and permission as required:
|
||||
|
||||
```
|
||||
```shell
|
||||
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:
|
||||
|
||||
```
|
||||
```shell
|
||||
psql "postgres://forgejo@example.db/forgejodb?sslmode=verify-full"
|
||||
```
|
||||
|
||||
|
|
@ -268,7 +268,7 @@ The PostgreSQL driver used by Forgejo supports two-way TLS. In two-way TLS, both
|
|||
|
||||
### MySQL/MariaDB
|
||||
|
||||
While the MySQL/MariaDB driver used by Forgejo also supports two-way TLS, Forgejo currently supports only one-way TLS. See the "Add TLS File Path Options for MySQL/MariaDB Database Connection](https://github.com/go-gitea/gitea/issues/10828)" issue for details.
|
||||
While the MySQL/MariaDB driver used by Forgejo also supports two-way TLS, Forgejo currently supports only one-way TLS. See the "[Add TLS File Path Options for MySQL/MariaDB Database Connection](https://github.com/go-gitea/gitea/issues/10828)" issue 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.
|
||||
|
||||
|
|
@ -290,7 +290,7 @@ In one-way TLS, the database client verifies the certificate sent from server du
|
|||
|
||||
3. Adjust credentials ownership and permission:
|
||||
|
||||
```
|
||||
```shell
|
||||
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
|
||||
```
|
||||
|
|
@ -312,7 +312,7 @@ In one-way TLS, the database client verifies the certificate sent from server du
|
|||
|
||||
7. On the server running Forgejo, test connection to the database:
|
||||
|
||||
```
|
||||
```shell
|
||||
mysql -u forgejo -h example.db -p --ssl
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ This guide describes how to go from Gitea to Forgejo.
|
|||
|
||||
Upgrades are supported [up to Gitea v1.22 included](https://forgejo.org/2024-12-gitea-compatibility/), in two steps:
|
||||
|
||||
- Upgrade from any Gitea version up to and including v1.22.x to Forgejo v10.0.x
|
||||
- Upgrade from any Gitea version up to and including v1.22.x to Forgejo v10.0.x.
|
||||
- Upgrade from Forgejo v10.0.x to any Forgejo version greater than v10.
|
||||
|
||||
Here's what to expect, and some helpful tips:
|
||||
|
|
@ -44,7 +44,7 @@ We need to set the group owner and group write permission so Forgejo can write t
|
|||
|
||||
If we want to leave a copy of the Gitea data untouched (recommend in case of mistakes)
|
||||
the next step is to copy the existing data to the Forgejo user's home directory.
|
||||
We need to change the ownership of the files to the `forgejo` user and group too.
|
||||
We need to change the ownership of the files to the `forgejo` user and group too:
|
||||
|
||||
$ cp -r /var/lib/gitea/* /var/lib/forgejo
|
||||
$ chown -R forgejo: /var/lib/forgejo/*
|
||||
|
|
@ -112,10 +112,9 @@ Forgejo.
|
|||
|
||||
Here are some common problems and how to solve them. Contributions are welcome.
|
||||
|
||||
## missing favicon or logo
|
||||
## Missing favicon or logo
|
||||
|
||||
The `public/assets/img/` stuff needs to live under custom/ now, it will
|
||||
have no effect otherwise.
|
||||
Files from `public/assets/img/` must live in `custom/` now; otherwise, they will have no effect.
|
||||
|
||||
See [here](https://forgejo.org/docs/next/contributor/customization/#changing-the-logo)
|
||||
for details of where these things should live.
|
||||
|
|
@ -128,7 +127,7 @@ The browser caches images, so after changing it, it may take some refreshes or c
|
|||
|
||||
Check (and double-check) your configured paths. Refer to the [storage documentation](https://forgejo.org/docs/latest/admin/storage/), and double-check what the configured path is relative to.
|
||||
|
||||
## action fails to run with "repository not found"
|
||||
## Action fails to run with "repository not found"
|
||||
|
||||
If the "Set up job" section fails with "repository not found", it's probably trying to pull the action from the wrong place.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,11 @@ This placeholder must only appear once in the address and must be in the user pa
|
|||
|
||||
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`
|
||||
If a catch-all mailbox is used, the placeholder may be used anywhere in the user part of the address, for example:
|
||||
|
||||
- `incoming+%{token}@example.com`
|
||||
- `incoming_%{token}@example.com`
|
||||
- `%{token}@example.com`
|
||||
|
||||
## Security
|
||||
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ sudo systemctl start forgejo.service
|
|||
|
||||
## Forgejo's web-based configuration
|
||||
|
||||
You should now be able to access Forgejo in your local web browser, so open http://git.example.com:3000/.
|
||||
Access the Forgejo web UI by opening `http://localhost:3000/` in your local web browser. Replace `localhost` with the server's local IP address if necessary.
|
||||
|
||||
If it doesn't work:
|
||||
|
||||
|
|
@ -148,7 +148,7 @@ write to it after the initial configuration):
|
|||
sudo chmod 750 /etc/forgejo && sudo chmod 640 /etc/forgejo/app.ini
|
||||
```
|
||||
|
||||
Now (as root) edit `/etc/forgejo/app.ini`
|
||||
Now, (as root), edit `/etc/forgejo/app.ini`.
|
||||
|
||||
> **NOTE:** You'll probably find the
|
||||
> [Configuration Cheat Sheet](../config-cheat-sheet/) and the
|
||||
|
|
@ -162,7 +162,7 @@ The following changes are recommended if dealing with many large files:
|
|||
is limited to 3MB per file, and 5 files at once. To increase it, under the `[repository]` section,
|
||||
add a `[repository.upload]` section with a line like `FILE_MAX_SIZE = 4095`
|
||||
(that would be 4095MB, about 4GB) and `MAX FILES = 20`
|
||||
It'll look somehow like this:
|
||||
It'll look somewhat like this:
|
||||
|
||||
```ini
|
||||
...
|
||||
|
|
@ -187,9 +187,9 @@ The following changes are recommended if dealing with many large files:
|
|||
- By default **LFS data uploads expire** after 20 minutes - this can be too short for big files,
|
||||
slow connections or slow LFS storage (git-lfs seems to automatically restart the upload then -
|
||||
which means that it can take forever and use lots of traffic)..
|
||||
If you're going to use LFS with big uploads, increase thus limit, by adding a line
|
||||
If you're going to use LFS with big uploads, increase thus limit, by adding the line
|
||||
`LFS_HTTP_AUTH_EXPIRY = 180m` (for 180 minutes) to the `[server]` section.
|
||||
- Similarly there are timeouts for all kinds of git operations, that can be too short.
|
||||
- Similarly, there are timeouts for all kinds of git operations, that can be too short.
|
||||
Increasing all those git timeouts by adding a `[git.timeout]` section
|
||||
below the `[server]` section:
|
||||
```ini
|
||||
|
|
@ -204,8 +204,9 @@ The following changes are recommended if dealing with many large files:
|
|||
PULL = 3000 ; Git pull from internal repositories timeout seconds
|
||||
GC = 600 ; Git repository GC timeout seconds
|
||||
```
|
||||
They are increased by a factor 10 (by adding a 0 at the end); probably not all these timeouts
|
||||
need to be increased (and if, then maybe not this much)... use your own judgement.
|
||||
The example values are increased by a factor of 10 for illustration. Increasing
|
||||
all timeouts, particularly by this magnitude, may not be necessary. Evaluate
|
||||
your specific performance requirements and adjust values accordingly.
|
||||
- By default LFS files are stored in the filesystem, in `/var/lib/forgejo/data/lfs`.
|
||||
In the `[lfs]` section you can change the `PATH = ...` line to store elsewhere, but you can also
|
||||
configure Forgejo to store the files in an S3-like Object-Storage.
|
||||
|
|
@ -217,13 +218,13 @@ The following changes are recommended if dealing with many large files:
|
|||
PROTOCOL = sendmail
|
||||
FROM = "Forgejo Git" <noreply@yourdomain.com>
|
||||
```
|
||||
- By default Forgejo will listen to the port 3000 but that can be [changed to 80 with `HTTP_PORT`](../config-cheat-sheet/) like this:
|
||||
- By default, Forgejo will listen on the port 3000, but that can be [changed to 80 with `HTTP_PORT`](../config-cheat-sheet/) like this:
|
||||
```ini
|
||||
[server]
|
||||
HTTP_PORT = 80
|
||||
```
|
||||
|
||||
When you're done editing the app.ini, save it and start the forgejo service again:
|
||||
When you're done editing the app.ini, save it and start the Forgejo service again:
|
||||
|
||||
```sh
|
||||
sudo systemctl start forgejo.service
|
||||
|
|
@ -248,8 +249,8 @@ Keep in mind that:
|
|||
```sh
|
||||
$ export FORGEJO_WORK_DIR=/var/lib/forgejo
|
||||
```
|
||||
- You need to specify the path to the config (app.ini) with `--config /etc/forgejo/app.ini`
|
||||
(or `-c /etc/forgejo/app.ini`).
|
||||
- You need to specify the path to the config (app.ini) with either `--config /etc/forgejo/app.ini`
|
||||
or `-c /etc/forgejo/app.ini`.
|
||||
|
||||
So all in all your command might look like:
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Forgejo provides [container images](https://codeberg.org/forgejo/-/packages/cont
|
|||
docker pull codeberg.org/forgejo/forgejo:10
|
||||
```
|
||||
|
||||
If `codeberg.org` can not be accessed you can replace every mention of `codeberg.org` with `data.forgejo.org` to use our mirror.
|
||||
If `codeberg.org` cannot be accessed, you can replace every mention of `codeberg.org` with `data.forgejo.org` to use our mirror.
|
||||
|
||||
The **10** tag is set to be the latest minor release, starting with **10.0.x**. The **10** tag will then be equal to **10.0.4** when it is released and so on. The **10.0** tag is also set to be the latest patch version release.
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ Upgrading from **X** to **X+1** (for instance from **9** to **10**) requires a [
|
|||
|
||||
### Docker:
|
||||
|
||||
Here is a sample [docker-compose](https://docs.docker.com/compose/install/) file:
|
||||
Here is an example [docker-compose](https://docs.docker.com/compose/install/) file:
|
||||
|
||||
```yaml
|
||||
networks:
|
||||
|
|
@ -44,7 +44,7 @@ services:
|
|||
```
|
||||
|
||||
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.
|
||||
If you don't set the volume correct permissions, the container may not start.
|
||||
|
||||
### Podman:
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ Currently tested on the following specifications:
|
|||
- Podman v5.2.1
|
||||
- Fedora 40, Alma Linux 9.4, Rocky Linux 9
|
||||
|
||||
Save the following files in /etc/containers/systemd, as port 222 requires elevated privileges:
|
||||
Save the following files in `/etc/containers/systemd`, as port 222 requires elevated privileges:
|
||||
|
||||
```
|
||||
# forgejo.container
|
||||
|
|
@ -90,7 +90,6 @@ Once saved, run:
|
|||
|
||||
```bash
|
||||
sudo systemctl daemon-reload
|
||||
|
||||
sudo systemctl start forgejo
|
||||
```
|
||||
|
||||
|
|
@ -127,7 +126,7 @@ ENABLE_PUSH_CREATE_USER = true
|
|||
|
||||
## Databases
|
||||
|
||||
In the following each database is shown as part of a `docker-compose` example file, with a `diff like` presentation that highlights additions to the example above.
|
||||
In the following each database is shown as part of a `docker-compose` example file, with a diff-like presentation that highlights additions to the example above.
|
||||
|
||||
If no database is configured, it will default to using SQLite.
|
||||
|
||||
|
|
@ -261,21 +260,21 @@ important behaviour.
|
|||
We now mount this folder on the `client` which will host Forgejo to a folder `/mnt/repositories`...
|
||||
|
||||
```shell
|
||||
# mount -o hard,timeo=10,retry=10,vers=4.1 server:/repositories /mnt/repositories/
|
||||
sudo mount -o hard,timeo=10,retry=10,vers=4.1 server:/repositories /mnt/repositories/
|
||||
```
|
||||
|
||||
... and create two folders
|
||||
|
||||
```shell
|
||||
$ mkdir conf
|
||||
$ mkdir data
|
||||
mkdir conf
|
||||
mkdir data
|
||||
```
|
||||
|
||||
To consider in the NFS client setup is the `hard` setting, blocking all file operations if the share is not available.
|
||||
This prevents state changes in the repository which could potentially corrupt the repository data and is an NFS-specific setting.
|
||||
|
||||
We will use the `rootless` image, which hosts the `ssh` server for Forgejo embedded. A possible entry for a `docker-compose` file
|
||||
would look like this (shown as a `diff like` view to the example shown [in our initial example](#installation-with-docker)):
|
||||
would look like this (shown as a diff-like view to the example shown [in our initial example](#installation-with-docker)):
|
||||
|
||||
```yaml
|
||||
networks:
|
||||
|
|
@ -318,4 +317,4 @@ It is important for all involved tools that these files not be writable by just
|
|||
Changing permissions will also not succeed through the chosen `all_squash` setup, which was necessary to allow a correct ownership
|
||||
mechanic on the server. To resolve this, we consider the `rootless` image, which embeds the `ssh` server, circumventing the problem entirely.
|
||||
|
||||
Note this setup is simple and does not necessarily reflect the reality of your network. User mapping and ownership could be streamlined better with Kerberos, but that is out of the scope of this guide.
|
||||
Note, that this setup is simple and does not necessarily reflect the reality of your network. User mapping and ownership could be streamlined better with Kerberos, but that is out of the scope of this guide.
|
||||
|
|
|
|||
|
|
@ -13,11 +13,11 @@ information.
|
|||
|
||||
Get started in a few simple steps:
|
||||
|
||||
1. set up Forgejo on your system ...
|
||||
1. Set up Forgejo on your system ...
|
||||
- [from binary](../installation-binary/)
|
||||
- [with Docker](../installation-docker/)
|
||||
- with third-party packaging for various platforms [(see the "Delightful Forgejo" list)](https://codeberg.org/forgejo-contrib/delightful-forgejo#packaging). Unlike the two official installation methods, these resources are not extensively tested to work on every release.
|
||||
2. connect to the web interface and complete the configuration, and,
|
||||
2. Connect to the web interface and complete the configuration, and,
|
||||
3. register the first user which will be granted administrative permissions.
|
||||
|
||||
If you already have Gitea installed through your package manager, look at the [Gitea
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@ origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8
|
|||
|
||||
The logging configuration of Forgejo mainly consists of 3 types of components:
|
||||
|
||||
- The `[log]` section for general configuration
|
||||
- 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>`
|
||||
- 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.
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ Configuration of logging facilities in Forgejo happen in the `[log]` section and
|
|||
|
||||
In the top level `[log]` section the following configurations can be placed:
|
||||
|
||||
- `ROOT_PATH`: (Default: **%(GITEA_WORK_DIR)/log**): Base path for log files
|
||||
- `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.
|
||||
|
|
@ -100,9 +100,9 @@ FILE_NAME = file-error.log
|
|||
|
||||
Forgejo 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)
|
||||
- `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
|
||||
|
||||
|
|
@ -218,10 +218,10 @@ Settings:
|
|||
|
||||
The Router logger logs the following message types when Forgejo's route handlers work:
|
||||
|
||||
- `started` messages will be logged at TRACE level
|
||||
- `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
|
||||
- `slow` routers will be logged at WARN.
|
||||
- `failed` routers will be logged at WARN.
|
||||
|
||||
### The "XORM" logger
|
||||
|
||||
|
|
@ -253,19 +253,19 @@ This value represents a go template. Its default value is
|
|||
|
||||
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`
|
||||
- `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.
|
||||
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 Forgejo to release and reopen it's logging files and connections by sending `SIGUSR1` to the
|
||||
It is possible force Forgejo to release and reopen its logging files and connections by sending `SIGUSR1` to the
|
||||
running process, or running `forgejo manager logging release-and-reopen`.
|
||||
|
||||
Alternatively, you may wish to pause and resume logging - this can be accomplished through the use of the
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@ title: 'Moderation tools'
|
|||
license: 'CC-BY-SA-4.0'
|
||||
---
|
||||
|
||||
Moderation tools are meant to help the Forgejo users and admins cope
|
||||
with spam bots and undesirable interactions.
|
||||
Moderation tools are meant to help the Forgejo users and admins handle
|
||||
spam bots and undesirable interactions.
|
||||
|
||||
`[admin].SEND_NOTIFICATION_EMAIL_ON_NEW_USER` can be set to `true` on
|
||||
small Forgejo instances with an open registration. Such instances are
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Each process in the list has a few key details:
|
|||
- Title: this is the description that was given to the process, this should identify why it was created and what the purpose is.
|
||||
- Date: this indicates when the process was created.
|
||||
|
||||
And a stacktrace, it is possible that a process has more than one stacktrace, in that case the first stacktrace can be seen as the _main_ stacktrace of that process and the others are children of that process that were not marked as new processes. The stacktrace is read from top to bottom, where each entry in the stacktrace represents a stack frame[^1]. The top entry is where the deepest stack frame and the bottom entry is the outer stack frame and where this process started its lifecycle.
|
||||
And a stacktrace, it is possible that a process has more than one stacktrace, in which case the first stacktrace can be seen as the _main_ stacktrace of that process and the others are children of that process that were not marked as new processes. The stacktrace is read from top to bottom, where each entry in the stacktrace represents a stack frame[^1]. The top entry is where the deepest stack frame and the bottom entry is the outer stack frame and where this process started its lifecycle.
|
||||
|
||||
[^1]: This can be conceptually seen as where the program made a function call.
|
||||
|
||||
|
|
|
|||
|
|
@ -127,12 +127,12 @@ they won't apply to users.
|
|||
|
||||
However, you can create quota groups and assign users to them:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
api_helper "/admin/quota/groups/<GROUPNAME>/users/<USERNAME>" -XPUT
|
||||
```
|
||||
|
||||
Or remove them:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
api_helper "/admin/quota/groups/<GROUPNAME>/users/<USERNAME>" -XDELETE
|
||||
```
|
||||
|
|
|
|||
|
|
@ -36,7 +36,12 @@ If your instances see a high amount of activity, it is recommended to change thi
|
|||
|
||||
### `[cache].ADAPTER`
|
||||
|
||||
Forgejo uses caching to avoid doing expensive work multiple times in multiple places. The default cache is a simple cache mechanism that deletes items after x time, regardless of whether they are used often or not used at all and not deleted if there are many items in the cache, this is clearly not a good cache. To give you an idea if your instance relies heavily on the caching code, a few examples where it is used: commit count of a repository, branch or only where x file was modified (requires a lot of IO work), user settings (frequent database lookup) and avatar hash (hash computation) are the most common usage of the caching code.
|
||||
Forgejo uses caching to avoid repeating expensive operations. The default cache implementation is basic: items expire after a fixed duration (time-to-live) regardless of usage frequency, and it lacks eviction strategies based on memory pressure or access patterns (like LRU). This simplicity means it may not be optimal for all workloads. To illustrate the potential impact of caching, consider these common use cases:
|
||||
|
||||
- Calculating commit counts for repositories or branches (reducing potentially expensive Git operations).
|
||||
- Retrieving specific file or commit history (reducing Git I/O).
|
||||
- Fetching user settings (minimizing database lookups).
|
||||
- Computing avatar hashes (saving CPU time).
|
||||
|
||||
If your instance does not see much activity, it is recommended to change this value to **twoqueue**. This will use a size-limited [LRU cache](<https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)>), which will keep frequently used items and remove the ones that are not used often. It is also recommended to change `[cache].HOST` to `{"size":100, "recent_ratio":0.25, "ghost_ratio":0.5}` because the default value has a limit of 50,000 items and since by default it will keep items for 16 hours, it is not memory efficient to possibly keep so many items for a small instance.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue