feat(local): label hops provider install resources so doctor distinguishes intentional installs

[patrickleet]

Summary

Follow-up to #53. hops local doctor flagged a custom-installed provider (e.g. hops provider install --repo jonasz-lasut/provider-helm, a fork built from source) as "drift" because it uses the <provider>-runtime DRC convention rather than the bootstrap local-dev-<provider> DRC. That's an intentional install, not drift — doctor just had no way to tell.

This labels what hops provider install creates so doctor can distinguish intent.

Changes

• hops provider install now stamps app.kubernetes.io/managed-by: hops-provider-install on the Provider, DeploymentRuntimeConfig, and ClusterRoleBinding it manages (shared consts in local/mod.rs).
• hops local doctor reads that label:
  • labeled → custom-install mode: checks the install convention (<provider>-runtime DRC, <provider>-cluster-admin binding, SA <provider>) and reports install mode — custom install via hops provider install (package: …)
  • unlabeled → bootstrap mode: the local-dev-<provider> convention (unchanged)
  • either way it still verifies cluster-admin, and still flags real drift (runtimeConfigRef=default / missing cluster-admin) in both modes.

Verification

• cargo build clean · cargo test 86 passed (incl. new label assertions on the 3 build_* YAML builders) · new code clippy-clean
• Live on colima: provider-kubernetes → install mode — bootstrap (all ✓); a labeled provider-helm → install mode — custom install via hops provider install (package: …provider-helm:v1.999.1) (all ✓); the previously-false drift is gone, exit 0
• Adversarial review (3 lenses + verify): no findings — real drift still caught, name derivation matches apply_provider_resources, label plumbing sound

Existing custom installs predating this are unlabeled; a re-run of hops provider install labels them (or kubectl label once).

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@patrickleet, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 7 minutes and 19 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 9cec50e5-fc50-44df-b2da-4c51205c63c5

📥 Commits

Reviewing files that changed from the base of the PR and between 25d5f5f and db0dab1.

📒 Files selected for processing (3)

• src/commands/local/doctor.rs
• src/commands/local/mod.rs
• src/commands/provider/install.rs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/provider-install-labels

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}