Crossplane Contrib - Provider SonarQube
Crossplane SonarQube provider, enabling platform teams to manage SonarQube resources through Kubernetes-native workflows.
From Manual Governance to Control Plane Resource
I started provider-sonarqube to solve a repeated platform pain point: SonarQube governance was often split between manual UI operations and disconnected scripts. The project brings that operational surface into Kubernetes resources so policy can be managed as code with review and traceability.
What I Own in This Project
As founder, owner, and maintainer, I drive both product direction and execution:
- Resource/API design decisions
- Milestone planning and prioritization
- Implementation and review standards
- Release quality, testing posture, and maintenance strategy
This is not only feature delivery; it is ongoing platform product ownership.
Roadmap Structure I Use
Work is planned in milestone tracks so delivery and hardening can progress together:
- Terraform Provider 1 to 1 Capabilities
- Production Readiness
- SonarQube Client Go Improvements
- Features Beyond Terraform
That structure keeps near-term releases focused while preserving medium-term project direction.
Delivered Value So Far
- Shipped core resource domains: Quality Profiles, Settings, Projects, and Rules.
- Enabled GitOps-based quality policy management for platform teams.
- Added stronger engineering guardrails with improved testing, linting, and release automation.
- Kept the project maintainable as scope expanded.
Managed Resources in the Provider
The provider currently supports the following SonarQube managed resources:
- Projects
- QualityGates
- QualityProfiles
- Rules
- Settings
It also includes Crossplane provider connection resources for operations:
- ProviderConfig and ClusterProviderConfig (plus their usage resources)
Engineering Notes
The key technical approach was to model resources around operator workflows, not raw endpoint shape. That improved reconciliation predictability and made provider behavior easier to reason about in production.
Community Signals
Star History
Contributors
Technologies Used
| Icon | Technology | How it was used |
|---|---|---|
 | Go | Provider implementation across API, client, controller, and test layers |
 | Kubernetes | CRD API surface and reconciliation runtime |
 | Crossplane | Managed resource patterns and control plane abstractions |
 | SonarQube | Quality governance domain modeled as declarative infrastructure |
Project History
Founded the Project and Technical Direction
Bootstrapped provider-sonarqube from zero and defined the roadmap around real platform operations needs. Established the architecture, contribution model, and quality baseline for future contributors.
Delivered Core SonarQube Resource Coverage
Shipped support for Quality Profiles, Settings, and Projects to cover the highest-value SonarQube admin workflows. This gave teams immediate leverage to manage quality policy through Kubernetes and GitOps.
Raised Engineering Quality and Release Maturity
Hardened linting standards, expanded test coverage, and introduced release changelog automation. This improved maintainability and reduced risk as the provider surface area grew.
Expanded Policy-Level Capability
Added Rules support to move policy management deeper into declarative workflows. In parallel, improved dependency automation to keep the project healthy without maintenance drag.
Project Details
- Role
- Owner & Maintainer
- Client
- Platform teams operating SonarQube
- Duration
- 4 months
- Published
