Vouch Request
Why do you want to contribute?
I'm Thullyo Cunha, platform engineer at Meistrari (https://tela.com). We self-host Trigger.dev v4 on EKS for our internal task platform. While bringing it up against an external ClickHouse + clickhouse.external.existingSecret (the officially recommended path for not committing secrets to values.yaml), we hit a bug that blocks the webapp on first start:
goose run: parse "http://default:${CLICKHOUSE_PASSWORD}@<host>:8123?secure=false": net/url: invalid userinfo
Root cause: hosting/k8s/helm/templates/_helpers.tpl (v4.0.5, also on main) renders CLICKHOUSE_URL with a shell-style literal ${CLICKHOUSE_PASSWORD} expecting bash expansion. But docker/scripts/entrypoint.sh does export GOOSE_DBSTRING="$CLICKHOUSE_URL" — single-pass POSIX sh substitution, so the inner ${...} survives as literal text and goose rejects the URL.
Fix: switch the two helpers (trigger-v4.clickhouse.url and trigger-v4.clickhouse.replication.url, external+existingSecret branch) from shell-style ${CLICKHOUSE_PASSWORD} to Kubernetes' $(CLICKHOUSE_PASSWORD). Kubelet substitutes $(VAR) at container-creation time from earlier env entries, and the chart already declares CLICKHOUSE_PASSWORD from the secret right before CLICKHOUSE_URL — so the URL reaches the entrypoint with the real password already inlined. No entrypoint change, no image change, minimal blast radius, plain-password branch untouched.
I've verified the fix end-to-end in our test EKS cluster (webapp boots, goose applies all 6 migrations, runtime ClickHouse client connects). Branch ready at https://github.com/ThullyoCunha/trigger.dev/tree/fix/clickhouse-external-url-kubelet-expansion — would appreciate a vouch so I can open the PR.
I'd also be glad to add a short README/values.yaml note about the URL-userinfo-safety caveat on CLICKHOUSE_PASSWORD (kubelet substitutes verbatim without percent-encoding) as part of the same PR if that's useful.
Prior contributions or relevant experience
Happy to answer any questions or split the patch further if preferred.
Vouch Request
Why do you want to contribute?
I'm Thullyo Cunha, platform engineer at Meistrari (https://tela.com). We self-host Trigger.dev v4 on EKS for our internal task platform. While bringing it up against an external ClickHouse +
clickhouse.external.existingSecret(the officially recommended path for not committing secrets to values.yaml), we hit a bug that blocks the webapp on first start:Root cause:
hosting/k8s/helm/templates/_helpers.tpl(v4.0.5, also onmain) rendersCLICKHOUSE_URLwith a shell-style literal${CLICKHOUSE_PASSWORD}expecting bash expansion. Butdocker/scripts/entrypoint.shdoesexport GOOSE_DBSTRING="$CLICKHOUSE_URL"— single-pass POSIX sh substitution, so the inner${...}survives as literal text and goose rejects the URL.Fix: switch the two helpers (
trigger-v4.clickhouse.urlandtrigger-v4.clickhouse.replication.url, external+existingSecret branch) from shell-style${CLICKHOUSE_PASSWORD}to Kubernetes'$(CLICKHOUSE_PASSWORD). Kubelet substitutes$(VAR)at container-creation time from earlier env entries, and the chart already declaresCLICKHOUSE_PASSWORDfrom the secret right beforeCLICKHOUSE_URL— so the URL reaches the entrypoint with the real password already inlined. No entrypoint change, no image change, minimal blast radius, plain-password branch untouched.I've verified the fix end-to-end in our test EKS cluster (webapp boots, goose applies all 6 migrations, runtime ClickHouse client connects). Branch ready at https://github.com/ThullyoCunha/trigger.dev/tree/fix/clickhouse-external-url-kubelet-expansion — would appreciate a vouch so I can open the PR.
I'd also be glad to add a short README/values.yaml note about the URL-userinfo-safety caveat on
CLICKHOUSE_PASSWORD(kubelet substitutes verbatim without percent-encoding) as part of the same PR if that's useful.Prior contributions or relevant experience
Happy to answer any questions or split the patch further if preferred.