Add contrib/ini-to-shell

[justusbunsi]

Description of the change

This adds a new binary for extracting settings from an existing app.ini.

Benefits

Instead of grep-ing the file via shell scripts, this binary uses the Gitea internals for reading the app.ini.

Possible drawbacks

None

Applicable issues

Helps addressing https://gitea.com/gitea/helm-chart/issues/356.

---

Signed-off-by: justusbunsi [email protected]

[justusbunsi]

Test error seems unrelated

[wxiaoguang]

I do not think it should use log module, it should just print to stdout as-is

[wxiaoguang]

Necessary?

I think we only need to pass the "config file" to the program, without InitWorkPathAndCfgProvider, and just NewConfigProviderFromFile

[wxiaoguang]

https://gitea.com/gitea/helm-chart/issues/356
#32669 will help us extract all values that must be persistent.

I do not quite understand the usage. Could you provide more details about how to "extract all values that must be persistent" and "restore default"?

The ini config system is quite tricky, if something wrong, it wouldn't be easy to fix.

[KN4CK3R]

The problem is that some settings are passend by env to Gitea and these settings then are written to the ini file. If you remove the setting from the env the user expects to get the default value again. But that's not the case because the old value was written to the ini. To get rid of it they would like to create a new ini on startup but recreating the ini looses values like SECRET_KEY. This app will extract these values from the ini.

[wxiaoguang]

The problem is that some settings are passend by env to Gitea and these settings then are written to the ini file. If you remove the setting from the env the user expects to get the default value again. But that's not the case because the old value was written to the ini. To get rid of it they would like to create a new ini on startup but recreating the ini looses values like SECRET_KEY. This app will extract these values from the ini.

Then the current environment-to-ini should be the right program to improve.

It already supports using an existing ini to create a new ini, now, we only need to make it support "only use specialized keys from existing ini":

cp app.ini app-old.ini
environment-to-ini --config app-old.ini --out app.ini --keep "[security].SECRET_KEY" --keep ....

[justusbunsi]

@KN4CK3R Thank you for the summary. 👍

@wxiaoguang Extending the environment-to-ini seems like a better approach. I wasn't aware that it can copy/migrate. I'll try implementing it.
Would I have to pass --keep "[].RUN_MODE" to keep the global RUN_MODE (hypothetically)?

[wxiaoguang]

Would I have to pass --keep "[].RUN_MODE" to keep the global RUN_MODE (hypothetically)?

There is no --keep support at the moment, I mean we could implement it.

IIRC global keys are written as RUN_MODE in the ini system.

[wxiaoguang]

Maybe there could be another approach (I am not sure which one is better)

If we'd like to "revert a key to default", maybe we could pass a special env value to it, eg: GITEA____RUN_MODE=__RESET_DEFAULT__, then environment-to-ini could delete such keys from the ini.

---

Actually for most cases, empty string should be enough, empty string in ini means default: GITEA____RUN_MODE=

[justusbunsi]

There is no --keep support at the moment, I mean we could implement it.

Yep, I'll try to implement this flag. My question regarding RUN_MODE was to discuss how such global keys could be passed to the new flag.

If we'd like to "revert a key to default", maybe we could pass a special env value to it.

That's not really possible. You cannot know dropped settings because there is no env variable anymore. The --keep approach seems suitable. There are just few settings that are unchangeable for an existing instance. Trying to reset all the others would be huge overhead.