-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
gitea command prints incorrect path to config file #21606
Labels
Comments
wxiaoguang
added
type/question
Issue needs no code to be fixed, only a description on how to fix it yourself.
issue/needs-feedback
For bugs, we need more details. For features, the feature must be described in more detail
type/bug
and removed
type/bug
type/question
Issue needs no code to be fixed, only a description on how to fix it yourself.
issue/needs-feedback
For bugs, we need more details. For features, the feature must be described in more detail
labels
Oct 26, 2022
Hmm ... it seems to be a bug. The
It's nearly unfixable (no clear solution), due to how the "urfave/cli" works and how Gitea uses it (improperly). |
Closed
wxiaoguang
added a commit
to wxiaoguang/gitea
that referenced
this issue
Jun 21, 2023
# 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. ---- Close go-gitea#24818 Close go-gitea#24222 Close go-gitea#21606 Close go-gitea#21498 Close go-gitea#25107 Close go-gitea#24981 Maybe close go-gitea#24503 Replace go-gitea#23301 Replace go-gitea#22754 And maybe more # Conflicts: # cmd/web.go
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
According to the documentation, the path of the currently used configuration file can be queried by running the following command:
As I have observed, the configuration file on my instance is located in
/etc/gitea/app.ini
.However,
gitea --help
shows a different path:The
/admin/config
also shows the former as the config file:The file indicated by
gitea --help
exists too, but possibly only because of an earlier misunderstanding of mine. About a year or 2 ago I had a hard time understanding where should I create the config file.However, modifying this file does not seem to have an effect.
Gitea Version
v1.17.3
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
Raspbian
How are you running Gitea?
In a self-built docker image built from the official Docker.rootless Dockerfile.
No source files or assets are modified, everything should be original.
Database
MySQL
The text was updated successfully, but these errors were encountered: