foster/forgejo
1
0
Fork 0
mirror of https://codeberg.org/forgejo/forgejo.git synced 2024-12-27 13:39:19 -05:00
Code Issues Wiki Activity
forgejo/modules/testlogger/testlogger.go

579 lines
27 KiB
Go
Raw Normal View History

Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
// Copyright 2019 The Gitea Authors. All rights reserved.
Implement FSFE REUSE for golang files (#21840) Change all license headers to comply with REUSE specification. Fix #16132 Co-authored-by: flynnnnnnnnnn <flynnnnnnnnnn@github> Co-authored-by: John Olheiser <john.olheiser@gmail.com>
2022-11-27 13:20:29 -05:00
// SPDX-License-Identifier: MIT
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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: ![image](https://user-images.githubusercontent.com/2114189/236620635-55576955-f95d-4810-b12f-879026a3afdf.png)
2023-05-08 07:49:59 -04:00
package testlogger
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
import (
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
"bytes"
Queue: Make WorkerPools and Queues flushable (#10001) * Make WorkerPools and Queues flushable Adds Flush methods to Queues and the WorkerPool Further abstracts the WorkerPool Adds a final step to Flush the queues in the defer from PrintCurrentTest Fixes an issue with Settings inheritance in queues Signed-off-by: Andrew Thornton <art27@cantab.net> * Change to for loop * Add IsEmpty and begin just making the queues composed WorkerPools * subsume workerpool into the queues and create a flushable interface * Add manager command * Move flushall to queue.Manager and add to testlogger * As per @guillep2k * as per @guillep2k * Just make queues all implement flushable and clean up the wrapped queue flushes * cope with no timeout Co-authored-by: Lauris BH <lauris@nix.lv>
2020-01-28 20:01:06 -05:00
"context"
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
"errors"
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
"fmt"
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
"io"
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
"os"
"runtime"
"strings"
Fix data race (#8204) * Fix data race * Fix data race in modules/log * Make the scope of lock finner-grained * Use syc.Map * Fix missing change in the test * Do not export LoggerMap
2019-09-17 05:39:37 -04:00
"sync"
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
"testing"
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-06-01 21:39:44 -04:00
"time"
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
"code.gitea.io/gitea/modules/log"
Queue: Make WorkerPools and Queues flushable (#10001) * Make WorkerPools and Queues flushable Adds Flush methods to Queues and the WorkerPool Further abstracts the WorkerPool Adds a final step to Flush the queues in the defer from PrintCurrentTest Fixes an issue with Settings inheritance in queues Signed-off-by: Andrew Thornton <art27@cantab.net> * Change to for loop * Add IsEmpty and begin just making the queues composed WorkerPools * subsume workerpool into the queues and create a flushable interface * Add manager command * Move flushall to queue.Manager and add to testlogger * As per @guillep2k * as per @guillep2k * Just make queues all implement flushable and clean up the wrapped queue flushes * cope with no timeout Co-authored-by: Lauris BH <lauris@nix.lv>
2020-01-28 20:01:06 -05:00
"code.gitea.io/gitea/modules/queue"
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
)
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-06-01 21:39:44 -04:00
var (
prefix string
Kd/ci playwright go test (#20123) * Add initial playwright config * Simplify Makefile * Simplify Makefile * Use correct config files * Update playwright settings * Fix package-lock file * Don't use test logger for e2e tests * fix frontend lint * Allow passing TEST_LOGGER variable * Init postgres database * use standard gitea env variables * Update playwright * update drone * Move empty env var to commands * Cleanup * Move integrations to subfolder * tests integrations to tests integraton * Run e2e tests with go test * Fix linting * install CI deps * Add files to ESlint * Fix drone typo * Don't log to console in CI * Use go test http server * Add build step before tests * Move shared init function to common package * fix drone * Clean up tests * Fix linting * Better mocking for page + version string * Cleanup test generation * Remove dependency on gitea binary * Fix linting * add initial support for running specific tests * Add ACCEPT_VISUAL variable * don't require git-lfs * Add initial documentation * Review feedback * Add logged in session test * Attempt fixing drone race * Cleanup and bump version * Bump deps * Review feedback * simplify installation * Fix ci * Update install docs
2022-09-02 15:18:23 -04:00
SlowTest = 10 * time.Second
SlowFlush = 5 * time.Second
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-06-01 21:39:44 -04:00
)
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
Kd/ci playwright go test (#20123) * Add initial playwright config * Simplify Makefile * Simplify Makefile * Use correct config files * Update playwright settings * Fix package-lock file * Don't use test logger for e2e tests * fix frontend lint * Allow passing TEST_LOGGER variable * Init postgres database * use standard gitea env variables * Update playwright * update drone * Move empty env var to commands * Cleanup * Move integrations to subfolder * tests integrations to tests integraton * Run e2e tests with go test * Fix linting * install CI deps * Add files to ESlint * Fix drone typo * Don't log to console in CI * Use go test http server * Add build step before tests * Move shared init function to common package * fix drone * Clean up tests * Fix linting * Better mocking for page + version string * Cleanup test generation * Remove dependency on gitea binary * Fix linting * add initial support for running specific tests * Add ACCEPT_VISUAL variable * don't require git-lfs * Add initial documentation * Review feedback * Add logged in session test * Attempt fixing drone race * Cleanup and bump version * Bump deps * Review feedback * simplify installation * Fix ci * Update install docs
2022-09-02 15:18:23 -04:00
var WriterCloser = &testLoggerWriterCloser{}
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
type testLoggerWriterCloser struct {
Fix data race (#8204) * Fix data race * Fix data race in modules/log * Make the scope of lock finner-grained * Use syc.Map * Fix missing change in the test * Do not export LoggerMap
2019-09-17 05:39:37 -04:00
sync.RWMutex
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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) {
Fix data race (#8204) * Fix data race * Fix data race in modules/log * Make the scope of lock finner-grained * Use syc.Map * Fix missing change in the test * Do not export LoggerMap
2019-09-17 05:39:37 -04:00
w.Lock()
Fix "data race" in testlogger (#9159) * Fix data race in testlogger * Update git_helper_for_declarative_test.go
2019-11-25 18:21:37 -05:00
w.t = append(w.t, t)
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
w.errs = append(w.errs, nil)
Fix data race (#8204) * Fix data race * Fix data race in modules/log * Make the scope of lock finner-grained * Use syc.Map * Fix missing change in the test * Do not export LoggerMap
2019-09-17 05:39:37 -04:00
w.Unlock()
}
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
func (w *testLoggerWriterCloser) Log(level log.Level, msg string) {
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
msg = strings.TrimSpace(msg)
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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.
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
var ignoredErrorMessage = []string{
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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`,
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
// TestPullWIPConvertSidebar
`:PullRequestPushCommits() [E] comment.LoadIssue: issue does not exist [id:`,
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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: ]`,
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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 `,
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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]`,
populate testlogger ignoreList
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
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:sendFile() [E] request file path contains invalid path: objects/info/..\..\..\..\custom\conf\app.ini`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/HTTP/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/HTTP/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/HTTP/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/HTTP/MergeFork/CreatePRAndMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:DeleteBranchPost() [E] DeleteBranch: GetBranch: branch does not exist [repo_id: 1099 name: user2:master]`, // sqlite
populate testlogger ignoreList
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
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/PushCommit/Little
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/PushCommit/Little
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/PushCommit/Big
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/PushCommit/Big
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/LFS/Locks
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/NoParams
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/NoParams
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/TitleOverride
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/TitleOverride
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/DescriptionOverride
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/PushParams/DescriptionOverride
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push/Fails
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push/Fails
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push/Succeeds
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push/Succeeds
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Force_push
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Branch_already_contains_commit
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull/Branch_already_contains_commit
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/CreateAgitFlowPull
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/BranchProtectMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Unknown git command. Unknown git command git-lfs-transfer`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/MergeFork/CreatePRAndMerge
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:DeleteBranchPost() [E] DeleteBranch: GetBranch: branch does not exist [repo_id: 1102 name: user2:master]`, // sqlite
populate testlogger ignoreList
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
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/PushCreate
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestGit/SSH/PushCreate
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SSHLog() [E] ssh: Invalid repo name. Invalid repo name: invalid/repo-tmp-push-create-ssh`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestIssueReaction
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:ChangeIssueReaction() [E] ChangeIssueReaction: '8ball' is not an allowed reaction`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestIssuePinMove
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:IssuePinMove() [E] Issue does not belong to this repository`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestLinksLogin
Add codespell support and fix a good number of typos with its help (#3270) More about codespell: https://github.com/codespell-project/codespell . I personally introduced it to dozens if not hundreds of projects already and so far only positive feedback. ``` ❯ grep lint-spell Makefile @echo " - lint-spell lint spelling" @echo " - lint-spell-fix lint spelling and fix issues" lint: lint-frontend lint-backend lint-spell lint-fix: lint-frontend-fix lint-backend-fix lint-spell-fix .PHONY: lint-spell lint-spell: lint-codespell .PHONY: lint-spell-fix lint-spell-fix: lint-codespell-fix ❯ git grep lint- -- .forgejo/ .forgejo/workflows/testing.yml: - run: make --always-make -j$(nproc) lint-backend checks-backend # ensure the "go-licenses" make target runs .forgejo/workflows/testing.yml: - run: make lint-frontend ``` so how would you like me to invoke `lint-codespell` on CI? (without that would be IMHO very suboptimal and let typos sneak in) Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3270 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Yaroslav Halchenko <debian@onerussian.com> Co-committed-by: Yaroslav Halchenko <debian@onerussian.com>
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: ]`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestLinksLogin
Add codespell support and fix a good number of typos with its help (#3270) More about codespell: https://github.com/codespell-project/codespell . I personally introduced it to dozens if not hundreds of projects already and so far only positive feedback. ``` ❯ grep lint-spell Makefile @echo " - lint-spell lint spelling" @echo " - lint-spell-fix lint spelling and fix issues" lint: lint-frontend lint-backend lint-spell lint-fix: lint-frontend-fix lint-backend-fix lint-spell-fix .PHONY: lint-spell lint-spell: lint-codespell .PHONY: lint-spell-fix lint-spell-fix: lint-codespell-fix ❯ git grep lint- -- .forgejo/ .forgejo/workflows/testing.yml: - run: make --always-make -j$(nproc) lint-backend checks-backend # ensure the "go-licenses" make target runs .forgejo/workflows/testing.yml: - run: make lint-frontend ``` so how would you like me to invoke `lint-codespell` on CI? (without that would be IMHO very suboptimal and let typos sneak in) Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3270 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Yaroslav Halchenko <debian@onerussian.com> Co-committed-by: Yaroslav Halchenko <debian@onerussian.com>
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: ]`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestLinksLogin
Add codespell support and fix a good number of typos with its help (#3270) More about codespell: https://github.com/codespell-project/codespell . I personally introduced it to dozens if not hundreds of projects already and so far only positive feedback. ``` ❯ grep lint-spell Makefile @echo " - lint-spell lint spelling" @echo " - lint-spell-fix lint spelling and fix issues" lint: lint-frontend lint-backend lint-spell lint-fix: lint-frontend-fix lint-backend-fix lint-spell-fix .PHONY: lint-spell lint-spell: lint-codespell .PHONY: lint-spell-fix lint-spell-fix: lint-codespell-fix ❯ git grep lint- -- .forgejo/ .forgejo/workflows/testing.yml: - run: make --always-make -j$(nproc) lint-backend checks-backend # ensure the "go-licenses" make target runs .forgejo/workflows/testing.yml: - run: make lint-frontend ``` so how would you like me to invoke `lint-codespell` on CI? (without that would be IMHO very suboptimal and let typos sneak in) Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3270 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Yaroslav Halchenko <debian@onerussian.com> Co-committed-by: Yaroslav Halchenko <debian@onerussian.com>
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: ]`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestLinksLogin
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
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
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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]`,
populate testlogger ignoreList
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
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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]`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestMirrorPush
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:GetInfoRefs() [E] fork/exec /usr/bin/git: no such file or directory -`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestOrgMembers
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:loadOrganizationOwners() [E] Organization does not have owner team: 25`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestOrgMembers
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:loadOrganizationOwners() [E] Organization does not have owner team: 25`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestOrgMembers
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:loadOrganizationOwners() [E] Organization does not have owner team: 25`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SyncRepoBranches() [E] OpenRepository[user30/repo50]: %!w(*errors.errorString=&{no such file or directory})`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:handlerBranchSync() [E] syncRepoBranches [50] failed: no such file or directory`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SyncRepoBranches() [E] OpenRepository[user30/repo51]: %!w(*errors.errorString=&{no such file or directory})`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:handlerBranchSync() [E] syncRepoBranches [51] failed: no such file or directory`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SyncRepoBranches() [E] OpenRepository[user2/scoped_label]: %!w(*errors.errorString=&{no such file or directory})`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestRecentlyPushed/unrelated_branches_are_not_shown
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:handlerBranchSync() [E] syncRepoBranches [55] failed: no such file or directory`,
populate testlogger ignoreList
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
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SyncRepoBranches() [E] OpenRepository[user30/repo50]: %!w(*errors.errorString=&{no such file or directory})`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:handlerBranchSync() [E] syncRepoBranches [50] failed: no such file or directory`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SyncRepoBranches() [E] OpenRepository[user30/repo51]: %!w(*errors.errorString=&{no such file or directory})`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:handlerBranchSync() [E] syncRepoBranches [51] failed: no such file or directory`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SyncRepoBranches() [E] OpenRepository[user2/scoped_label]: %!w(*errors.errorString=&{no such file or directory})`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:handlerBranchSync() [E] syncRepoBranches [55] failed: no such file or directory`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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'
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
- fatal: bad revision 'master...refs/heads/will-be-missing'`,
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SyncRepoBranches() [E] OpenRepository[user30/repo50]: %!w(*errors.errorString=&{no such file or directory})`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:handlerBranchSync() [E] syncRepoBranches [50] failed: no such file or directory`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SyncRepoBranches() [E] OpenRepository[user30/repo51]: %!w(*errors.errorString=&{no such file or directory})`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:handlerBranchSync() [E] syncRepoBranches [51] failed: no such file or directory`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:SyncRepoBranches() [E] OpenRepository[user2/scoped_label]: %!w(*errors.errorString=&{no such file or directory})`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestDatabaseMissingABranch
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:handlerBranchSync() [E] syncRepoBranches [55] failed: no such file or directory`,
populate testlogger ignoreList
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
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
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`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestMarkDownReadmeImage
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:checkOutdatedBranch() [E] GetBranch: branch does not exist [repo_id: 1 name: home-md-img-check]`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestMarkDownReadmeImage
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:checkOutdatedBranch() [E] GetBranch: branch does not exist [repo_id: 1 name: home-md-img-check]`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestMarkDownReadmeImageSubfolder
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:checkOutdatedBranch() [E] GetBranch: branch does not exist [repo_id: 1 name: sub-home-md-img-check]`,
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
// TestMarkDownReadmeImageSubfolder
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
`:checkOutdatedBranch() [E] GetBranch: branch does not exist [repo_id: 1 name: sub-home-md-img-check]`,
populate testlogger ignoreList
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"`,
[FEAT] Mark database errors in tests as failure - If the database returns a error in integration tests, it should be marked as a failure of the test. - Ref: https://codeberg.org/forgejo/forgejo/issues/2962 (this should help with logging the SQL that is resulting in the error).
2024-04-02 07:34:17 -04:00
// TestDatabaseCollation
`[E] [Error SQL Query] INSERT INTO test_collation_tbl (txt) VALUES ('main') []`,
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
}
func (w *testLoggerWriterCloser) recordError(msg string) {
[TESTS] do not include line numbers in the error whitelist They are bound to change. The worst that can happen is that the same error happens somewhere else and is ignored although it should not. Which is not worse than the previous situation which was to ignore all errors anyway. Also be more liberal about what is ignored. Some error messages are very long and may contain elements with some variance. It is enough to have an ignored that is specific.
2024-03-31 14:57:49 -04:00
for _, s := range ignoredErrorMessage {
if strings.Contains(msg, s) {
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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]
}
[TESTS] prevent overriding testlogger when calling mainApp
2024-03-27 17:02:51 -04:00
if len(w.t) > 0 {
// format error message to easily add it to the ignore list
populate testlogger ignoreList
2024-03-28 06:41:27 -04:00
msg = fmt.Sprintf("// %s\n\t%q,", w.t[len(w.t)-1].Name(), msg)
[TESTS] prevent overriding testlogger when calling mainApp
2024-03-27 17:02:51 -04:00
}
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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: ![image](https://user-images.githubusercontent.com/2114189/236620635-55576955-f95d-4810-b12f-879026a3afdf.png)
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.
Fix data race (#8204) * Fix data race * Fix data race in modules/log * Make the scope of lock finner-grained * Use syc.Map * Fix missing change in the test * Do not export LoggerMap
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: ![image](https://user-images.githubusercontent.com/2114189/236620635-55576955-f95d-4810-b12f-879026a3afdf.png)
2023-05-08 07:49:59 -04:00
defer w.RUnlock()
Fix "data race" in testlogger (#9159) * Fix data race in testlogger * Update git_helper_for_declarative_test.go
2019-11-25 18:21:37 -05:00
if len(w.t) > 0 {
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
t := w.t[len(w.t)-1]
t.Log(msg)
} else {
Make testlogger output "TestLogger" prefix (#24683) Make testlogger output "TestLogger" prefix instead of "Unknown Test" when there is no running test case.
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
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
fmt.Fprintln(os.Stdout, "??? [TestLogger]", msg)
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
}
}
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
func (w *testLoggerWriterCloser) popT() error {
Fix "data race" in testlogger (#9159) * Fix data race in testlogger * Update git_helper_for_declarative_test.go
2019-11-25 18:21:37 -05:00
w.Lock()
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
defer w.Unlock()
Fix "data race" in testlogger (#9159) * Fix data race in testlogger * Update git_helper_for_declarative_test.go
2019-11-25 18:21:37 -05:00
if len(w.t) > 0 {
w.t = w.t[:len(w.t)-1]
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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
Fix "data race" in testlogger (#9159) * Fix data race in testlogger * Update git_helper_for_declarative_test.go
2019-11-25 18:21:37 -05:00
}
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
return w.err
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
}
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
func (w *testLoggerWriterCloser) Reset() error {
Ensure that the testlogger has its final test removal safely (#16907) It is possible to get a data race right at the end of the TestMain in integrations during the final removal of the test from the testlogger. This PR uses a Reset function to remove any final tests but adds some extra logging which will forcibly fail if there is an unclosed logger. Signed-off-by: Andrew Thornton <art27@cantab.net>
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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())
Ensure that the testlogger has its final test removal safely (#16907) It is possible to get a data race right at the end of the TestMain in integrations during the final removal of the test from the testlogger. This PR uses a Reset function to remove any final tests but adds some extra logging which will forcibly fail if there is an unclosed logger. Signed-off-by: Andrew Thornton <art27@cantab.net>
2021-09-01 09:05:04 -04:00
}
w.t = nil
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
w.errs = nil
Ensure that the testlogger has its final test removal safely (#16907) It is possible to get a data race right at the end of the TestMain in integrations during the final removal of the test from the testlogger. This PR uses a Reset function to remove any final tests but adds some extra logging which will forcibly fail if there is an unclosed logger. Signed-off-by: Andrew Thornton <art27@cantab.net>
2021-09-01 09:05:04 -04:00
}
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
err := w.err
w.err = nil
Ensure that the testlogger has its final test removal safely (#16907) It is possible to get a data race right at the end of the TestMain in integrations during the final removal of the test from the testlogger. This PR uses a Reset function to remove any final tests but adds some extra logging which will forcibly fail if there is an unclosed logger. Signed-off-by: Andrew Thornton <art27@cantab.net>
2021-09-01 09:05:04 -04:00
w.Unlock()
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
return err
Ensure that the testlogger has its final test removal safely (#16907) It is possible to get a data race right at the end of the TestMain in integrations during the final removal of the test from the testlogger. This PR uses a Reset function to remove any final tests but adds some extra logging which will forcibly fail if there is an unclosed logger. Signed-off-by: Andrew Thornton <art27@cantab.net>
2021-09-01 09:05:04 -04:00
}
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
// PrintCurrentTest prints the current test to os.Stdout
Fix "data race" in testlogger (#9159) * Fix data race in testlogger * Update git_helper_for_declarative_test.go
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()
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-06-01 21:39:44 -04:00
start := time.Now()
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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)
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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)
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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)
Fix "data race" in testlogger (#9159) * Fix data race in testlogger * Update git_helper_for_declarative_test.go
2019-11-25 18:21:37 -05:00
return func() {
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-06-01 21:39:44 -04:00
took := time.Since(start)
Kd/ci playwright go test (#20123) * Add initial playwright config * Simplify Makefile * Simplify Makefile * Use correct config files * Update playwright settings * Fix package-lock file * Don't use test logger for e2e tests * fix frontend lint * Allow passing TEST_LOGGER variable * Init postgres database * use standard gitea env variables * Update playwright * update drone * Move empty env var to commands * Cleanup * Move integrations to subfolder * tests integrations to tests integraton * Run e2e tests with go test * Fix linting * install CI deps * Add files to ESlint * Fix drone typo * Don't log to console in CI * Use go test http server * Add build step before tests * Move shared init function to common package * fix drone * Clean up tests * Fix linting * Better mocking for page + version string * Cleanup test generation * Remove dependency on gitea binary * Fix linting * add initial support for running specific tests * Add ACCEPT_VISUAL variable * don't require git-lfs * Add initial documentation * Review feedback * Add logged in session test * Attempt fixing drone race * Cleanup and bump version * Bump deps * Review feedback * simplify installation * Fix ci * Update install docs
2022-09-02 15:18:23 -04:00
if took > SlowTest {
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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)))
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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)
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-06-01 21:39:44 -04:00
}
}
Kd/ci playwright go test (#20123) * Add initial playwright config * Simplify Makefile * Simplify Makefile * Use correct config files * Update playwright settings * Fix package-lock file * Don't use test logger for e2e tests * fix frontend lint * Allow passing TEST_LOGGER variable * Init postgres database * use standard gitea env variables * Update playwright * update drone * Move empty env var to commands * Cleanup * Move integrations to subfolder * tests integrations to tests integraton * Run e2e tests with go test * Fix linting * install CI deps * Add files to ESlint * Fix drone typo * Don't log to console in CI * Use go test http server * Add build step before tests * Move shared init function to common package * fix drone * Clean up tests * Fix linting * Better mocking for page + version string * Cleanup test generation * Remove dependency on gitea binary * Fix linting * add initial support for running specific tests * Add ACCEPT_VISUAL variable * don't require git-lfs * Add initial documentation * Review feedback * Add logged in session test * Attempt fixing drone race * Cleanup and bump version * Bump deps * Review feedback * simplify installation * Fix ci * Update install docs
2022-09-02 15:18:23 -04:00
timer := time.AfterFunc(SlowFlush, func() {
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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)
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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)
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
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: ![image](https://user-images.githubusercontent.com/2114189/236620635-55576955-f95d-4810-b12f-879026a3afdf.png)
2023-05-08 07:49:59 -04:00
if err := queue.GetManager().FlushAll(context.Background(), time.Minute); err != nil {
Queue: Make WorkerPools and Queues flushable (#10001) * Make WorkerPools and Queues flushable Adds Flush methods to Queues and the WorkerPool Further abstracts the WorkerPool Adds a final step to Flush the queues in the defer from PrintCurrentTest Fixes an issue with Settings inheritance in queues Signed-off-by: Andrew Thornton <art27@cantab.net> * Change to for loop * Add IsEmpty and begin just making the queues composed WorkerPools * subsume workerpool into the queues and create a flushable interface * Add manager command * Move flushall to queue.Manager and add to testlogger * As per @guillep2k * as per @guillep2k * Just make queues all implement flushable and clean up the wrapped queue flushes * cope with no timeout Co-authored-by: Lauris BH <lauris@nix.lv>
2020-01-28 20:01:06 -05:00
t.Errorf("Flushing queues failed with error %v", err)
}
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-06-01 21:39:44 -04:00
timer.Stop()
flushTook := time.Since(start) - took
Kd/ci playwright go test (#20123) * Add initial playwright config * Simplify Makefile * Simplify Makefile * Use correct config files * Update playwright settings * Fix package-lock file * Don't use test logger for e2e tests * fix frontend lint * Allow passing TEST_LOGGER variable * Init postgres database * use standard gitea env variables * Update playwright * update drone * Move empty env var to commands * Cleanup * Move integrations to subfolder * tests integrations to tests integraton * Run e2e tests with go test * Fix linting * install CI deps * Add files to ESlint * Fix drone typo * Don't log to console in CI * Use go test http server * Add build step before tests * Move shared init function to common package * fix drone * Clean up tests * Fix linting * Better mocking for page + version string * Cleanup test generation * Remove dependency on gitea binary * Fix linting * add initial support for running specific tests * Add ACCEPT_VISUAL variable * don't require git-lfs * Add initial documentation * Review feedback * Add logged in session test * Attempt fixing drone race * Cleanup and bump version * Bump deps * Review feedback * simplify installation * Fix ci * Update install docs
2022-09-02 15:18:23 -04:00
if flushTook > SlowFlush {
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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)))
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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)
log slow tests (#11487) * log slow tests Signed-off-by: Andrew Thornton <art27@cantab.net> * placate lint Signed-off-by: Andrew Thornton <art27@cantab.net> * More lint placation Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-06-01 21:39:44 -04:00
}
}
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
if err := WriterCloser.popT(); err != nil {
[TESTS] disable test failure on log.Error for now
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)
fail test when log.Error is called except for some specific messages (to make the test pass for now)
2024-03-14 09:45:41 -04:00
}
Fix "data race" in testlogger (#9159) * Fix data race in testlogger * Update git_helper_for_declarative_test.go
2019-11-25 18:21:37 -05:00
}
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
}
// Printf takes a format and args and prints the string to os.Stdout
Replace `interface{}` with `any` (#25686) Result of running `perl -p -i -e 's#interface\{\}#any#g' **/*` and `make fmt`. Basically the same [as golang did](https://github.com/golang/go/commit/2580d0e08d5e9f979b943758d3c49877fb2324cb).
2023-07-04 14:36:08 -04:00
func Printf(format string, args ...any) {
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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...)
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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{}
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </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
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
}
fail test when log.Error is called except for some specific messages (to make the test pass for now)
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)
}
}
}
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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: ![image](https://user-images.githubusercontent.com/2114189/236620635-55576955-f95d-4810-b12f-879026a3afdf.png)
2023-05-08 07:49:59 -04:00
const relFilePath = "modules/testlogger/testlogger.go"
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
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: ![image](https://user-images.githubusercontent.com/2114189/236620635-55576955-f95d-4810-b12f-879026a3afdf.png)
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)
Quieter Integration Tests (#6513) * Rename BaseLogger to WriterLogger to help the creation of other providers * Don't export ColorBytes and ResetBytes from ColoredValues * Make integration tests only print logs if they fail * check can color before coloring * I always forget about MSSQL * Oh and use LEVEL in sqlite.ini * Make the test logger log at info - as it means you see the router * Remove empty expected changes * Make the migrations quieter too * Don't display SQL on error - it can be looked at in the file logs if necessary * Fix skip when using onGiteaRun
2019-04-06 20:25:14 -04:00
}
Copy permalink