Accept multiple config files

[clarfonthey]

Use case, I'd like to be able to create a base app.ini file that I can mindlessly copy to servers while still having instance-specific configuration options like database passwords stored in a separate app.ini file.

Alternatively, we could allow some form of [include] section which will load options from a separate app.ini file.

Ideally, we'd have both. But accepting on the CLI is a good start.

[clarfonthey]

I'd like to maybe get to work on this, although I'd definitely appreciate some guidance if anyone is willing to point me in the right direction.

[techknowlogick]

@clarcharr the ini library used is go-ini (docs: https://ini.unknwon.io/docs/intro/getting_started) and it allows multiple ini files to be loaded and appended (ex. err := cfg.Append("other file", []byte("other raw data"))).

Perhaps you could have the config flag for each cli cmd be overloaded to be called multiple times and then take each option and append them to one another (so you'd have gitea web -c base.ini -c specific_options.ini)

[aanderse]

@clarfon Did you end up working on this? Do you still have motivation? This would really help us simplify our packaging over at NixOS as right now we're forced to use less than ideal code to get secrets to work with our immutable configuration files.

[clarfonthey]

@aanderse I did not actually get to coding this, so I'm open to others working on it. Right now I don't really have the time for it.

[aanderse]

@clarfon Understandable. I thought I'd ping you just in case though 😄 Thanks for clarifying.

[techknowlogick]

Some information that may be useful for this issue: Something that the project is looking into is switching to use https://github.com/spf13/viper/ to handle configuration, this will allow us to move to another format as ini has some downsides (Note: INI support has a pending PR in viper).

@aanderse some information re: secrets from a different area, right now internal secret supports inclusion of information from a different place, and could be extended to JWT secrets as well.

[aanderse]

@aanderse some information re: secrets from a different area, right now internal secret supports inclusion of information from a different place, and could be extended to JWT secrets as well.

@techknowlogick is there documentation or an example on this? Thanks for the info.

[techknowlogick]

@aanderse Turns out there isn't documentation on this, which is embarrassing since I was the one who created that PR. I'll sum it up here, but I'll also put a PR through to add this documentation.

Under the security section instead of defining INTERNAL_TOKEN in the file INTERNAL_TOKEN_URI can fetch the content of a file to be used (so it isn't stored directly in configuration).

[security]
INTERNAL_TOKEN_URI=file:/etc/gitea/internal_uri.txt

Another PR could be added to extend this to support SECRET_KEY, LFS_JWT_SECRET and JWT_SECRET

[aanderse]

@techknowlogick fantastic! I only wish I knew go so I could write such a PR 😄

[aanderse]

For reference this functionality was added in #5812.

[jpds]

Instead of configuration files, can't gitea be made to use environment variables instead (like a 12-factor application) ?

[clarfonthey]

@jpds environment variables are not nearly as versatile as config files. They are a potential option, but I feel that having some form of include functionality, or the ability to load multiple config files, would be a bit better than just allowing a single config file plus extra environment variables.

[preisi]

Is anyone still working on this? This feature would be handy in conjunction with config management.