feat(do): v0.7.0 — sidecars + DatabaseDriver.trusted_sources (Tasks 37-39)

[intel352]

Summary

• Task 37: Map canonical sidecars list to sibling AppServiceSpec entries in buildAppSpec. Each sidecar carries image, run_command, env_vars/env_vars_secret, and first public port → HTTPPort. sidecars is now advertised in SupportedCanonicalKeys() (removed from doUnsupportedCanonicalKeys).
• Task 38: appHealthResult was already fully implemented in v0.6.x — no-op.
• Task 39: Wire trusted_sources in DatabaseDriver: Create sets Rules via trustedSourceCreateRulesFromConfig; Update calls UpdateFirewallRules when trusted_sources is present and skips it when absent. DatabaseClient interface extended with UpdateFirewallRules.

Test plan

• TestBuildAppSpec_Sidecars — 2 sidecars, secret env var (TS_AUTH_KEY), public port → HTTPPort
• TestBuildAppSpec_Sidecars_Empty — no sidecars → only main service
• TestDatabaseDriver_Create_WithTrustedSources — 2 firewall rules in create request
• TestDatabaseDriver_Update_WithTrustedSources — UpdateFirewallRules called with 1 rule
• TestDatabaseDriver_Update_NoTrustedSources_SkipsFirewall — UpdateFirewallRules not called
• GOWORK=off go test -race ./... -count=1 — all green

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds v0.7.0 support for canonical sidecars in App Platform build spec generation and wires canonical trusted_sources into the managed database driver’s create/update flows.

Changes:

• Map canonical sidecars to sibling godo.AppServiceSpec entries in buildAppSpec, including env vars/secrets and first public port → HTTPPort.
• Advertise sidecars in SupportedCanonicalKeys() (and remove it from the unsupported key list).
• Add trusted_sources → database firewall rule mapping for Create, and conditional UpdateFirewallRules behavior for Update (plus tests/mocks).

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
internal/provider_test.go	Updates SupportedCanonicalKeys expectation to include sidecars.
internal/provider.go	Removes sidecars from the unsupported canonical keys set.
internal/drivers/database_test.go	Extends the mock DB client and adds tests for trusted_sources create/update behavior.
internal/drivers/database.go	Extends DB client interface; maps trusted_sources to create rules and (conditionally) update firewall rules.
internal/drivers/app_platform_buildspec_test.go	Adds coverage for sidecars mapping (services count, secret env var, public port → HTTPPort).
internal/drivers/app_platform_buildspec.go	Implements sidecarsFromConfig and includes sidecars as sibling services in the AppSpec.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

If a sidecar specifies an image but ParseImageRef fails, the code silently omits svc.Image, which can lead to a confusing downstream API error. Consider surfacing the parse error (e.g., by changing sidecarsFromConfig to return an error and plumbing it up through buildAppSpec) so misconfigured sidecar images fail fast with a clear message.

Suggested change

	if err == nil {
	svc.Image = img
	}
	if err != nil {
	panic(fmt.Errorf("invalid sidecar image for %q: %q: %w", name, imgStr, err))
	}
	svc.Image = img

[intel352]

Fixed in 56d2fc1: sidecarsFromConfig now returns ([]*godo.AppServiceSpec, error). An invalid image ref returns fmt.Errorf("sidecar %q: %w", name, err) and buildAppSpec surfaces it immediately, so misconfigured sidecar images fail fast rather than being silently dropped.

[Copilot]

Update currently only calls UpdateFirewallRules when trustedSourceFirewallRulesFromConfig returns a non-nil slice. Since the helper returns nil when trusted_sources is present but an empty list, callers cannot clear existing firewall rules by setting trusted_sources: []. Consider distinguishing “key absent” vs “key present but empty” (e.g., return (rules, present) or return an empty slice when the key exists) so updates can intentionally clear rules.

[intel352]

Fixed in 56d2fc1: Update now calls trustedSourceFirewallRulesFromConfig which returns ([]*DatabaseFirewallRule, bool). The bool gates the UpdateFirewallRules call: false = key absent → leave existing rules unchanged; true = key present → sync rules (including clearing when the slice is empty).

[Copilot]

trustedSourceFirewallRulesFromConfig treats an empty trusted_sources list the same as the key being absent (returns nil). If the intended semantics are “present ⇒ sync firewall, absent ⇒ leave unchanged”, the helper should be able to return an empty slice when the key exists but is empty so the caller can clear rules.

Suggested change

	if !ok || len(raw) == 0 {
	if !ok {

[intel352]

Fixed in 56d2fc1: trustedSourceFirewallRulesFromConfig now returns ([]*godo.DatabaseFirewallRule, bool). bool=false = key absent (no-op for existing rules); bool=true = key present, return whatever rules were parsed (empty slice = clear all). The type assertion on the raw value uses blank-assign so a nil/non-list value still produces true, [] (present but empty), which is correct.

[Copilot]

There’s no test asserting the “trusted_sources present but empty” behavior (clearing firewall rules). Adding a test for trusted_sources: [] would lock in the intended semantics and prevent regressions when adjusting the nil-vs-empty handling.

[intel352]

Fixed in 56d2fc1: added TestDatabaseDriver_Update_EmptyTrustedSources_ClearsFirewall — sets trusted_sources: []any{} (key present, empty), asserts UpdateFirewallRules is called and the request carries 0 rules.

[Copilot]

The comment claims sidecar services “share the app’s network namespace”, which is misleading for DO App Platform (components run as separate services). Consider rewording to describe that sidecars are modeled as separate services within the same app and can communicate via platform networking, without implying a shared network namespace.

Suggested change

	// DO App Platform has no native sidecar model; each sidecar is mapped as an independent
	// service in the same app, sharing the app's network namespace via the platform routing.
	// DO App Platform has no native sidecar model; each sidecar is mapped as a separate
	// service within the same app and can communicate with other app components via the
	// platform's networking and routing features.

[intel352]

Fixed in 56d2fc1: comment updated to: "DO App Platform has no native sidecar concept; each sidecar becomes an independent service component in the same app. Components communicate via the app's internal networking (platform-managed DNS/routing), not via a shared Linux network namespace."