Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
add ability to support free entry of environment variables for nango-…
…server (#10) This PR addresses [Allow Arbitrary Environment Variables to be set for nango-server](#9). I've attached a screenshot of a basicauth login below: <img width="1050" alt="nango-basicauth-login" src="https://github.com/user-attachments/assets/be457c83-1f5e-4237-bc82-4fb51ecebb54" /> Note that there are a _number_ of ways to support environment variables within helm charts - two options which I tested/considered are below: 1. Free-entry configuration - where a user would only provide an `env` value that renders valid YAML. This is rendered utilizing the following: ``` {{- if .Values.server.env }} {{- toYaml .Values.server.env | nindent 12 }} {{- end }} ``` 2. Iterative configuration (which is what I've seen used more frequently) - where a user provides a list composed of `name` and `value` or `valueFrom` fields which (I thought) offered a greater deal of validation (see "A Note on Iterative Configuration" below). # A Note on Iterative Configuration I was open to utilizing this as it was/is common within the kubernetes/helm community and a popular suggestion on AI sites. What I discovered was this was _worse_ than simply accepting "free entry" as it _modified_ the YAML but did not reject it - an example is below: ``` {{- range .Values.server.env }} - name: {{ .name }} {{- if .value }} value: {{ .value | quote }} {{- else if .valueFrom }} valueFrom: {{ toYaml .valueFrom | nindent 16 }} {{- end }} {{- end }} ``` When given: ``` env: - namea: FLAG_AUTH_ENABLED value: "false" - name: NANGO_DASHBOARD_USERNAME value: nango - name: NANGO_DASHBOARD_PASSWORD valueFroma: secretKeyRef: name: nango-secrets key: nango-dashboard-password ``` Would render: ``` - name: value: "false" - name: NANGO_DASHBOARD_USERNAME value: "nango" - name: NANGO_DASHBOARD_PASSWORD ```
- Loading branch information