[Feature Request] Don't unnecessarily format app.ini #7333

New Issue

GiteaMirror · 2025-11-02T07:23:12-06:00

GiteaMirror commented

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

Originally created by @lonix1 on GitHub (May 13, 2021).

Gitea version (or commit ref): 1.14.2 (the latest version)
Operating system: linux
Docker
Database: SQLite
Can you reproduce the bug at https://try.gitea.io: n/a
Log gist: n/a

Description

Every time gitea restarts, it reformats the app.ini file.

When using a config management environment (e.g. ansible, puppet), changes are detected every time - even whitespace changes. So it "breaks" automated systems.

Feature Request

If there are no real changes, please don't reformat the config file.

Thanks!

Originally created by @lonix1 on GitHub (May 13, 2021). - Gitea version (or commit ref): 1.14.2 (the latest version) - Operating system: linux - Docker - Database: SQLite - Can you reproduce the bug at https://try.gitea.io: n/a - Log gist: n/a ## Description Every time gitea restarts, it reformats the `app.ini` file. When using a config management environment (e.g. ansible, puppet), changes are detected every time - even whitespace changes. So it "breaks" automated systems. ## Feature Request If there are no real changes, please don't reformat the config file. Thanks!

GiteaMirror added the type/enhancement label 2025-11-02 07:23:12 -06:00

GiteaMirror closed this issue

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

GiteaMirror commented

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

@lonix1 commented on GitHub (May 15, 2021):

@zeripath Thanks for considering my feature request!

Quick question, under what circumstances does gitea edit the app.ini? I thought that was a user file, but now I realize gitea can write to it too (and so we must not mount it as a :ro file in docker).

@lonix1 commented on GitHub (May 15, 2021): @zeripath Thanks for considering my feature request! Quick question, under what circumstances does gitea edit the app.ini? I thought that was a user file, but now I realize gitea can write to it too (and so we must not mount it as a `:ro` file in docker).

GiteaMirror commented

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

@zeripath commented on GitHub (May 15, 2021):

In the case of docker since the environment-to-ini merge - if you set GITEA__section__KEY environment variables these will potentially change the app.ini.

If your app.ini does not contain certain vital things - e.g. [security] INTERNAL_TOKEN then these will be generated changing the app.ini.

So why do we have the app.ini?

Whilst not every setting needs to be in the app.ini and some could be moved out of the file and to the database, Gitea has at least two very important sub processes that run in different environments, gitea serv and gitea hook - these need to be able to communicate with the running gitea web server over the /api/internal endpoint - so that has to be shared making environment variables a lot more fiddly. Environment-to-ini exists as at least a partial solution allowing full configuration by environment variables - depressingly, but common to changes affecting docker, it seems that this doesn't please the people that it was envisaged to help.

Whilst I could envision a PR that could try to avoid some of this - such a PR would be very fiddly, and likely engender a significant refactor and still only partially solve the issue. Thus I suspect that a drive-by PR would not necessarily be appropriate. Sponsorship of developers would be one route to help redirect our focus, as are bounties on bountysource - but the issue is there is that the bounties are often too small for the size of the feature that is required and they encourage dumping of features with no ongoing support or recognition for the time spent reviewing and eventually fixing these PRs.

@zeripath commented on GitHub (May 15, 2021): In the case of docker since the environment-to-ini merge - if you set `GITEA__section__KEY` environment variables these will potentially change the app.ini. If your app.ini does not contain certain vital things - e.g. `[security]` `INTERNAL_TOKEN` then these will be generated changing the app.ini. So why do we have the app.ini? Whilst not every setting needs to be in the app.ini and some could be moved out of the file and to the database, Gitea has at least two very important sub processes that run in different environments, `gitea serv` and `gitea hook` - these need to be able to communicate with the running `gitea web` server over the `/api/internal` endpoint - so that has to be shared making environment variables a lot more fiddly. Environment-to-ini exists as at least a partial solution allowing full configuration by environment variables - depressingly, but common to changes affecting docker, it seems that this doesn't please the people that it was envisaged to help. Whilst I could envision a PR that could try to avoid some of this - such a PR would be very fiddly, and likely engender a significant refactor and still only partially solve the issue. Thus I suspect that a drive-by PR would not necessarily be appropriate. Sponsorship of developers would be one route to help redirect our focus, as are bounties on bountysource - but the issue is there is that the bounties are often too small for the size of the feature that is required and they encourage dumping of features with no ongoing support or recognition for the time spent reviewing and eventually fixing these PRs.

GiteaMirror commented

2025-11-02 07:23:13 -06:00

@lonix1 commented on GitHub (May 16, 2021):

That was way more info than I expected, thanks! 😄

Environment-to-ini ... seems that this doesn't please the people that it was envisaged to help

I didn't know about this until now, thanks for the pointer - its good and I'm gonna use it!

In other apps the expectation is to "mount a config file" that is readonly, and for that to be used by the app to override its default config. So I can see why others may not like it (because as you say it becomes "fiddly" when used with docker).

For any reading this in the future, the ultimate solution is:

a config file that is readonly, can be mounted by docker as :ro (so can be managed by automated systems like ansible/puppet)
the app merges config, in order: shell args, docker environment variables, the mounted readonly config file, internal default config file

But I understand the tone of your comment - all this is pointless if the project is not properly sponsored. Like I said in my other comment I can't believe how much effort you and your teammates put into this. Respect.

@lonix1 commented on GitHub (May 16, 2021): That was way more info than I expected, thanks! :smile: > Environment-to-ini ... seems that this doesn't please the people that it was envisaged to help I didn't know about this until now, thanks for the pointer - its good and I'm gonna use it! In other apps the expectation is to "mount a config file" that is readonly, and for that to be used by the app to override its default config. So I can see why others may not like it (because as you say it becomes "fiddly" when used with docker). For any reading this in the future, the ultimate solution is: - a config file that is readonly, can be mounted by docker as `:ro` (so can be managed by automated systems like ansible/puppet) - the app merges config, in order: shell args, docker environment variables, the mounted readonly config file, internal default config file But I understand the tone of your comment - all this is pointless if the project is not properly sponsored. Like I said in my other comment I can't believe how much effort you and your teammates put into this. Respect.

GiteaMirror commented

2025-11-02 07:23:13 -06:00

@lonix1 commented on GitHub (May 16, 2021):

As a side note, to alleviate the problems you highlighted above.

It might be a good idea to have a "voting" approach on new major features, to avoid the "drive-by PR" problem where the feature won't be supported? It would avoid, for e.g., the env-to-ini problem which as you said was not well received.

Then when someone puts in serious effort, he at least knows he's not wasting his time.

Like a "community roadmap" that you sometimes find on other repos.

Might be a good way to eliminate unnecessary work and rework.

@lonix1 commented on GitHub (May 16, 2021): As a side note, to alleviate the problems you highlighted above. It might be a good idea to have a "voting" approach on new **major** features, to avoid the "drive-by PR" problem where the feature won't be supported? It would avoid, for e.g., the env-to-ini problem which as you said was not well received. Then when someone puts in serious effort, he at least knows he's not wasting his time. Like a "community roadmap" that you sometimes find on other repos. Might be a good way to eliminate unnecessary work and rework.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7333