3 Commits (864bdd0ac8a597eaed5c59b31979a160b776ee2b)

Author	SHA1	Message	Date
wxiaoguang	b4460cf541	Make "install page" respect environment config (#25648) (#25799) ... Backport #25648 Replace #25580 Fix #19453 The problem was: when users set "GITEA__XXX__YYY" , the "install page" doesn't respect it. So, to make the result consistent and avoid surprising end users, now the "install page" also writes the environment variables to the config file. And, to make things clear, there are enough messages on the UI to tell users what will happen. There are some necessary/related changes to `environment-to-ini.go`: * The "--clear" flag is removed and it was incorrectly written there. The "clear" operation should be done if INSTALL_LOCK=true * The "--prefix" flag is removed because it's never used, never documented and it only causes inconsistent behavior. The only conflict during backport is "ui divider" in templates/install.tmpl	2 years ago
Giteabot	71d2a6a41a	Use InitWorkPathAndCfgProvider for environment-to-ini to avoid unnecessary checks (#25480) (#25488) ... Backport #25480 by @wxiaoguang Fix #25481 The `InitWorkPathAndCommonConfig` calls `LoadCommonSettings` which does many checks like "current user is root or not". Some commands like "environment-to-ini" shouldn't do such check, because it might be run with "root" user at the moment (eg: the docker's setup script) ps: in the future, the docker's setup script should be improved to avoid Gitea's command running with "root" Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>	2 years ago
wxiaoguang	061b68e995	Refactor path & config system (#25330) (#25416) ... Backport #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.	2 years ago