You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(helm): track the app release in appVersion, and enforce it
appVersion sat at v0.8.18 while the app shipped through v0.8.24 -- six
releases. Because the image tags default to Chart.AppVersion, a default
`helm install` deployed the older Sim, and regenerating images.yaml here
moved eleven lines, so the mirror inventory an air-gapped operator works
from named the wrong images too.
Publishing is what makes this serious. Cloning main got you whatever was
there; a published chart version is immutable, so every stale appVersion
would be frozen and installable forever.
It was bumped by hand and nothing checked it, which is why it drifted. The
publish job now refuses to publish when appVersion does not match the latest
GitHub release, comparing against the release API rather than a hardcoded
value so the check cannot go stale itself. Confirmed it fires on exactly the
drift that existed (v0.8.18 vs v0.8.24) and passes now that it is fixed.
Bumps appVersion to v0.8.24, regenerates images.yaml, and takes the chart to
1.9.5.
latest=$(gh api "repos/${GITHUB_REPOSITORY}/releases/latest" --jq .tag_name)
267
+
if [ -z "$latest" ]; then
268
+
echo "::error::Could not resolve the latest release; refusing to publish unverified."
269
+
exit 1
270
+
fi
271
+
if [ "$app_version" != "$latest" ]; then
272
+
echo "::error::Chart.yaml appVersion is ${app_version} but the latest release is ${latest}. Bump appVersion (and the chart version) so the chart does not publish an install pinned to an older Sim."
273
+
exit 1
274
+
fi
275
+
echo "appVersion ${app_version} matches the latest release."
276
+
252
277
# Chart versions are immutable once published: whoever pinned a version
253
278
# must keep resolving the same bytes forever. The PR gate above already
254
279
# forces a version bump on every chart change, so a version that is
Copy file name to clipboardExpand all lines: apps/docs/content/docs/platform/self-hosting/environment-variables.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -311,7 +311,7 @@ Setting the variable to an empty string does **not** remove it: the chart reads
311
311
Null the variable in every layer that sets it. If it appears in both `app.env` and `app.envDefaults`, nulling only the `app.env` entry lets the `envDefaults` value apply again and the limit stays in force. With External Secrets, also drop the key from `externalSecrets.remoteRefs.app`, which keeps syncing it independently. Confirm what the pod will actually receive before rolling out:
`null`deletion has no effect under `helm upgrade --reuse-values` — pass your full values with `-f`, or use `--reset-then-reuse-values` (Helm 3.14+). If you deploy with Argo CD, put the `null` in `valueFiles` or the `values` string rather than `valuesObject`, which strips nulls. On Docker Compose, delete the line from your `.env` file.
@@ -87,11 +87,11 @@ apply to the OCI artifact only.
87
87
Every published version is signed with Sigstore keyless signing and carries a SLSA build-provenance attestation. Both live in the registry alongside the chart, so they survive a mirror into an internal registry.
Discouraged for production — values land in `helm get values` output.
@@ -484,7 +484,7 @@ With the chart-managed Secret (the default), nulling a key the application canno
484
484
The common case is a free-tier cap inherited from a chart release older than the one that stopped presetting them, which shipped `FREE_TABLES_LIMIT: "3"` and `FREE_TABLE_ROWS_LIMIT: "1000"` under `app.envDefaults`. With billing disabled, Sim reads an unset limit as unlimited, so nulling these lifts the cap. Verify before rolling out:
0 commit comments