GitLab Chart issueshttps://gitlab.com/gitlab-org/charts/gitlab/-/issues2024-02-20T19:43:53Zhttps://gitlab.com/gitlab-org/charts/gitlab/-/issues/4907helm install with external-cert-manager-and-issuer-external pods complained s...2024-02-20T19:43:53Z李一凡helm install with external-cert-manager-and-issuer-external pods complained secret "gitlab-wildcard-tls-ca" not found<!--
NOTICE: This Issue tracker is for the GitLab Helm chart, not the GitLab Rails application.
Support: Please do not raise support issues for GitLab.com on this tracker. See https://about.gitlab.com/support/
-->
## Summary
When I in...<!--
NOTICE: This Issue tracker is for the GitLab Helm chart, not the GitLab Rails application.
Support: Please do not raise support issues for GitLab.com on this tracker. See https://about.gitlab.com/support/
-->
## Summary
When I install gitlab via helm following the documentations (https://docs.gitlab.com/charts/installation/tls.html#external-cert-manager-and-issuer-external and https://docs.gitlab.com/charts/charts/globals.html#globalingressconfigurecertmanager) using the external cert-manager and issuer, most pods were complaining MountVolume.SetUp failed for volume "custom-ca-certificates" : secret "gitlab- wildcard-tls-ca" not found error
## Steps to reproduce
(Please provide the steps to reproduce the issue)
## Configuration used
Here is part of my values.yaml configuration
```yaml
global:
hosts:
domain: xxx.xx
externalIP: 127.0.0.1
https: true
ingress:
class: nginx
configureCertmanager: false
annotations:
"kubernetes.io/tls-acme": true
"cert-manager.io/cluster-issuer": letsencrypt
gitlab:
webservice:
ingress:
tls:
secretName: gitlab-gitlab-tls
kas:
ingress:
tls:
secretName: gitlab-kas-tls
registry:
enabled: false
ingress:
tls:
secretName: gitlab-registry-tls
minio:
ingress:
tls:
secretName: gitlab-minio-tls
```
## Current behavior
(What you're experiencing happening)
## Expected behavior
(What you're expecting to happen)
## Versions
- Chart: 7.2.1
- Platform:
- Self-hosted: kubernetes in docker-desktop
- Kubernetes: (`1.27.2`)
- Client:
- Server:
- Helm: (`3.12.1`)
- Client:
- Server:
## Relevant logs
![屏幕截图_2023-07-31_190252](/uploads/049b85c237b0cafe66e18b1c2cf0552a/屏幕截图_2023-07-31_190252.png)
![屏幕截图_2023-07-31_190427](/uploads/b9bd5bc0342d50363a4f586fc6e379dd/屏幕截图_2023-07-31_190427.png)
(Please provide any relevate log snippets you have collected, using code blocks (```) to format)Next 1-3 releaseshttps://gitlab.com/gitlab-org/charts/gitlab/-/issues/4834Unable to deploy with no self signed certs2024-03-22T20:50:14ZNicolas GourdonUnable to deploy with no self signed certs<!--
NOTICE: This Issue tracker is for the GitLab Helm chart, not the GitLab Rails application.
Support: Please do not raise support issues for GitLab.com on this tracker. See https://about.gitlab.com/support/
-->
## Summary
While dep...<!--
NOTICE: This Issue tracker is for the GitLab Helm chart, not the GitLab Rails application.
Support: Please do not raise support issues for GitLab.com on this tracker. See https://about.gitlab.com/support/
-->
## Summary
While deploying in a new namespace, pods are waiting for the wildcard self signed cert secret which is not generated.
There has been [an update on the condition](https://gitlab.com/gitlab-org/charts/gitlab/-/blame/master/templates/shared-secrets/self-signed-cert-job.yml#L4) to create the self signed cert job but [the condition for mounting the secret](https://gitlab.com/gitlab-org/charts/gitlab/-/blame/master/templates/_certificates.tpl#L71) stayed the same.
## Steps to reproduce
Deploy in a new namespace with a configuration that does not define `global.ingress.tls` but does define `gitlab.webservice.ingress.tls.secretName` (same with another component)
## Configuration used
```yaml
global:
ingress:
enabled: true
configureCertmanager: false
gitlab:
webservice:
ingress:
enabled: true
tls:
secretName: gitlab-ingress-tls
certmanager:
install: false
nginx-ingress:
enabled: false
```
## Current behavior
The wildcard self signed cert is mounted on pods but not created by the self signed cert job.
## Expected behavior
The wildcard self signed cert should not be mounted on pods.
## Versions
- Chart: 6.11.9
- Platform:
- Self-hosted: Rancher RKE
- Kubernetes: (`kubectl version`)
- Client: 1.25
- Server: 1.24
- Helm: (`helm version`)
- Client: v3.11.2https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3107gitlab-toolbox-backup does not support group_saml omniauth provider2023-10-02T23:13:31ZLazare Olivrygitlab-toolbox-backup does not support group_saml omniauth provider## Summary
gitlab-toolbox-backup does not support group_saml omniauth provider : when a secret is defined and contains only `name: 'group-saml'` and is used in the omniauth providers list, gitlab-toolbox-backup crashes.
## Steps to rep...## Summary
gitlab-toolbox-backup does not support group_saml omniauth provider : when a secret is defined and contains only `name: 'group-saml'` and is used in the omniauth providers list, gitlab-toolbox-backup crashes.
## Steps to reproduce
1) Define the special omniauth provider "group_saml" that does require only `name: 'group-saml'` in the secret definition to activate the fonctionnality (source : https://docs.gitlab.com/ee/integration/saml.html#configuring-group-saml-on-a-self-managed-gitlab-instance )
2) apply the new config of the helm chart
3) gitlab works fine, gitlab UI does have the saml group feature, but the secret broke gitlab-toolbox-backup and we got this error (gitlab-saml-group is the name of the secret) :
/usr/lib/ruby/2.7.0/psych.rb:577:in `initialize': No such file or directory @ rb_sysopen - /etc/gitlab/omniauth/gitlab-saml-group/provider (Errno::ENOENT)
And this is not because I broke something : there is no provider section in this secret, according to the docs, and the group saml feature works fine in the UI. I guess that gitlab-toolbox-backup tries to access everything but the presence of the "provider" section seems hardcoded ?
## Configuration used
(I deleted the config of our others saml providers, because it did not seems to be the issue.
```yaml
omniauth:
enabled: true
providers:
- secret: gitlab-saml-group
# kubernetes secret "gitlab-saml-group":
---
name: 'group-saml'
```
## Current behavior
gitlab works fine, gitlab UI does have the saml group feature, but the secret broke gitlab-toolbox-backup and we got this error (gitlab-saml-group is the name of the secret) :
/usr/lib/ruby/2.7.0/psych.rb:577:in `initialize': No such file or directory @ rb_sysopen - /etc/gitlab/omniauth/gitlab-saml-group/provider (Errno::ENOENT)
## Expected behavior
gitlab-toolbox-backup shouldn't fail in trying to access tries to access /etc/gitlab/omniauth/gitlab-saml-group/provider
## Versions
- Chart: 5.6.0
- Platform:
- Cloud: EKS
- Kubernetes: (`kubectl version`)
- Client: v1.22.4
- Server: v1.20.11-eks-f17b81
- Helm: (`helm version`)
- Client: v3.6.3
- Server: v3.6.3
## Relevant logs
gitlab-toolbox-backup logs :
```
/usr/lib/ruby/2.7.0/psych.rb:577:in `initialize': No such file or directory @ rb_sysopen - /etc/gitlab/omniauth/gitlab-saml-group/provider (Errno::ENOENT)
```https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1768Update minio chart and version to newer release2023-08-28T16:11:11ZDJ Mountneydj@gitlab.comUpdate minio chart and version to newer release## Summary
Our minio version is from 2017, we should get it updated to a newer version.
A MR has been started here, but it appears that chart updates are needed to proceed: https://gitlab.com/gitlab-org/charts/gitlab/merge_requests/1074## Summary
Our minio version is from 2017, we should get it updated to a newer version.
A MR has been started here, but it appears that chart updates are needed to proceed: https://gitlab.com/gitlab-org/charts/gitlab/merge_requests/1074https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1685Add Settings for Feature Flags Unleash Client2021-12-31T09:47:58ZBalasankar 'Balu' CAdd Settings for Feature Flags Unleash ClientExpose the settings added in https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/3681 in ChartsExpose the settings added in https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/3681 in Charts