GitHub Pull Request Review


(Gabe Levasseur) #1

My team would like the ability for SonarCloud to set status on GitHub depending on the Quality Gate and percent of test coverage on new code.

I saw the ticket for test coverage on new code has been completed (https://jira.sonarsource.com/browse/MMF-1118).

Based on this information we would like to set a success or failure status on sha’s (https://developer.github.com/v3/repos/statuses/) based on configurations we set.

As an example, if test coverage on new code is less than 90% set a failure status, or if overall test coverage drops by 1.0% with the addition of the new code, set a failure status. Similar functionality for Quality Gate scores, number of bugs, etc.


(Frédéric Drouet) #2

We are also interested for such capability but for on-premise (publicly reachable) SonarQube deployment


(G Ann Campbell) #3

Hi,

We would like this (internally) as well. And we plan to get there. You can watch this ticket to follow our progress:

MMF-1369 - Real Quality Gates for PRs and short-lived branches

 
Ann


Quality Gate + Short Lived Branches
(Gabe Levasseur) #4

Awesome thank you G Ann.

Is there any way for use to subscribe to you’re issues and automatically get notified when they are being worked on or complete?


(G Ann Campbell) #5

Hi,

You should be able to create an account on our Jira instance. It won’t give you a lot of permissions, but you will be able to vote for and watch issues, and receive update notifications on your watched issues.

 
:slight_smile:
Ann


(Christophe Lévis) #6

Hi @gabel0287 @fdrouet,

I’d be happy to get your thoughts on the topic.

In your case, when would you expect the Pull Request status to be in failure: when the test coverage / the quality of the code added with the PR is not good enough to be merged, or when the Quality Gate of the upstream branch would be red if the PR is merged?

If you are in the first case, would you like the Quality Gate to apply under the same conditions as those defined for the upstream branch?

Christophe


(Frédéric Drouet) #7

Hello Chris

In our case, we want to check the added code is good enough to be merged so it is case number 1.

I do not have completely clear ideas on this point but I currently think that it can be all the rules or a subset.

Fred


(Gabe Levasseur) #8

Hi Christophe,

Ideally there would be the option to configure the Pull Request to fail under both scenarios. Also, in both scenarios the Quality Gate would apply the same conditions as the upstream branch as you suggested.

I would like to be able to configure the state to fail if percent of new code covered by tests is less than 90% or if overall test coverage of the entire repo doesn’t increase by 2% for example.

I see two use cases, the first one is to keep code coverage high an a code base where it is already high and the second one is to encourage gradual increase of test coverage for a code base where it is low.


(Christophe Lévis) #9

Thanks for sharing your thoughts.