fix(cli): inject version into Go binary via ldflags#5313
Merged
Conversation
The legacy CLI shell forwards most commands to the bundled `supabase-go` binary, whose upgrade banner reports the currently installed version from `utils.Version` — a string assigned via `-ldflags -X` at compile time. The Bun build script was missing that injection, so every release shipped a Go binary with `utils.Version=""`, producing: A new version of Supabase CLI is available: v2.100.1 (currently installed v) and triggering the upgrade prompt on every invocation (semver.Compare treats the empty string as less than any valid version). Restore the `-X github.com/supabase/cli/internal/utils.Version=...` ldflag in `apps/cli/scripts/build.ts` so the npm version is baked into the Go binary at build time, matching the prior `.goreleaser.yml` behavior. Fixes #5308
avallete
approved these changes
May 20, 2026
Coly010
added a commit
that referenced
this pull request
May 20, 2026
…5314) ## What changed - `apps/cli/scripts/build.ts` — `buildGoTarget` now reads `SENTRY_DSN`, `POSTHOG_API_KEY`, and `POSTHOG_ENDPOINT` from `process.env` and appends a matching `-X github.com/supabase/cli/internal/utils.{SentryDsn,PostHogAPIKey,PostHogEndpoint}=...` segment to the Go linker flags when the value is set. - `.github/workflows/release-shared.yml` — the `build` job's `env:` block now exposes the three repo secrets so release builds get the values populated. ## Why Companion fix to #5313. The legacy CLI shell forwards telemetry through the bundled `supabase-go` binary, which reads its Sentry DSN and PostHog credentials from `-ldflags -X`-injected vars. The bun build script only injected `utils.Version`, so every release after the goreleaser → bun-script migration shipped with empty credentials: - `apps/cli-go/internal/telemetry/service.go:61` constructs the PostHog client with an empty key and host → the client returns a no-op (`internal/telemetry/client.go:32-56`). - `apps/cli-go/cmd/root.go:78` initializes Sentry with an empty DSN → no-op client. PostHog event flow stopped on 2026-05-18 with v2.98.2 (the last build produced by the prior pipeline). Restoring these injections matches the historical `.goreleaser.yml` behavior using the same three repo secrets, which already exist (`gh secret list --repo supabase/cli`). ## Reviewer notes - The TS shells don't need build-time injection. The `next` shell carries hardcoded PostHog defaults with runtime env overrides (`apps/cli/src/next/config/cli-config.layer.ts`), and `legacy` delegates everything to the Go binary via `LegacyGoProxy`. - The env vars are conditionally appended in the build script, so local builds and PR smoke builds (which don't expose the secrets) produce binaries with empty telemetry credentials and the existing safe no-op runtime behavior — no leakage and no test breakage. - Verified locally: `SENTRY_DSN=… POSTHOG_API_KEY=… POSTHOG_ENDPOINT=… pnpm exec bun apps/cli/scripts/build.ts --version 2.100.1 --shell legacy` produces a `supabase-go` whose `strings` output contains the three sentinel values; running the same command with the envs unset produces a binary with none of them. Fixes CLI-1506 Co-authored-by: Julien Goux <hi@jgoux.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Pass the npm release version into the bundled
supabase-gobinary via-ldflags -X github.com/supabase/cli/internal/utils.Version=...inapps/cli/scripts/build.ts.Why
The legacy CLI shell forwards most commands to the bundled Go binary. That binary's upgrade banner reports the currently installed version from
utils.Version, which is a string assigned at compile time via-ldflags -X. The Bun build script was only passing-s -w, so every release shipped a Go binary withutils.Version="". The user-visible symptom was:semver.Comparetreats the empty string as less than any valid version, so the upgrade prompt fired on every invocation regardless of the installed version.The
-Xinjection had been part of the prior.goreleaser.ymlbuild but was dropped during the goreleaser → Bun build-script migration. The bug only became user-visible once thebetaandstablechannels started buildingshell=legacyagain, which is what bundlessupabase-gointo the release tarballs.Reviewer notes
v) is the right form to inject —apps/cli-go/cmd/root.go:199constructs"v"+utils.Versionfor the comparison and other callsites use the raw value.-Xinjections forutils.SentryDsn,utils.PostHogAPIKey, andutils.PostHogEndpoint. The Go binary in current releases runs without Sentry/PostHog credentials. Out of scope for this PR — worth a separate ticket so the secret-handling and CI-secret wiring can be designed deliberately.Fixes #5308