Skip to content

fix: production URL + browser fallback, remove unused staging infra#6

Merged
diogocabral merged 2 commits into
mainfrom
chore/staging-cleanup-and-url-fix
May 26, 2026
Merged

fix: production URL + browser fallback, remove unused staging infra#6
diogocabral merged 2 commits into
mainfrom
chore/staging-cleanup-and-url-fix

Conversation

@diogocabral
Copy link
Copy Markdown
Collaborator

Summary

Two related cleanups triggered by manually testing the freshly-built CLI binary against the real server, before flipping the repo public.

Commit 1 — fix: correct default server URL and always surface OAuth URL

  • Wrong default URL. DefaultServerURL was a placeholder (https://searchlight.io) that never resolved to a real deploy. The actual production host is https://searchlight.headline.com. Fixed the constant + all docs/tests that referenced the bogus URL.
  • OAuth URL fallback. internal/oauth/flow.go only printed the authorize URL when browser.OpenURL returned an error. On WSL (and headless containers / remote SSH sessions) OpenURL frequently returns nil while nothing actually opens, leaving the user stuck at a blank prompt. The URL is now printed to stderr unconditionally so manual paste is always possible.
  • .gitignore updated so cross-compiled searchlight.exe is covered alongside searchlight.

Commit 2 — chore: remove unused staging infrastructure

There is no staging deploy of the Searchlight server. The CLI was carrying a parallel staging configuration path (separate stagingClientID ldflag, env-var-driven routing in config.Load, a STAGING_CID Makefile variable, a SEARCHLIGHT_STAGING_CLIENT_ID GitHub secret reference, and matching test) that has never pointed at anything real.

Removed:

  • stagingClientID variable + the strings.Contains(server, "staging") branch in config.Load()
  • TestLoad_SelectsStagingClientID and the staging-related cleanup in surrounding tests
  • stagingClientID ldflag from .goreleaser.yaml
  • SEARCHLIGHT_STAGING_CLIENT_ID env injected into the GoReleaser workflow step
  • Staging ldflag from the CI smoke build
  • STAGING_CID variable from the Makefile
  • "register two OAuth apps" → "register one" in CLAUDE.md + README.md, plus matching tweaks in the file-purpose table and pre-release setup checklist

The SEARCHLIGHT_STAGING_CLIENT_ID GitHub secret itself can be deleted via gh secret delete SEARCHLIGHT_STAGING_CLIENT_ID --repo headlinevc/searchlight-cli — left out of this PR because secret state is owned by the repo, not the codebase.

Test plan

  • go test -race -cover ./... — all packages pass; config coverage 81.2% (above 80% floor)
  • make build PROD_CID=<real-uuid> — produces working Linux binary
  • GOOS=windows GOARCH=amd64 go build — produces working Windows binary
  • ./searchlight version --pretty shows server_url: "https://searchlight.headline.com"
  • Manual auth login round-trip against production succeeded (verified separately)
  • CI: vet, test (-race), golangci-lint, gosec, smoke build all green
  • Once merged, release-please PR chore(main): release 0.2.0 #5 (currently proposing v0.2.0) updates to include these commits

🤖 Generated with Claude Code

diogocabral and others added 2 commits May 26, 2026 15:08
Three small fixes triggered by manual testing of the freshly-rebuilt binary:

- DefaultServerURL was a placeholder (searchlight.io) that never existed —
  there is no production deploy at that hostname. Switched to
  searchlight.headline.com and updated all docs/tests that referenced the
  bogus URL. Removed staging URL examples since there is no staging deploy.
- internal/oauth/flow.go now always prints the authorize URL to stderr
  before attempting browser.OpenURL. On WSL (and headless containers /
  remote SSH sessions) OpenURL frequently returns nil even when nothing
  opens, leaving the user staring at a blank prompt; printing the URL
  unconditionally lets them paste it manually.
- Added /searchlight.exe to .gitignore so the cross-compiled Windows
  binary doesn't escape the existing /searchlight rule.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There is no staging deploy of the Searchlight server — only production.
The CLI was carrying a parallel staging configuration path (separate
client_id ldflag, env-var-driven routing in config.Load, a STAGING_CID
Makefile variable, a SEARCHLIGHT_STAGING_CLIENT_ID GitHub secret reference,
and matching test) that has never pointed at anything real.

Removed everything staging-specific:

- internal/config/config.go: dropped the stagingClientID variable and the
  staging/localhost branch in Load(); the baked-in client_id is now just
  prodClientID, used unconditionally when SEARCHLIGHT_CLIENT_ID is unset.
- internal/config/config_test.go: removed TestLoad_SelectsStagingClientID,
  simplified the surrounding tests that backed up both client_id variables.
- .goreleaser.yaml: removed the stagingClientID ldflag.
- .github/workflows/release-please.yml: dropped the
  SEARCHLIGHT_STAGING_CLIENT_ID env var injected into the GoReleaser step.
- .github/workflows/ci.yml: removed the staging ldflag from the smoke build.
- Makefile: dropped the STAGING_CID variable from the LDFLAGS recipe.
- CLAUDE.md, README.md: collapsed the "register two OAuth apps" sections
  into a single production-only application, removed the SEARCHLIGHT_
  STAGING_CLIENT_ID mention from the pre-release setup checklist, and
  updated the file-purpose table + verification checklist accordingly.

Tests still pass (config coverage 81.2%, above the 80% floor) and the
smoke build still produces a working binary. Follow-up: the
SEARCHLIGHT_STAGING_CLIENT_ID GitHub secret can now be deleted with
`gh secret delete SEARCHLIGHT_STAGING_CLIENT_ID` — that's outside this
commit since secret state is owned by the repo, not the codebase.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@gitvelocity-reviewer
Copy link
Copy Markdown

📊 Code Quality Score: 14/100

Base Score 35 × ESF 0.4 = 14

Category Score Factors
🔭 Scope 8/20 9 files touched across config, CI, build tooling, docs, tests, AI memory file; cross-cutting staging removal; no new APIs; deletions/simplifications
🏗️ Architecture 6/20 Removes conditional dispatch in config.go; simplifies config loading path; no new patterns; complexity reduction rewarded
⚙️ Implementation 5/20 Mostly deletions and simplifications; small OAuth UX improvement (always print URL); no complex algorithms
⚠️ Risk 6/20 Removes staging OAuth support (breaking for staging users); default URL change is behavioral; no feature flag; relatively easy to revert
✅ Quality 9/15 Tests updated appropriately; CLAUDE.md in sync; one stale docs/agents.md line; good inline comment for browser URL change; README updated
🔒 Perf / Security 1/5 No security concerns; slight attack surface reduction from removing staging code path

Scored by GitVelocity · How are scores calculated?

@diogocabral diogocabral merged commit c31f8bb into main May 26, 2026
4 checks passed
@gitvelocity-reviewer
Copy link
Copy Markdown

📊 Code Quality Score: 13/100

33 × 0.4 (Small ESF) = 13.2 → 13

Category Score Factors
🔭 Scope 8/20 9 files touched across build tooling, Go source, CI/CD, docs; single subsystem (environment config); clean removal with no new APIs or endpoints
🏗️ Architecture 6/20 Removes conditional URL-based client ID selection; simplifies from dual-environment to single-environment model; minor architectural improvement through reduction
⚙️ Implementation 5/20 Simple variable removal and switch statement deletion in config.go; OAuth UX fix (always print URL) is small but thoughtful with good rationale comment for WSL/headless environments
⚠️ Risk 4/20 Low-risk removal/simplification; default URL change from searchlight.io to searchlight.headline.com is a behavioral change for existing users; easily reversible
✅ Quality 9/15 Tests updated to match new behavior (removed staging-specific tests, consolidated); CLAUDE.md AI artifact kept in sync with code changes; good inline comment explaining OAuth UX rationale; no new tests for OAuth flow change
🔒 Perf / Security 1/5 No specific performance or security work; baseline framework security maintained

Scored by GitVelocity · How are scores calculated?

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.

1 participant