You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the templates in /installer/third_party/charts/docker-registry, the downloaded charts in docker-registry-1.11.0.tgz don't specify the metadata.namespace: {{ .Release.Namespace }} property. This means that the generated charts won't get installed to the same namespace if the namespace is not default
Steps to reproduce
Run gitpod-installer render -c /path/to/config --namespace custom-nsp and search for the docker-registry components
Workspace affected
No response
Expected behavior
No response
Example repository
No response
Anything else?
This can be fixed in the following ways:
Import the files from the chart rather than using them as a Helm dependency. This is simpler, but has the added risk of this change being forgotten if we ever update the dependency
mrsimonemms
changed the title
Installer in-cluster docker registry doesn't support non-default namespace
[Installer]: In-cluster docker registry doesn't support non-default namespace
Dec 12, 2021
Bug description
In the templates in /installer/third_party/charts/docker-registry, the downloaded charts in
docker-registry-1.11.0.tgz
don't specify themetadata.namespace: {{ .Release.Namespace }}
property. This means that the generated charts won't get installed to the same namespace if the namespace is notdefault
Steps to reproduce
Run
gitpod-installer render -c /path/to/config --namespace custom-nsp
and search for thedocker-registry
componentsWorkspace affected
No response
Expected behavior
No response
Example repository
No response
Anything else?
This can be fixed in the following ways:
Import the files from the chart rather than using them as a Helm dependency. This is simpler, but has the added risk of this change being forgotten if we ever update the dependencypost-process the generated YAML in installer/pkg/components/docker-registry/helm.go. It's potentially a dirtier solution, but means we can still use the third party dependencyThe text was updated successfully, but these errors were encountered: