Open Jay-Madden opened 1 year ago
Hi, can you please share more details on your use case?
If I got you right, Helm already does similar stuff for labels. There is a named template in _helpers.tpl
{{/*
Common labels
*/}}
{{- define "app.labels" -}}
helm.sh/chart: {{ include "app.chart" . }}
{{ include "app.selectorLabels" . }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}
And then these labels are added to all chart manifests:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "app.fullname" . }}-myapp
labels:
app: myapp
{{- include "app.labels" . | nindent 4 }}
Which results to:
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-app-myapp
labels:
app: myapp
helm.sh/chart: app-0.1.0
app.kubernetes.io/name: app
app.kubernetes.io/instance: test
app.kubernetes.io/version: "0.1.0"
app.kubernetes.io/managed-by: Helm
You can modify app.labels
to add some env-specific labels or create a similar template for annotations.
I am not fully aware of your use case but it is not very common to provide the same set of annotations to all chart manifests.
PS
Recently we added a processor for ServiceAccount annotations in #115.
So if the desired behavior is to extract annotation from source manifests into values.yaml, you can use WithAnnotations
option for other resource processors (not only ServiceAccount) - see https://github.com/arttor/helmify/blob/main/pkg/processor/rbac/serviceaccount.go#L30.
SericeAccount annotations processor was added to the main branch because it is a very common use case for cloud environments.
I think the original requirement was to introduce into values.yaml
similar variables:
podAnnotations: {}
podLabels: {}
which are extra added after those annotations/labels provided by built-in named templates. I.e., same thing as what allows an empty helm chart create via helm create
:
template:
metadata:
...
labels:
{{- include "app.labels" . | nindent 8 }}
{{- with .Values.podLabels }} <--------
{{- toYaml . | nindent 8 }}
{{- end }}
Updating app.labels
template is valid solution as long as you use helmify to generate something for the start and craft/finish it manually. We use helmify fully automatically to always process source and generate final chart, so these extra modifications would need to be done via extra patching on every run.
@vholer we use helmify
in a similar fashion as "chartgen" and would prefer this to be programmatically supported. We need consumers of our operator charts to be able to specify their own custom labels without having to modify chart source.
I like the idea of this being top-level values podLabels
and podAnnotations
. I can try to take a stab at this as a contribution, similar to what was done with ServiceAccount
annotations as @arttor mentioned.
Got something draft in #139 , will hopefully add annotations soon.
any progress on this?
We have a need to add specific annotations to helm chart releases per environment. Adding a way to set those at helm install time would be very helpful.
If this is a useful feature i would be willing to contribute it myself if desired