values.yaml: Rename section "gitea" to "forgejo"?

johanneskastl commented

2023-02-23 09:33:09 +00:00

(Migrated from codeberg.org)

codeberg.org/forgejo-contrib/forgejo-helm@4179b94eb3/values.yaml (L270)

Not sure if this is a good idea in terms of "keeping up with changes in gitea helm chart", but:

I took my existing gitea helm chart setup, copied it into a another folder and did a search&replace for "gitea", where I changed everything (hostnames, secret names, etc.) to "forgejo".

This included this section in the values.yaml, which unfortunately meant all of my settings were ignored. :-(

So, this can be discussed. I would at least add a comment to the values.yaml to explicitly state that this key needs to be called "gitea", not "forgejo".

What do you think?

https://codeberg.org/forgejo-contrib/forgejo-helm/src/commit/4179b94eb341632143d5f319b070ff34a2b57f90/values.yaml#L270 Not sure if this is a good idea in terms of "keeping up with changes in gitea helm chart", but: I took my existing gitea helm chart setup, copied it into a another folder and did a search&replace for "gitea", where I changed everything (hostnames, secret names, etc.) to "forgejo". This included this section in the `values.yaml`, which unfortunately meant all of my settings were ignored. :-( So, this can be discussed. I would at least add a comment to the values.yaml to explicitly state that this key needs to be called "gitea", not "forgejo". What do you think?

viceice commented

2023-03-03 06:06:38 +00:00

(Migrated from codeberg.org)

yes, i didn't rename that because merging upstream changes would become a big challenge and i don't have much time for this.

so I'm ok with some extra docs to explain it.

yes, i didn't rename that because merging upstream changes would become a big challenge and i don't have much time for this. so I'm ok with some extra docs to explain it.

dachary commented

2023-03-03 08:27:35 +00:00

(Migrated from codeberg.org)

FWIW, the strategy of branding in Forgejo itself is to change Gitea to Forgejo only where it is user visible. That minimizes the diff footprint and helps share code between Gitea & Forgejo. Which is generally interesting because the codebase have a lot in common.

voidcontext commented

2024-02-07 09:35:32 +00:00

(Migrated from codeberg.org)

I guess this could/should go ahead considering the decision to make forgejo a hard fork: https://codeberg.org/forgejo/governance/issues/58

viceice commented

2024-02-07 10:22:54 +00:00

(Migrated from codeberg.org)

I think we should defer until we really have a benefit. it would make backports from gitea chart very hard because of all the conflicts.

viceice added the

labels

2024-05-30 11:03:52 +00:00

pat-s commented

2025-08-20 09:01:40 +00:00

Member

@viceice Given the current situation, I think it would be good to do a renaming. Both in terms of branding and because I don't think that many cherry-picks from the Gitea chart are needed anymore.

Given that v14 is breaking already, it would be a good time to include it now. What do you think?

The chart could even account for the renaming and treat gitea: the same way as forgejo:, so that this change wouldn't even be breaking.

@viceice Given the current situation, I think it would be good to do a renaming. Both in terms of branding and because I don't think that many cherry-picks from the Gitea chart are needed anymore. Given that v14 is breaking already, it would be a good time to include it now. What do you think? The chart could even account for the renaming and treat `gitea:` the same way as `forgejo:`, so that this change wouldn't even be breaking.

viceice commented

2025-08-20 13:52:53 +00:00

sounds good, can you do it?

pat-s commented

2025-08-20 16:12:17 +00:00

Member

I can, but this is more complicated than I first anticipated, especially because one needs to take care to not recreate important resources, especially the PVCs. I am not sure we can ensure this directly within the chart, but I'll try. More likely, users will need to add existingXY and the appropriate name into their values after the defaults got renamed.

Shouldn't block the upcoming release.

I can, but this is more complicated than I first anticipated, especially because one needs to take care to not recreate important resources, especially the PVCs. I am not sure we can ensure this directly within the chart, but I'll try. More likely, users will need to add `existingXY` and the appropriate name into their values after the defaults got renamed. Shouldn't block the upcoming release.

viceice commented

2025-08-21 09:52:38 +00:00

let's shift this and try to do backward compatible if possible. so we can drop old in a later release.

merge function seems reasonable

https://helm.sh/docs/chart_template_guide/function_list/#mergeoverwrite-mustmergeoverwrite

let's shift this and try to do backward compatible if possible. so we can drop old in a later release. `merge` function seems reasonable https://helm.sh/docs/chart_template_guide/function_list/#mergeoverwrite-mustmergeoverwrite

viceice removed the

Status

Blocked

label

2025-08-21 09:52:56 +00:00

viceice self-assigned this

2025-08-21 13:05:52 +00:00

viceice added this to the v14 milestone

2025-08-21 13:05:55 +00:00

viceice added the

Status

In progress