feat(local): add hops local listmonk provider bootstrap#51
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThis PR adds a new Listmonk provider command with credential resolution, Kubernetes manifest orchestration, and CRD polling. It integrates the command into the local subcommand dispatcher and updates Zitadel to require an explicit source_context argument instead of using a default. ChangesListmonk Provider Command
Zitadel Refinement
Possibly related PRs
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Mirrors `hops local zitadel` / `hops local github`. Bootstraps the
hops-ops/provider-listmonk Crossplane provider + a cluster-scoped
ProviderConfig pointing at a Listmonk instance via Basic-Auth
credentials (JSON Secret).
Credential resolution waterfall:
1. Explicit --endpoint / --username / --token flags
2. LISTMONK_{ENDPOINT,USERNAME,TOKEN} env vars
3. Read from the chart-bootstrapped Secret on a source cluster
(with keys `username` + `token` — the shape produced by
listmonk-chart v0.2.0's post-install api-user-bootstrap hook)
Endpoint is derived from the source Secret name when not explicitly
set: `<release>-provider-creds` → in-cluster service
`http://<release>.<source-namespace>.svc.cluster.local:9000`.
Default upjet provider package: ghcr.io/hops-ops/provider-listmonk:v0.0.3.
Also drops the `pat-local` default from `--source-context` on BOTH
this command and `hops local zitadel` — that hardcoded value bakes
the implementer's personal cluster name into a tool meant for
multiple users. Required positional flag now; users explicitly pass
their own source context.
Verified end-to-end on pat-local 2026-05-25:
- Provider install + Healthy
- ProviderConfig applied
- UserRole MR reconciled (Crossplane → upjet → TF provider →
Listmonk REST API → users / roles table)
- User MR reconciled with cross-resource userRoleIdRef → numeric
userRoleId (typed-reference resolution works end-to-end)
- AppSettings MR reconciled (no-op write of current values; round-
trip lossless)
8e7adcd to
35c4563
Compare
Summary
Mirrors
hops local zitadel/hops local github. Bootstraps thehops-ops/provider-listmonk Crossplane provider + a cluster-scoped
ProviderConfig pointing at a Listmonk instance via Basic-Auth
credentials (JSON Secret).
Credential waterfall
--endpoint/--username/--tokenLISTMONK_{ENDPOINT,USERNAME,TOKEN}env vars(default
pat-local/marketing/marketing-listmonk-provider-credswith keys
username+token— the exact shape produced bylistmonk-chart v0.2.0's post-install api-user-bootstrap hook).
Endpoint derivation
When
--endpointis not explicitly set:<release>-provider-creds→ release
<release>→ in-clusterhttp://<release>.<ns>.svc.cluster.local:9000).Test plan
cargo test --bin hops-cli— 3 new unit tests pass(credentials shape, ProviderConfig YAML uses cluster-scoped
apiVersion, Provider YAML uses v0.0.3 package default)
cargo buildclean./target/debug/hops-cli local listmonk --helprenders cleanly→ Provider Healthy → ProviderConfig Ready → UserRole MR
reconciles → DB row created.
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Breaking Changes
source_contextparameter for the Zitadel command is now required and must be explicitly provided (no default value).