2019-04-06 20:25:14 -04:00
// Copyright 2019 The Gitea Authors. All rights reserved.
2022-11-27 13:20:29 -05:00
// SPDX-License-Identifier: MIT
2019-04-06 20:25:14 -04:00
Rewrite queue (#24505)
# ⚠️ Breaking
Many deprecated queue config options are removed (actually, they should
have been removed in 1.18/1.19).
If you see the fatal message when starting Gitea: "Please update your
app.ini to remove deprecated config options", please follow the error
messages to remove these options from your app.ini.
Example:
```
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].ISSUE_INDEXER_QUEUE_TYPE`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].UPDATE_BUFFER_LEN`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [F] Please update your app.ini to remove deprecated config options
```
Many options in `[queue]` are are dropped, including:
`WRAP_IF_NECESSARY`, `MAX_ATTEMPTS`, `TIMEOUT`, `WORKERS`,
`BLOCK_TIMEOUT`, `BOOST_TIMEOUT`, `BOOST_WORKERS`, they can be removed
from app.ini.
# The problem
The old queue package has some legacy problems:
* complexity: I doubt few people could tell how it works.
* maintainability: Too many channels and mutex/cond are mixed together,
too many different structs/interfaces depends each other.
* stability: due to the complexity & maintainability, sometimes there
are strange bugs and difficult to debug, and some code doesn't have test
(indeed some code is difficult to test because a lot of things are mixed
together).
* general applicability: although it is called "queue", its behavior is
not a well-known queue.
* scalability: it doesn't seem easy to make it work with a cluster
without breaking its behaviors.
It came from some very old code to "avoid breaking", however, its
technical debt is too heavy now. It's a good time to introduce a better
"queue" package.
# The new queue package
It keeps using old config and concept as much as possible.
* It only contains two major kinds of concepts:
* The "base queue": channel, levelqueue, redis
* They have the same abstraction, the same interface, and they are
tested by the same testing code.
* The "WokerPoolQueue", it uses the "base queue" to provide "worker
pool" function, calls the "handler" to process the data in the base
queue.
* The new code doesn't do "PushBack"
* Think about a queue with many workers, the "PushBack" can't guarantee
the order for re-queued unhandled items, so in new code it just does
"normal push"
* The new code doesn't do "pause/resume"
* The "pause/resume" was designed to handle some handler's failure: eg:
document indexer (elasticsearch) is down
* If a queue is paused for long time, either the producers blocks or the
new items are dropped.
* The new code doesn't do such "pause/resume" trick, it's not a common
queue's behavior and it doesn't help much.
* If there are unhandled items, the "push" function just blocks for a
few seconds and then re-queue them and retry.
* The new code doesn't do "worker booster"
* Gitea's queue's handlers are light functions, the cost is only the
go-routine, so it doesn't make sense to "boost" them.
* The new code only use "max worker number" to limit the concurrent
workers.
* The new "Push" never blocks forever
* Instead of creating more and more blocking goroutines, return an error
is more friendly to the server and to the end user.
There are more details in code comments: eg: the "Flush" problem, the
strange "code.index" hanging problem, the "immediate" queue problem.
Almost ready for review.
TODO:
* [x] add some necessary comments during review
* [x] add some more tests if necessary
* [x] update documents and config options
* [x] test max worker / active worker
* [x] re-run the CI tasks to see whether any test is flaky
* [x] improve the `handleOldLengthConfiguration` to provide more
friendly messages
* [x] fine tune default config values (eg: length?)
## Code coverage:
2023-05-08 07:49:59 -04:00
package testlogger
2019-04-06 20:25:14 -04:00
import (
2024-03-14 09:45:41 -04:00
"bytes"
2020-01-28 20:01:06 -05:00
"context"
2024-03-14 09:45:41 -04:00
"errors"
2019-04-06 20:25:14 -04:00
"fmt"
2024-03-14 09:45:41 -04:00
"io"
2019-04-06 20:25:14 -04:00
"os"
"runtime"
"strings"
2019-09-17 05:39:37 -04:00
"sync"
2019-04-06 20:25:14 -04:00
"testing"
2020-06-01 21:39:44 -04:00
"time"
2019-04-06 20:25:14 -04:00
"code.gitea.io/gitea/modules/log"
2020-01-28 20:01:06 -05:00
"code.gitea.io/gitea/modules/queue"
2019-04-06 20:25:14 -04:00
)
2020-06-01 21:39:44 -04:00
var (
prefix string
2022-09-02 15:18:23 -04:00
SlowTest = 10 * time . Second
SlowFlush = 5 * time . Second
2020-06-01 21:39:44 -04:00
)
2019-04-06 20:25:14 -04:00
2022-09-02 15:18:23 -04:00
var WriterCloser = & testLoggerWriterCloser { }
2019-04-06 20:25:14 -04:00
type testLoggerWriterCloser struct {
2019-09-17 05:39:37 -04:00
sync . RWMutex
2024-03-14 09:45:41 -04:00
t [ ] testing . TB
errs [ ] error // stack of error, parallel to the stack of testing.TB
err error // fallback if the stack is empty
2019-04-06 20:25:14 -04:00
}
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
func ( w * testLoggerWriterCloser ) pushT ( t testing . TB ) {
2019-09-17 05:39:37 -04:00
w . Lock ( )
2019-11-25 18:21:37 -05:00
w . t = append ( w . t , t )
2024-03-14 09:45:41 -04:00
w . errs = append ( w . errs , nil )
2019-09-17 05:39:37 -04:00
w . Unlock ( )
}
2024-03-14 09:45:41 -04:00
func ( w * testLoggerWriterCloser ) Log ( level log . Level , msg string ) {
2024-03-28 06:41:27 -04:00
msg = strings . TrimSpace ( msg )
2024-03-14 09:45:41 -04:00
w . printMsg ( msg )
if level >= log . ERROR {
w . recordError ( msg )
}
}
// list of error message which will not fail the test
// ideally this list should be empty, however ensuring that it does not grow
// is already a good first step.
2024-03-31 14:57:49 -04:00
var ignoredErrorMessage = [ ] string {
2024-03-14 09:45:41 -04:00
// only seen on mysql tests https://codeberg.org/forgejo/forgejo/pulls/2657#issuecomment-1693055
` table columns using inconsistent collation, they should use "utf8mb4_0900_ai_ci". Please go to admin panel Self Check page ` ,
2024-03-31 14:57:49 -04:00
// TestPullWIPConvertSidebar
` :PullRequestPushCommits() [E] comment.LoadIssue: issue does not exist [id: ` ,
2024-03-14 09:45:41 -04:00
// TestAPIDeleteReleaseByTagName
// action notification were a commit cannot be computed (because the commit got deleted)
` Notify() [E] an error occurred while executing the DeleteRelease actions method: gitRepo.GetCommit: object does not exist [id: refs/tags/release-tag, rel_path: ] ` ,
` Notify() [E] an error occurred while executing the PushCommits actions method: gitRepo.GetCommit: object does not exist [id: refs/tags/release-tag, rel_path: ] ` ,
// TestAPIRepoTags
` Notify() [E] an error occurred while executing the DeleteRelease actions method: gitRepo.GetCommit: object does not exist [id: refs/tags/gitea/22, rel_path: ] ` ,
` Notify() [E] an error occurred while executing the PushCommits actions method: gitRepo.GetCommit: object does not exist [id: refs/tags/gitea/22, rel_path: ] ` ,
// TestAPIDeleteTagByName
` Notify() [E] an error occurred while executing the DeleteRelease actions method: gitRepo.GetCommit: object does not exist [id: refs/tags/delete-tag, rel_path: ] ` ,
` Notify() [E] an error occurred while executing the PushCommits actions method: gitRepo.GetCommit: object does not exist [id: refs/tags/delete-tag, rel_path: ] ` ,
// TestAPIGenerateRepo
` Notify() [E] an error occurred while executing the CreateRepository actions method: gitRepo.GetCommit: object does not exist [id: , rel_path: ] ` ,
2024-03-31 14:57:49 -04:00
// TestAPIPullUpdateByRebase
` :testPR() [E] Unable to GetPullRequestByID[ ` ,
` :PullRequestSynchronized() [E] LoadAttributes: getRepositoryByID ` ,
` :PullRequestSynchronized() [E] pr.Issue.LoadRepo: getRepositoryByID [ ` ,
` :handler() [E] Was unable to create issue notification: issue does not exist [ ` ,
` :func1() [E] PullRequestList.LoadAttributes: issues and prs may be not in sync: cannot find issue ` ,
` :func1() [E] checkForInvalidation: GetRepositoryByIDCtx: repository does not exist ` ,
2024-03-14 09:45:41 -04:00
// TestAPIPullReview
` PullRequestReview() [E] Unsupported review webhook type ` ,
// TestAPIPullReviewRequest
` ToAPIPullRequest() [E] unable to resolve PR head ref ` ,
// TestAPILFSUpload
` Put() [E] Whilst putting LFS OID[ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb]: Failed to copy to tmpPath: ca/97/8112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb Error: content size does not match ` ,
` [E] Error putting LFS MetaObject [ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb] into content store. Error: content size does not match ` ,
` UploadHandler() [E] Upload does not match LFS MetaObject [ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb]. Error: content size does not match ` ,
` Put() [E] Whilst putting LFS OID[2581dd7bbc1fe44726de4b7dd806a087a978b9c5aec0a60481259e34be09b06a]: Failed to copy to tmpPath: 25/81/dd7bbc1fe44726de4b7dd806a087a978b9c5aec0a60481259e34be09b06a Error: content hash does not match OID ` ,
` [E] Error putting LFS MetaObject [2581dd7bbc1fe44726de4b7dd806a087a978b9c5aec0a60481259e34be09b06a] into content store. Error: content hash does not match OID ` ,
` UploadHandler() [E] Upload does not match LFS MetaObject [2581dd7bbc1fe44726de4b7dd806a087a978b9c5aec0a60481259e34be09b06a]. Error: content hash does not match OID ` ,
` UploadHandler() [E] Upload does not match LFS MetaObject [83de2e488b89a0aa1c97496b888120a28b0c1e15463a4adb8405578c540f36d4]. Error: content size does not match ` ,
// TestAPILFSVerify
` getAuthenticatedMeta() [E] Unable to get LFS OID[fb8f7d8435968c4f82a726a92395be4d16f2f63116caf36c8ad35c60831ab042] Error: LFS Meta object does not exist ` ,
// TestAPIUpdateOrgAvatar
` UpdateAvatar() [E] UploadAvatar: image.DecodeConfig: image: unknown format ` ,
// TestGetAttachment
` /data/attachments/a/0/a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a18: no such file or directory ` ,
// TestBlockUser
` BlockedUsersUnblock() [E] IsOrganization: org3 is an organization not a user ` ,
` BlockedUsersBlock() [E] IsOrganization: org3 is an organization not a user ` ,
` Action() [E] Cannot perform this action on an organization "unblock" ` ,
` Action() [E] Cannot perform this action on an organization "block" ` ,
// TestBlockActions
` /gitea-repositories/user10/repo7.git Error: no such file or directory ` ,
// TestRebuildCargo
` RebuildCargoIndex() [E] RebuildIndex failed: GetRepositoryByOwnerAndName: repository does not exist [id: 0, uid: 0, owner_name: user2, name: _cargo-index] ` ,
2024-03-28 06:41:27 -04:00
// TestDangerZoneConfirmation/Convert_fork/Fail
` /gitea-repositories/user20/big_test_public_fork_7.git Error: no such file or directory ` ,
// TestGitSmartHTTP
2024-03-31 14:57:49 -04:00
` :sendFile() [E] request file path contains invalid path: objects/info/..\..\..\..\custom\conf\app.ini ` ,
2024-03-28 06:41:27 -04:00
// TestGit/HTTP/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Not allowed to push to protected branch protected. HookPreReceive(last) failed: internal API error response, status=403 ` ,
2024-03-28 06:41:27 -04:00
// TestGit/HTTP/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Not allowed to push to protected branch protected. HookPreReceive(last) failed: internal API error response, status=403 ` ,
2024-03-28 06:41:27 -04:00
// TestGit/HTTP/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: branch protected is protected from force push. HookPreReceive(last) failed: internal API error response, status=403 ` ,
2024-10-24 12:40:14 -04:00
// TestGit/HTTP/BranchProtect
` :SSHLog() [E] ssh: branch before-create-2 is protected from changing file protected-file-data- ` ,
2024-03-28 06:41:27 -04:00
// TestGit/HTTP/MergeFork/CreatePRAndMerge
2024-03-31 14:57:49 -04:00
` :DeleteBranchPost() [E] DeleteBranch: GetBranch: branch does not exist [repo_id: 1099 name: user2:master] ` , // sqlite
2024-03-28 06:41:27 -04:00
"s/web/repo/branch.go:108:DeleteBranchPost() [E] DeleteBranch: GetBranch: branch does not exist [repo_id: 10000 name: user2:master]" , // mysql
"s/web/repo/branch.go:108:DeleteBranchPost() [E] DeleteBranch: GetBranch: branch does not exist [repo_id: 1060 name: user2:master]" , // pgsql
2024-03-31 14:57:49 -04:00
// TestGit/HTTP/BranchProtectMerge
` :func1() [E] PushToBaseRepo: PushRejected Error: exit status 1 - remote: error: cannot lock ref ` ,
// TestGit/SSH/BranchProtectMerge
` :func1() [E] PushToBaseRepo: PushRejected Error: exit status 1 - remote: error: cannot lock ref ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/PushCommit/Little
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/PushCommit/Little
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/PushCommit/Big
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/PushCommit/Big
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/NoParams
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/NoParams
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/TitleOverride
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/TitleOverride
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/DescriptionOverride
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/DescriptionOverride
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push/Fails
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push/Fails
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push/Succeeds
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push/Succeeds
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Branch_already_contains_commit
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Branch_already_contains_commit
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Not allowed to push to protected branch protected. HookPreReceive(last) failed: internal API error response, status=403 ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: branch protected is protected from force push. HookPreReceive(last) failed: internal API error response, status=403 ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/MergeFork/CreatePRAndMerge
2024-03-31 14:57:49 -04:00
` :DeleteBranchPost() [E] DeleteBranch: GetBranch: branch does not exist [repo_id: 1102 name: user2:master] ` , // sqlite
2024-03-28 06:41:27 -04:00
"s/web/repo/branch.go:108:DeleteBranchPost() [E] DeleteBranch: GetBranch: branch does not exist [repo_id: 10003 name: user2:master]" , // mysql
"s/web/repo/branch.go:108:DeleteBranchPost() [E] DeleteBranch: GetBranch: branch does not exist [repo_id: 1063 name: user2:master]" , // pgsql
// TestGit/SSH/PushCreate
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Push to create is not enabled for users. ServCommand failed: internal API error response, status=403 ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/PushCreate
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Cannot find repository: user2/repo-tmp-push-create-ssh. ServCommand failed: internal API error response, status=404 ` ,
2024-03-28 06:41:27 -04:00
// TestGit/SSH/PushCreate
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Invalid repo name. Invalid repo name: invalid/repo-tmp-push-create-ssh ` ,
2024-03-28 06:41:27 -04:00
// TestIssueReaction
2024-03-31 14:57:49 -04:00
` :ChangeIssueReaction() [E] ChangeIssueReaction: '8ball' is not an allowed reaction ` ,
2024-03-28 06:41:27 -04:00
// TestIssuePinMove
2024-03-31 14:57:49 -04:00
` :IssuePinMove() [E] Issue does not belong to this repository ` ,
2024-03-28 06:41:27 -04:00
// TestLinksLogin
2024-05-09 09:49:37 -04:00
` :GetIssuesAllCommitStatus() [E] getAllCommitStatus: can't get commit statuses of pull [6]: object does not exist [id: refs/pull/2/head, rel_path: ] ` ,
2024-03-28 06:41:27 -04:00
// TestLinksLogin
2024-05-09 09:49:37 -04:00
` :GetIssuesAllCommitStatus() [E] getAllCommitStatus: can't get commit statuses of pull [6]: object does not exist [id: refs/pull/2/head, rel_path: ] ` ,
2024-03-28 06:41:27 -04:00
// TestLinksLogin
2024-05-09 09:49:37 -04:00
` :GetIssuesAllCommitStatus() [E] getAllCommitStatus: can't get commit statuses of pull [6]: object does not exist [id: refs/pull/2/head, rel_path: ] ` ,
2024-03-28 06:41:27 -04:00
// TestLinksLogin
2024-03-31 14:57:49 -04:00
` :GetIssuesAllCommitStatus() [E] Cannot open git repository <Repository 23:org17/big_test_public_4> for issue #1[20]. Error: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestMigrate
` ] for OwnerID[2] failed: error while listing issues: token does not have at least one of required scope(s): [read:issue] ` ,
// TestMigrate
2024-03-31 14:57:49 -04:00
` :handler() [E] Run task failed: error while listing issues: token does not have at least one of required scope(s): [read:issue] ` ,
2024-03-28 06:41:27 -04:00
// TestMigrate
` ] for OwnerID[2] failed: error while listing issues: token does not have at least one of required scope(s): [read:issue] ` ,
// TestMigrate
2024-03-31 14:57:49 -04:00
` :handler() [E] Run task failed: error while listing issues: token does not have at least one of required scope(s): [read:issue] ` ,
2024-03-28 06:41:27 -04:00
// TestMirrorPush
2024-03-31 14:57:49 -04:00
` :GetInfoRefs() [E] fork/exec /usr/bin/git: no such file or directory - ` ,
2024-03-28 06:41:27 -04:00
// TestOrgMembers
2024-03-31 14:57:49 -04:00
` :loadOrganizationOwners() [E] Organization does not have owner team: 25 ` ,
2024-03-28 06:41:27 -04:00
// TestOrgMembers
2024-03-31 14:57:49 -04:00
` :loadOrganizationOwners() [E] Organization does not have owner team: 25 ` ,
2024-03-28 06:41:27 -04:00
// TestOrgMembers
2024-03-31 14:57:49 -04:00
` :loadOrganizationOwners() [E] Organization does not have owner team: 25 ` ,
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
2024-03-31 14:57:49 -04:00
` :SyncRepoBranches() [E] OpenRepository[user30/repo50]: %!w(*errors.errorString=& { no such file or directory}) ` ,
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
2024-03-31 14:57:49 -04:00
` :handlerBranchSync() [E] syncRepoBranches [50] failed: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
2024-03-31 14:57:49 -04:00
` :SyncRepoBranches() [E] OpenRepository[user30/repo51]: %!w(*errors.errorString=& { no such file or directory}) ` ,
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
2024-03-31 14:57:49 -04:00
` :handlerBranchSync() [E] syncRepoBranches [51] failed: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
2024-03-31 14:57:49 -04:00
` :SyncRepoBranches() [E] OpenRepository[user2/scoped_label]: %!w(*errors.errorString=& { no such file or directory}) ` ,
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
2024-03-31 14:57:49 -04:00
` :handlerBranchSync() [E] syncRepoBranches [55] failed: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestCantMergeConflict
"]user1/repo1#1[base...conflict]> Unable to merge tracking into base: Merge Conflict Error: exit status 1: \nAuto-merging README.md\nCONFLICT (content): Merge conflict in README.md\nAutomatic merge failed; fix conflicts and then commit the result." ,
// TestCantMergeUnrelated
` ]user1/repo1#1[base...unrelated]> Unable to merge tracking into base: Merge UnrelatedHistories Error: exit status 128: fatal: refusing to merge unrelated histories ` ,
// TestCantFastForwardOnlyMergeDiverging
"]user1/repo1#1[master...diverging]> Unable to merge tracking into base: Merge DivergingFastForwardOnly Error: exit status 128: hint: Diverging branches can't be fast-forwarded, you need to either:\nhint: \nhint: \tgit merge --no-ff\nhint: \nhint: or:\nhint: \nhint: \tgit rebase\nhint: \nhint: Disable this message with \"git config advice.diverging false\"\nfatal: Not possible to fast-forward, aborting." ,
// TestPullrequestReopen/Base_branch_deleted
` fatal: couldn't find remote ref base-branch ` ,
// TestPullrequestReopen/Head_branch_deleted
` ]user2/reopen-base#1[base-branch...org26/reopen-head:head-branch]>]: branch does not exist [repo_id: 0 name: head-branch] ` ,
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :SyncRepoBranches() [E] OpenRepository[user30/repo50]: %!w(*errors.errorString=& { no such file or directory}) ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :handlerBranchSync() [E] syncRepoBranches [50] failed: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :SyncRepoBranches() [E] OpenRepository[user30/repo51]: %!w(*errors.errorString=& { no such file or directory}) ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :handlerBranchSync() [E] syncRepoBranches [51] failed: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :SyncRepoBranches() [E] OpenRepository[user2/scoped_label]: %!w(*errors.errorString=& { no such file or directory}) ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :handlerBranchSync() [E] syncRepoBranches [55] failed: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` : LoadBranches ( ) [ E ] loadOneBranch ( ) on repo # 1 , branch ' will - be - missing ' failed : CountDivergingCommits : exit status 128 - fatal : bad revision ' master ... refs / heads / will - be - missing '
2024-03-28 06:41:27 -04:00
- fatal : bad revision ' master ... refs / heads / will - be - missing ' ` ,
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :SyncRepoBranches() [E] OpenRepository[user30/repo50]: %!w(*errors.errorString=& { no such file or directory}) ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :handlerBranchSync() [E] syncRepoBranches [50] failed: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :SyncRepoBranches() [E] OpenRepository[user30/repo51]: %!w(*errors.errorString=& { no such file or directory}) ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :handlerBranchSync() [E] syncRepoBranches [51] failed: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :SyncRepoBranches() [E] OpenRepository[user2/scoped_label]: %!w(*errors.errorString=& { no such file or directory}) ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
2024-03-31 14:57:49 -04:00
` :handlerBranchSync() [E] syncRepoBranches [55] failed: no such file or directory ` ,
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
"LoadBranches() [E] loadOneBranch() on repo #1, branch 'will-be-missing' failed: CountDivergingCommits: exit status 128 - fatal: bad revision 'master...refs/heads/will-be-missing'\n - fatal: bad revision 'master...refs/heads/will-be-missing'" ,
// TestCreateNewTagProtected/Git
2024-03-31 14:57:49 -04:00
` :SSHLog() [E] ssh: Tag v-2 is protected. HookPreReceive(last) failed: internal API error response, status=403 ` ,
2024-03-28 06:41:27 -04:00
// TestMarkDownReadmeImage
2024-03-31 14:57:49 -04:00
` :checkOutdatedBranch() [E] GetBranch: branch does not exist [repo_id: 1 name: home-md-img-check] ` ,
2024-03-28 06:41:27 -04:00
// TestMarkDownReadmeImage
2024-03-31 14:57:49 -04:00
` :checkOutdatedBranch() [E] GetBranch: branch does not exist [repo_id: 1 name: home-md-img-check] ` ,
2024-03-28 06:41:27 -04:00
// TestMarkDownReadmeImageSubfolder
2024-03-31 14:57:49 -04:00
` :checkOutdatedBranch() [E] GetBranch: branch does not exist [repo_id: 1 name: sub-home-md-img-check] ` ,
2024-03-28 06:41:27 -04:00
// TestMarkDownReadmeImageSubfolder
2024-03-31 14:57:49 -04:00
` :checkOutdatedBranch() [E] GetBranch: branch does not exist [repo_id: 1 name: sub-home-md-img-check] ` ,
2024-03-28 06:41:27 -04:00
// TestKeyOnlyOneType
` :ssh-key-test-repo-push is not authorized to write to user2/ssh-key-test-repo. ServCommand failed: internal API error response, status=401 ` ,
// TestPullRebase
"/gitea-repositories/user2/repo1.git' does not appear to be a git repository\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists." ,
// TestPullRebaseMerge
"]user2/repo1#3[master...branch2]>]: branch does not exist [repo_id: 0 name: branch2]" ,
// TestAuthorizeNoClientID
` TrString() [E] Missing translation "form.ResponseType" ` ,
// TestWebhookForms
` TrString() [E] Missing translation "form.AuthorizationHeader" ` ,
` TrString() [E] Missing translation "form.Channel" ` ,
` TrString() [E] Missing translation "form.ContentType" ` ,
` TrString() [E] Missing translation "form.HTTPMethod" ` ,
` TrString() [E] Missing translation "form.PayloadURL" ` ,
// TestRenameInvalidUsername
` TrString() [E] Missing translation "form.Name" ` ,
2024-04-02 07:34:17 -04:00
// TestDatabaseCollation
` [E] [Error SQL Query] INSERT INTO test_collation_tbl (txt) VALUES ('main') [] ` ,
2024-03-14 09:45:41 -04:00
}
func ( w * testLoggerWriterCloser ) recordError ( msg string ) {
2024-03-31 14:57:49 -04:00
for _ , s := range ignoredErrorMessage {
if strings . Contains ( msg , s ) {
2024-03-14 09:45:41 -04:00
return
}
}
w . Lock ( )
defer w . Unlock ( )
err := w . err
if len ( w . errs ) > 0 {
err = w . errs [ len ( w . errs ) - 1 ]
}
2024-03-27 17:02:51 -04:00
if len ( w . t ) > 0 {
// format error message to easily add it to the ignore list
2024-03-28 06:41:27 -04:00
msg = fmt . Sprintf ( "// %s\n\t%q," , w . t [ len ( w . t ) - 1 ] . Name ( ) , msg )
2024-03-27 17:02:51 -04:00
}
2024-03-14 09:45:41 -04:00
err = errors . Join ( err , errors . New ( msg ) )
if len ( w . errs ) > 0 {
w . errs [ len ( w . errs ) - 1 ] = err
} else {
w . err = err
}
}
func ( w * testLoggerWriterCloser ) printMsg ( msg string ) {
Rewrite queue (#24505)
# ⚠️ Breaking
Many deprecated queue config options are removed (actually, they should
have been removed in 1.18/1.19).
If you see the fatal message when starting Gitea: "Please update your
app.ini to remove deprecated config options", please follow the error
messages to remove these options from your app.ini.
Example:
```
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].ISSUE_INDEXER_QUEUE_TYPE`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].UPDATE_BUFFER_LEN`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [F] Please update your app.ini to remove deprecated config options
```
Many options in `[queue]` are are dropped, including:
`WRAP_IF_NECESSARY`, `MAX_ATTEMPTS`, `TIMEOUT`, `WORKERS`,
`BLOCK_TIMEOUT`, `BOOST_TIMEOUT`, `BOOST_WORKERS`, they can be removed
from app.ini.
# The problem
The old queue package has some legacy problems:
* complexity: I doubt few people could tell how it works.
* maintainability: Too many channels and mutex/cond are mixed together,
too many different structs/interfaces depends each other.
* stability: due to the complexity & maintainability, sometimes there
are strange bugs and difficult to debug, and some code doesn't have test
(indeed some code is difficult to test because a lot of things are mixed
together).
* general applicability: although it is called "queue", its behavior is
not a well-known queue.
* scalability: it doesn't seem easy to make it work with a cluster
without breaking its behaviors.
It came from some very old code to "avoid breaking", however, its
technical debt is too heavy now. It's a good time to introduce a better
"queue" package.
# The new queue package
It keeps using old config and concept as much as possible.
* It only contains two major kinds of concepts:
* The "base queue": channel, levelqueue, redis
* They have the same abstraction, the same interface, and they are
tested by the same testing code.
* The "WokerPoolQueue", it uses the "base queue" to provide "worker
pool" function, calls the "handler" to process the data in the base
queue.
* The new code doesn't do "PushBack"
* Think about a queue with many workers, the "PushBack" can't guarantee
the order for re-queued unhandled items, so in new code it just does
"normal push"
* The new code doesn't do "pause/resume"
* The "pause/resume" was designed to handle some handler's failure: eg:
document indexer (elasticsearch) is down
* If a queue is paused for long time, either the producers blocks or the
new items are dropped.
* The new code doesn't do such "pause/resume" trick, it's not a common
queue's behavior and it doesn't help much.
* If there are unhandled items, the "push" function just blocks for a
few seconds and then re-queue them and retry.
* The new code doesn't do "worker booster"
* Gitea's queue's handlers are light functions, the cost is only the
go-routine, so it doesn't make sense to "boost" them.
* The new code only use "max worker number" to limit the concurrent
workers.
* The new "Push" never blocks forever
* Instead of creating more and more blocking goroutines, return an error
is more friendly to the server and to the end user.
There are more details in code comments: eg: the "Flush" problem, the
strange "code.index" hanging problem, the "immediate" queue problem.
Almost ready for review.
TODO:
* [x] add some necessary comments during review
* [x] add some more tests if necessary
* [x] update documents and config options
* [x] test max worker / active worker
* [x] re-run the CI tasks to see whether any test is flaky
* [x] improve the `handleOldLengthConfiguration` to provide more
friendly messages
* [x] fine tune default config values (eg: length?)
## Code coverage:
2023-05-08 07:49:59 -04:00
// There was a data race problem: the logger system could still try to output logs after the runner is finished.
// So we must ensure that the "t" in stack is still valid.
2019-09-17 05:39:37 -04:00
w . RLock ( )
Rewrite queue (#24505)
# ⚠️ Breaking
Many deprecated queue config options are removed (actually, they should
have been removed in 1.18/1.19).
If you see the fatal message when starting Gitea: "Please update your
app.ini to remove deprecated config options", please follow the error
messages to remove these options from your app.ini.
Example:
```
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].ISSUE_INDEXER_QUEUE_TYPE`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].UPDATE_BUFFER_LEN`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [F] Please update your app.ini to remove deprecated config options
```
Many options in `[queue]` are are dropped, including:
`WRAP_IF_NECESSARY`, `MAX_ATTEMPTS`, `TIMEOUT`, `WORKERS`,
`BLOCK_TIMEOUT`, `BOOST_TIMEOUT`, `BOOST_WORKERS`, they can be removed
from app.ini.
# The problem
The old queue package has some legacy problems:
* complexity: I doubt few people could tell how it works.
* maintainability: Too many channels and mutex/cond are mixed together,
too many different structs/interfaces depends each other.
* stability: due to the complexity & maintainability, sometimes there
are strange bugs and difficult to debug, and some code doesn't have test
(indeed some code is difficult to test because a lot of things are mixed
together).
* general applicability: although it is called "queue", its behavior is
not a well-known queue.
* scalability: it doesn't seem easy to make it work with a cluster
without breaking its behaviors.
It came from some very old code to "avoid breaking", however, its
technical debt is too heavy now. It's a good time to introduce a better
"queue" package.
# The new queue package
It keeps using old config and concept as much as possible.
* It only contains two major kinds of concepts:
* The "base queue": channel, levelqueue, redis
* They have the same abstraction, the same interface, and they are
tested by the same testing code.
* The "WokerPoolQueue", it uses the "base queue" to provide "worker
pool" function, calls the "handler" to process the data in the base
queue.
* The new code doesn't do "PushBack"
* Think about a queue with many workers, the "PushBack" can't guarantee
the order for re-queued unhandled items, so in new code it just does
"normal push"
* The new code doesn't do "pause/resume"
* The "pause/resume" was designed to handle some handler's failure: eg:
document indexer (elasticsearch) is down
* If a queue is paused for long time, either the producers blocks or the
new items are dropped.
* The new code doesn't do such "pause/resume" trick, it's not a common
queue's behavior and it doesn't help much.
* If there are unhandled items, the "push" function just blocks for a
few seconds and then re-queue them and retry.
* The new code doesn't do "worker booster"
* Gitea's queue's handlers are light functions, the cost is only the
go-routine, so it doesn't make sense to "boost" them.
* The new code only use "max worker number" to limit the concurrent
workers.
* The new "Push" never blocks forever
* Instead of creating more and more blocking goroutines, return an error
is more friendly to the server and to the end user.
There are more details in code comments: eg: the "Flush" problem, the
strange "code.index" hanging problem, the "immediate" queue problem.
Almost ready for review.
TODO:
* [x] add some necessary comments during review
* [x] add some more tests if necessary
* [x] update documents and config options
* [x] test max worker / active worker
* [x] re-run the CI tasks to see whether any test is flaky
* [x] improve the `handleOldLengthConfiguration` to provide more
friendly messages
* [x] fine tune default config values (eg: length?)
## Code coverage:
2023-05-08 07:49:59 -04:00
defer w . RUnlock ( )
2019-11-25 18:21:37 -05:00
if len ( w . t ) > 0 {
2024-03-14 09:45:41 -04:00
t := w . t [ len ( w . t ) - 1 ]
t . Log ( msg )
} else {
2023-05-12 10:20:29 -04:00
// if there is no running test, the log message should be outputted to console, to avoid losing important information.
// the "???" prefix is used to match the "===" and "+++" in PrintCurrentTest
2024-03-14 09:45:41 -04:00
fmt . Fprintln ( os . Stdout , "??? [TestLogger]" , msg )
2019-04-06 20:25:14 -04:00
}
}
2024-03-14 09:45:41 -04:00
func ( w * testLoggerWriterCloser ) popT ( ) error {
2019-11-25 18:21:37 -05:00
w . Lock ( )
2024-03-14 09:45:41 -04:00
defer w . Unlock ( )
2019-11-25 18:21:37 -05:00
if len ( w . t ) > 0 {
w . t = w . t [ : len ( w . t ) - 1 ]
2024-03-14 09:45:41 -04:00
err := w . errs [ len ( w . errs ) - 1 ]
w . errs = w . errs [ : len ( w . errs ) - 1 ]
return err
2019-11-25 18:21:37 -05:00
}
2024-03-14 09:45:41 -04:00
return w . err
2019-04-06 20:25:14 -04:00
}
2024-03-14 09:45:41 -04:00
func ( w * testLoggerWriterCloser ) Reset ( ) error {
2021-09-01 09:05:04 -04:00
w . Lock ( )
if len ( w . t ) > 0 {
for _ , t := range w . t {
if t == nil {
continue
}
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "Unclosed logger writer in test: %s" , t . Name ( ) )
t . Errorf ( "Unclosed logger writer in test: %s" , t . Name ( ) )
2021-09-01 09:05:04 -04:00
}
w . t = nil
2024-03-14 09:45:41 -04:00
w . errs = nil
2021-09-01 09:05:04 -04:00
}
2024-03-14 09:45:41 -04:00
err := w . err
w . err = nil
2021-09-01 09:05:04 -04:00
w . Unlock ( )
2024-03-14 09:45:41 -04:00
return err
2021-09-01 09:05:04 -04:00
}
2019-04-06 20:25:14 -04:00
// PrintCurrentTest prints the current test to os.Stdout
2019-11-25 18:21:37 -05:00
func PrintCurrentTest ( t testing . TB , skip ... int ) func ( ) {
Refactor path & config system (#25330)
# The problem
There were many "path tricks":
* By default, Gitea uses its program directory as its work path
* Gitea tries to use the "work path" to guess its "custom path" and
"custom conf (app.ini)"
* Users might want to use other directories as work path
* The non-default work path should be passed to Gitea by GITEA_WORK_DIR
or "--work-path"
* But some Gitea processes are started without these values
* The "serv" process started by OpenSSH server
* The CLI sub-commands started by site admin
* The paths are guessed by SetCustomPathAndConf again and again
* The default values of "work path / custom path / custom conf" can be
changed when compiling
# The solution
* Use `InitWorkPathAndCommonConfig` to handle these path tricks, and use
test code to cover its behaviors.
* When Gitea's web server runs, write the WORK_PATH to "app.ini", this
value must be the most correct one, because if this value is not right,
users would find that the web UI doesn't work and then they should be
able to fix it.
* Then all other sub-commands can use the WORK_PATH in app.ini to
initialize their paths.
* By the way, when Gitea starts for git protocol, it shouldn't output
any log, otherwise the git protocol gets broken and client blocks
forever.
The "work path" priority is: WORK_PATH in app.ini > cmd arg --work-path
> env var GITEA_WORK_DIR > builtin default
The "app.ini" searching order is: cmd arg --config > cmd arg "work path
/ custom path" > env var "work path / custom path" > builtin default
## ⚠️ BREAKING
If your instance's "work path / custom path / custom conf" doesn't meet
the requirements (eg: work path must be absolute), Gitea will report a
fatal error and exit. You need to set these values according to the
error log.
----
Close #24818
Close #24222
Close #21606
Close #21498
Close #25107
Close #24981
Maybe close #24503
Replace #23301
Replace #22754
And maybe more
2023-06-21 01:50:26 -04:00
t . Helper ( )
2020-06-01 21:39:44 -04:00
start := time . Now ( )
2019-04-06 20:25:14 -04:00
actualSkip := 1
if len ( skip ) > 0 {
Refactor path & config system (#25330)
# The problem
There were many "path tricks":
* By default, Gitea uses its program directory as its work path
* Gitea tries to use the "work path" to guess its "custom path" and
"custom conf (app.ini)"
* Users might want to use other directories as work path
* The non-default work path should be passed to Gitea by GITEA_WORK_DIR
or "--work-path"
* But some Gitea processes are started without these values
* The "serv" process started by OpenSSH server
* The CLI sub-commands started by site admin
* The paths are guessed by SetCustomPathAndConf again and again
* The default values of "work path / custom path / custom conf" can be
changed when compiling
# The solution
* Use `InitWorkPathAndCommonConfig` to handle these path tricks, and use
test code to cover its behaviors.
* When Gitea's web server runs, write the WORK_PATH to "app.ini", this
value must be the most correct one, because if this value is not right,
users would find that the web UI doesn't work and then they should be
able to fix it.
* Then all other sub-commands can use the WORK_PATH in app.ini to
initialize their paths.
* By the way, when Gitea starts for git protocol, it shouldn't output
any log, otherwise the git protocol gets broken and client blocks
forever.
The "work path" priority is: WORK_PATH in app.ini > cmd arg --work-path
> env var GITEA_WORK_DIR > builtin default
The "app.ini" searching order is: cmd arg --config > cmd arg "work path
/ custom path" > env var "work path / custom path" > builtin default
## ⚠️ BREAKING
If your instance's "work path / custom path / custom conf" doesn't meet
the requirements (eg: work path must be absolute), Gitea will report a
fatal error and exit. You need to set these values according to the
error log.
----
Close #24818
Close #24222
Close #21606
Close #21498
Close #25107
Close #24981
Maybe close #24503
Replace #23301
Replace #22754
And maybe more
2023-06-21 01:50:26 -04:00
actualSkip = skip [ 0 ] + 1
2019-04-06 20:25:14 -04:00
}
_ , filename , line , _ := runtime . Caller ( actualSkip )
if log . CanColorStdout {
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "=== %s (%s:%d)\n" , fmt . Formatter ( log . NewColoredValue ( t . Name ( ) ) ) , strings . TrimPrefix ( filename , prefix ) , line )
2019-04-06 20:25:14 -04:00
} else {
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "=== %s (%s:%d)\n" , t . Name ( ) , strings . TrimPrefix ( filename , prefix ) , line )
2019-04-06 20:25:14 -04:00
}
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
WriterCloser . pushT ( t )
2019-11-25 18:21:37 -05:00
return func ( ) {
2020-06-01 21:39:44 -04:00
took := time . Since ( start )
2022-09-02 15:18:23 -04:00
if took > SlowTest {
2020-06-01 21:39:44 -04:00
if log . CanColorStdout {
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "+++ %s is a slow test (took %v)\n" , fmt . Formatter ( log . NewColoredValue ( t . Name ( ) , log . Bold , log . FgYellow ) ) , fmt . Formatter ( log . NewColoredValue ( took , log . Bold , log . FgYellow ) ) )
2020-06-01 21:39:44 -04:00
} else {
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "+++ %s is a slow test (took %v)\n" , t . Name ( ) , took )
2020-06-01 21:39:44 -04:00
}
}
2022-09-02 15:18:23 -04:00
timer := time . AfterFunc ( SlowFlush , func ( ) {
2020-06-01 21:39:44 -04:00
if log . CanColorStdout {
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "+++ %s ... still flushing after %v ...\n" , fmt . Formatter ( log . NewColoredValue ( t . Name ( ) , log . Bold , log . FgRed ) ) , SlowFlush )
2020-06-01 21:39:44 -04:00
} else {
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "+++ %s ... still flushing after %v ...\n" , t . Name ( ) , SlowFlush )
2020-06-01 21:39:44 -04:00
}
} )
Rewrite queue (#24505)
# ⚠️ Breaking
Many deprecated queue config options are removed (actually, they should
have been removed in 1.18/1.19).
If you see the fatal message when starting Gitea: "Please update your
app.ini to remove deprecated config options", please follow the error
messages to remove these options from your app.ini.
Example:
```
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].ISSUE_INDEXER_QUEUE_TYPE`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].UPDATE_BUFFER_LEN`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [F] Please update your app.ini to remove deprecated config options
```
Many options in `[queue]` are are dropped, including:
`WRAP_IF_NECESSARY`, `MAX_ATTEMPTS`, `TIMEOUT`, `WORKERS`,
`BLOCK_TIMEOUT`, `BOOST_TIMEOUT`, `BOOST_WORKERS`, they can be removed
from app.ini.
# The problem
The old queue package has some legacy problems:
* complexity: I doubt few people could tell how it works.
* maintainability: Too many channels and mutex/cond are mixed together,
too many different structs/interfaces depends each other.
* stability: due to the complexity & maintainability, sometimes there
are strange bugs and difficult to debug, and some code doesn't have test
(indeed some code is difficult to test because a lot of things are mixed
together).
* general applicability: although it is called "queue", its behavior is
not a well-known queue.
* scalability: it doesn't seem easy to make it work with a cluster
without breaking its behaviors.
It came from some very old code to "avoid breaking", however, its
technical debt is too heavy now. It's a good time to introduce a better
"queue" package.
# The new queue package
It keeps using old config and concept as much as possible.
* It only contains two major kinds of concepts:
* The "base queue": channel, levelqueue, redis
* They have the same abstraction, the same interface, and they are
tested by the same testing code.
* The "WokerPoolQueue", it uses the "base queue" to provide "worker
pool" function, calls the "handler" to process the data in the base
queue.
* The new code doesn't do "PushBack"
* Think about a queue with many workers, the "PushBack" can't guarantee
the order for re-queued unhandled items, so in new code it just does
"normal push"
* The new code doesn't do "pause/resume"
* The "pause/resume" was designed to handle some handler's failure: eg:
document indexer (elasticsearch) is down
* If a queue is paused for long time, either the producers blocks or the
new items are dropped.
* The new code doesn't do such "pause/resume" trick, it's not a common
queue's behavior and it doesn't help much.
* If there are unhandled items, the "push" function just blocks for a
few seconds and then re-queue them and retry.
* The new code doesn't do "worker booster"
* Gitea's queue's handlers are light functions, the cost is only the
go-routine, so it doesn't make sense to "boost" them.
* The new code only use "max worker number" to limit the concurrent
workers.
* The new "Push" never blocks forever
* Instead of creating more and more blocking goroutines, return an error
is more friendly to the server and to the end user.
There are more details in code comments: eg: the "Flush" problem, the
strange "code.index" hanging problem, the "immediate" queue problem.
Almost ready for review.
TODO:
* [x] add some necessary comments during review
* [x] add some more tests if necessary
* [x] update documents and config options
* [x] test max worker / active worker
* [x] re-run the CI tasks to see whether any test is flaky
* [x] improve the `handleOldLengthConfiguration` to provide more
friendly messages
* [x] fine tune default config values (eg: length?)
## Code coverage:
2023-05-08 07:49:59 -04:00
if err := queue . GetManager ( ) . FlushAll ( context . Background ( ) , time . Minute ) ; err != nil {
2020-01-28 20:01:06 -05:00
t . Errorf ( "Flushing queues failed with error %v" , err )
}
2020-06-01 21:39:44 -04:00
timer . Stop ( )
flushTook := time . Since ( start ) - took
2022-09-02 15:18:23 -04:00
if flushTook > SlowFlush {
2020-06-01 21:39:44 -04:00
if log . CanColorStdout {
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "+++ %s had a slow clean-up flush (took %v)\n" , fmt . Formatter ( log . NewColoredValue ( t . Name ( ) , log . Bold , log . FgRed ) ) , fmt . Formatter ( log . NewColoredValue ( flushTook , log . Bold , log . FgRed ) ) )
2020-06-01 21:39:44 -04:00
} else {
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "+++ %s had a slow clean-up flush (took %v)\n" , t . Name ( ) , flushTook )
2020-06-01 21:39:44 -04:00
}
}
2024-03-14 09:45:41 -04:00
if err := WriterCloser . popT ( ) ; err != nil {
2024-04-01 05:00:32 -04:00
// disable test failure for now (too flacky)
_ , _ = fmt . Fprintf ( os . Stdout , "testlogger.go:recordError() FATAL ERROR: log.Error has been called: %v" , err )
// t.Errorf("testlogger.go:recordError() FATAL ERROR: log.Error has been called: %v", err)
2024-03-14 09:45:41 -04:00
}
2019-11-25 18:21:37 -05:00
}
2019-04-06 20:25:14 -04:00
}
// Printf takes a format and args and prints the string to os.Stdout
2023-07-04 14:36:08 -04:00
func Printf ( format string , args ... any ) {
2019-04-06 20:25:14 -04:00
if log . CanColorStdout {
for i := 0 ; i < len ( args ) ; i ++ {
args [ i ] = log . NewColoredValue ( args [ i ] )
}
}
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
_ , _ = fmt . Fprintf ( os . Stdout , "\t" + format , args ... )
2019-04-06 20:25:14 -04:00
}
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
// NewTestLoggerWriter creates a TestLogEventWriter as a log.LoggerProvider
func NewTestLoggerWriter ( name string , mode log . WriterMode ) log . EventWriter {
w := & TestLogEventWriter { }
2024-03-14 09:45:41 -04:00
w . base = log . NewEventWriterBase ( name , "test-log-writer" , mode )
w . writer = WriterCloser
Rewrite logger system (#24726)
## ⚠️ 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>
2023-05-21 18:35:11 -04:00
return w
2019-04-06 20:25:14 -04:00
}
2024-03-14 09:45:41 -04:00
// TestLogEventWriter is a logger which will write to the testing log
type TestLogEventWriter struct {
base * log . EventWriterBaseImpl
writer * testLoggerWriterCloser
}
// Base implements log.EventWriter.
func ( t * TestLogEventWriter ) Base ( ) * log . EventWriterBaseImpl {
return t . base
}
// GetLevel implements log.EventWriter.
func ( t * TestLogEventWriter ) GetLevel ( ) log . Level {
return t . base . GetLevel ( )
}
// GetWriterName implements log.EventWriter.
func ( t * TestLogEventWriter ) GetWriterName ( ) string {
return t . base . GetWriterName ( )
}
// GetWriterType implements log.EventWriter.
func ( t * TestLogEventWriter ) GetWriterType ( ) string {
return t . base . GetWriterType ( )
}
// Run implements log.EventWriter.
func ( t * TestLogEventWriter ) Run ( ctx context . Context ) {
for {
select {
case <- ctx . Done ( ) :
return
case event , ok := <- t . base . Queue :
if ! ok {
return
}
var errorMsg string
switch msg := event . Msg . ( type ) {
case string :
errorMsg = msg
case [ ] byte :
errorMsg = string ( msg )
case io . WriterTo :
var buf bytes . Buffer
if _ , err := msg . WriteTo ( & buf ) ; err != nil {
panic ( err )
}
errorMsg = buf . String ( )
default :
errorMsg = fmt . Sprint ( msg )
}
t . writer . Log ( event . Origin . Level , errorMsg )
}
}
}
2019-04-06 20:25:14 -04:00
func init ( ) {
Rewrite queue (#24505)
# ⚠️ Breaking
Many deprecated queue config options are removed (actually, they should
have been removed in 1.18/1.19).
If you see the fatal message when starting Gitea: "Please update your
app.ini to remove deprecated config options", please follow the error
messages to remove these options from your app.ini.
Example:
```
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].ISSUE_INDEXER_QUEUE_TYPE`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].UPDATE_BUFFER_LEN`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [F] Please update your app.ini to remove deprecated config options
```
Many options in `[queue]` are are dropped, including:
`WRAP_IF_NECESSARY`, `MAX_ATTEMPTS`, `TIMEOUT`, `WORKERS`,
`BLOCK_TIMEOUT`, `BOOST_TIMEOUT`, `BOOST_WORKERS`, they can be removed
from app.ini.
# The problem
The old queue package has some legacy problems:
* complexity: I doubt few people could tell how it works.
* maintainability: Too many channels and mutex/cond are mixed together,
too many different structs/interfaces depends each other.
* stability: due to the complexity & maintainability, sometimes there
are strange bugs and difficult to debug, and some code doesn't have test
(indeed some code is difficult to test because a lot of things are mixed
together).
* general applicability: although it is called "queue", its behavior is
not a well-known queue.
* scalability: it doesn't seem easy to make it work with a cluster
without breaking its behaviors.
It came from some very old code to "avoid breaking", however, its
technical debt is too heavy now. It's a good time to introduce a better
"queue" package.
# The new queue package
It keeps using old config and concept as much as possible.
* It only contains two major kinds of concepts:
* The "base queue": channel, levelqueue, redis
* They have the same abstraction, the same interface, and they are
tested by the same testing code.
* The "WokerPoolQueue", it uses the "base queue" to provide "worker
pool" function, calls the "handler" to process the data in the base
queue.
* The new code doesn't do "PushBack"
* Think about a queue with many workers, the "PushBack" can't guarantee
the order for re-queued unhandled items, so in new code it just does
"normal push"
* The new code doesn't do "pause/resume"
* The "pause/resume" was designed to handle some handler's failure: eg:
document indexer (elasticsearch) is down
* If a queue is paused for long time, either the producers blocks or the
new items are dropped.
* The new code doesn't do such "pause/resume" trick, it's not a common
queue's behavior and it doesn't help much.
* If there are unhandled items, the "push" function just blocks for a
few seconds and then re-queue them and retry.
* The new code doesn't do "worker booster"
* Gitea's queue's handlers are light functions, the cost is only the
go-routine, so it doesn't make sense to "boost" them.
* The new code only use "max worker number" to limit the concurrent
workers.
* The new "Push" never blocks forever
* Instead of creating more and more blocking goroutines, return an error
is more friendly to the server and to the end user.
There are more details in code comments: eg: the "Flush" problem, the
strange "code.index" hanging problem, the "immediate" queue problem.
Almost ready for review.
TODO:
* [x] add some necessary comments during review
* [x] add some more tests if necessary
* [x] update documents and config options
* [x] test max worker / active worker
* [x] re-run the CI tasks to see whether any test is flaky
* [x] improve the `handleOldLengthConfiguration` to provide more
friendly messages
* [x] fine tune default config values (eg: length?)
## Code coverage:
2023-05-08 07:49:59 -04:00
const relFilePath = "modules/testlogger/testlogger.go"
2019-04-06 20:25:14 -04:00
_ , filename , _ , _ := runtime . Caller ( 0 )
Rewrite queue (#24505)
# ⚠️ Breaking
Many deprecated queue config options are removed (actually, they should
have been removed in 1.18/1.19).
If you see the fatal message when starting Gitea: "Please update your
app.ini to remove deprecated config options", please follow the error
messages to remove these options from your app.ini.
Example:
```
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].ISSUE_INDEXER_QUEUE_TYPE`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [E] Removed queue option: `[indexer].UPDATE_BUFFER_LEN`. Use new options in `[queue.issue_indexer]`
2023/05/06 19:39:22 [F] Please update your app.ini to remove deprecated config options
```
Many options in `[queue]` are are dropped, including:
`WRAP_IF_NECESSARY`, `MAX_ATTEMPTS`, `TIMEOUT`, `WORKERS`,
`BLOCK_TIMEOUT`, `BOOST_TIMEOUT`, `BOOST_WORKERS`, they can be removed
from app.ini.
# The problem
The old queue package has some legacy problems:
* complexity: I doubt few people could tell how it works.
* maintainability: Too many channels and mutex/cond are mixed together,
too many different structs/interfaces depends each other.
* stability: due to the complexity & maintainability, sometimes there
are strange bugs and difficult to debug, and some code doesn't have test
(indeed some code is difficult to test because a lot of things are mixed
together).
* general applicability: although it is called "queue", its behavior is
not a well-known queue.
* scalability: it doesn't seem easy to make it work with a cluster
without breaking its behaviors.
It came from some very old code to "avoid breaking", however, its
technical debt is too heavy now. It's a good time to introduce a better
"queue" package.
# The new queue package
It keeps using old config and concept as much as possible.
* It only contains two major kinds of concepts:
* The "base queue": channel, levelqueue, redis
* They have the same abstraction, the same interface, and they are
tested by the same testing code.
* The "WokerPoolQueue", it uses the "base queue" to provide "worker
pool" function, calls the "handler" to process the data in the base
queue.
* The new code doesn't do "PushBack"
* Think about a queue with many workers, the "PushBack" can't guarantee
the order for re-queued unhandled items, so in new code it just does
"normal push"
* The new code doesn't do "pause/resume"
* The "pause/resume" was designed to handle some handler's failure: eg:
document indexer (elasticsearch) is down
* If a queue is paused for long time, either the producers blocks or the
new items are dropped.
* The new code doesn't do such "pause/resume" trick, it's not a common
queue's behavior and it doesn't help much.
* If there are unhandled items, the "push" function just blocks for a
few seconds and then re-queue them and retry.
* The new code doesn't do "worker booster"
* Gitea's queue's handlers are light functions, the cost is only the
go-routine, so it doesn't make sense to "boost" them.
* The new code only use "max worker number" to limit the concurrent
workers.
* The new "Push" never blocks forever
* Instead of creating more and more blocking goroutines, return an error
is more friendly to the server and to the end user.
There are more details in code comments: eg: the "Flush" problem, the
strange "code.index" hanging problem, the "immediate" queue problem.
Almost ready for review.
TODO:
* [x] add some necessary comments during review
* [x] add some more tests if necessary
* [x] update documents and config options
* [x] test max worker / active worker
* [x] re-run the CI tasks to see whether any test is flaky
* [x] improve the `handleOldLengthConfiguration` to provide more
friendly messages
* [x] fine tune default config values (eg: length?)
## Code coverage:
2023-05-08 07:49:59 -04:00
if ! strings . HasSuffix ( filename , relFilePath ) {
panic ( "source code file path doesn't match expected: " + relFilePath )
}
prefix = strings . TrimSuffix ( filename , relFilePath )
2019-04-06 20:25:14 -04:00
}
