fix(deploy): auto-pick the only project when --project is missing#22
Conversation
Telemetry shows "No project specified" on `dhq deploy` is a steady small bucket (19 hits / 30d, mix of humans and a claude-code agent), and 4/19 came from current v0.18.2. The deploy command already auto- selects the only server on the account; extend the same symmetry to projects, and when there are multiple, list them in the error so agents can self-correct on retry without a separate `dhq projects list` call. - New resolveDeployProject helper: returns the configured project if set, otherwise calls ListProjects. 1 project → auto-pick with a Status line. 0 → tell the user to create one. >1 → UserError whose Hint enumerates Identifier (Name) pairs. - "No project specified" stays as the headline string in every error path so the existing Mixpanel failure bucket stays continuous after the fix lands. - Five unit tests cover configured short-circuit, lone-project pick, multi-project listing, zero-project hint, and the headline-preserved API-error path. - Update the deploy command's Long description so the auto-pick is discoverable from `dhq deploy --help`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
Disabled knowledge base sources:
WalkthroughThis PR adds automatic project selection to the ChangesDeploy Project Auto-Resolution
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…project # Conflicts: # internal/commands/deploy_test.go
Summary
dhq deployrequires--project(orDEPLOYHQ_PROJECT/.deployhq.toml), and Mixpanel shows "No project specified" as a small but steady bucket — 19 hits / 30d, 4 of them on the current v0.18.2 release, split between humans and a claude-code agent. The fix mirrors whatdeployalready does for servers: when there's exactly one project on the account, just use it. When there are multiple, the error now enumerates them so agents can self-correct on retry.internal/commands/deploy.go— newresolveDeployProjecthelper: configured short-circuit, single-project auto-pick (with aStatusline on stderr), zero-project hint pointing at project creation, multi-project error whose Hint listsIdentifier (Name)pairs. The deploy command now resolves the project through this helper instead ofRequireProject, but only when--projectis missing — the configured path costs zero API calls. Long description updated so it's discoverable from--help.internal/commands/deploy_test.go— five unit tests: configured short-circuit (no API hits), lone-project pick, multi-project listing, zero-project hint, and an API-error path that asserts on the first line oferr.Error()to keep the "No project specified" headline continuous in the existing Mixpanel bucket.Why scope to deploy specifically
RequireProjectis called from many list/show commands; firingListProjectsfrom every one of them on a stale config would balloon API traffic. The data showed pain only ondeploy, where the user clearly wants one project, so the auto-pick lives there and other commands keep their existing fast-fail behaviour.Test plan
go test ./...— all packages greengolangci-lint run ./...— 0 issues🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Tests