Refactor path system

[wxiaoguang]

Feature Description

Gitea's path system was not well designed, it just got patched and patched and accumulated a lot of problems:

• GITEA_WORK_DIR not being used for GITEA_CUSTOM when looking up locales #21498
• Gitea's path system quirk and bug #24222
• Use shadowing script for docker #17846
• gitea command prints incorrect path to config file #21606
• Inconsistent value for [repository].ROOT causes errors on git push #25107

The root problem is, Gitea tries to guess these paths, and the environment/command argument/config option affect each other.

This a a refactoring plan for improving this system and resolving the problem with minimal breaking.

1. Deprecate the environment GITEA_XXX_DIR and command argument "--custom-dir / --work-dir"
2. When "gitea web" runs, try to detect whether there is an absolute "WORK_DIR" in app.ini
   • If no, use "guessed" absolute WorkDir to update the config
3. Other commands always use the "WORK_DIR" in app.ini

There could be more details, I think this plan is feasible and stable.

Screenshots

No response

[silverwind]

Generally agree. If there is no WORK_DIR in config, default it to current working directory. I would not write back into config at all. Writing into config should be avoided wherever possible.

[wxiaoguang]

default it to current working directory.

It doesn't work. The "writing back" is necessary.

eg: some people do this:

• put gitea in /usr/loca/bin
• the "working dir" is /data/gitea
• use GITEA_WORK_DIR to run gitea web
• when run other commands, other commands only have --config option.

[eeyrjmr]

thing is, an application shouldn't write to /etc so if gitea needs to store such persistent changes it really should go into $HOME/.config/gitea.ini (or /var/lib/gitea/*) but this just adds more confusion as to where a setting is actually being set, as well as a full backup and restore

[silverwind]

• GITEA_WORK_DIR

This variable is mislabeled. A working directory in the classic sense is the directory where the application runs in. Not necessarily the directory where the data resides. A better name would be GITEA_DATA_DIR where subdirectories like repos exist, but I guess we can only change so much while staying compatible.

[wxiaoguang]

thing is, an application shouldn't write to /etc so if gitea needs to store such persistent changes it really should go into $HOME/.config/gitea.ini (or /var/lib/gitea/*) but this just adds more confusion as to where a setting is actually being set, as well as a full backup and restore

If the app.ini is read-only, Gitea will prompt users to manually set the WORK_DIR correctly in their config file.

[wxiaoguang]

• GITEA_WORK_DIR

This variable is mislabeled. A working directory in the classic sense is the directory where the application runs in. Not necessarily the directory where the data resides. A better name would be GITEA_DATA_DIR where subdirectories like repos exist, but I guess we can only change so much while staying compatible.

There was already a DataDir in code.

In history, the code only got patched and patched (as an open-source project, I can understand), no design, refactoring or improvement, so the situation becomes today's problems.

[eeyrjmr]

thing is, an application shouldn't write to /etc so if gitea needs to store such persistent changes it really should go into $HOME/.config/gitea.ini (or /var/lib/gitea/*) but this just adds more confusion as to where a setting is actually being set, as well as a full backup and restore

If the app.ini is read-only, Gitea will prompt users to manually set the WORK_DIR correctly in their config file.

I appreciate that but for a correctly configured system /etc shouldn't be writable by non-root and if it was writeable by non-root implies a system that has some serious issue if it is compromised.
with gitea not being launchable as root, it is extremely safe to assume that /etc would not be writable.

So if it can be assumed that /etc isn't writable by root and gitea would not run as root, where would such settings be storable by gitea?

1. database
2. $WORK_DIR
3. $XDG_CONFIG_HOME

[wxiaoguang]

where would such settings be storable by gitea?

Sorry I don't get the point. The whole picture in my mind is:

For a fresh installation:

1. No config/data on disk
2. Run gitea web
3. Visit the "install" page, set "work dir"
4. Gitea save the config into "work dir/custom/app.ini"
5. Then gitea could run with "--config work-dir/custom/app.ini"

For an existing installation (upgrading):

1. Stop old gitea
2. Run gitea web
3. Gitea tries to write the GITEA_WORK_DIR into "app.ini"
   • If the "app.ini" is read-only, let site admin manually set this value
4. Then gitea could run with "--config app.ini"

(there could be some slightly different cases, IMO all of them could be covered)

---

Does this answer your question? Or could you help to show some bad cases?

[eeyrjmr]

my bad, I interpreted aspects of this as advocating writing to /etc/gitea/app.ini

[lunny]

Maybe we should introduce another file to store the write-back information including tokens.

[silverwind]

It's not completely unheard of that applications write back into config, Redis does it too. But I agree, a second file would be good where we could write stuff to, e.g. app.override.ini or something.