env-to-ini: account for helm section notation? #11569

Closed
opened 2025-11-02 09:41:19 -06:00 by GiteaMirror · 7 comments
Owner

Originally created by @pat-s on GitHub (Aug 31, 2023).

Description

We've had some issues with config parsing in the helm chart lately (https://gitea.com/gitea/helm-chart/issues/488#issuecomment-747888, https://github.com/go-gitea/gitea/issues/26821#issuecomment-1699020365) due to Gitea using more and more of the [X.Y] notation for config headers in app.ini.

In helm YAML the . usually means a section divider, i.e. writing

X:
  Y:

Yet this won't result in the desired [X.Y] in app.ini but will be translated into

X: map[Y:<value>]

One way is to instruct users to quote the value as this will prevent parsing the . as a section divider:

"X.Y"

I wonder if env-to-ini could help here, i.e. to account for such notation and write all sections of a value into the header in app.ini and only use the last child as the value? Gitea does not have nested sections so this should work in theory.

To make it more clear, as a helm user I would want to write the cron config setting as follows

cron:
  update_checker:
    enabled: false
  archive_cleanup:
    enabled: false

and hope it gets translated into

[cron.update_checker]
ENABLED=false
[cron.archive_cleanup]
ENABLED=false

Otherwise we will get reports like the referenced ones forever as this mistake is quite easy to make - and quoted section values in helm are rarely used.

@wxiaoguang What do you think? (Disclaimer: I assumed that env-to-ini is responsible for all config parsing, apologies if it has no relation to this specific issue.)

Gitea Version

1.20.3

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

helm

Database

None

Originally created by @pat-s on GitHub (Aug 31, 2023). ### Description We've had some issues with config parsing in the helm chart lately (https://gitea.com/gitea/helm-chart/issues/488#issuecomment-747888, https://github.com/go-gitea/gitea/issues/26821#issuecomment-1699020365) due to Gitea using more and more of the `[X.Y]` notation for config headers in `app.ini`. In helm YAML the `.` usually means a section divider, i.e. writing ```yml X: Y: ``` Yet this won't result in the desired `[X.Y]` in `app.ini` but will be translated into ``` X: map[Y:<value>] ``` One way is to instruct users to quote the value as this will prevent parsing the `.` as a section divider: ```yml "X.Y" ``` I wonder if `env-to-ini` could help here, i.e. to account for such notation and write all sections of a value into the header in `app.ini` and only use the last child as the value? Gitea does not have nested sections so this should work in theory. To make it more clear, as a helm user I would want to write the `cron` config setting as follows ```yml cron: update_checker: enabled: false archive_cleanup: enabled: false ``` and hope it gets translated into ``` [cron.update_checker] ENABLED=false [cron.archive_cleanup] ENABLED=false ``` Otherwise we will get reports like the referenced ones forever as this mistake is quite easy to make - and quoted section values in helm are rarely used. @wxiaoguang What do you think? (Disclaimer: I assumed that `env-to-ini` is responsible for all config parsing, apologies if it has no relation to this specific issue.) ### Gitea Version 1.20.3 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? helm ### Database None
GiteaMirror added the issue/needs-feedback label 2025-11-02 09:41:19 -06:00
Author
Owner

@wxiaoguang commented on GitHub (Aug 31, 2023):

I do not see a clear solution for both YAML and INI at the same time

And there is a new case:

[git.config]
diff.algorithm = histogram

IMO maybe the only solution is "do not do any trick", just "do 1-vs-1 mapping":

git.config:
    diff.algorithm: histogram
@wxiaoguang commented on GitHub (Aug 31, 2023): I do not see a clear solution for both YAML and INI at the same time And there is a new case: ``` [git.config] diff.algorithm = histogram ``` IMO maybe the only solution is "do not do any trick", just "do 1-vs-1 mapping": ``` git.config: diff.algorithm: histogram ```
Author
Owner

@wxiaoguang commented on GitHub (Sep 8, 2023):

What do you think about it?

@wxiaoguang commented on GitHub (Sep 8, 2023): What do you think about it?
Author
Owner

@pat-s commented on GitHub (Sep 8, 2023):

Thanks for bumping!

IMO maybe the only solution is "do not do any trick", just "do 1-vs-1 mapping":

That's a solution to get it working yes (which works since the start) but not a "nice one" for helm users in general.
In the end the config notation chosen by Gitea conflicts with how one would usually define nested sections in helm, i.e. the "dot" is usually a section divider. And in the end env-to-ini does the translation so it might be worth it to find a "proper" solution longterm? What do you think?

I am wondering if it would be possible to unnest/translate

cron:
  update_checker:
    enabled: false

into

[cron.update_checker]
enabled=false

somehow within env-to-ini? In the end app.ini does not have nested sections, i.e. always just a section header and the key/value pairs below such. So it shouldn't be too complicated, what do you think?

An approach could be

  1. Flatten the YAML, e.g. via https://stackoverflow.com/questions/73703896/how-to-flatten-the-yaml-structure-list-map
  2. Split on the last dot
  3. Use the former part for the section name and the latter for the key=value mapping?
  4. (optionally account for quotes, but with 1-3 and splitting on the last dot this shouldn't matter)
@pat-s commented on GitHub (Sep 8, 2023): Thanks for bumping! > IMO maybe the only solution is "do not do any trick", just "do 1-vs-1 mapping": That's a solution to get it working yes (which works since the start) but not a "nice one" for helm users in general. In the end the config notation chosen by Gitea conflicts with how one would usually define nested sections in helm, i.e. the "dot" is usually a section divider. And in the end `env-to-ini` does the translation so it might be worth it to find a "proper" solution longterm? What do you think? I am wondering if it would be possible to unnest/translate ``` cron: update_checker: enabled: false ``` into ``` [cron.update_checker] enabled=false ``` somehow within `env-to-ini`? In the end `app.ini` does not have nested sections, i.e. always just a section header and the key/value pairs below such. So it shouldn't be too complicated, what do you think? An approach could be 1. Flatten the YAML, e.g. via https://stackoverflow.com/questions/73703896/how-to-flatten-the-yaml-structure-list-map 2. Split on the last dot 3. Use the former part for the section name and the latter for the key=value mapping? 4. (optionally account for quotes, but with 1-3 and splitting on the last dot this shouldn't matter)
Author
Owner

@wxiaoguang commented on GitHub (Sep 8, 2023):

I am wondering if it would be possible to unnest/translate

I do not see it possible. See the case above. The dot could appear anywhere.

@wxiaoguang commented on GitHub (Sep 8, 2023): > I am wondering if it would be possible to unnest/translate I do not see it possible. See the case above. The dot could appear anywhere.
Author
Owner

@pat-s commented on GitHub (Sep 8, 2023):

Ahh forget about that one.

One option would be that Gitea only uses _ instead of dots in key=value mappings or at least supports both notations for these conflicting pairs (with the _ being the default one).

@pat-s commented on GitHub (Sep 8, 2023): Ahh forget about that one. One option would be that Gitea only uses `_` instead of dots in key=value mappings or at least supports both notations for these conflicting pairs (with the `_` being the default one).
Author
Owner

@wxiaoguang commented on GitHub (Sep 8, 2023):

IMO the more tricks introduced, the more fragile the system will be.

I think at the moment the 1-vs-1 mapping is the most stable and maintainable approach.

I have some plans to rewrite the ini package to resolve some legacy problems. Maybe at that time we can accept the dots appearing anywhere (but not now ....)

@wxiaoguang commented on GitHub (Sep 8, 2023): IMO the more tricks introduced, the more fragile the system will be. I think at the moment the 1-vs-1 mapping is the most stable and maintainable approach. I have some plans to rewrite the ini package to resolve some legacy problems. Maybe at that time we can accept the dots appearing anywhere (but not now ....)
Author
Owner

@pat-s commented on GitHub (Sep 22, 2023):

Alright, I am not fully happy with it but I understand the limits. I'll pin this discussion and issue in the helm repo and hope not too many users will fall about it in the future :)

@pat-s commented on GitHub (Sep 22, 2023): Alright, I am not fully happy with it but I understand the limits. I'll pin this discussion and issue in the helm repo and hope not too many users will fall about it in the future :)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#11569