-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix settings not being loaded at CLI #26402
Conversation
I wonder if this is really the right place to load the settings or if we should do it earlier. Doing it in the middle of command processing does seem odd. |
Both way works as of my tests. I thought to initialize together with the DB but thinking better at the beginning may be more clean. I'll adjust it |
Signed-off-by: cassiozareck <cassiomilczareck@gmail.com>
efa170c
to
6096745
Compare
Ah I see the context now, previous place was fine then I guess, the validation does not depend on settings it looks like. Note I'm not really knowledgeable around these parts so take my comments with a grain of salt :) |
As we're loading settings there's happening some output when a user runs
|
That reinforces that it needs to be after validation. |
Hmm so its ok? I think its unavoidable unless we try to change the config for logging outputs before |
Just revert to previous location imho. |
Oh no no! It happen doesn't matter where loadsetting is. There's log statements inside loadsettings. I think its alright as it states settings are being loaded but if you dont want log to happen I can see what I can do. I know I caused some confusion because it looked like I was saying because of position. Pls dont avoid my PRs 😆 |
This fix works but it is somewhat hacky and fragile. Ideally, there should be command line options to set the flags, but not continue loading more unclear settings. There is already |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a quick fix, I think it's enough.
Made some changes in 170261a :
|
Closes go-gitea#25898 The problem was that the default settings weren't being loaded --------- Signed-off-by: cassiozareck <cassiomilczareck@gmail.com> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* giteaofficial/main: Fix issue comment number (go-gitea#30556) Fix duplicate co-author in squashed merge commit messages (go-gitea#33020) Merge updatecommentattachment functions (go-gitea#33044) Move SetMerged to service layer (go-gitea#33045) Remove aws go sdk package dependency (go-gitea#33029) Fix settings not being loaded at CLI (go-gitea#26402) Refactor fixture loading for testing (go-gitea#33024) Use gitrepo.GetTreePathLatestCommit to get file lastest commit instead from latest commit cache (go-gitea#32987) Fix bug automerge cannot be chosed when there is only 1 merge style (go-gitea#33040) use `-s -w` ldflags for release artifacts (go-gitea#33041)
Closes #25898
The problem was that the default settings weren't being loaded, so
gitea/models/user/user.go
Line 593 in ad69f71
was always false.