gitea/helm-chart
45
54
Fork 127
Code Issues 31 Pull Requests 7 Actions Releases 87 Activity

How to configure external applications? #489

New Issue
Closed
opened 2023-08-24 01:58:44 +00:00 by fbongiovanni29 · 11 comments
fbongiovanni29 commented 2023-08-24 01:58:44 +00:00
Copy Link

I'm standing up other services such as ArgoCD/Backstage/etc. that use redis/postgres. I'd like to share a postgres instance and redis instance between them hosted in GCP. How can I configure the gitea helm chart to do this?

It looks like it should be possible, but seems tricky.

I'm standing up other services such as ArgoCD/Backstage/etc. that use redis/postgres. I'd like to share a postgres instance and redis instance between them hosted in GCP. How can I configure the gitea helm chart to do this? It looks like it should be possible, but seems tricky.
pat-s commented 2023-08-24 07:36:13 +00:00
Member
Copy Link

I don't understand the request yet - where is the relation to Gitea? It sounds like you're asking how to connect external apps to redis/postgres.

I don't understand the request yet - where is the relation to Gitea? It sounds like you're asking how to connect external apps to redis/postgres.
fbongiovanni29 commented 2023-08-24 21:16:14 +00:00
Author
Copy Link

Sorry, I realize that was unclear. All I really want to know is how to configure the helm chart to use an external postgres & redis instance rather than the ones provided by the helm chart.

Sorry, I realize that was unclear. All I really want to know is how to configure the helm chart to use an external postgres & redis instance rather than the ones provided by the helm chart.
pat-s commented 2023-08-26 11:02:45 +00:00
Member
Copy Link

You need to set up the config vars for the respective service as outlined in the cheat sheet, e.g. for Databases: https://docs.gitea.com/next/administration/config-cheat-sheet#database-database.

The same for every other service. At the same time, you should disable the helm-chart dependency for the respective service so you don't deploy unused pods.

This is not specific to the helm chart and a basic administration task for various external tools, which is probably why it hasn't been explicitly documented so far.

You need to set up the config vars for the respective service as outlined in the cheat sheet, e.g. for Databases: https://docs.gitea.com/next/administration/config-cheat-sheet#database-database. The same for every other service. At the same time, you should disable the helm-chart dependency for the respective service so you don't deploy unused pods. This is not specific to the helm chart and a basic administration task for various external tools, which is probably why it hasn't been explicitly documented so far.
pat-s changed title from Document/Implement How To Configure Your Own Datastores to How to configure external applications? 2023-08-26 11:03:20 +00:00
pat-s added the
kind
question
 label 2023-08-26 11:03:25 +00:00
smolinari commented 2023-10-08 07:10:43 +00:00
Copy Link

I'm also finding the docs a bit confusing....

Before upgrading to the newest major version, I had my Postgres db credentials being pulled from secrets in the gitea.additionalConfigFromEnvs (and still are after the renaming that was required to upgrade). Now I'm reading they can (should?) be put into the gitea.config property? What is correct? What is best? Does it matter?

It would be nice if the Redis config were documented on how to "key in" the config values into the chart, much like the database section does, especially because it's not totally clear where or what needs to use redis. After reading a good bit, I found there is the cache, the queue and sessions. They all have to be manually set, correct? Or can I just hook up the redis instance and Gitea would know to use it, where it needs it?

Can you agree this might need a bit better clarification in the docs? As I see it, the goal of a Helm charts is to ease the installation of an application, no matter what the infrastructure decisions are.

That said, I'm using a mail server called Mailu. It has a ton of config too. Yet, I feel their helm chart also handles the choice between external databases or self-installed ones fairly elegantly. https://github.com/Mailu/helm-charts/blob/master/mailu/values.yaml

Maybe it can offer some food for thought on ways to possibly improve this chart? 😀

Scott

I'm also finding the docs a bit confusing.... Before upgrading to the newest major version, I had my Postgres db credentials being pulled from secrets in the `gitea.additionalConfigFromEnvs` (and still are after the renaming that was required to upgrade). Now I'm reading they can (should?) be put into the `gitea.config` property? What is correct? What is best? Does it matter? It would be nice if the Redis config were documented on how to "key in" the config values into the chart, much like the database section does, especially because it's not totally clear where or what needs to use redis. After reading a good bit, I found there is the cache, the queue and sessions. They all have to be manually set, correct? Or can I just hook up the redis instance and Gitea would know to use it, where it needs it? Can you agree this might need a bit better clarification in the docs? As I see it, the goal of a Helm charts is to ease the installation of an application, no matter what the infrastructure decisions are. That said, I'm using a mail server called Mailu. It has a ton of config too. Yet, I feel their helm chart also handles the choice between external databases or self-installed ones fairly elegantly. https://github.com/Mailu/helm-charts/blob/master/mailu/values.yaml Maybe it can offer some food for thought on ways to possibly improve this chart? 😀 Scott
pat-s commented 2023-10-09 15:37:44 +00:00
Member
Copy Link

Before upgrading to the newest major version, I had my Postgres db credentials being pulled from secrets in the gitea.additionalConfigFromEnvs (and still are after the renaming that was required to upgrade). Now I'm reading they can (should?) be put into the gitea.config property? What is correct? What is best? Does it matter?

It's just a secret. It doesn't matter how you import it as long as it's secured/encrypted in some way.

They all have to be manually set, correct? Or can I just hook up the redis instance and Gitea would know to use it, where it needs it?

You only need to configure it manually if you roll your own external redis as the chart can't guess the connection information.

Can you agree this might need a bit better clarification in the docs?

What might need better clarification? That session, cache and queue exists and need to be configured when using an external instance?
This has been like this forever and is covered by "how to to configure gitea with external apps" in the official documentation.
We could duplicate it again here but lately I feel that most people only look once in the the helm chart README and expect to find every detail there without consulting the official documentation.
The facts above don't really relate to the helm installation method specifically but to configuring Gitea in general.

That said, I'm using a mail server called Mailu. It has a ton of config too. Yet, I feel their helm chart also handles the choice between external databases or self-installed ones fairly elegantly. https://github.com/Mailu/helm-charts/blob/master/mailu/values.yaml

What exactly do you refer to? "external" and "self-installed" are actually the same in this context.

I think we're always open to suggestions and we'll discuss them here/internally but we can't guarantee to implement all of them.

> Before upgrading to the newest major version, I had my Postgres db credentials being pulled from secrets in the gitea.additionalConfigFromEnvs (and still are after the renaming that was required to upgrade). Now I'm reading they can (should?) be put into the gitea.config property? What is correct? What is best? Does it matter? It's just a secret. It doesn't matter how you import it as long as it's secured/encrypted in some way. > They all have to be manually set, correct? Or can I just hook up the redis instance and Gitea would know to use it, where it needs it? You only need to configure it manually if you roll your own external redis as the chart can't guess the connection information. > Can you agree this might need a bit better clarification in the docs? What might need better clarification? That `session`, `cache` and `queue` exists and need to be configured when using an external instance? This has been like this forever and is covered by "how to to configure gitea with external apps" in the official documentation. We could duplicate it again here but lately I feel that most people only look once in the the helm chart README and expect to find every detail there without consulting the official documentation. The facts above don't really relate to the helm installation method specifically but to configuring Gitea in general. > That said, I'm using a mail server called Mailu. It has a ton of config too. Yet, I feel their helm chart also handles the choice between external databases or self-installed ones fairly elegantly. https://github.com/Mailu/helm-charts/blob/master/mailu/values.yaml What exactly do you refer to? "external" and "self-installed" are actually the same in this context. I think we're always open to suggestions and we'll discuss them here/internally but we can't guarantee to implement all of them.
smolinari commented 2023-10-09 16:14:01 +00:00
Copy Link

It's just a secret. It doesn't matter how you import it as long as it's secured/encrypted in some way.

My question was, which part of the chart should the secrets be added? gitea.additionalConfigFromEnvs or gitea.config. Or does it not matter?

What might need better clarification? That session, cache and queue exists and need to be configured when using an external instance?

Yes

This has been like this forever

Yes, but people new to Gitea and installing it via this chart won't be in the know to go to the docs to understand how to set the charts values for an external Redis instance.

Once more, the purpose of a Helm chart is to make the installation of an application simple(r) in k8s. Expecting the user of the chart to go to the docs to find answers on the k8s installation "because this has been like this forever" is a poor expectation that will fail practically every time. Either the docs for the Helm chart need to properly point to the regular docs as the reference to getting something done or the chart does the work for the user. Neither is happening currently for Redis. The database docs are a bit better, but only a little.

What exactly do you refer to? "external" and "self-installed" are actually the same in this context.

"External" is a database instance already installed by the user. "Self-installed" is an instance installed by the chart. Maybe "chart-installed" would have been a better choice of wording, instead of "self-installed".

I think we're always open to suggestions and we'll discuss them here/internally but we can't guarantee to implement all of them.

I can't expect anything more. I just hope you can agree the chart or the chart's docs can be improved in general. Thanks.

Scott

> It's just a secret. It doesn't matter how you import it as long as it's secured/encrypted in some way. My question was, which part of the chart should the secrets be added? `gitea.additionalConfigFromEnvs` or `gitea.config`. Or does it not matter? > What might need better clarification? That session, cache and queue exists and need to be configured when using an external instance? Yes > This has been like this forever Yes, but people new to Gitea and installing it via this chart won't be in the know to go to the docs to understand how to set the charts values for an external Redis instance. Once more, the purpose of a Helm chart is to make the installation of an application simple(r) in k8s. Expecting the user of the chart to go to the docs to find answers on the k8s installation "because this has been like this forever" is a poor expectation that will fail practically every time. Either the docs for the Helm chart need to properly point to the regular docs as the reference to getting something done or the chart does the work for the user. Neither is happening currently for Redis. The database docs are a bit better, but only a little. > What exactly do you refer to? "external" and "self-installed" are actually the same in this context. "External" is a database instance already installed by the user. "Self-installed" is an instance installed by the chart. Maybe "chart-installed" would have been a better choice of wording, instead of "self-installed". > I think we're always open to suggestions and we'll discuss them here/internally but we can't guarantee to implement all of them. I can't expect anything more. I just hope you can agree the chart or the chart's docs can be improved in general. Thanks. Scott
pat-s commented 2023-10-09 17:56:05 +00:00
Member
Copy Link

Or does it not matter?

It does not matter.

Yes, but people new to Gitea and installing it via this chart won't be in the know to go to the docs to understand how to set the charts values for an external Redis instance.

Hmm. I'd argue that if you have one and want to configure any service against it, reading the docs of the respective app is a must.
I actually think that people should read the docs more often/in greater detail before just doing a "quick setup", especially for such tasks as the above one.
This is surely a bit of a subjective topic here and many people will have a different opinion about it.
Yet, seeing other issues opened in the last weeks, I got a bit the feeling that people like to spend rather time writing/opening issues and complaining about defaults which don't meet their needs instead of reading the docs and adapting the config/install to their needs.
There is a reason for a central place WRT to documentation like the above. Otherwise we would have to maintain it for every single installation option in multiple places.
If you extend this idea, you would need to document every single config value down to the git config and tell users what and where to set the value (again, this is a bit extreme but I think you get the point: what to include and what not?)

"External" is a database instance already installed by the user. "Self-installed" is an instance installed by the chart. Maybe "chart-installed" would have been a better choice of wording, instead of "self-installed".

The chart configures a working install. If external apps should be used, one needs to consult the official documentation and check how to establish a connection. And it's literally just one connection string and this is the same as for every other app out there (no matter if connecting to postgres, redis, minio, you name it).
As an alternative, one can even check the app.ini of a dummy/test install and check the values there.

Once more, the purpose of a Helm chart is to make the installation of an application simple(r) in k8s. Expecting the user of the chart to go to the docs to find answers on the k8s installation "because this has been like this forever" is a poor expectation that will fail practically every time. Either the docs for the Helm chart need to properly point to the regular docs as the reference to getting something done or the chart does the work for the user. Neither is happening currently for Redis. The database docs are a bit better, but only a little.

I am not sharing your view here. The chart already configures a working installation. If one decides to use external applications, they need to consult the official documentation at the latest at this point.
Gitea can be configured in so many ways, it's impossible to list and describe all possible options.
I am a somewhat desperate about this lately as I got the impression that we got some issues around "why isn't my very specific XYZ config described to the latest detail in the README?"
If such attempts fail because of a missing link to the redis configuration options within the official documentation, then I am out of words at this point...
Not saying that we can't put a link there but you might also notice that I am putting a lot of time into explaining this by replying so extensively.

I am closing here as we went a bit off-topic and me a bit emotional. Guess I should take a bit of a break from answering issues 🙃 Thanks for your replies/suggestions, nothing personal - just me being a bit upset with the latest requests that came up here.

> Or does it not matter? It does not matter. > Yes, but people new to Gitea and installing it via this chart won't be in the know to go to the docs to understand how to set the charts values for an external Redis instance. Hmm. I'd argue that if you have one and want to configure any service against it, reading the docs of the respective app is a must. I actually think that people should read the docs more often/in greater detail before just doing a "quick setup", especially for such tasks as the above one. This is surely a bit of a subjective topic here and many people will have a different opinion about it. Yet, seeing other issues opened in the last weeks, I got a bit the feeling that people like to spend rather time writing/opening issues and complaining about defaults which don't meet their needs instead of reading the docs and adapting the config/install to their needs. There is a reason for a central place WRT to documentation like the above. Otherwise we would have to maintain it for every single installation option in multiple places. If you extend this idea, you would need to document every single config value down to the git config and tell users what and where to set the value (again, this is a bit extreme but I think you get the point: what to include and what not?) > "External" is a database instance already installed by the user. "Self-installed" is an instance installed by the chart. Maybe "chart-installed" would have been a better choice of wording, instead of "self-installed". The chart configures a working install. If external apps should be used, one needs to consult the official documentation and check how to establish a connection. And it's literally just one connection string and this is the same as for every other app out there (no matter if connecting to postgres, redis, minio, you name it). As an alternative, one can even check the `app.ini` of a dummy/test install and check the values there. > Once more, the purpose of a Helm chart is to make the installation of an application simple(r) in k8s. Expecting the user of the chart to go to the docs to find answers on the k8s installation "because this has been like this forever" is a poor expectation that will fail practically every time. Either the docs for the Helm chart need to properly point to the regular docs as the reference to getting something done or the chart does the work for the user. Neither is happening currently for Redis. The database docs are a bit better, but only a little. I am not sharing your view here. The chart already configures a working installation. If one decides to use external applications, they *need* to consult the official documentation **at the latest** at this point. Gitea can be configured in so many ways, it's impossible to list and describe all possible options. I am a somewhat desperate about this lately as I got the impression that we got some issues around "why isn't my very specific XYZ config described to the latest detail in the README?" If such attempts fail because of a missing link to the redis configuration options within the official documentation, then I am out of words at this point... Not saying that we can't put a link there but you might also notice that I am putting a lot of time into explaining this by replying so extensively. I am closing here as we went a bit off-topic and me a bit emotional. Guess I should take a bit of a break from answering issues 🙃 Thanks for your replies/suggestions, nothing personal - just me being a bit upset with the latest requests that came up here.
pat-s closed this issue 2023-10-09 17:56:06 +00:00
smolinari commented 2023-10-10 03:52:15 +00:00
Copy Link

@pat-s - You are unfortunately putting the users of the chart in the "being too lazy to read docs" category and that's not what I'm saying. The point of the users coming here and "complaining" isn't because they don't read the docs, it's because they don't know what in particular they should read in the docs. Are they supposed to read all of the docs to know what is missing? How should they know to hit three different section of the cheat sheet to get all the info they need to setup Gitea with an external Redis? They simply won't. So, they come here and make their case for better chart docs.

Or, the chart should offer a direct option to enter things in a standard way for an external Redis.

On a side note: If I understood the Gitea docs correctly, if there isn't a Redis set up (properly), Gitea should still work. This chart doesn't allow for that. Gitea doesn't work, when the Redis instance section is set to redis.enabled: false

This happens (in my installation):

2023/10/10 03:37:53 ...les/queue/manager.go:108:]() [E] Failed to create queue "mail": dial tcp: lookup gitpoint-redis-cluster-headless.gitpoint.svc.cluster.local: no such host

So, I'd even consider the whole Redis setup a bug.

I'm not understanding your hand-wavy attitude. This chart needs improvement for sure. Try installing Gitea with it and put yourself in the user's shoes of being ignorant to Gitea's Redis needs and think about the wall the user hits, when the chart doesn't work, because not everything is set up properly, when (if my understanding of the Gitea docs is correct) the docs say it should run anyway. Then not knowing where to look in the docs for a proper Redis config, because it is spread over 3 different sections of a cheat sheet.

The chart docs should, at a minimum, refer the user to the three sections of the cheat sheet.

In the cache section, it should have

Many cloud providers offer a managed redis service, which can be used instead of the built-in redis-cluster. If you use an external provider or your own Redis instance, refer to the cheat sheet for the exact config values necessary.

I'd also add a minimum example config entry.

And there also needs to be two new sections for queue and session config exactly like the above.

The better solution is the chart just has an external redis credentials section, like in the example chart I mentioned in my first post.

If I can get my installation working, I'll be happy to offer a PR on the chart's docs, since you seem to be happy with the current poor situation. You can correct my PR, if it is technically incorrect.

Scott

@pat-s - You are unfortunately putting the users of the chart in the "being too lazy to read docs" category and that's not what I'm saying. The point of the users coming here and "complaining" isn't because they don't read the docs, it's because they don't know what in particular they should read in the docs. Are they supposed to read all of the docs to know what is missing? How should they know to hit three different section of the cheat sheet to get all the info they need to setup Gitea with an external Redis? They simply won't. So, they come here and make their case for better chart docs. Or, the chart should offer a direct option to enter things in a standard way for an external Redis. On a side note: If I understood the Gitea docs correctly, if there isn't a Redis set up (properly), Gitea should still work. This chart doesn't allow for that. Gitea doesn't work, when the Redis instance section is set to `redis.enabled: false` This happens (in my installation): ``` 2023/10/10 03:37:53 ...les/queue/manager.go:108:]() [E] Failed to create queue "mail": dial tcp: lookup gitpoint-redis-cluster-headless.gitpoint.svc.cluster.local: no such host ``` So, I'd even consider the whole Redis setup a bug. I'm not understanding your hand-wavy attitude. This chart needs improvement for sure. Try installing Gitea with it and put yourself in the user's shoes of being ignorant to Gitea's Redis needs and think about the wall the user hits, when the chart doesn't work, because not everything is set up properly, when (if my understanding of the Gitea docs is correct) the docs say it should run anyway. Then not knowing where to look in the docs for a proper Redis config, because it is spread over 3 different sections of a cheat sheet. The chart docs should, at a minimum, refer the user to the three sections of the cheat sheet. In the cache section, it should have > Many cloud providers offer a managed redis service, which can be used instead of the built-in redis-cluster. **If you use an external provider or your own Redis instance, refer to the cheat sheet for the exact config values necessary.** I'd also add a minimum example config entry. And there also needs to be two new sections for queue and session config exactly like the above. The better solution is the chart just has an external redis credentials section, like in the example chart I mentioned in my first post. If I can get my installation working, I'll be happy to offer a PR on the chart's docs, since you seem to be happy with the current poor situation. You can correct my PR, if it is technically incorrect. Scott
kha7iq commented 2023-10-17 11:53:51 +00:00
Copy Link

I run into same issue when wanted to use external redis instead of the one provided. I did read the docs and after trying multiple configs i got it to work without redis. The point @smolinari is making that there are improvements which can be made to the chart for such scenarios and we are happy to contribute.
Considering a fairly new user of gittea some guidance in this regard is required to make such improvements.

If you disable redis from values.yaml file the chart still includes it as provider, by default the values should be changed to memory for sessions config.
1
To reproduce just disable redis and render the template of chart.

helm template gitea . | grep -i redis
    PROVIDER=redis

config.yaml

session: |-
    PROVIDER=redis
    PROVIDER_CONFIG=

This results in following error when the pod starts

2023/10/17 10:33:48 cmd/web.go:212:func1() [F] PANIC: dial tcp 127.0.0.1:6379: connect: connection refused

To fix this, if redis is disabled and no external host is configured the following should be the default values

  session: |-
    PROVIDER=memory
    PROVIDER_CONFIG=data/sessions

A block of external redis host can be added to values.yaml file for such scenarios for both database and redis which will make this very easy for the users.
i.e from the link

externalRedis:
  enabled: false
  host: ""
  port: 6379
I run into same issue when wanted to use external redis instead of the one provided. I did read the docs and after trying multiple configs i got it to work without redis. The point @smolinari is making that there are improvements which can be made to the chart for such scenarios and we are happy to contribute. Considering a fairly new user of gittea some guidance in this regard is required to make such improvements. If you disable redis from values.yaml file the chart still includes it as provider, by default the values should be changed to memory for sessions config. 1 To reproduce just disable redis and render the template of chart. ``` helm template gitea . | grep -i redis PROVIDER=redis ``` `config.yaml` ```yaml session: |- PROVIDER=redis PROVIDER_CONFIG= ``` This results in following error when the pod starts ```bash 2023/10/17 10:33:48 cmd/web.go:212:func1() [F] PANIC: dial tcp 127.0.0.1:6379: connect: connection refused ``` To fix this, if redis is disabled and no external host is configured the following should be the default values ```yaml session: |- PROVIDER=memory PROVIDER_CONFIG=data/sessions ``` A block of external redis host can be added to `values.yaml` file for such scenarios for both database and redis which will make this very easy for the users. i.e from the link ```yaml externalRedis: enabled: false host: "" port: 6379 ```
pat-s commented 2023-10-17 13:40:41 +00:00
Member
Copy Link

If you disable redis from values.yaml file the chart still includes it as provider, by default the values should be changed to memory for sessions config.

This is well known and tracked in #356

A block of external redis host can be added to values.yaml file for such scenarios for both database and redis which will make this very easy for the users.
i.e from the link

We won't do this and this won't help. Both sections would aim to modify the same internal gitea settings and just conflict. Besides, there's no need for it as it doesn't matter whether the connection is internal (chart) or external - all it matters is a proper config if things deviate from the default chart config.

> If you disable redis from values.yaml file the chart still includes it as provider, by default the values should be changed to memory for sessions config. This is well known and tracked in #356 > A block of external redis host can be added to values.yaml file for such scenarios for both database and redis which will make this very easy for the users. i.e from the link We won't do this and this won't help. Both sections would aim to modify the same internal gitea settings and just conflict. Besides, there's no need for it as it doesn't matter whether the connection is internal (chart) or external - all it matters is a proper config if things deviate from the default chart config.
kha7iq commented 2023-10-17 13:56:40 +00:00
Copy Link

We won't do this and this won't help. Both sections would aim to modify the same internal gitea settings and just conflict. Besides, there's no need for it as it doesn't matter whether the connection is internal (chart) or external - all it matters is a proper config if things deviate from the default chart config.

I guess there is no point discussing this further, i genuinely don't understand how it will create conflict when both are trying to change the same gitea settings, there are countless charts i have created and using my self as well where you modify a certain setting based on the arguments in values file.
if enabled do this otherwise do something else

In any case thank you for the response

> We won't do this and this won't help. Both sections would aim to modify the same internal gitea settings and just conflict. Besides, there's no need for it as it doesn't matter whether the connection is internal (chart) or external - all it matters is a proper config if things deviate from the default chart config. > > I guess there is no point discussing this further, i genuinely don't understand how it will create conflict when both are trying to change the same gitea settings, there are countless charts i have created and using my self as well where you modify a certain setting based on the arguments in values file. _if enabled do this otherwise do something else_ In any case thank you for the response
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
has
backport

  
in progress

   
invalid
  
kind
breaking

  
kind
bug

  
kind
build

  
kind
dependency

  
kind
deployment

  
kind
docs

  
kind
enhancement

  
kind
feature

  
kind
lint

  
kind
proposal

  
kind
question

  
kind
refactor

  
kind
security

  
kind
testing

  
kind
translation

  
kind
ui

  
need
backport

  
priority
critical

  
priority
low

  
priority
maybe

  
priority
medium

  
reviewed
duplicate

  
reviewed
invalid

  
reviewed
wontfix

  
skip-changelog
  
status
blocked

  
status
needs-feedback

  
status
needs-reviews

  
status
wip

  
upstream
gitea

  
upstream
other

No Label
has
backport
in progress
invalid
kind
breaking
kind
bug
kind
build
kind
dependency
kind
deployment
kind
docs
kind
enhancement
kind
feature
kind
lint
kind
proposal
kind
question
kind
refactor
kind
security
kind
testing
kind
translation
kind
ui
need
backport
priority
critical
priority
low
priority
maybe
priority
medium
reviewed
duplicate
reviewed
invalid
reviewed
wontfix
skip-changelog
status
blocked
status
needs-feedback
status
needs-reviews
status
wip
upstream
gitea
upstream
other
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/helm-chart#489
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?