Issue with GitHub checks for repo with 2 SQ analysis

SonarQube 10.7 Developer edition in Docker

Context
One of our GitHub repository contains 2 parts of a project:

  • C code for FW
  • python code for Client

Jenkins is performing build and run SQ analysis.

Each part has its own SonarQube project, to avoid mixing different langages and help relevant team focusing.
For each SQ project, we have configured the DevOps platform integration targeting the same GitHub repository.

Issue
Only one GitHub check is made available on GitHub side (PR/branch analysis), the latest to finish.

GitHub check context name is hardcoded to SonarQube Code Analysis, and it seems it is not possible to publish different checks with same context (ie. check is updated instead of created).

How can we properly show the 2 SQ analysis using GitHub check?

For the record, the open-source SQ Community branch plugin does use the SQ project name as part of the check name, so it is able to differentiate several SQ analysis for a same commit.

Hi,

You’ve said you’re using Developer Edition, but also mentioned the Community-branch plugin. To be clear, we don’t support that plugin here.

And unfortunately, Developer Edition doesn’t support the functionality you’re after. What you want is monorepo support, which starts in Enterprise Edition($$).

 
HTH,
Ann

Hello G Ann, thanks for your answer

Why not having an option to configure, in the DevOps Platform integration page, the name of the SQ check?
This is a GitHub API data, that is currently hardcoded in the SonarQube source code but could be made configurable easily from the SQ WebUI or API…

This is a bit disappointing to need to upgrade to a more expensive offer, to use the complete mono-repo project type that we don’t actually need.

About the mention of Community-branch plugin, it was just to highlight that it is barely few lines of code to get such feature available. :wink:

Hello

We would like to get added an extra configuration field for DevOps platform integration, allowing to override the default name SonarQube Code Analysis for the published commit status.

This seems like a reasonable feature to ask for, at least for the first subscription level (Developer Edition).

I tried creating an entry on the SonarQube roadmap, but it is not showing up (tried twice actually :frowning: ).
Is this list reviewed internally before getting updated?

Hi,

We try to keep it to one topic per thread. Otherwise it can get messy, fast. Please create a new thread for this with all the details.

 
Thx,
Ann

Hello
i don’t understand your message, i’m the topic creator, and i’m just explaining why we would like such feature in the application.
For such purpose, i tried creating an “idea” on SQ roadmap website but it is not yet showing
That’s it, no mess, no new thread needed.
Regards

Hi,

The initial post in this thread was about monorepo support.

I don’t understand how this is related to it:

 
Ann

Hi

initial question was not about monorepo support, but about the capability to specify the name of DevOps platform commit check in the application to differentiate 2 SQ analysis on same commit.

You told this requires the monorepo support, which is an Enterprise edition only feature (!!!).

Having to upgrade to Enterprise edition just to get this obvious capability is a real surprise.

It is just a matter of configuring the commit check name using DevOps platform API.
This is a feature available for each major DevOps platform APIs supported by SQ, and it just need to be exposed from SQ, which is not the case actually. Come on…

So in the end i’m trying to capture this request in the SQ product roadmap website, to gain some visibility if other users are interested in this feature.

Because, as SQ team explained recently:

  1. You, our customers, are at the center of everything we do.
  2. Real solutions to improve developers’ experiences.

Edit
Just checked, and in fact it is specified in documentation that only Enterprise Edition has
feature to customize the name of the commit check…
So sad such obvious feature (simple string API field…) is hidden behind a paywall :disappointed_relieved: