The tests at tests/integration/migration-test/migration_test.go will
not run any Forgejo migration when using the gitea-*.sql.gz files
because they do not contain a ForgejoVersion row which is interpreted
as a new Forgejo installation for which there is no need for migration.
Create a situation by which the ForgejoVersion table exists and has a
version of 0 in tests/integration/migration-test/forgejo-v1.19.0.*.sql.gz
thus ensuring all Forgejo migrations are run.
The forgejo*.sql.gz files do not have any Gitea related records, which
will be interpreted by the Gitea migrations as a new installation that
does not need any migration. As a consequence the migration tests run
when using forgejo-v1.19.0.*.sql.gz are exclusively about Forgejo
migrations.
(cherry picked from commit ec8003859c920ac05a071ad9b1d9d8af5a694ac0)
(cherry picked from commit 697570ff390656930d41bcdc4194aacc5c7a54f4)
(cherry picked from commit f041aec17265ca34943f961d9640e60c96c0f24d)
(cherry picked from commit 60463e3bab9dfa6aae7f379fc77309ab52b1d250)
(cherry picked from commit b2fc2a7c1338ad2a9bd0a6887443e604dccda53f)
(cherry picked from commit fb2759b6afc213d5e2db8f6e523391927c611b23)
(cherry picked from commit 37cfc3b2275afd523f53e149781d69a2914fd83b)
(cherry picked from commit 832607500a576a40ee1e35897e58ef319dba9788)
(cherry picked from commit 143d4007b1b60ad1880b64ce1d4998e77854a05a)
(cherry picked from commit a17e803fbfb7908729c2d92fd58360806cce6fbe)
(cherry picked from commit 72ffd49bc3c218acf8c87f7464f2c028860adba8)
(cherry picked from commit 9b92a5fd725b34d7ed18b5f1ebc78e1a45de07eb)
(cherry picked from commit 0a334d0a9b02617360aaa76d55dbb0f6fd5547f4)
(cherry picked from commit 3add683c94)
(cherry picked from commit 8ed3f3f86b)
(cherry picked from commit 97dc65852b215d85c8608033bd4180d91aef1a54)
(cherry picked from commit e0503cbfead8e5f7f48d0eb0f32bd6881437bb9b)
(cherry picked from commit f25e6a196b32dcb500fa7df65f21124e5e6a10c4)
(cherry picked from commit cca19c7a4e35982c5fec4de4fcb53690f22d1212)
(cherry picked from commit 2c89d7f18c9493e720e0d06c4b2cd072445eff47)
(cherry picked from commit 4eb8695c40e5d1c64113ce19bb3deae1eafe64c9)
(cherry picked from commit e4c42a68ffccb83fcd7379baa402daae15d6f57b)
## ⚠️ Breaking
The `log.<mode>.<logger>` style config has been dropped. If you used it,
please check the new config manual & app.example.ini to make your
instance output logs as expected.
Although many legacy options still work, it's encouraged to upgrade to
the new options.
The SMTP logger is deleted because SMTP is not suitable to collect logs.
If you have manually configured Gitea log options, please confirm the
logger system works as expected after upgrading.
## Description
Close#12082 and maybe more log-related issues, resolve some related
FIXMEs in old code (which seems unfixable before)
Just like rewriting queue #24505 : make code maintainable, clear legacy
bugs, and add the ability to support more writers (eg: JSON, structured
log)
There is a new document (with examples): `logging-config.en-us.md`
This PR is safer than the queue rewriting, because it's just for
logging, it won't break other logic.
## The old problems
The logging system is quite old and difficult to maintain:
* Unclear concepts: Logger, NamedLogger, MultiChannelledLogger,
SubLogger, EventLogger, WriterLogger etc
* Some code is diffuclt to konw whether it is right:
`log.DelNamedLogger("console")` vs `log.DelNamedLogger(log.DEFAULT)` vs
`log.DelLogger("console")`
* The old system heavily depends on ini config system, it's difficult to
create new logger for different purpose, and it's very fragile.
* The "color" trick is difficult to use and read, many colors are
unnecessary, and in the future structured log could help
* It's difficult to add other log formats, eg: JSON format
* The log outputer doesn't have full control of its goroutine, it's
difficult to make outputer have advanced behaviors
* The logs could be lost in some cases: eg: no Fatal error when using
CLI.
* Config options are passed by JSON, which is quite fragile.
* INI package makes the KEY in `[log]` section visible in `[log.sub1]`
and `[log.sub1.subA]`, this behavior is quite fragile and would cause
more unclear problems, and there is no strong requirement to support
`log.<mode>.<logger>` syntax.
## The new design
See `logger.go` for documents.
## Screenshot
<details>
</details>
## TODO
* [x] add some new tests
* [x] fix some tests
* [x] test some sub-commands (manually ....)
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Giteabot <teabot@gitea.io>
Replace #23350.
Refactor `setting.Database.UseMySQL` to
`setting.Database.Type.IsMySQL()`.
To avoid mismatching between `Type` and `UseXXX`.
This refactor can fix the bug mentioned in #23350, so it should be
backported.
Some bugs caused by less unit tests in fundamental packages. This PR
refactor `setting` package so that create a unit test will be easier
than before.
- All `LoadFromXXX` files has been splited as two functions, one is
`InitProviderFromXXX` and `LoadCommonSettings`. The first functions will
only include the code to create or new a ini file. The second function
will load common settings.
- It also renames all functions in setting from `newXXXService` to
`loadXXXSetting` or `loadXXXFrom` to make the function name less
confusing.
- Move `XORMLog` to `SQLLog` because it's a better name for that.
Maybe we should finally move these `loadXXXSetting` into the `XXXInit`
function? Any idea?
---------
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: delvh <dev.lh@web.de>
Change all license headers to comply with REUSE specification.
Fix#16132
Co-authored-by: flynnnnnnnnnn <flynnnnnnnnnn@github>
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
