Gitea helm deployement on failure oicd connect warning instead of hard failure

[aladante]

Description

Situation

While updating Authentik, the nodes in my Kubernetes cluster (EKS) rebooted due to an unexpected update window. This led to the following chain of events:

Gitea was down during the Authentik update because it couldn't resolve the OIDC connection.

EKS nodes restarted, and new nodes were created.

Gitea pods failed to start because they could not reach the OIDC provider during initialization.

Because the Gitea containers didn’t successfully start, the cluster could not retrieve or pull those pods, resulting in a prolonged outage.

Problem

The main issue is that Gitea completely fails to start when the OIDC provider is unreachable. Ideally, this kind of external authentication failure should:

Be logged as a warning or error.

Still allow Gitea to start up so that other parts of the cluster (like deployments and pod management) are not blocked.

Optionally degrade gracefully (e.g., fall back to local users or offer a maintenance mode).

Request

Would it be possible to change the behavior so that failure to connect to an OIDC provider during startup does not cause the entire application to fail?

This would improve resilience, especially in cloud environments where service restarts and temporary network issues are common.

Not sure if this is a Gitea core issue or better suited for the Helm chart discussion. Please feel free to redirect me if needed.

Thanks in advance!

Gitea Version

1.24.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

talos linux

How are you running Gitea?

Helm kuberenetes

Database

PostgreSQL