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

Default image tags to .Charts.AppVersion #697

Open
nschrader opened this issue Dec 7, 2022 · 5 comments
Open

Default image tags to .Charts.AppVersion #697

nschrader opened this issue Dec 7, 2022 · 5 comments

Comments

@nschrader
Copy link

Hey,

A lot of Helm charts out there fall back to the appVersion in Chart.yaml if no tag is given for the Docker image, so that you can update it dynamically using helm package mychart --app-version 1.2.3.

I took a look at _helpers.tpl, but it looks very intricate and no chance of getting a hold of .Charts inside the define "kong.getRepoTag". For now, I am sed'ing the tag to my chart version before helm package. Could there be a nicer solution?

Cheers

@rainest
Copy link
Contributor

rainest commented Dec 8, 2022

Do you think there'd be a need for it? We do populate tags in the default values.yaml, and Helm will use those if you don't provide any value of your own.

@nschrader
Copy link
Author

It'd be for great help in a CI pipeline. We use custom Docker images and helm package mychart --app-version 1.2.3 makes the chart use the version (containing a git sha) build in a previous CI step.

@rainest
Copy link
Contributor

rainest commented Dec 8, 2022

What would be your end workflow? Would you need to remove the existing default? We'd prefer to keep the defaults in values.yaml. We can't rely entirely on appVersion--there's only one of it, we need to set versions for multiple images, and would like to have both defaults in the same location. Normally those defaults are always set if there's no user-provided value, but I think you can --set image.tag=null to forcibly clear it.

We can probably get rid of kong.getRepoTag. The unifiedRepoTag it lets override the repository/tag is something we added to satisfy an external requirement from another product. That product is now deprecated and won't need support from new chart versions. We'd need to first add a deprecation warning, but could eventually remove support for unifiedRepoTag.

With that removed, you could use a template with access to the top-level values array for the Kong images.

FWIW, you can provide otherwise out of scope variables to a template by constructing a new dict, merging your desired scope into it, and then setting other keys to Helm built-in values or whatever, similar to how we populate inputs for Service templates. The special $ variable should also allow out-of-scope access per the Helm docs, but IIRC it doesn't quite work for some reason.

@nschrader
Copy link
Author

--set image.tag was actually a good hint. Our use case is basically what people have been describing here: helm/helm#3141.

Maybe we're not talking about the same "default" values. I wanted to point out that in Helm Charts generated with helm create mychart, there is this line in deployment.yaml:

image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"

So if you don't put image.tag into values.yaml, you can effectively set the tag when packaging with --app-version.

@rainest
Copy link
Contributor

rainest commented Dec 9, 2022

User-supplied values work as overlays: when you helm install myname kong/kong -f myvalues.yaml, Helm effectively starts with the chart's default values.yaml (https://github.com/Kong/charts/blob/main/charts/kong/values.yaml) and replaces values there with values from your values.yaml, leaving any values you haven't explicitly set untouched. Thus, if you do not set image.tag yourself, you get the image.tag value in the default:

11:07:55-0800 esenin $ helm template bread kong/kong --set image.tag=3.3.3 | grep kong:
        image: kong:3.3.3
        image: kong:3.3.3
11:08:01-0800 esenin $ helm template bread kong/kong | grep kong: 
        image: kong:3.0
        image: kong:3.0

In the templates, {{ .Values.image.tag | default .Chart.AppVersion }} will use the default only if image.tag is empty, but because of the value in the default values.yaml, it never is. You don't get the default template value even if you haven't set the value:

11:18:21-0800 esenin $ git diff
diff --git a/charts/kong/Chart.yaml b/charts/kong/Chart.yaml
index 476339a..c329773 100644
--- a/charts/kong/Chart.yaml
+++ b/charts/kong/Chart.yaml
@@ -12,7 +12,7 @@ name: kong
 sources:
 - https://github.com/Kong/charts/tree/main/charts/kong
 version: 2.13.1
-appVersion: "3.0"
+appVersion: "4.0"
 dependencies:
 - name: postgresql
   version: 11.1.15
diff --git a/charts/kong/templates/deployment.yaml b/charts/kong/templates/deployment.yaml
index e162da1..df01ec3 100644
--- a/charts/kong/templates/deployment.yaml
+++ b/charts/kong/templates/deployment.yaml
@@ -125,7 +125,7 @@ spec:
       {{- end }}
       {{- if .Values.deployment.kong.enabled }}
       - name: "proxy"
-        image: {{ include "kong.getRepoTag" .Values.image }}
+        image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
         imagePullPolicy: {{ .Values.image.pullPolicy }}
         securityContext:
         {{ toYaml .Values.containerSecurityContext | nindent 10 }}
11:18:23-0800 esenin $ helm template bread /tmp/symkong 2>/dev/null | grep kong:                     
        image: kong:3.0
        image: "kong:3.0"

Using --set image.tag=null didn't work for be because of template errors, though it looks like that's because I only made a basic test change and didn't rewrite all the other templates that rely on that value.

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

No branches or pull requests

2 participants