Helm upgrade from 1.19 to 1.20 was not successful due to init-app-ini init container #11239

New Issue

GiteaMirror · 2025-11-02T09:31:48-06:00

GiteaMirror commented

2025-11-02 09:31:48 -06:00

Originally created by @jmhbnz on GitHub (Jul 16, 2023).

Description

Excited to try 1.20.0 I tried a helm upgrade in my dev cluster.

The chart I maintain is a cutdown version of the official one and is here: https://gitea.jamma.life/jmhbnz/charts/src/branch/master/gitea

After running the following and checking pods I can see:

james@jamma-server:~/Services/gitea/charts/gitea$ helm upgrade --install -n jamma-gitea jamma-gitea . \
    --set "gitea.admin.password=${gitea_admin_password}" \
    --set "ingress.hosts[0].host=gitea.jamma.dev" \
    --set "ingress.hosts[0].paths[0].path=/" \
    --set "ingress.hosts[0].paths[0].pathType=Prefix" \
    --set "ingress.tls[0].hosts[0]=gitea.jamma.dev" \
    --set "ingress.tls[0].secretName=tls-jamma-gitea"

james@jamma-server:~/Services/gitea/charts/gitea$ sudo kubectl get pods -n jamma-gitea         
NAMESPACE        NAME                                            READY   STATUS       RESTARTS       AGE
jamma-gitea      jamma-gitea-0                                   0/1     Init:Error   3 (42s ago)    74s

Checking the logs for init containers I can see the following for init-app-ini which doesn't look happy:

james@jamma-server:~/Services/gitea/charts/gitea$ sudo kubectl -n jamma-gitea logs jamma-gitea-0 -c init-app-ini
...Initial secrets generated

Processing inlines...
  repository
    + 'ROOT'
  metrics
    + 'ENABLED'
  database
    + 'DB_TYPE'
  cache
    + 'ENABLED'
  [ini root]
  service
    + 'DISABLE_REGISTRATION'
  server
    + 'APP_DATA_PATH'
    + 'DOMAIN'
    + 'ENABLE_PPROF'
    + 'HTTP_PORT'
    + 'PROTOCOL'
    + 'ROOT_URL'
    + 'SSH_DOMAIN'
    + 'SSH_LISTEN_PORT'
    + 'SSH_PORT'
    + 'START_SSH_SERVER'
  security
    + 'INSTALL_LOCK'


Reloading preset envs...
=== All configuration sources loaded ===

An app.ini file already exists. To prevent overwriting secret keys, these settings are dropped and remain unchanged:
  - security.INTERNAL_TOKEN
  - security.SECRET_KEY
  - oauth2.JWT_SECRET
  - server.LFS_JWT_SECRET
Incorrect Usage. flag provided but not defined: -p

NAME:
   environment-to-ini - Use provided environment to update configuration ini

USAGE:
   environment-to-ini [global options] command [command options] [arguments...]

DESCRIPTION:
   As a helper to allow docker users to update the gitea configuration
  through the environment, this command allows environment variables to
  be mapped to values in the ini.

  Environment variables of the form "GITEA__SECTION_NAME__KEY_NAME"
  will be mapped to the ini section "[section_name]" and the key
  "KEY_NAME" with the value as provided.

  Environment variables of the form "GITEA__SECTION_NAME__KEY_NAME__FILE"
  will be mapped to the ini section "[section_name]" and the key
  "KEY_NAME" with the value loaded from the specified file.

  Environment variables are usually restricted to a reduced character
  set "0-9A-Z_" - in order to allow the setting of sections with
  characters outside of that set, they should be escaped as following:
  "_0X2E_" for ".". The entire section and key names can be escaped as
  a UTF8 byte string if necessary. E.g. to configure:

    """
    ...
    [log.console]
    COLORIZE=false
    STDERR=true
    ...
    """

  You would set the environment variables: "GITEA__LOG_0x2E_CONSOLE__COLORIZE=false"
  and "GITEA__LOG_0x2E_CONSOLE__STDERR=false". Other examples can be found
  on the configuration cheat sheet.

COMMANDS:
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --custom-path value, -C value  Custom path file path
   --config value, -c value       Custom configuration file path
   --work-path value, -w value    Set the gitea working path (default: "/usr/local/bin")
   --out value, -o value          Destination file to write to
   --help, -h                     show help
2023/07/16 20:13:54 ...nvironment-to-ini.go:73:main() [F] Failed to run app with [environment-to-ini -o /data/gitea/conf/app.ini -p ENV_TO_INI]
: flag provided but not defined: -p

The pertinent log appears to be:

2023/07/16 20:13:54 ...nvironment-to-ini.go:73:main() [F] Failed to run app with [environment-to-ini -o /data/gitea/conf/app.ini -p ENV_TO_INI]
: flag provided but not defined: -p

Thinking my chart may need an update I compared the template for this initcontainer to the upstream official chart to see if there were any changes and there wasn't any meaningful diff, I'm just missing the resources line which won't cause this.

Can anyone please provide some gentle guidance on what might be causing this?

Gitea Version

1.20.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.30.2

Operating System

Debian 11 /w k3s 1.25.3

How are you running Gitea?

Running in helm via chart I linked above.

Database

None

Originally created by @jmhbnz on GitHub (Jul 16, 2023). ### Description Excited to try 1.20.0 I tried a helm upgrade in my dev cluster. The chart I maintain is a cutdown version of the official one and is here: https://gitea.jamma.life/jmhbnz/charts/src/branch/master/gitea After running the following and checking pods I can see: ```bash james@jamma-server:~/Services/gitea/charts/gitea$ helm upgrade --install -n jamma-gitea jamma-gitea . \ --set "gitea.admin.password=${gitea_admin_password}" \ --set "ingress.hosts[0].host=gitea.jamma.dev" \ --set "ingress.hosts[0].paths[0].path=/" \ --set "ingress.hosts[0].paths[0].pathType=Prefix" \ --set "ingress.tls[0].hosts[0]=gitea.jamma.dev" \ --set "ingress.tls[0].secretName=tls-jamma-gitea" james@jamma-server:~/Services/gitea/charts/gitea$ sudo kubectl get pods -n jamma-gitea NAMESPACE NAME READY STATUS RESTARTS AGE jamma-gitea jamma-gitea-0 0/1 Init:Error 3 (42s ago) 74s ``` Checking the logs for init containers I can see the following for `init-app-ini` which doesn't look happy: ```bash james@jamma-server:~/Services/gitea/charts/gitea$ sudo kubectl -n jamma-gitea logs jamma-gitea-0 -c init-app-ini ...Initial secrets generated Processing inlines... repository + 'ROOT' metrics + 'ENABLED' database + 'DB_TYPE' cache + 'ENABLED' [ini root] service + 'DISABLE_REGISTRATION' server + 'APP_DATA_PATH' + 'DOMAIN' + 'ENABLE_PPROF' + 'HTTP_PORT' + 'PROTOCOL' + 'ROOT_URL' + 'SSH_DOMAIN' + 'SSH_LISTEN_PORT' + 'SSH_PORT' + 'START_SSH_SERVER' security + 'INSTALL_LOCK' Reloading preset envs... === All configuration sources loaded === An app.ini file already exists. To prevent overwriting secret keys, these settings are dropped and remain unchanged: - security.INTERNAL_TOKEN - security.SECRET_KEY - oauth2.JWT_SECRET - server.LFS_JWT_SECRET Incorrect Usage. flag provided but not defined: -p NAME: environment-to-ini - Use provided environment to update configuration ini USAGE: environment-to-ini [global options] command [command options] [arguments...] DESCRIPTION: As a helper to allow docker users to update the gitea configuration through the environment, this command allows environment variables to be mapped to values in the ini. Environment variables of the form "GITEA__SECTION_NAME__KEY_NAME" will be mapped to the ini section "[section_name]" and the key "KEY_NAME" with the value as provided. Environment variables of the form "GITEA__SECTION_NAME__KEY_NAME__FILE" will be mapped to the ini section "[section_name]" and the key "KEY_NAME" with the value loaded from the specified file. Environment variables are usually restricted to a reduced character set "0-9A-Z_" - in order to allow the setting of sections with characters outside of that set, they should be escaped as following: "_0X2E_" for ".". The entire section and key names can be escaped as a UTF8 byte string if necessary. E.g. to configure: """ ... [log.console] COLORIZE=false STDERR=true ... """ You would set the environment variables: "GITEA__LOG_0x2E_CONSOLE__COLORIZE=false" and "GITEA__LOG_0x2E_CONSOLE__STDERR=false". Other examples can be found on the configuration cheat sheet. COMMANDS: help, h Shows a list of commands or help for one command GLOBAL OPTIONS: --custom-path value, -C value Custom path file path --config value, -c value Custom configuration file path --work-path value, -w value Set the gitea working path (default: "/usr/local/bin") --out value, -o value Destination file to write to --help, -h show help 2023/07/16 20:13:54 ...nvironment-to-ini.go:73:main() [F] Failed to run app with [environment-to-ini -o /data/gitea/conf/app.ini -p ENV_TO_INI] : flag provided but not defined: -p ``` The pertinent log appears to be: ```bash 2023/07/16 20:13:54 ...nvironment-to-ini.go:73:main() [F] Failed to run app with [environment-to-ini -o /data/gitea/conf/app.ini -p ENV_TO_INI] : flag provided but not defined: -p ``` Thinking my chart may need an update I compared the template for this initcontainer to the upstream official chart to see if there were any changes and there wasn't any meaningful diff, I'm just missing the resources line which won't cause this. Can anyone please provide some gentle guidance on what might be causing this? ### Gitea Version 1.20.0 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.30.2 ### Operating System Debian 11 /w k3s 1.25.3 ### How are you running Gitea? Running in helm via chart I linked above. ### Database None

GiteaMirror added the type/bug label 2025-11-02 09:31:48 -06:00

GiteaMirror closed this issue

2025-11-02 09:31:49 -06:00

GiteaMirror commented

2025-11-02 09:31:50 -06:00

@delvh commented on GitHub (Jul 16, 2023):

-p ENV_TO_INI

Wasn't there a recent PR in the helm chart that removed this parameter?

@delvh commented on GitHub (Jul 16, 2023): > -p ENV_TO_INI Wasn't there a recent PR in the helm chart that removed this parameter?

GiteaMirror commented

2025-11-02 09:31:50 -06:00

@delvh commented on GitHub (Jul 16, 2023):

Oh, it is not merged yet: https://gitea.com/gitea/helm-chart/pulls/464.

@delvh commented on GitHub (Jul 16, 2023): Oh, it is not merged yet: https://gitea.com/gitea/helm-chart/pulls/464.

GiteaMirror commented

2025-11-02 09:31:50 -06:00

@pat-s commented on GitHub (Jul 16, 2023):

Well there was simply no release yet. Nobody claimed the chart to be working with 1.20 yet ;)

I guess for the future it would be good to

check with the official chart
ensure your fork is up-to-date
if in doubt open an issue in the helm-chart repo

I've had a look at your fork but couldn't infer why a fork would be necessary to run Gitea on k3s. Also contributions (discussions/PRs) to the official chart are always welcome!

@pat-s commented on GitHub (Jul 16, 2023): Well there was simply no release yet. Nobody claimed the chart to be working with 1.20 yet ;) I guess for the future it would be good to 1. check with the official chart 2. ensure your fork is up-to-date 3. if in doubt open an issue in the helm-chart repo I've had a look at your fork but couldn't infer why a fork would be necessary to run Gitea on `k3s`. Also contributions (discussions/PRs) to the official chart are always welcome!

GiteaMirror commented

2025-11-02 09:31:50 -06:00

@jmhbnz commented on GitHub (Jul 16, 2023):

Hey @pat-s, @delvh - Thanks for the quick replies.

In terms of my own fork, I do that for personal reasons I don't wish to get into.

I had compared charts for diff against main but not looked at open pr's. As a user I guess I had assumed the gitea helm chart would support newly released versions of gitea. This is I believe a pretty common assumption and I would wager I'm not the only one that might hit this error today so is probably the one area I would encourage some sort of alignment on in future. Many projects will release chart updates in sync with overall project updates, but I understand it's not easy and do note the disclaimer in the chart readme.

Just feedback to take or leave for what it is worth. I will hold off adopting the new release until the chart is ready.

Edit: For anyone that hits this error, in my case a simple helm rollback <release> followed by manual pod kill was all that was required to bring 1.19.x back to life.

@jmhbnz commented on GitHub (Jul 16, 2023): Hey @pat-s, @delvh - Thanks for the quick replies. In terms of my own fork, I do that for personal reasons I don't wish to get into. I had compared charts for diff against `main` but not looked at open pr's. As a user I guess I had assumed the gitea helm chart would support newly released versions of gitea. This is I believe a pretty common assumption and I would wager I'm not the only one that might hit this error today so is probably the one area I would encourage some sort of alignment on in future. Many projects will release chart updates in sync with overall project updates, but I understand it's not easy and do note the disclaimer in the chart readme. Just feedback to take or leave for what it is worth. I will hold off adopting the new release until the chart is ready. Edit: For anyone that hits this error, in my case a simple `helm rollback <release>` followed by manual pod kill was all that was required to bring 1.19.x back to life.

GiteaMirror commented

2025-11-02 09:31:50 -06:00

@pat-s commented on GitHub (Jul 16, 2023):

1.20 got released a few hours ago. Not even professional services catch up with their chart compatibility that fast, also given its Sunday today 😱

Next Gitea is an open source project and most people do it in their spare time. There is not always the case that changes are needed for the chart for new gitea versions but this time it is like this.

And disclaimer: the upcoming changes will be a lot a and large, so prepare your fork 🥷😄

(just saw you work at RH so I guess you understand my sentiment an reasoning :))

@pat-s commented on GitHub (Jul 16, 2023): 1.20 got released a few hours ago. Not even professional services catch up with their chart compatibility that fast, also given its Sunday today 😱 Next Gitea is an open source project and most people do it in their spare time. There is not always the case that changes are needed for the chart for new gitea versions but this time it is like this. And disclaimer: the upcoming changes will be a lot a and large, so prepare your fork 🥷😄 (just saw you work at RH so I guess you understand my sentiment an reasoning :))

GiteaMirror commented

2025-11-02 09:31:51 -06:00

@jmhbnz commented on GitHub (Jul 16, 2023):

1.20 got released a few hours ago. Not even professional services catch up with their chart compatibility that fast, also given its Sunday today

You may have missed my point, the feedback I was trying to provide is that many software projects will sync the release of a new version with the publication of a chart to be able to install said release. That way user foot guns like I encountered today can be avoided.

In this case it may have meant delaying the release of gitea 1.20.0 slightly until the chart to install it was ready. That's something the project has to weigh up and perhaps you already have and prefer to do things the way they are currently. I'm conscious helm is only one installation method and perhaps not a priority or not something you want to be coupled to.

It's feedback for the project as a user, no response needed. Just want to make sure it's clear what I am talking about.

Edit: FWIW I don't want you to think I am ungrateful, I have been a project sponsor on open collective for a while and this is purely feedback. It can be ignored if the project have already thought about this issue.

Edit2: I see you've merged the chart updates, thanks. I've updated my fork and gitea 1.20.0 is now deployed successfully 🎉

@jmhbnz commented on GitHub (Jul 16, 2023): > 1.20 got released a few hours ago. Not even professional services catch up with their chart compatibility that fast, also given its Sunday today You may have missed my point, the feedback I was trying to provide is that many software projects will sync the release of a new version with the publication of a chart to be able to install said release. That way user foot guns like I encountered today can be avoided. In this case it may have meant delaying the release of gitea 1.20.0 slightly until the chart to install it was ready. That's something the project has to weigh up and perhaps you already have and prefer to do things the way they are currently. I'm conscious helm is only one installation method and perhaps not a priority or not something you want to be coupled to. It's feedback for the project as a user, no response needed. Just want to make sure it's clear what I am talking about. Edit: FWIW I don't want you to think I am ungrateful, I have been a project sponsor on open collective for a while and this is purely feedback. It can be ignored if the project have already thought about this issue. Edit2: I see you've merged the chart updates, thanks. I've updated my fork and gitea 1.20.0 is now deployed successfully 🎉

GiteaMirror commented

2025-11-02 09:31:51 -06:00

@pat-s commented on GitHub (Jul 17, 2023):

You may have missed my point, the feedback I was trying to provide is that many software projects will sync the release of a new version with the publication of a chart to be able to install said release. That way user foot guns like I encountered today can be avoided.

I got your point but to me it sounds as if this was the default and Gitea is an outlier here. It might just be my bubble but of all the dozen helm charts I use, none of them syncs releases (by the hour) with the app version upstream release.

In this case it may have meant delaying the release of gitea 1.20.0 slightly until the chart to install it was ready. That's something the project has to weigh up and perhaps you already have and prefer to do things the way they are currently. I'm conscious helm is only one installation method and perhaps not a priority or not something you want to be coupled to.

No impossible but if we would do so, this would result in a substantial management overhead. I see how this can be easily done within a software company (like RH and others) but once it comes to FOSS projects, it's rather unrealistic. Different time zones, people not responding, etc. You don't want to delay a release just because one of the satellite repos is not yet ready.

It's feedback for the project as a user, no response needed. Just want to make sure it's clear what I am talking about.

Appreciated, no worries. My slightly harsh reply came from the fact that I've replied to a few "when 1.20" messages lately/these days and that all them kinda implied "why doesn't it already work, the release was 5 min ago" - which sounds a bit "😶️" at some point, especially if you're putting your free time in to get things going.

@pat-s commented on GitHub (Jul 17, 2023): > You may have missed my point, the feedback I was trying to provide is that many software projects will sync the release of a new version with the publication of a chart to be able to install said release. That way user foot guns like I encountered today can be avoided. I got your point but to me it sounds as if this was the default and Gitea is an outlier here. It might just be my bubble but of all the dozen helm charts I use, none of them syncs releases (by the hour) with the app version upstream release. > In this case it may have meant delaying the release of gitea 1.20.0 slightly until the chart to install it was ready. That's something the project has to weigh up and perhaps you already have and prefer to do things the way they are currently. I'm conscious helm is only one installation method and perhaps not a priority or not something you want to be coupled to. No impossible but if we would do so, this would result in a substantial management overhead. I see how this can be easily done within a software company (like RH and others) but once it comes to FOSS projects, it's rather unrealistic. Different time zones, people not responding, etc. You don't want to delay a release just because one of the satellite repos is not yet ready. > It's feedback for the project as a user, no response needed. Just want to make sure it's clear what I am talking about. Appreciated, no worries. My slightly harsh reply came from the fact that I've replied to a few "when 1.20" messages lately/these days and that all them kinda implied "why doesn't it already work, the release was 5 min ago" - which sounds a bit "😶️" at some point, especially if you're putting your free time in to get things going.

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#11239