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

envVars with object should quote environment variables #34

Open
maarten-blokker opened this issue Feb 5, 2024 · 1 comment
Open

envVars with object should quote environment variables #34

maarten-blokker opened this issue Feb 5, 2024 · 1 comment

Comments

@maarten-blokker
Copy link

Hello, i've been using helmet for a little while and it makes creating a Helm chart quite a bit easier for me, thanks for creating this project!

In a recent task, I needed to define a chart with environment variables, including a port and a boolean value. Initially, Helmet used a list for envVars, which meant my custom envVars would override the predefined ones. However, with the update to version 0.11.0, Helmet now supports using a dictionary for envVars, allowing me to specify my variables in a values file without overriding the existing ones.

Unfortunately, I encountered a problem where the function fails to render environment variables as strings:

#values.yaml
image:
  repository: repo
envVars:
  SHOULD_BE_STRING: "true"
  SHOULD_BE_STRING_AS_WELL: "43"

this renders the following output:

...
    spec:
      restartPolicy: Always
      containers:
        - name: test
          image: docker.io/repo:latest
          imagePullPolicy: Always
          env:            
            - name: SHOULD_BE_STRING
              value: true
            - name: SHOULD_BE_STRING_AS_WELL
              value: 43
...

The spec.template.spec.containers.env.value should be a string, but the output incorrectly presents these values as a boolean and an integer (unquoted values).

@bittrance
Copy link

There is another probably common occasion where this is a problem, namely where you use YAML anchors. The obvious example is with port numbers which must be integers. E.g.:

ports:
  - name: api
    containerPort: &containerPort 8080

envVars:
  - name: BIND_PORT
    value: *containerPort

Kubernetes will fail this manifest because containerPort must be an int and env var must be a string. The linked PR would allow this.

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