mirror of
https://codeberg.org/forgejo/forgejo.git
synced 2024-11-08 16:14:30 +00:00
Backport #25202 by @wxiaoguang Close #23654 Close #24684 @techknowlogick I still think we need to rename https://dl.gitea.com/gitea/1.20/ to https://dl.gitea.com/gitea/1.20-nightly/ `/gitea/1.20/` is quite confusing, it needs these words to explain why. If we call it `1.20-nightly`, the FAQ can be simplified a lot. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This commit is contained in:
Giteabot
GitHub
parent
0cf467e9e0
commit
0ad5ae0dbf
|
|
@ -25,21 +25,19 @@ For more help resources, check all [Support Options]({{< relref "doc/help/suppor
|
|||
|
||||
{{< toc >}}
|
||||
|
||||
## Difference between 1.x and 1.x.x downloads
|
||||
## Difference between 1.x and 1.x.x downloads, how can I get latest stable release with bug fixes?
|
||||
|
||||
Version 1.7.x will be used for this example.
|
||||
Version 1.20.x will be used for this example.
|
||||
|
||||
**NOTE:** this example applies to Docker images as well!
|
||||
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.
|
||||
|
||||
On our [downloads page](https://dl.gitea.io/gitea/) you will see a 1.7 directory, as well as directories for 1.7.0, 1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5, and 1.7.6.
|
||||
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.7 and 1.7.0 directories are **not** the same. The 1.7 directory is built on each merged commit to the [`release/v1.7`](https://github.com/go-gitea/gitea/tree/release/v1.7) 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 1.7.0 directory, however, is a build that was created when the [`v1.7.0`](https://github.com/go-gitea/gitea/releases/tag/v1.7.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.
|
||||
|
||||
This means that 1.x downloads will change as commits are merged to their respective branch (think of it as a separate "main" branch for each release).
|
||||
|
||||
On the other hand, 1.x.x downloads should never change.
|
||||
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
|
||||
|
||||
|
|
@ -404,14 +402,6 @@ You will also need to change the app.ini database charset to `CHARSET=utf8mb4`.
|
|||
|
||||
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.
|
||||
|
||||
## Stdout logging on SystemD and Docker
|
||||
|
||||
Stdout on systemd goes to the journal by default. Try using `journalctl`, `journalctl -u gitea`, or `journalctl <path-to-gitea-binary>`.
|
||||
|
||||
Similarly, stdout on docker can be viewed using `docker logs <container>`.
|
||||
|
||||
To collect logs for help and issue report, see [Support Options]({{< relref "doc/help/support.en-us.md" >}}).
|
||||
|
||||
## 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.
|
||||
|
|
@ -454,12 +444,6 @@ gitea doctor recreate-table
|
|||
|
||||
It is highly recommended to back-up your database before running these commands.
|
||||
|
||||
## Why are tabs/indents wrong when viewing files
|
||||
|
||||
If you are using Cloudflare, turn off the auto-minify option in the dashboard.
|
||||
|
||||
`Speed` -> `Optimization` -> Uncheck `HTML` within the `Auto-Minify` settings.
|
||||
|
||||
## 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`.
|
||||
|
|
@ -470,3 +454,17 @@ If you are using Cloudflare, turn off the auto-minify option in the dashboard.
|
|||
- 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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -35,30 +35,13 @@ menu:
|
|||
[log]
|
||||
LEVEL=debug
|
||||
MODE=console,file
|
||||
ROUTER=console,file
|
||||
XORM=console,file
|
||||
ENABLE_XORM_LOG=true
|
||||
FILE_NAME=gitea.log
|
||||
[log.file.router]
|
||||
FILE_NAME=router.log
|
||||
[log.file.xorm]
|
||||
FILE_NAME=xorm.log
|
||||
```
|
||||
|
||||
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 meet slow/hanging/deadlock problems, please report the stack trace when the problem occurs:
|
||||
1. Enable pprof in `app.ini` and restart Gitea
|
||||
|
||||
```ini
|
||||
[server]
|
||||
ENABLE_PPROF = true
|
||||
```
|
||||
|
||||
2. Trigger the bug, when Gitea gets stuck, use curl or browser to visit: `http://127.0.0.1:6060/debug/pprof/goroutine?debug=1` (IP must be `127.0.0.1` and port must be `6060`).
|
||||
3. If you are using Docker, please use `docker exec -it <container-name> curl "http://127.0.0.1:6060/debug/pprof/goroutine?debug=1"`.
|
||||
4. Report the output (the stack trace doesn't contain sensitive data)
|
||||
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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue