Proposal for configurations

[lunny]

I think we should make a rule for commands reading/writing configurations so that it's more clear for our next developments.

Currently, we can use GITEA_CUSTOM env or -c flag or the default location to detect the configuration file or create it automatically.

I think we can disable auto-creation for other command include gitea web. And introduce a new command gitea config to create a default configuration file or other things.

For other commands, when reading configuration file, if the configuration is not exist, just return error but not create it automatically. And I expect the reading location sequence is:

1. get from flag -c
2. from ENV $GITEA_CUSTOM/conf/app.ini
3. /etc/gitea/app.ini if it's UNIX like system
4. current work directory custom/conf/app.ini

[wxiaoguang]

My thoughts:

1. Stop creating app.ini automatically in most cases (this bug has been fixed in 1.16)
2. If multiple app.ini candidates exist, exit with a detailed error message, force users to remove wrong files, or choose a correct file. For most users, this won't be a problem since they only have one correct config file. For unlucky users have messed up the config files, it's still good for them to clean up.
3. Warn users and provide enough help messages if users try to re-install Gitea on a installed database. (done in 1.16)
4. Improve documents, tell users how important app.ini is and how to migrate Gitea correctly.
5. Store the hash of SECRET_KEY into database, if the config is missing (or mismatched), warn users as early as possible.
6. Use doctor to clean legacy encrypted data if the SECRET_KEY is really lost, or make code compatible with non-decryptable legacy data.

With these steps, I think there will be no more problems in recent future, then we can have enough time to design some more breaking systems.

Step 2 won't introduce new problems. If one day we use other methods instead of WorkPath, it's still fine. If a user only have one config file, step 2 has no effect. If a user has multiple config files, there must be something wrong, or the user must be a very experienced user that we do not need to worry about. (because we do not want to break too many things, so step 2 comes.)

[lunny]

Closed as something changed and this is outdated.