Add system setting table with cache and also add cache supports for user setting

[lunny]

• Add a new table system_setting to store system setting. And it also has been stored into cache when enabled.
• Move some related code into system
• Also add cache supports for user settings.
• Add a UI for site admin to edit system settings, this will reuse admin configuration page.
• Move some settings from app.ini to the system setting table, so then all these setting could be updated immediately with no necessary to reboot Gitea.
  • Move DisableGravatar from ini to table system_setting as a record with key disable_gravatar
  • Move EnableFederatedAvatar from ini to table system_setting as a record with key enable_federated_avatar

[silverwind]

Seems like a good idea to have some settings UI-editable but I think gitea must stay fully configurable from ini. Do you plan on writing modified settings back into the ini?

[lunny]

Seems like a good idea to have some settings UI-editable but I think gitea must stay fully configurable from ini. Do you plan on writing modified settings back into the ini?

No. I plan to move most configurations into the database and will not write back to ini and there will be migration to copy user's old setting from ini into database.

Which configuration should be moved into database and anothers will not?
I think it depends on if it needs to be changed when installation. i.e.
Database related configuration should be kept in ini file, HTTP listen related, storage configuration and etc.

And those i.e. pagination numbers, some cron tasks enable/disable and etc. could be moved into database.

What's the benefits? Less restarts.
Currently, even if you change a pagination number you have to restart Gitea. It must be changed and the configuration is unnecessary to be kept in ini file.

[silverwind]

Migration seems like a must-have, yeah. Maybe even emit warnings logs for migrated settings in the ini so users know which ones to remove there.

Cron tasks seems like a good canidate, it always felt odd to me to having to configure those in the ini.

[mscherer]

Ini files is easier to manage using a configuration management system (eg, ansible, puppet, etc) and moving them to the database will make it harder to collaborate using git for sysadmins.

I think a CLI command to change the settings would make sense and avoid inflicting too much pain to sysadmins who wish to use config management, and also maybe one to prevent UI editing (if possible) to prevent errors and manual change.

[lunny]

Ini files is easier to manage using a configuration management system (eg, ansible, puppet, etc) and moving them to the database will make it harder to collaborate using git for sysadmins.

I think a CLI command to change the settings would make sense and avoid inflicting too much pain to sysadmins who wish to use config management, and also maybe one to prevent UI editing (if possible) to prevent errors and manual change.

This will move some of them which Gitea should not be restarted when changing.

[yardenshoham]

I think this breaks gitpod

Screenshot:

Log:

        /home/gitpod/go/src/runtime/panic.go:260 (0x459475)
                panicmem: panic(memoryError)
        /home/gitpod/go/src/runtime/signal_unix.go:835 (0x459445)
                sigpanic: panicmem()
        /workspace/gitea/models/db/context.go:78 (0xb9ca65)
                GetEngine: enginedInterface := ctx.Value(enginedContextKey)
        /workspace/gitea/models/system/setting.go:96 (0xcaa93e)
                GetSettings: if err := db.GetEngine(db.DefaultContext).
        /workspace/gitea/models/system/setting.go:80 (0xcaa765)
                GetSetting: v, err := GetSettings([]string{key})
        /workspace/gitea/routers/install/install.go:152 (0x206feba)
                Install: disableGravatarSetting, _ := system_model.GetSetting(system_model.KeyPictureDisableGravatar)
        /workspace/gitea/modules/web/wrap_convert.go:47 (0x1db4f13)
                convertHandler.func3: t(ctx)
        /workspace/gitea/modules/web/wrap.go:41 (0x1db33e4)
                wrapInternal.func1: done, deferrable := handler(resp, req, others...)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:442 (0x19b1dd5)
                (*Mux).routeHTTP: h.ServeHTTP(w, r)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/gitea/routers/install/install.go:89 (0x206f9ea)
                Init.func1.1: next.ServeHTTP(resp, ctx.Req)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/gitea/routers/install/routes.go:80 (0x2075071)
                installRecovery.func1.1: next.ServeHTTP(w, req)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/go/pkg/mod/gitea.com/go-chi/session@v0.0.0-20211218221615-e3605d8b28b8/session.go:257 (0x11a77aa)
                Sessioner.func1.1: next.ServeHTTP(w, req)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/gitea/modules/web/wrap.go:110 (0x1db41e8)
                WrapWithPrefix.func1.1: next.ServeHTTP(resp, req)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/gitea/routers/common/middleware.go:79 (0x1e7a4e2)
                Middlewares.func2.1: next.ServeHTTP(resp, req)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/gitea/modules/web/routing/logger_manager.go:123 (0x1daf0f3)
                (*requestRecordsManager).handler.func1: next.ServeHTTP(w, req)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/middleware/strip.go:30 (0x1e77d78)
                StripSlashes.func1: next.ServeHTTP(w, r)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/go/pkg/mod/github.com/chi-middleware/proxy@v1.1.1/middleware.go:37 (0x1e74516)
                ForwardedHeaders.func1.1: h.ServeHTTP(w, r)
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/gitea/routers/common/middleware.go:32 (0x1e7a331)
                Middlewares.func1.1: next.ServeHTTP(context.NewResponse(resp), req.WithContext(ctx))
        /home/gitpod/go/src/net/http/server.go:2109 (0x94f18e)
                HandlerFunc.ServeHTTP: f(w, r)
        /workspace/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:88 (0x19afb4f)
                (*Mux).ServeHTTP: mx.handler.ServeHTTP(w, r)
        /workspace/gitea/modules/web/route.go:200 (0x1db280d)
                (*Route).ServeHTTP: r.R.ServeHTTP(w, req)
        /home/gitpod/go/src/net/http/server.go:2947 (0x95258b)
                serverHandler.ServeHTTP: handler.ServeHTTP(rw, req)
        /home/gitpod/go/src/net/http/server.go:1991 (0x94dc66)
                (*conn).serve: serverHandler{c.server}.ServeHTTP(w, w.req)
        /home/gitpod/go/src/runtime/asm_amd64.s:1594 (0x477140)
                goexit: BYTE    $0x90   // NOP

cc @anbraten

[wxiaoguang]

One more thing, on try.gitea.io, it is using local avatars now, maybe before this PR it used gravatar avatars.

If it is the side effect of this PR, there will be a lot of people complaining about this changed behavior.

[techknowlogick]

@wxiaoguang I had updated try.gitea.io to use local avatars to test the switch, can switch it back.

[SuperSandro2000]

Move some settings from app.ini to the system setting table, so then all these setting could be updated immediately with no necessary to reboot Gitea.

Is this really necessary? With that it is no longer possible to easily manage the settings decoratively decoratively.

[lunny]

Move some settings from app.ini to the system setting table, so then all these setting could be updated immediately with no necessary to reboot Gitea.

Is this really necessary? With that it is no longer possible to easily manage the settings decoratively.

We can provide a command to help set/get them later. Some users don't want to restart Gitea even if he just change a pagination number.

[SuperSandro2000]

We can provide a command to help set/get them later. Some users don't want to restart Gitea even if he just change a pagination number.

For NixOS it would probably be the easiest if the value just appeared again in the config file. No need to develop something new.

[kdumontnu]

Should this be labeled as a breaking change? I know it's a little late, but aren't we essentially deprecating breaking support for some ini settings?

I suggest we think through and document how config settings that are being migrated from ini to the database will be supported in the future and what the interaction between database and ini is (for example, does ini override db setting or vice-versa?). I'm a little confused how server settings should be set and maintained now, as there are now two places to configure server settings (three if you include some support for env variable overrides).

[rmbleeker]

I haven't seen a satisfying answer yet to a point that's been brought up a few times already, which is: how would a sysadmin (like myself) set the options that now reside in the database during an automated installation of Gitea? I personally use Ansible for my automation needs, I have a Jinja2 template of the ini file and all the options for Gitea in yaml. This is very easy to maintain and makes for a quick installation/update, while calling gitea from the command line to change options in a database would not be. Having to use the GUI post-installation to properly configure your software completely defeats the purpose of automation.