Accept multiple config files #2291

New Issue

GiteaMirror · 2025-11-02T04:31:25-06:00

GiteaMirror commented

2025-11-02 04:31:25 -06:00

Originally created by @clarfonthey on GitHub (Sep 3, 2018).

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.

Originally created by @clarfonthey on GitHub (Sep 3, 2018). 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.

GiteaMirror added the type/proposal label 2025-11-02 04:31:25 -06:00

GiteaMirror commented

2025-11-02 04:31:26 -06:00

@clarfonthey commented on GitHub (Jan 22, 2019):

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.

@clarfonthey commented on GitHub (Jan 22, 2019): 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.

GiteaMirror commented

2025-11-02 04:31:26 -06:00

@techknowlogick commented on GitHub (Jan 22, 2019):

@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)

@techknowlogick commented on GitHub (Jan 22, 2019): @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`)

GiteaMirror commented

2025-11-02 04:31:26 -06:00

@aanderse commented on GitHub (Jun 17, 2019):

@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.

@aanderse commented on GitHub (Jun 17, 2019): @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](https://github.com/NixOS/nixpkgs/pull/63101) code to get secrets to work with our immutable configuration files.

GiteaMirror commented

2025-11-02 04:31:26 -06:00

@clarfonthey commented on GitHub (Jun 18, 2019):

@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.

@clarfonthey commented on GitHub (Jun 18, 2019): @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.

GiteaMirror commented

2025-11-02 04:31:27 -06:00

@aanderse commented on GitHub (Jun 18, 2019):

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

@aanderse commented on GitHub (Jun 18, 2019): @clarfon Understandable. I thought I'd ping you just in case though :smile: Thanks for clarifying.

GiteaMirror commented

2025-11-02 04:31:27 -06:00

@techknowlogick commented on GitHub (Jun 18, 2019):

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.

@techknowlogick commented on GitHub (Jun 18, 2019): 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.

GiteaMirror commented

2025-11-02 04:31:27 -06:00

@aanderse commented on GitHub (Jun 18, 2019):

@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.

@aanderse commented on GitHub (Jun 18, 2019): > @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.

GiteaMirror commented

2025-11-02 04:31:28 -06:00

@techknowlogick commented on GitHub (Jun 18, 2019):

@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

@techknowlogick commented on GitHub (Jun 18, 2019): @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`

GiteaMirror commented

2025-11-02 04:31:28 -06:00

@aanderse commented on GitHub (Jun 18, 2019):

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

@aanderse commented on GitHub (Jun 18, 2019): @techknowlogick fantastic! I only wish I knew `go` so I could write such a PR :smile:

GiteaMirror commented

2025-11-02 04:31:28 -06:00

@aanderse commented on GitHub (Jun 27, 2019):

For reference this functionality was added in https://github.com/go-gitea/gitea/pull/5812.

@aanderse commented on GitHub (Jun 27, 2019): For reference this functionality was added in https://github.com/go-gitea/gitea/pull/5812.

GiteaMirror commented

2025-11-02 04:31:29 -06:00

@jpds commented on GitHub (Aug 13, 2019):

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

@jpds commented on GitHub (Aug 13, 2019): Instead of configuration files, can't gitea be made to use environment variables instead (like a 12-factor application) ?

GiteaMirror commented

2025-11-02 04:31:29 -06:00

@clarfonthey commented on GitHub (Aug 13, 2019):

@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.

@clarfonthey commented on GitHub (Aug 13, 2019): @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.

GiteaMirror commented

2025-11-02 04:31:29 -06:00

@preisi commented on GitHub (Feb 2, 2021):

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

@preisi commented on GitHub (Feb 2, 2021): Is anyone still working on this? This feature would be handy in conjunction with config management.

GiteaMirror referenced this issue

2025-11-02 12:07:51 -06:00

[PR #2291] [MERGED] back port from #1709 #16326

Sign in to join this conversation.