Skip to content
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

[Proposal] Gitea subcommand for installation #24220

Open
lunny opened this issue Apr 20, 2023 · 2 comments
Open

[Proposal] Gitea subcommand for installation #24220

lunny opened this issue Apr 20, 2023 · 2 comments
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@lunny
Copy link
Member

lunny commented Apr 20, 2023

Feature Description

As Gitea's configuration becomes more and more and once some configuration changes, gitea needs to be restarted. So we introduced database-based global configuration in #18058 . But once most of system configurations have been moved to database-based global configuration. For those who want to quickly set up a predefined Gitea instance, it becomes very difficult. Then I suppose we could have a subcommand which could be named install or init. i.e.

./gitea install --config gitea.yml

The subcommand will become an alternative choice of the current Web-based installation guide. It accepts a YAML configuration file. The file could contain all possible app.ini configurations, database-based global configurations and even authentication sources (LDAP, OAuth2), and some default users, orgs and etc.

Screenshots

No response

@lunny lunny added type/proposal The new feature has not been accepted yet but needs to be discussed first. type/feature Completely new functionality. Can only be merged if feature freeze is not active. labels Apr 20, 2023
@wxiaoguang
Copy link
Contributor

wxiaoguang commented Apr 20, 2023

I would suggest to improve the db-config (#18058) to a complete solution first, instead of leaving it as a semi-finished approach.

There are some design problems of #18058 :

  1. Most uses of it require cache/context, not general enough
  2. It causes unsolvable cycle-import if it would be used in some (low-level) packages
  3. There is no UI support to migrate more options
  4. The performance is not good enough even if there is a cache
  5. Difficult to use, the code for each option is always complex

There are too many technical debts in Gitea's code base, the similar things happen again and again: an idea -> try -> incomplete solution gets merged -> difficult to use / have problems -> nobody cares -> unmaintainable legacy code.

@a1012112796
Copy link
Member

I think a command like git config is also usefull.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

3 participants