fix: deploy hygiene (validate-before-persist, env filter, honest badge, real hostname) — CashPilot-Desktop-ada - #99
Conversation
…ge, real hostname (CashPilot-Desktop-ada) Four pre-existing latents from the PR #96 review: 1. DeployService persisted credentials BEFORE validation, so a rejected deploy left invalid/blank creds lingering (and lighting the 'Configured' badge for a service that could never start). Validate via the new Manager.ValidateCredentials first; persist only if it passes. 2. buildEnv copied every stored-cred key into the container env unfiltered. Restrict to catalog-declared keys so an orphaned pre-migration key can't leak into a container. (The native twin keeps its documented passthrough.) 3. The 'Configured' badge was len(creds)>0, so an orphaned old-key blob read as configured though a deploy would fail. Key it off the current required fields via Manager.RequiredCredentialsMet. 4. An unedited deploy form resubmitted the raw 'cashpilot-{hostname}' default as an override, which buildEnv only substituted on defaults (and to the literal 'desktop') — producing a device literally named cashpilot-{hostname}. Expand {hostname} to the real host on defaults AND overrides (both runtimes), and surface AppState.hostname so the form renders the real value. Tests: buildEnv filter+hostname, ValidateCredentials/RequiredCredentialsMet, DeployService validate-before-persist. go test -race + vet + gofmt clean, tsc clean.
|
@coderabbitai review |
|
Warning Review limit reached
Next review available in: 10 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (9)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Action performedReview finished.
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #99 +/- ##
==========================================
+ Coverage 75.03% 75.15% +0.12%
==========================================
Files 14 14
Lines 3433 3454 +21
==========================================
+ Hits 2576 2596 +20
- Misses 669 670 +1
Partials 188 188
🚀 New features to boost your workflow:
|
Four pre-existing low-severity latents from the PR #96 review panel.
1. Validate before persisting credentials (
app.goDeployService)Creds were saved before
manager.Deploy's validation, so a rejected deploy left invalid/blank creds lingering — they can never deploy, yet they linger and light the "Configured" badge. Now validates via a newManager.ValidateCredentials(mirroring Deploy's known/deployable/required gates) and persists only on success.2. Filter container env to catalog-declared keys (
runtime.gobuildEnv)buildEnvcopied every stored-cred key into the container env unfiltered, so an orphaned pre-migration key (e.g.USER_ID/DEVICE_NAME) could leak into a running container. Now only catalog-declared keys pass. (The nativebuildNativeEnvkeeps its documented passthrough — its test asserts an undeclared override survives — so that path is out of scope.)3. Honest "Configured" badge (
app.gosettings)The badge was
len(creds) > 0, so an orphaned old-key blob showed Configured although a deploy would fail until re-entry. Now keyed off the current required fields viaManager.RequiredCredentialsMet(credsConfigured= has creds and they satisfy the required schema).4. Real hostname instead of the literal
{hostname}(both runtimes + form)An unedited deploy form resubmitted the raw
cashpilot-{hostname}default as an override;buildEnvonly substituted{hostname}on defaults (and to the literal"desktop"), so a container was literally namedcashpilot-{hostname}. Now{hostname}expands to the real host (DeviceHostname()) on defaults and overrides in both the Docker and native paths, andAppState.hostnamelets the form render the real value up front.Tests
runtime:buildEnvdrops an undeclared override and expands{hostname}on an override.services:ValidateCredentials(unknown/manual/missing/valid) +RequiredCredentialsMet(orphaned blob → false).app:DeployServicerejects an invalid blob and persists nothing.go test -race ./...,go vet,gofmtclean; frontendtscclean.Closes bead CashPilot-Desktop-ada.