Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow specifying custom labels and annotations from values.yaml #119

Open
Jay-Madden opened this issue Aug 15, 2023 · 4 comments · May be fixed by #139
Open

Allow specifying custom labels and annotations from values.yaml #119

Jay-Madden opened this issue Aug 15, 2023 · 4 comments · May be fixed by #139

Comments

@Jay-Madden
Copy link

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

@arttor
Copy link
Owner

arttor commented Aug 15, 2023

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.

@vholer
Copy link

vholer commented Jan 17, 2024

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.

@onelapahead
Copy link
Contributor

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

@onelapahead
Copy link
Contributor

Got something draft in #139 , will hopefully add annotations soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants