Managing SonarCloud Configuration with GitOps and Kubernetes

SonarQube Cloud
1

At our company, we rely on Infrastructure as Code using GitOps, primarily with FluxCD and Crossplane. I wanted to extend this approach to manage SonarCloud configurations, enabling developers to configure SonarCloud via pull requests, without needing admin access to the SonarCloud platform.

To achieve this, I set out to create a Kubernetes operator that interacts with SonarCloud’s API, allowing configuration management entirely through Kubernetes manifests.

Given that we are a .NET-focused company, I initially looked for a .NET library to interface with the SonarCloud API, but I found none. As a result, I developed a custom library, which you can find here: SonarCloud.NET.

During the development process, I encountered some inconsistencies in the SonarCloud API. Would this be the right forum to raise these issues, or is there another recommended channel for addressing them?

1 Like
2

Hi,

Welcome to the community and thanks for your contribution to the overall ecosystem!

This is as good a place as any to raise the API inconsistencies, although I can’t promise what will happen. The APIs were developed over time (with evolving sensibilities) to service our own needs in the product, rather than as an overt attempt to publish or expose anything.

But what are you seeing?

 
Thx,
Ann

4

I understand that these discrepancies can arise over time, and I don’t expect immediate resolution.

Typically, APIs that handle pagination include a paging property at the root level, alongside a separate property containing an array of the results. For example:

{
  "paging": {
    "pageIndex": 1,
    "pageSize": 100,
    "total": 2
  },
  "groups": []
}

However, the api/user_groups/users endpoint does not fully conform to this pattern. Instead, it includes the paging elements at the root level, but with a different structure. For example:

{
  "users": [],
  "p": 1,
  "ps": 25,
  "total": 2
}
1 Like
5

Hi,

That’s a good one. In fact, on the SonarQube side (and I expect this to make its way to SonarCloud at some point soon-ish) we’ve kinda started over, beginning with user-related APIs. You should be able to expect more consistency going forward there.

Are there any other particular pain points?

 
Ann

1 Like
6

I confirm that moving forward, all new paginated endpoints will include the following pagination data:

  "page": {
    "pageIndex": "integer (int32)",
    "pageSize": "integer (int32)",
    "total": "integer (int32)"
  }
1 Like
7

there is also an inconsistency in the naming conventions, with a mix of snake_case and camelCase being used for property names.

1 Like