Pre-installation support

[lunny]

This feature is very useful for rapidly creating an OEM Gitea instance. All the pre-installation will only need give a specific ini file. This file is not the same as the config.ini.

• set a default database
• set run user
• set a default admin user and password
• add users or organizations
• add auth source
• migrate some git repos. For example, migrate all the repos of mine in github.

[stevenroose]

Why would it not be the same as config.ini? All the things you mention seem to be configuration variables..

[lunny]

The first three could, but the last three cannot

[stevenroose]

Hmm. "add auth source" could, see #183. The other two indeed should not. But that are post-installation steps, imo.

[bkcsoft]

IMO just create a gitea admin load <FILE>-command.

config.yml (Yes, I like yaml. And very much hand-written, non-linted, pseudo-yaml)

install:
  database:
    type: sqlite
    path: data/gitea.db
    secret: FOOBAR42
  run_user: git
  admin_user:
  - name: admin
    password: foobaz
users:
- name: bkc
  password: foobar42
  admin: false
- name: lunny
  password: badf00d1337
  admin: true
organizations:
- name: octokit
migrate:
- source: https://github.com/octokit/hello-world.git
  namespace: octokit
  name: hello-world
  mirror: false

[lunny]

lack of auth sources.

[stevenroose]

Run user, admin user, database and auth sources are not install vars but global config vars that should be kept in a config file that is loaded on every run, not black-box inserted on install.

There is no need for pre-installation stuff, I setup a whole lot self-hosted applications and none have them. What they have is a config file that contains all you need.

Post-installation actions might make sense, though. F.e. adding users and organisations. However shouldn't the API allow for this when you provide an admin user in app.ini?

[lunny]

@stevenroose, I don't think so. Installation and Configuration are not the same things. Installation should have something you can not easily change. i.e. database, run user, data root dir. If you changed these, you have to restart your system. Adding users/organizations, adding auth source, config sendmail and etc. are configurations and could be changed when system is running.

[tboerger]

I would prefer a single file as well. And if authentication sources are defined via config I would even disable editing via ui

[stevenroose]

@lunny Almost all of them you could in theory change at runtime except maybe run user. But almost all of them you probably don't want to do that at runtime. Things like database, datadirs, auth source, sendmail are core configurations and will almost never change once your system is deployed. They shouldn't too.

[bkcsoft]

@stevenroose Gitea currently makes no effort at separating global/install var so currently it's sort-of a moot argument. Being able to bootstrap an instance is really helpful :)

[stevenroose]

@bkcsoft Yeah but there currently is a global config file and no install config file, so instead of making the latter, I think it makes more sense to just put it into the already existing config file :)

Makes installation much more intuitive for new users too, just fill in the app.ini file and run and you're done.