Skip to content

ci: pass POSTHOG_API_KEY through to release builds#96

Merged
8bitAlex merged 1 commit into
mainfrom
ci/pass-posthog-key-to-release-builds
May 15, 2026
Merged

ci: pass POSTHOG_API_KEY through to release builds#96
8bitAlex merged 1 commit into
mainfrom
ci/pass-posthog-key-to-release-builds

Conversation

@8bitAlex
Copy link
Copy Markdown
Owner

Summary

Caught during the v1.0 release-readiness check: both .goreleaser.yaml and .goreleaser.preview.yaml inject POSTHOG_API_KEY via -X ldflag into src/internal/telemetry.APIKey — but the deploy and preview workflows weren't passing the secret into the GoReleaser action's env: block.

Result before this PR: every released binary had APIKey=\"\" baked in, telemetry was silent dead code for everyone but dev builds (which never had a key anyway), and no opt-in user could fire events even if they tried. Confirmed live by checking the workflow files against the goreleaser configs.

Confirmed secret is set: POSTHOG_API_KEY is configured as a repo-level secret per your check.

Change

Adds POSTHOG_API_KEY: ${{ secrets.POSTHOG_API_KEY }} to the GoReleaser step's env: block in both .github/workflows/deploy.yml (stable channel) and .github/workflows/preview.yml (preview channel). Same shape as the existing GITHUB_TOKEN / HOMEBREW_TOKEN passthroughs.

Validation

  • The ldflag pattern in both goreleaser configs already uses envOrDefault \"POSTHOG_API_KEY\" \"\", so missing-secret tolerance is preserved (dev / branch builds without the secret still produce a working empty-APIKey binary that no-ops telemetry).
  • Existing docs.yml already wires the secret correctly — used as the reference pattern.
  • No Go code changes; no test changes needed. The ldflag's effect is invisible to unit tests (they stub APIKey directly).

Why this matters for v1.0

This needs to land before the v1.0.0 tag. Otherwise the first "real" telemetry-capable binary that ships will silently never send anything — opted-in users contribute zero signal, and the project gets a free "opt-out rate looks 100%" data point that's actually a CI bug.

🤖 Generated with Claude Code

Both .goreleaser.yaml and .goreleaser.preview.yaml inject
POSTHOG_API_KEY via -X ldflag into src/internal/telemetry.APIKey,
but the deploy and preview workflows weren't passing the secret
into the GoReleaser action's env block. Result: every released
binary had APIKey="" baked in, telemetry was silent dead code for
everyone but dev builds (which never had a key anyway), and no
opt-in user could fire events even if they tried.

Wires POSTHOG_API_KEY into both workflows' env blocks so the
ldflag resolves to the actual secret at release time. The
mechanism mirrors the existing GITHUB_TOKEN / HOMEBREW_TOKEN
passthrough — same shape, same secret-management story.

Docs.yml already references the secret correctly for the site
build, so the secret was always available; only the release
workflows were missing the wiring.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings May 15, 2026 03:06
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Wires the POSTHOG_API_KEY repository secret into the GoReleaser steps for both the stable (deploy.yml) and preview (preview.yml) release workflows, so the -X ldflag in the goreleaser configs can bake the key into src/internal/telemetry.APIKey for shipped binaries.

Changes:

  • Add POSTHOG_API_KEY env passthrough to the GoReleaser step in deploy.yml.
  • Add the same passthrough in preview.yml, with explanatory comments in both files.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
.github/workflows/deploy.yml Passes POSTHOG_API_KEY secret into the GoReleaser release step for stable builds.
.github/workflows/preview.yml Passes POSTHOG_API_KEY secret into the GoReleaser release step for preview builds.

@codecov
Copy link
Copy Markdown

codecov Bot commented May 15, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.81%. Comparing base (b70e93c) to head (898c890).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #96      +/-   ##
==========================================
- Coverage   90.86%   90.81%   -0.05%     
==========================================
  Files          47       47              
  Lines        4063     4063              
==========================================
- Hits         3692     3690       -2     
- Misses        244      245       +1     
- Partials      127      128       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@8bitAlex
Copy link
Copy Markdown
Owner Author

Auto-review by meeseeks

Updates pushed: none
Copilot comments addressed: 0 of 0 — Copilot reviewed both files and generated no comments
Skipped: 0
Codecov patch: 100% (project 90.81%) — at-or-above project; codecov/patch is green ("All modified and coverable lines are covered by tests"). codecov/project is red on a 0.05% drift (90.86% → 90.81%, 2 fewer Hits / 1 more Miss / 1 more Partial across an unchanged 4063 lines), which is flake in unrelated Go tests — this PR only touches deploy.yml / preview.yml.
Other CI: green (build matrix, CodeQL, Analyze ×3, changed-files, build)

No action taken: workflow-only PR; no actionable Copilot feedback and patch coverage already ≥ project.

@8bitAlex 8bitAlex merged commit 54c851b into main May 15, 2026
16 of 17 checks passed
@8bitAlex 8bitAlex deleted the ci/pass-posthog-key-to-release-builds branch May 15, 2026 16:14
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

Successfully merging this pull request may close these issues.

2 participants